必要な機能を列挙するのが設計だと思っている人が多すぎます。
そして、工数を見積もって設計したつもりになっているのです。それでは頓挫することも多いでしょう。
ヒトモノカネといわなくても分かると思いますが、設計というのは、限られたリソースをうまいこと組み合わせることによって最大のパフォーマンスを引き出す知恵をひねり出す行為です。
このリソースを、人月と期間に帰着させるのは、悪くない考えです。
ただしここで指摘しているのは、設計対象物のリソースのことです。
ソフトウェアなら、最低でも以下の項目をパラメータとして設計しなければなりません。
- 必要メモリ量
- 必要処理量
最近では、
- 発熱量(消費電力量)
も重要になってきています。
発熱量はハード屋さんが考えること、などといってる人は、学校に入りなおしたほうが良いでしょう。
パラメータとして設計するということは、ノブを付けると言うことです。
ノブというのは、オーディオアンプについているボリウムのつまみのことです。
ソフトウェアの最適化では、メモリを湯水のごとく使うことで実行速度を向上させることが出来る場合があります。
アルゴリズムの選択によっては、メモリと処理速度がトレードオフの関係を持つこともあります。
実際にはそんな格好の良いことばかりでもありません。
画像を取り扱うフィルタシステムなら、最大画像サイズは何で決まりますか？
メモリですか？ハードディスクのサイズですか？ページファイルですか？
どれを選択して、どれと組み合わせればどうなるかの関係を整理するのが設計検討です。
そうして、最終的に選択肢を絞り込むのが設計作業なのです。
このように設計すれば、何かまずいことが起こったときにも慌てることはありません。
例えばあるアルゴリズムではメモリ10MBを使用して毎秒20枚の画像処理がおこなえる設計だったのが、実装してみるとバスボトルネックのために、半分しか性能が出ないと分かった。
そのときに、ビジネス側に対して
- 毎秒10枚の画像処理へのスペックダウン
というマヌケな選択肢だけでなく
- メモリ20MB使用で毎秒15枚までならなんとかなるはず(ただし機能Ａは削除)
というオプションを即座に示すことができるのです。これがいわゆるバックアッププランです。
設計検討時に、ただ思いついた実装方針だけで突き進んでしまっていると、問題が起こるたびに、設計検討フェーズへの巻き戻しが発生します。
あわてて検討するので精度も悪い。これが典型的なもぐら叩き開発の原因のひとつです。
バックアッププランについては勘違いしている人が多いようです。第一案と並行して第二案の実装をこっそり進めておくことがバックアッププランのことだと信じてしまっています。
確かにそれは瞬時に切り替え可能なバックアッププランです。しかしそういうものは、リスクに敏感すぎる役員が別の組織でやればいいことです。第二案にかける工数を全力で第一案にかけないで第一案が成功するはずもありません。
さて、最後にブレークスルーのことを書いておかなければなりません。
既知の問題を既知の手法で解決するように設計するのが、セオリーどおりの設計ということになります。しかしそれでは平均以上の組織は皆同じような設計に収束してしまいます。
そこでブレークスルーを起こすには、いわゆる研究開発が必要で、リスクが大きくなります。ですが、研究開発でも設計、実装は必要です。
自分の仕事が、フツウの設計でよいのか、研究開発寄りなのかは意識しないとエライ目にあうかもしれません。
コメント