要求仕様作成における最大のコツ――機能の2割をカットする（第14回）

1990年代なかばから、企業の経営環境が大きく変化している。きっかけになったのは、インターネットの普及である。

インターネットが出現する以前、市場の変化は現在よりはるかに緩やかだった。企業は、市場の変化を見てから組織を変更し、対応するだけの余裕があった。この時期、ITはあくまでも組織を支援するための道具にすぎなかった。

しかし、インターネットの普及がビジネスのスピードを劇的に速めた。

近年、新製品が発売されるやいなや、その品質や使い勝手について口コミ情報がインターネット上に溢れるようになった。消費者は、インターネットを通じて製品を比較し選択する。消費者の本能である比較して選択する行為が、瞬時に行われるのである。このような市場に対して、従来のように組織変更で対応しようとしても間に合わない。組織とは人間の集合であり、人間の動作は遅いからだ。

このため、変化の激しい市場に対しては組織ではなくITで対応するようになった（図1）。その代表例がBtoCであり、BtoBである。近年は、さらに進化してオークションサイトのようなCtoBtoCのビジネスモデルも出現した。

図1　変化の速い市場に対して、従来の組織では対応しきれない。そのギャップを埋めるため、従来は組織を支援する役割だったＩＴが市場と直接接するようになりつつある

このようにITが市場とじかに接するようになれば、システムに対する要求は厳しくなる。当然ながら、要求仕様の作成にはこれまで以上の精度が求められる。万が一、要求仕様をしっかり詰め切れないとその後の開発が予定通り進まず、システムの稼働が遅れるからだ。システムの稼働が遅れればそれだけ市場への対応も遅れ、企業全体の収益に影響を及ぼしかねない。

要求仕様をつくるコツ

ここで、筆者がこれまでのシステム開発経験から得た「要求仕様を作るコツ」を紹介したい。

プロジェクトが失敗する原因は、機能の詰め込みすぎにあることが多い。もちろん、限られた予算と開発期間の中でよりよいものを作ろうとするのは、システム担当者として自然な欲求である。

しかし、機能を詰め込めばよいというわけではない。あれもこれもと欲張ると、機能間の整合性を確保しにくくなるし、開発期間も圧迫する。「機能を2割カットする」。これが要求仕様を作る際の最大のコツである。

具体的にはまず、必要な要求機能を洗い出して一覧に書き出す。次に、1つひとつの要求機能に優先順位をつけていく。優先順位を付け終わったら、順位の高いもの順にソートする。そして、優先順位の低い機能から2割をカットするのである。カットする際は、機能同士の整合性を担保しておくことに注意したい。

要求機能をカットすることで、機能間の整合性を確保しやすくなるから、開発期間も大幅に短くできる。こうして予定より早くシステムを作り上げれば、余った期間でカットした2割の機能の一部を追加開発することも可能である。

ここで、「ユーザー部門から上がってくる要求に優先順位をつけるのは難しい」「カットする機能をどう判断すればよいのか」という疑問を解消しておこう。

まず、ユーザーが要求する機能には「あると便利な機能」と「なければ困る機能」の2種類があることを知っておきたい。この2つには、大きな差がある。

あると便利な機能は、真っ先にカットする対象になる。その機能がなくても、たいして不便でない場合が多いからだ。実際、「あると便利だから」というユーザー要求は、単なる個人的な趣味に近い場合がある。そうした機能が提案されたら、「なければ困るのか」と問えばよい。多忙なIT担当者に、個人的趣味につきあう暇はないはずである。

一例を挙げよう。ある企業でシステムを再構築することになった。IT部門の担当者が機能を棚卸した結果、バッチプログラムの約40％が帳票プログラムであった。そこでこの担当者は現場に出向いてヒアリングを実施した。ヒアリングの要点は、帳票の要不要を判断することである。現場から1つひとつの帳票の必要性について合理的な説明と裏付けがないものは、新システムでは出力しないことにした。その結果、新システム稼働後に「帳票がなくて困る」といったクレームを受けることはほとんどなかったそうである。

3層構造アーキテクチャ

一方、なければ困る機能については、優先順位を決める必要がある。このとき、大きく2つの指針を持つ必要がある。その機能が実際の業務に合わず使えなくなるまでの寿命と、その機能がもたらす利益である。

システムに実装すべき機能が有する寿命は、企業全体を支えるITアーキテクチャと密接な関係がある。それが3層構造アーキテクチャあるいは多層構造アーキテクチャと呼ばれているものである（図2）。これらのアーキテクチャについてはWeb上に資料が多くあるし、技術書も多いので、必要に応じて調べてもらいたい。ここでは、要求機能の寿命とアーキテクチャの関係を説明する。

図2 ＩＴアーキテクチャは、大きく3層に分けられる。プレゼンテーション層での要求機能の寿命は短く、データ層での要求機能の寿命は長い傾向がある

3層構造アーキテクチャを構成するのは、「プレゼンテーション層」「ファンクション層」「データ層」である。

プレゼンテーション層は、ユーザーと直接接する部分である。最近は、Webアプリケーションとして実装することが多いようだ。ここに実装される機能は、データの照会・登録・変更・削除などである。プレゼンテーション層におけるこうした要求機能の寿命は、短い傾向にある。筆者が最近聞いた話では、せっかく開発したWebアプリケーションが、たった6カ月で実用に耐えなくなったケースもあるという。

ファンクション層は、プレゼンテーション層とデータ層の間に位置し、両層からの要求に応えたり、要求したりする。この層はさらに4つのコンポーネントに分解できる（図3）。データの正規化や正当性をチェックする「サービスインタフェース」、ファンクション層内のデータの流れやビジネスロジックの順序を制御する「ビジネスワークフロー」、ビジネスロジックそのものの実装である「ビジネスコンポーネント」、ビジネスコンポーネントとの間でデータのやりとりを行う「ビジネスエンティティ」である。こうしたファンクション層に位置する機能の寿命は、3〜5年程度と考えておけばよい。

図3 プレゼンテーション層とデータ層の橋渡し役を果たすファンクション層は、4つのコンポーネントから成る

データ層の役割は、ファンクション層からの要求に応えてデータソースとやりとりすることである。データソースはRDBMSで実装されることがほとんどのようだ。ここは、企業のデータ構造をモデル化したものだと考えてよい。従って、実装される要求機能の寿命は5年以上と、他の2層に比べて長い傾向にある。

コスト意識

その機能を導入するといくら儲かるか。導入にかかるコストはいくらか。要求機能に優先順位をつける際には、こうした視点も重要である。技術者の中には、「利益」や「コスト」という言葉を聞くと鼻白む人もいる。しかし、利益の追求は会社を支える根本的な原理である。

企業とは、利益を生み出す装置である（図4）。逆の言い方をすれば、利益を出さない企業は社会に必要とされない。出資者は配当を誘因として企業に出資する。経営者はそれを資本金として運用し、利益を出す責務がある。利益を出せなければ、経営者は株主総会で解任される。

図4　システム導入は、資本金を投入する資本運用活動の1つ。要求仕様を作成する際は、「導入コストに見合う利益を出す」という発想が不可欠だ

企業におけるシステム導入は、資本金を投入する資本運用活動の1つである。経営者の発想は、常にここにある。だからこそ、コストに見合う利益の発想が要求仕様には必要なのだ。要求仕様を完成して経営者に説明した後、経営者が笑顔でなければ、利益やコストについて説明が不足している可能性が高い。

豊かな想像力

「要求仕様に取り組む技術者に必要な資質を1つだけ挙げよ」と問われれば、筆者は躊躇なく「想像力」と答える。想像力がないITエンジニアは、他人の発した言葉や書いた文章の意図をくみ取れない。このため、想像力のないITエンジニアはユーザーの要求を自分勝手に解釈してしまい、要求仕様の作成に失敗しやすい。

それだけではない。想像力を欠いたITエンジニアは、他人に伝わる文章を書けない。読む人はどのような内容を期待しているのか、自分の書いた文章はどのように理解されるのか想像できないからである。すると何が起きるか。数ページに満たない仕様書を何度も作り直し、自分だけでなくユーザーやほかのメンバーの時間を無駄にすることになる。

それでは、想像力を高めるには何をすべきなのだろうか。

想像力の豊かな人は言葉が豊かである。それはそのはず。我々人間は社会を観察するとき、物事をいったん言葉に置き換えて理解していると考えられるからである。言葉の数が豊富であれば、物事をより詳しく観察することができる。

言葉の豊かな人は読書量が豊富である。読書によって獲得しているのは、実は知識ではない。言葉を獲得しているのである。その獲得した言葉によって、知識を体系化しているのである。想像力を高めるためには読書をすることである。

要求仕様の美学

筆者は、人間を含めて生き物すべてを美しいと思う。生きる上での機能に無駄がないからである。無駄をそぎ落とすことで、これまで地球に幾度となく訪れた環境や生態系の変化に対応してきた。進化論を提唱したダーウィンは「この世を生き延びられるのは、最も強い種でも最も賢い種でもなく、変化に最もよく対応できる種である」と言った。これは、システムにも当てはまると筆者は思う。無駄がなく変化に強いシステムは美しい。

ただし、これは筆者個人の美学である。「美しい」と感じるのは主観だ。たとえ数百年にわたる審美の目を通り抜けた絵画であっても、観賞する人によっては「美しい」と感じないこともある。どのような要求仕様に美を感じるかは、人によって当然異なるだろう。個人が内在する主観をもって要求仕様を美しいと感じることができれば、これをもって要求仕様の美学と言えるはずだ。美学とは、個人が獲得した哲学である。この哲学を、ぜひ大切にしていただきたい。

昨年の10月号で連載を開始して以来、読者のみなさんには1年以上お付き合いいただいた。長期間のご愛読に感謝しつつ、筆を置くことにする。ありがとうございました。