“設計思想書”で開発の効率と質を高めよう：エクスプレス開発バイブル（4）（3/3 ページ）

[西村 泰洋（富士通），＠IT]

究極の効率化“モジュール化”への道が自ずとみえてくる

　さて、設計思想書に記述すべきに内容について、分かりやすく説明するために「データ項目」を例に取りましたが、“思想”を説く切り口としては、ほかにもさまざまなものがあります。

　例えば物流システムでは、入庫、出庫、入出庫合計表示、日次更新、棚卸、ロケーション移動、マスタメンテナンスなど、基本的な機能はある程度決まっています。これもデータ項目の例と同様に、「物流システムとして本来持っているべき機能」「その物流システムに固有の部分」を明確化しておくわけです。

　このほか、物流業務における入庫、出庫のように、5W1Hで定義できる作業のうち、オペレータが行う処理と、コンピュータが自動で行う処理を分けておくのも参考になります。具体的には、「作業の具体的な内容」と、そのうち「オペレータが行うべき処理」「コンピュータが自動で行うべき処理」「今回のシステムで採用した役割分担」を記すといった具合です。

　ちなみにエクスプレス開発の現場では、設計思想書の作成基準や記述ルールを合わせて、同じ様式で作成するようにしていました。これによって、本質的な要件・機能を見据え、応用を図りやすくする環境を整え、積極的な再利用を促していたのです。また、「設計思想書の補足資料も作る」と前述しましたが、こちらには、システム開発当時、要件を実現するうえで複数の選択肢やアイデアがあった場合、「なぜそれを選択し、ほかを選択しなかったか」の理由を記録していました。

　そこまでしておけば、「使えそうなものはないか」と既存資産から探して使う“流用”に比べて、開発当時の“思想”という的確な判断材料を基に、はるかに早く、的確に再利用することができます。その結果、再利用によって得られる効果はいっそう高まりますし、開発スピードも自ずと速くなるのです。

　そしてもう1つ、メリットとして挙げておきたいのは、異なる顧客企業に向けて複数回、物流システムを開発した際など、同種のシステムの設計思想書を2回以上作成すると、みえてくるものもあることです。それは、業務の遂行に不可欠なデータ項目と機能──“最小要素”と、不可欠ではないがあったほうがよいデータ項目と機能──“最大要素”です。

　この最小要素、最大要素のいずれかを基準に“標準仕様”を固めてしまえば、同種の新しいシステムを開発する際も、標準仕様に対する追加もしくは削除で済んでしまうのです。いわゆる“モジュール化”や“パッケージ化”につながる発想です。Page2の図1・図2と図3・図4からもご理解いただけるのではないでしょうか。両者に共通する項目、When、What、Whereが最小要素で、それ以外が最大要素です。

　設計思想書を作成することは一見、手間が増えるように思えるかもしれません。しかし、開発業務を中長期的にとらえると、実はとても効率的な取り組みなのです。

設計思想書の実用に向けて

　一方、設計思想書を真に生かすためには、記述様式だけではなく、編集・保管方法についても配慮する必要があります。例えば、欧米製のハードウェアやシステムのマニュアルは、まずイントロダクションでその製品が採用している要素技術や、サポートしている業務そのものについて解説し、そのうえで製品固有の機能説明に入るものが数多く見受けられます。日本製品はその逆で、すぐに製品そのものの説明に入るものが多いように思います。設計思想書の場合、本質的な部分を重視している点で前者のアプローチだといえます。

　この意味で、過去に開発したシステムの資料を作る際は、その冒頭に設計思想書をファイリングするのも手です。実際、いきなり仕様書を読むよりも、本質部分を明らかにした設計思想書を先に読んだほうが、全体の理解が早いはずです。

　このほか、設計思想書だけをまとめてファイリングしておくのも、既存資産を短時間で理解するうえで便利です。また、閲覧資格のある関係者の誰もが活用できるよう、情報セキュリティ上、安全かつ、分かりやすい場所に保管しておくことも大切です。

　ただし、設計思想書はあくまで“虎の巻”的なものであることも忘れてはなりません。ユーザー部門や顧客企業にとってのメリットはもちろんありますが、基本的には自社あるいは情報システム部門にとっての開発効率を向上させるためのものです。事実、前述した“モジュール化の発想”の観点からみれば、システム提供先にとっては「独自の戦略的なシステム」にみえても、エクスプレス開発に慣れたSEにとっては、「項目数や機能数は“最大要素”にならった仕様で、データ項目名だけその提供先に合わせていい換えているだけ」といったシステムも多々あります。

　これをどうとらえるかは、立場や視点によってさまざまですが、いらぬ誤解を避けるうえでも、自社内のユーザー部門ならともかく、社外の顧客企業にシステムを提供する立場の場合、部外者には閲覧させず、あくまで内部資料として活用するべきでしょう。

まずは、既存システムの機能を絵解きしてみよう

　さて、今回は満足度と開発効率をともに高められる設計思想書をご紹介しましたが、いかがだったでしょうか。仮に、システム開発を料理にたとえるとすれば、要件定義書、設計書、仕様書、開発手法などはレシピに当たるものであり、設計思想書はシェフ独自のメモ──まさしく“虎の巻”といった位置付けになります。

　確かにレシピさえあれば、料理自体は作ることができます。しかし、それが顧客の好みや要求に合うかどうかはまた別の問題です。もちろん、ニーズを聞き込んで、一から開発を始める方法もありますが、決して効率的とはいえません。限られた期間内で、スピーディに満足してもらえるものを仕上げるためには、既存資産の“再利用”と、「その顧客企業あるいはユーザー部門の業務状況やニーズに適合させるために、いまある資産の中からどれを選んで再利用すべきか」、マッチングを判断するための過去の資料も必要となるのです。

　その意味で、筆者はこの設計思想書を作るという取り組みは、システム開発だけではなく、市場動向に即した早急な取り組みが求められる製品・サービス開発など、企業におけるほかの活動にも有益なのではないかと考えています（ただしこの場合、設計思想書に加えて、顧客の声を整理して記録するノウハウも必要となりますが）。

　それはともかく、ぜひ皆さんも設計思想書を日々の業務に取り入れてみてはいかがでしょうか。まずはA3の紙1枚に、図1、図2のような形で、いまあるシステムの機能を書き出してみてはどうでしょう。多機能なシステムの場合、1枚に収めるのは難しいでしょうから、紙1枚に1ブロックの機能といった形で書いてみるといいでしょう。先ほど「同種のシステムの設計思想書を2回以上作成すると、みえてくるものもある」と述べましたが、それと同様に、2つ以上の同種のシステムについて、カバーする業務内容と機能を書き出してみると、何らかの有益な発見があるかもしれません。

筆者プロフィール

西村 泰洋（にしむら やすひろ）

富士通株式会社 マーケティング本部フィールド・イノベーションプロジェクト員。物流システムコンサルタント、新ビジネス企画、マーケティングを経て2004年度よりRFIDビジネスに従事。RFIDシステム導入のコンサルティングサービスを立ち上げ、数々のプロジェクトを担当する。＠IT RFID+ICフォーラムでの「RFIDシステムプログラミングバイブル」、「RFIDプロフェッショナル養成バイブル」などを連載。著書に『RFID＋ICタグシステム導入構築標準講座』（翔泳社／2006年11月）などがある。

「エクスプレス開発バイブル」バックナンバー

• エクスプレス開発は、クラウド時代に本領を発揮する
• 2チーム制で、開発効率とユーザー満足度を高めよう！
• 納期・コストを削減する“開発案件3分割”の術
• “設計思想書”で開発の効率と質を高めよう
• すべてを任せてもらえる「専門家」になろう
• イメージに訴えて、要件定義を効率化すべし
• 超短期開発を支える7つのエッセンス