【ソフトウェア開発】HIPOと言う設計書
んー、寒暖差が大きくなってそれでいて空気が乾燥する季節。
一番苦手かも知れません。
・鼻炎
・気管支炎
・風邪／偏頭痛
が頻発し、朝起きた時からライフはもうオレンジで始まるすがすがしい一日。そんな縛りプレイでスタートするステージがたまりません。いつ、次のように言われるのかハラハラしています。
HIPO（ハイポ）
開発を実際に行っている方の中にはHIPO（ハイポ）と言うコトバを聞いたことがある人もいるかもしれません。なんかタバコの代替品みたいな名前ですが、特に関係はありません。HIPOと言うコトバを知らなくても、実際にその手法を用いた設計書を見た、あるいは作ったことがある人もいるのではないでしょうか（多くは３０代後半以上かもしれませんが）。
それ以前に、基本情報技術者試験でもたまに出題されるのでそこから知った人もいるかもしれません。
HIPOとは、Hierarchy plus Input Process Outputの略で、日本語では、
"階層的入力処理出力"
と言います（ここで言う"階層的"とは、ヒエラルキーが意味するようにピラミッド構造の階層を指します）。この手法を利用した設計書が、HIPO図とIPO図です。
しかし、正式名称を見てもわかるように、HIPOは本来「階層化」「構造化」された言語に対してプロセス（処理）概念を詳細化するために用いるもので、1970年代に流行した考え方です。
「COBOL」「FORTRAN」「BASIC」「PL/I」「アセンブラ」などは、この構造化の考え方に非常に当てはまりやすく、「C言語」なども70～90年代の頃はこの流れに沿って設計されていました（goto文を使用しないことが前提ですが）。
オブジェクト指向とは相容れない
しかし実はこれ、オブジェクト指向言語や関数型言語には本来向いていません。…表現できないわけではないんですけどね。でも相当面倒になると思います。
いえ、オブジェクト指向言語であってもほとんどオブジェクト指向を取り入れていない場合は問題ないかもしれません。オブジェクト指向言語や関数型言語が向いていないのはそれらの言語のベースとなる考え方と合わないだけですから、言語を用いていても考え方自体が古いままであればあまり影響はありません。
逆に、影響をほとんど感じない場合は「あ、全然オブジェクト指向（関数型志向）が理解できていないかもしれない」と思ったほうがいいでしょう。
本当に正しくオブジェクト指向化されたプログラムは、特定の処理などを意識せず、すべてが汎用的な部品の集合体として存在しているため、固有処理の実現のために作られた奇麗なピラミッド構造が成立しないからです。そうでなくても、アノテーションなどの登場で、普通にプログラムを読み解くのも難しくなってきました。ただ羅列されたプログラムを順次に読めばいいというわけではなくなっているのです。
けれども、古くから設計を積み重ねた方や大手SIerの前時代的な手法に慣らされた方など、未だに年輩設計者の多くがおそらくは盲目的にこの設計手法を用いているように見受けられます（50代…でも怪しいかな？60代には結構アタリがいるような…）。
この手法は、たとえばジョブ設計のように順次性が明確で、親から子、子から孫のプロセスを順に追っていく場合にはプログラム言語の種類に関わらず都合は悪くないのですが、それは本来の言語選定の主旨から外れます。
オブジェクト指向言語の本質は元来、一つひとつのクラスに込められた目的と意味を理解し、実体となるオブジェクトを部品として扱うクラスの「再利用性」にこそあるのだと思います。
今までの構造化言語で作られた関数を『パズルのピース』とするなら、オブジェクト指向言語で作られたクラスは『LEGOブロック』のようなものです。
すなわち、『パズルのピース』は決められた用途のためだけに作られたものですが、『LEGOブロック』は組み合わせ次第でどのようにも利用することができる汎用性の高い部品と言う位置づけです。
構造化言語とは根底からコンセプトが異なります。
オブジェクト指向はそもそも親プロセスから見るのではなく、システム全体を素因数分解して、１つ１つを最小単位の部品として俯瞰して見た場合に、
「どことどこには同じ部品が使えるか？」
「どの部品を、どう組み合わせると、どんな製品(部品)ができるのか？」
と言う視点が重要となってくる言語であり、思想です（これをOOA(オブジェクト指向分析）とかOOD（オブジェクト指向設計）と言います）。
よってオブジェクト指向言語に対してHIPOを導入すると、こうした言語特性との衝突によってその言語特性の恩恵を受けることができなくなるばかりでなく、オブジェクト指向特有のデメリットが強調され、納品直前に問題が顕在化することになりかねません。
とは言え、構造化言語においては相変わらず一線級の活躍が期待できる設計手法なので、要はプログラム言語だけでなく設計手法や設計書に対しても使いどころをきちんと見極めましょうと言うことです。
でなければ、ただ単にソフトウェア・アーキテクチャの選択肢を狭めるだけでなく、マネジメント活動の選択肢も限られてくるようになり、品質を低下させ、チームや会社、ひいてはユーザーにまで迷惑をかけることになりかねません。
まぁ、今となってはエンジニアの絶対数が未だに多いオブジェクト指向言語ですが、最先端を行くエンジニアから見ればもう「オワコン」と言われるかもしれませんね。
たまたまなのか、今いる企業内で使われている傾向はこのランキングに似ていて、C/C++が半数以上でダントツ、次いでJavaとC#が全社員の1/3ほどを占め、あとは軒並みどんぐりの背比べになっているかなぁ？と言う感じでした。
Angularなどを使った開発も大掛かりなものをしていたようなので、Javascriptに長けたチームもいるかもしれません。コンシューマー向けのWeb開発は現時点ではしていないと思うので、PHPやRubyの開発者は極端に少ないと思います。まぁ、あくまで私が今いる会社…の話ですが。
用途や特性を把握して使おう
なぜ、急にそんなことを言い出したかと言うと、「要件定義」工程だって言ってるのに、なぜか急にHIPOを書き出すあるエンジニアの方がいらっしゃったからです。
プロジェクトとして、先にWBS(Work Breakdown Structure)を定義し、成果物を決定しておかなくてはならなかったのでしょうが、それもせずいきなり設計書（？）、しかも本来であれば詳細設計等で用いられるような様式を書き出した方がいらっしゃったので、ここに書き留めておこうかと思った次第です。
業務を構造化し、フロー（アクティビティ図）を文章化し、input/outputをデータフローのように使う…ことも可能ではあるのでしょうが、正直、それはおススメしません。
上流、あるいは超上流と呼ばれる工程は「外部設計」とも呼ばれ、本来はユーザーの要求や要望、頭の中にあるイメージを明らかにするための工程で、最低条件として
ユーザーが理解できるものでなくてはならない
からです。何よりも読み手のための資料でなくてはなりません。少なくとも、書き手の自己満足であってはならないのです。当然、そのエンジニアにとって「得意か、不得意か」と言うのも関係ありません。この工程で作成されるoutput は『お客さまファースト』になりきらなければなりません（言いなりになるということじゃないよ？）。
ユーザーとイメージを共有できるようにするためには、小難しい文章を必要最低限度に抑え、図表で伝えられるようにするのが一番です。プレゼンなどの資料でも、文章ではなくグラフや絵を多用するのはそのためです。
残念ながら、HIPOでそうした要求を満たすだけの資料を作成する方がよほど面倒です（「できない」とは言ってない）。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。