2014.07.16

第202回 プラモデルと要件定義 【IT・情報システム支援】

コンサルティング事業本部 コンサルティングサービス1部 シニアマネージャー 森 真平

有名なロボットアニメが生まれて30年以上立ちました。当時、そのプラモデルは一大ブームとなり、小学生だった私も模型店をはしごして探したものです。
ちょうど2000年頃、技術進歩により小学生のころとは恰好良さのレベルが全く違うプラモデルを目にして、作る時間も無いのに大人買いしてしまいました。
それから十数年、更なる技術進歩で同じロボットの模型が進化していましたが、変わったのは技術だけでは無いようです。
それは、二次元のアニメを三次元の模型にするために必要な解釈の変更が止まることなくされているようです。そもそもロボットアニメのロボットはバーチャルです。
さらに、アニメ制作を効率的に実施するためにロボットの絵を単純化してあったと思います。
アニメ制作当時も、木で作ったモックアップはあったようですが、精巧さが不十分なものだったそうです。ロボットが機械であることから工学的な考察を加えて、より精巧な模型を作ろうとすると独自解釈が必要です。最近、その解釈による変化により、プラモデルが恰好よくなっていることを知りました。このロボットアニメに限らず、二次元で作成されているものを三次元化しようとするには、人による解釈が必要となり、それは明確になっていない部分を「作り込む行為」だから、その結果の立体像が異なるのは当然だと思います。
この二次元の絵を三次元の立体化する行為は、システム開発における要件定義とエッセンスが似ているような気がします。

要件定義を、どのように考えるかはいろいろあるようですが、私は、「要求」と「要件」を分ける考え方が気にいっています。まず、システムで何を実現したいかの要望をまとめたのが「要求」です。ここから実現性、開発費用、開発期間、要員といった開発上の制約を加味し、各要求の整合性を確保してシステムとして実現することを確約したものを「要件」と考えます。
「要件定義」は一部の人しかできない作業とは思いません。ただし、訓練が必要なスキルだと思います。
もともと私は、システム利用者の立場でした。開発側に入って要件定義を実施することになったとき、上司のSEの細かさに泣かされました。ただ、よく考えるとシステムを作る方の立場からすると、「要求」だけでは作れないのです。プラモデルの話でいうと「二次元の絵」なのです。システムの要件定義は、アニメの絵を三次元で立体化するのと同様に、要件の整合性の確保が必要です。システム開発の後工程で要件定義が問題となるのは、

1:実現性が見極められていない。
2:詳細化できていない。
といった項目があがりますが、
3:要件に整合性が無い(要件の相反する矛盾)
4:要件に一貫性(要件の統一感)が無い
が問題になっているのではないでしょうか?

誤解を恐れずに言えば、業務を知っているから「要件定義」ができるというのは間違いだと思います。
要求を整理するのは、そんなに難しくないと思います。難しいのは、「要求を整理して、システムの実現性を担保し、業務要求の整合性を確保した要件を作り込んでいく」ことではないかと思います。それには、そのための訓練が必要だと考えます。
あるお客様は、同一のシステム開発の要件定義を複数のコンサルティング会社に、短期間で発注し、システム要求となりうる良いエッセンスを吸収して自分たちで整合性のある要件を作成しているとのことです。最終的に要件定義を自分たちでできるようになるために費用を掛けて社内にノウハウを蓄積されているのだと思います。
二次元のものを三次元化するのと同様に、業務をシステム化する際も、人によりアウトプットは異なります。
個人的には本当にシステムで実現したいことは利用者自身が一番わかっているはずなので究極的には、利用者自身が「要件定義」を実施する方が良いシステムができると思います。
しかし、その準備が不十分で、難易度が高い会計業務をシステム化する場合は是非弊社にご相談頂ければと思います。

お問い合わせ先はこちらです。

MAIL MAGAZINE

メールマガジン

NEWS

ニュース

SEMINAR / EVENT

セミナー / イベント

セミナー/イベント一覧を見る

お問い合わせ