【ソフトウェア開発】全体像を見る目を養う大切さ
とかく、ソフトウェア開発と言うと
要件定義
プログラミング
テスト
主にこの３つしか、テーマにされていないのをよく見かけます（あくまでよく見かけるだけで、全てとは言わない）。しかも、非常に多いんです。それがわたしにはどうにも悔しい。悲しい！我慢できない！！
…。
……(:3_ヽ)_
………_(┐「ε:)_ｺﾞﾛﾝ
嘘つきました。別に今まで我慢してきたのでそんな言うほどじゃないです。
でも、この３点ばかりが取り上げられる傾向が強い昨今のソフトウェア開発系ＩＴ業界には、ちょっと暗雲が立ち込めている気がしてなりません。
ソフトウェア開発はある工程（フェーズ）だけに焦点を当てれば、成功するようなそんな適当なものではありません。点と点をつなげて『線』にしなければまともな開発になんてなりませんし、その線も「アプリケーション」だけでなく「ハードウェア」「ネットワーク」「マネジメント」「アーキテクチャ」など様々な線とつなげて『面』にしなければ最終的な集合体である
システム
にすることなんて到底夢のまた夢です。まぁ、夢は夢のままにしておこうとする人が多いから、ﾁｮｲﾁｮｲあちこちでトラブルを起こしているんですけど。
とりあえずソフトウェア開発の中だけに閉じた場合、どうしても気になるのが「設計」という工程に対してあまり着目されていません。
ですが、
プロダクトの品質（つまり、アプリケーションの品質）
は主に設計で決まります。設計は実現する内容（機能と言います）とその具体的手段を決める工程…今どきで言うとフェーズだからです。
ＩＴ関係ないけど、もうこの書籍のタイトル通り。
まぁ実際にはそれ"だけ"ではダメですけどね。Ｂ２Ｂの受注生産がメインであるソフトウェア開発の場合「品質（Q）」だけを見ててもダメで、「コスト（C）」や「期限（D）」を放置していいわけではありませんから、少なくとも『マネジメント』の品質も高くないとプロジェクト自体は破たんします。
ですが、プロダクトだけに焦点を当てればやはり『設計』こそが全ての源流となるのは確かです。
要件定義は、厳密にはプロダクトの品質に直接影響することはありません。まったく影響しないのではなく、直接的にかかわることが無いのです。影響が出るケースがあるのは、
要件定義中に設計まがいのことをしようとしてる
要件定義として検討すべきテーマ自体が全然足りてない
基本設計の際に要件定義をインプットとして使いこなせていない
のいずれかかが原因となっているからであって、要件定義そのものがプロダクト品質に影響を与えているわけではなく、どちらかというとマネジメントがあまりにもおろそかになっていることが問題なのでしょう。
これを理解していない人は、おそらく「ソフトウェア品質（ISO 25010）」を理解されていないのではないでしょうか。プロダクト品質とは、このソフトウェア品質の定義の中で言うところの『内部品質』『外部品質（主にこちらの意味合いが強い）』となります。
では、要件定義が保証する品質はというと、それは
利用時の品質
です。もちろん、設計工程なかでも要件定義と密接にかかわる基本設計あるいは外部設計と呼ばれている設計は、この『利用時の品質』に深くかかわるものもあります。ですが、それを差し引いても要件定義はこの『利用時の品質』の柱を決定する重要なフェーズであるのは言うまでもありません。
各企業、各エンジニアがどう思っているのか、ＩＳＯの定義がどう考えているのか、そういうのはとりあえず後回しにして、私の目から見て多くのプロジェクトチームでは『ソフトウェア品質』のことを理解していないがゆえに、このような領域でプロジェクトが進んでいることがままあります。
ちょっと歪（いびつ）にみえますよね。
そう、基本設計工程だけ色々な思惑や事情が渦巻いて、やたらと複雑になっているのです。特に『利用時の品質』にかかる部分は、お客さまのＩＴリテラシーの低さと、社内調整の遅れによって、私たちがよく言う「仕様」を確定するのに時間がかかる…と言う不可逆な事情によってどうしてもこうならざるを得ません。
基本設計工程では「何を」「何の機能を」作るかについて多くが語られる工程でもあります。お客さまから見ればやっと具体的なソフトウェア像を拝める工程でもあるのです。
そのため、お客さまがお客さま自身の要望を客観視できるようになるのはこの工程なのです。建築でも『基本設計』と言いますが、家の全体像をデザイン図にしたり、模型を作ったり、間取りを決めたり…あるいは内装の選定をしますよね。
そのため、要件定義だけでお客さまのニーズのすべてを洗い出すことは難しく、設計しながらお客さまの具体的なあるいは細部まで仕様を詰めることになるのです。
また、基本設計には大別すると
・方式設計（アーキテクチャ設計）
・機能設計（アプリケーション設計）
の２つがあります（細かく言えばもっと色々ありますけど、ここではプログラミングのための設計だけに焦点を当てます）。ソフトウェアの線の要になりますが、アプリケーション以外の設計も並行して進んでいてハードウェアの、ネットワークの、ミドルウェアの、運用保守の、データ移行の、etc.…さまざまな設計とも連携しなければ作るべきアプリケーション像も定まりません。
そう、まさにシステムの全体像をここで俯瞰したマネジメントができなければ設計工程は失敗します。設計が失敗すれば、当然できあがるアプリケーションもどこか失敗しています。大きな失敗か／小さな失敗かはともかく、必ずあとで修正を余儀なくされることでしょう。
この中の『機能設計』は、大雑把な機能から具体的な処理の単位に分解しなければならなかったり、条件によってどのような結果になるのかを明示しなければなりませんから、どうしても「プログラムでできること」をイメージしながら設計せねばならず詳細設計の観点に片足突っ込んでしまうことが往々にして起こります。
だからこそ、基本設計は非常に難易度が高く、
「お客さまが理解できる成果物作成が問われる」
「この設計次第でプロダクトの出来が決まる」
「詳細設計の観点を含むため、詳細設計不要論が持ち上がる」
という側面を持っていたりします。
少し脱線しましたが、このように設計工程…なかでもひときわ重要となるのが『基本設計』工程となるであろうことは嫌でもわかるかと思います。日本では…なかでも古くから存在する比較的スタンダードなソフトウェア開発においては、この設計に品質の様々なエッセンスを集約してしまっているのが実情です。
ですが、そんな大事な設計工程に対して触れられているサイト、ブログ、書籍等は数えるほどしかありません。部分的なノウハウや「基本設計とは？」「ほかの工程との違いとは？」と言った概要レベルに近い話はサイトであればいくらでもあります。しかし、その肝心な基本設計の核心に迫る情報はほとんど出てこないのです。
…まぁ、そうなる理由もわからなくもありません。
機能に関わる重要な部分ですが、「機能」と一口に言っても分野、領域ごとに大きく異なります。色々な切り口がありますが、
「画面」「帳票」「バッチ」
とか、
「業務系」「制御系」「監視系」「組込み系」
とか、仮に同じプログラム言語を使ってもその背景にあるアーキテクチャが全く異なるために、まったく同じ設計観点では開発できないケースが多々あります。そのため「〇〇系」に特化してしか基本設計は語れないのが一般です。そのせいで「基本設計はこうだ！」と断言するのが難しいのかもしれません。
また、日本の多くのエンジニアのキャリアパスは
としているところが非常に多いようです。このモデルは、15～20年ほど前に流行った『エンジニア35歳定年説』を確立したベースモデルでもあります。このモデル自体は30年以上前からあったんじゃないでしょうか。
真っ当にソフトウェア開発に長けてくれば、だいたい35歳くらいでエンジニアリングから離れ、マネージャーや管理職への道に進んでしまって開発する機会はなくなってしまう（=エンジニアとしては終わる）と言われたものです。そうなると、自分のいる会社が倒産等してしまった時に手に職がない状態で、転職が難しくなるなどの弊害が多くありました。当時はブラックも普通にまかり通っていて、ＩＴ企業の興亡は激しかったですからね。
ブラック偏差値『四天王』と呼ばれたソフトウェア興業が倒産したと言うのは、当時を知る年代の人にはいまだに伝説して語り継がれています。
実際、このモデルのままでは35歳でマネージャーや管理職になるかどうかともかく、今でもそうなる傾向は強いと思います。
実際、このモデルを採用している企業では、課長がまだギリギリプレイングマネージャーとして活躍し（ほとんど課の面倒を見ず）、部長になった頃には進捗管理と要員調整…あわよくばごくわずかな営業活動くらいしかできず、経営層の顔色ばかりうかがって売上や利益にご執心している人も多いかもしれません。エンジニアから白い目で見られるくらいエンジニアリングのことがわかっていない人が多いのではないでしょうか。
ですが、このモデルのせいで（そのせい？）現場のエンジニアと話をしてみると、恐ろしいくらい設計工程を軽視していることがわかります。
プログラマーとエンジニアの明確な定義が存在しないうえに、アーキテクチャに精通する人材が育成されないと言うのもあるでしょう。プログラマーとしての色が強いとどうしても「アプリケーション目線」でしか物事が考えられません。ハードウェアやネットワークとの関係性、利用シーンや運用シーンの具体的なシミュレーションなどはそもそも考えている人を見かけません（自分以外の誰かがどこかで担当している…はずと思ってる）。
そうすると『システム』全体を把握している人がどこにもいなくなるのです。
こうした原因でよく起こるのが、
・結合テスト以降に、ビックリするくらい設計ミス・漏れの不具合が出る
・仕様として不透明な課題が散見されてくる
・非機能についての問題・課題が噴出する
といった事例です。
そうなるともう「いつになったらテストが終わるのか」さっぱり見当がつきません。それでもやらなきゃいけないという意識だけが先行し、あれもこれもとメンバーに負担をかけて活動させると当然残業も多発します。
すると、予算が不足しますよね？
で、管理職層があの手この手を使って、お客さまのところに追加請求の話をもっていってまた揉める…こんな現場を毎年見ますし、毎年そんな話で何億か吹っ飛んでます（いいなぁ、無駄な金の使い道がたくさんあって）。
ビックリしました。
つい先日も１～２億規模のシステム開発に関わることがありましたが、誰一人としてシステムの全体像、システム開発の全体像、プロジェクト活動の全体像を正確に把握し、コントロールしようとする人がいないのです。
まぁ…そんな状況だから、問題が噴出して関わらさせられたわけですが…。
誰に聞いても、断片的な情報は出てくるのですが全体像になっていないのです。いくら担当ごとに分業しているとはいえ、どこかに取りまとめている役割の人がいるかと思ったらまったくいないのです。
小規模のプロジェクトであれば、リーダーやマネージャーが担当することになっていたりしますが、大抵の場合、彼らは
・お客さまとのスケジュール調整
・メンバーの進捗状況
・メンバーの不良解決状況
程度しか把握しておらず、自分たちが作成したアプリケーションがシステムやお客様のビジネス全体のどの位置づけにあるのかも理解していなくて、作成している成果物がどのような役割を果たしているのかも知らない。お客さまとの打ち合わせで聞いてきた内容が「きちんと反映できているか」程度しか気にしていないのです。
結果、本来のあるべき形…ゴール（目標ともいいます）がそこに達していないため、お客さまからは「品質が悪い」と言われ、プロジェクト活動としてのあるべき姿を正しく把握しないためにスケジュールは破たんし、その穴埋めをするために大きなコストをかけて赤字化すると言う事態になります。
プロジェクトにおいて全体像を把握すると言うことは、スタートからゴールまでの道筋を完全に把握しようとする姿勢そのものを表します。スタートからゴールまでの道筋を把握すると言うことは、未来予測の精度が向上し、そのために必要なものをあらかじめ準備しておけると言うことです。未来予測の精度が向上すれば、多くのケース、多くのシーンを視野に入れて、先に手を打っておくことも可能になります。
つまり、逆算思考が身につくのです。
逆算思考は、目標達成の確度を上げるためには必須の能力です。
よほどセンスの優れた人や経験値が高い人は、その能力の高さゆえに逆算思考は不要かもしれません。ですが通常はそうもいきませんし、なによりチーム全体の足並みをそろえることを考えた場合、特定の優れた人をベースにして足並みを揃わせようとすれば、大抵失敗します。
システムの全体像、システム開発の全体像、ソフトウェアの全体像、ソフトウェア開発の全体像、ソフトウェア開発プロジェクト活動の全体像、etc.…がわからないままでは、いつまで経っても「ゴールに向かって」正しく進めているのかわからない
五里霧中
な状況から脱却できないのだと言うことを肝に銘じておきましょう。そしてそんな状態のままでは、目の前の作業を行う分には困りませんが、いつまで経ってもエンジニアとしても、マネージャーとしても一流にはなれません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。