最近、要件定義がうまくいきません。ユーザー主導ではいつまでも終わらず、IT主導では「使えないシステムを作るな」と言われます。アジャイルも試しましたが、自社の環境には合わないようです。(情報システム部門/中堅エンジニア)

 要件定義は、システム開発の最難関工程と言われて久しいです。最近、さらに難しくなっているようで、同様の相談を受けることが増えています。要因としては、デバイスやUI表現の多様化、次々と現れる新技術などがあるのでしょう。その結果、ユーザーの欲しいものが変化し続けるようになっています。

 ユーザー主導の要件定義を行うと、目移りしながら理想を追い続けることになってしまい、要件定義が終わりのない沼に落ち込んでいきます。一方で、システム部門やSIベンダーといったIT側が主導すると、リスクを小さくすることを重視するあまり、保守的すぎてユーザーが満足しないシステムになりがちです。

 “変化への適応”という目的からアジャイル型に挑戦する組織もありますが、社内外問わずユーザーから発注を受ける立場の開発組織では、組織間の利害関係によりなかなかうまくいかないようです。

 最近はこうした環境を踏まえて、「カタログを使った要件定義」をおすすめすることが多くなっています。注文住宅を設計するときのように、「カタログ」から部品を選んで組み合わせる形式です。Excel方眼紙などによる自由なデザインはあえて避けます。

 例えばWebベースの管理系システムであれば、グリッドコンポーネントのバリエーションが用意されているUIライブラリーを企画時や提案時から前提に置きます。代表的なものとしては「Kendo UI」や「Ignite UI」がありますが、フレームワークやライブラリーは組織の経験や戦略から好きな組み合わせを選べば良いでしょう。ただ、最新かつ長期のメンテナンスが見込まれる組み合わせにしておきましょう。

 可能であれば、SPA(Single Page Application)ベースのアーキテクチャーの採用をおすすめします。変化の激しいフロントエンドの技術と、変化の緩やかなバックエンドの技術を、APIを境界として切り離せるからです。仕様を決める際には、フロントエンドはユースケースやユーザーストーリーなどのシナリオ型で、バックエンドは機能型で行うと良いでしょう。扱いやすく定義でき、将来のマイクロサービス化も見据えることができます。

 ここまでテクニックの話をしてきましたが、要件定義が難しくなっているのは日本のIT業界の構造に起因する面も少なからずあります。

 結論から言うと、外部からの調達が前提のこれまでの受託型開発が時代に合わなくなってきています。これまで、発注から納品までのリードタイムは年単位の比較的長期間が許容されてきました。ユーザーがRFPを提示し、ベンダーを選定し、スコープ・期間・コストを調整し、発注してやっとプロジェクトが開始されるものでした。

 最近の技術の変化スピードを考えると、こんな悠長なことはできなくなるはずです。例えば「ディープラーニングを活用して事業を変革させたい」と考えたとき、長い発注プロセスを踏んでいる間により洗練された新しい技術が出てくるかもしれません。

 世界には、自分たちの判断で技術を検証し、採用し、新たな技術が出てきたら自分たちの判断で乗り換える、という組織が多くあります。そうした組織と競合した場合、従来型の受託開発に頼っている組織とどちらかが勝つかは自明でしょう。

 エンジニアの役割は「誰かの要件を定義する」というものではなく、ユーザーと一緒になって「自分たちの実現したいことを理解し、適合する技術を自分たちで選び、自分たちでシステムを作っていく」というものに変わってきています。