新人技術者のためのロジカル・シンキング入門（3） ―― 「必要とされる設計書」の作り方

【5】ブロック図に向かないシステもがある

　この記事を読んで，「自分が開発しているシステムでも設計にブロック図を使うといいかもしれない」と思った方はいますか？ そのようなありがたい方には，自分が実際に開発しているシステムと似た構成のシステムを雑誌の記事などで探して，ブロック図を起こしてみていただきたいと思います．例えば，ゲーム専用機を作っている人なら，それをもし携帯電話に乗せるとしたら，どのような構成になるのか，既存の携帯電話に何を新たに追加して，何をあきらめると性能のいい"ゲーム・ケータイ"になるのかを考えるなどしてみましょう（図9）．

図9　ユーザが製品に求める機能に着目
ユーザが製品に求める機能をユーザの「目的関数」と考えると，各「関数」の作りは製品ごとに異なるだろう．ユーザから見ると似たような「目的関数」でも，作り手から見るとどう違うのかを，設計レベルで検討する必要がある

　そして，具体的にその全体構成を考えたら，自分の担当する機能ブロックの詳細を掘り下げてみます．そうした後で，実際に出荷されている製品の構成と比べれば，自分の見通しがまちがっていた，あるいは古すぎたといったことが判断できたり，新しい製品開発のきっかけが見いだせるかもしれません．そうなれば，ブロック図をあなたが手がけている実際の開発で使ってみるのもいいでしょう．

　逆に，ブロック図を作成してみたところ，ふだん自分が使っている設計手法を補うようなものは得られず，肝心の情報が欠落してしまうような印象を持つことがあるかもしれません．この場合は，あなたの開発しているシステムは，ブロック図を設計書に採用するのには向かないので，導入はあきらめたほうがいいかもしれません．

　システム開発のいいところは，くふうをすればいろいろなことが自分の手の届く範囲で手軽に試せることであると筆者は考えています．大規模システムの開発が相手でも，くふうしだいで開発手法を思考実験や比較的簡単なテスト・プログラムのレベルに落とし込んで試してみることができます．このように，まず小さめの開発サイクルを回してみる，というアプローチは，ソフトウェア開発においては，けっこう使いでのあるやりかたなのです．

さえき・はじめ
＜筆者プロフィール＞
冴木元．システム・エンジニア．昔から実は語学マニア．今までマスタしそこねた言語は数知れず．プログラム言語ならなんとかなるのだが...．大学時代は英仏独の文献が読めるようになれればいいなと思っていたが，この調子だとライフワークになるかもしれない．