こんにちは、ブリスウェルの山口です。
リモートワークを始めて4ヶ月以上が過ぎました。
リモートワークが当然のように馴染んだ人、やっぱオフィスがしっくり来る人、色々あると思います。
ブリスウェルでは7月から出社を全面的に解禁し、自己判断で出社とリモートワークを選択するという試みを始めています。出社時間や帰社時間も自由に決めて良いということにしました。
東京では感染者数も収束しているわけではないので正直どうすべきか悩ましいところなのですが、シンプルに基本に立ち返って、パフォーマンスが発揮できれば働く場所はどこでも良いという考え方を基本に据えようと思ってこの試みを決めました。
まずは始めてみて、様子を見ながら軌道修正が必要であれば修正する。そういうスタンスでやってみようと考えています。
さて、今回は前回の提案編の続編ということで、要件定義編と題して私の考え方をご紹介していきます。
提案フェーズで競合との競争を勝ち抜き、いよいよプロジェクトがスタートします。
まず始まるのが要件定義フェーズになります。
進め方はプロジェクト内容や規模によって様々なので、ブリスウェルでよく手がけることの多い業務系アプリの再構築プロジェクトのような案件をイメージしてご紹介していこうと思います。
要件定義フェーズでとても重要な要素は以下の点だと考えています。
１）体制
２）要件ヒアリング
３）既存システムの調査
４）領域を横断できる人
５）データ
さて、個別に見ていきましょう。
１）体制
お客様とベンダーで両方とも体制は重要ではあるのですが、とりわけお客様の体制で重要なポイントがいくつかあります。
・プロジェクトに要件を抽出できるキーマンがいること、もしくはキーマンにコンタクトできること
・課題のレベルに応じて素早く判断をできる体制であること
・領域横断的に要件を把握し、適切な決定を行えるリーダーがいること
様々な領域でのヒアリングが同時並行的に進む要件定義フェーズでは、現状業務を漏れなくベンダーに説明し、新たにやりたいことを正しく伝えられるかがとても大切です
特に新たにやりたいことに関しては様々な検討課題が議題として上がってくるため、課題に応じた会議体でできるだけ早く解決法を決定していく必要があります
一番良くないのは課題を後回しにして、曖昧な部分が残った状態で開発のフェーズに入ってしまうことです
ベンダーにはお客様が直面する課題に対して、過去の経験や技術的観点から解決案や解決の道筋を提案できることが求められます
・要件定義においてベンダー側の体制は経験豊富なプロジェクトリーダーを立てること
・技術的に課題を解決するための提案をできるメンバーをアサインすること
ベンダー側はこのような観点で体制を組み立てられると非常に良いと思います
２）要件ヒアリング
まず現状業務を把握することが非常に重要ですが、現状にとらわれないことも重要です
現状を漏れなく把握した上で、新しいビジネスや業務のあり方を再構築していくのが王道だと思います
まずはお客様のビジネス（顧客、商品・サービス、仕入先、商流のパターンなどなど）を理解し、ドキュメントで可視化していきます
どのようなビジネスケースが存在していて、それぞれがどのような業務やデータの流れで構築されているのかを明確にしていくのです
お客様側で全ての領域のビジネスや業務を100%漏れなく説明できる方はほぼいないので、ベンダー側が第３者的な視点でQAを繰り返し、抜け漏れなくヒアリングできることがとても重要です
提案編で「お客様の見えない要求を嗅ぎ分ける」ことを重要なポイントとして挙げた理由もここにあります
次に新しくやりたいことの大枠をお客様からヒアリングするわけですが、ほとんどの場合はシステム化できるレベルで詳細化されていません
現状ヒアリングで得た情報を元に、新技術や様々なサービスなどを組み合わせながら新らしいビジネスや業務を構築していくことになります
様々な検討課題に対して、調査や費用対効果の分析などを実施して、決定をしていくことになるため、できるだけスムーズにお客様側で決定いただくための下準備をしていくことが重要です
不要な業務やシステム要件をバッサリと切り捨てることも非常に重要です
スケジュール的な制約で現状機能があるので今後も必要だという判断を行うケースもありますが、業務ボリュームが少ないとか複雑すぎるような要件に関しては、開発工数も膨大になるケースが多いため、システム機能を実装せず業務での対応が残るという選択肢を常に持っておくことも重要です
３）既存システムの調査
業務アプリの再構築プロジェクトでは業務をヒアリングする流れの中で必ず既存システムが登場します
要件ヒアリングでの抜け漏れを防ぐ目的で、既存システムの画面、帳票、データベース、機能を漏れなく調査することが大切です
以下のようなメリットがあります
・要件や機能の抜け漏れを防ぐことができる
・業務要件を深掘りできる詳細な質問ができるようになる（データ項目やリスト値のレベルで現状を理解します）
・データ移行の下調べになる
私の経験上、既存システムには使っていない機能がごっそりあるケースがあります
その場合は、要件定義で不要な機能が入り込んでいないか、要件が複雑になりすぎていないかを特に注意する必要があるかもしれません
２と３の調査ができて、初めて現状が把握できた状態になるイメージです
４）領域を横断できる人
プロジェクト規模が大きくなればなるほど、お客様もベンダーも問わず、領域を横断的に把握できる人が少なくなります
全体の流れが常に頭の中に入っていると、以下のようなメリットがあります
・領域ごとの要件に不整合が出ることを防止できる
・領域をまたがる課題の解決が早くなる
・ユーザー部門へ新システムを普及させる際に幅広い観点からうまく説明ができる
・リリース後の追加改修の際に影響調査を効率的に行える
５）データ
業務アプリで最も重要なのはデータです
アプリケーションの機能やインフラ・ネットワークなどシステムを構成する様々な要素がありますが、全てのビジネスや業務を最終的に支えているのはデータです
そのデータがどのような構造で保持されているのかをデータモデルと呼びますが、この設計をいかにうまく行うかがベンダーの腕の見せ所です
新システムのデータモデルが既存システムのデータモデルから大きな変更を伴う場合、データ移行の工数が非常に大きくなります
現状をより正確に、より詳細に理解し、新しい要件を元に新しいデータモデルを構築できる人がいるかどうかがプロジェクト成功の鍵となると言っても過言ではありません
４で紹介した領域を横断できる人でないとデータモデル設計をすることは非常に難しいです
ベンダー側にこのようなスキルを持つ人がいるかどうかを提案時点や要件定義時点でチェックすることがお客様にとっても重要な指標となります
以上が私が要件定義で大切にしていることになります
今回は考慮すべき要素が多い「業務アプリの再構築プロジェクト」を例にご紹介しました
新しいサービスを構築するプロジェクトだと既存調査のプロセスが無いとか、小規模プロジェクトだと領域横断的な要素が少ないとか、今回のお話を引き算してイメージしていただけるのではないかと思います
インフラやデータ移行など色々と書けなかったこともありますが、重要な５点に絞り込んで紹介させていただきました
皆様のお役に少しでも立つことができたら幸いです！
