こんにちは。
とても大きなプロジェクトが無事に完了でき、一安心している技術リーダーの因藤です。
このプロジェクトは、取引させていただいているお客様の基幹システム刷新に伴い、関連のあるEC、店舗、社内システム、、等々すべてに影響がある大きなプロジェクトでした。
自分がジョインしてからリプレイスまでは1年ほどしかなく、自分としては過去一番に難しいプロジェクトでした。（お客様の規模間も大きく、ベンダーは10社ほど関連）
難しいプロジェクトほど、学びも多いものです。
このプロジェクトを振り返ると、「スケジュールが短い」という状況が前提としてあり、早く開発を行わないといけないという焦りから、要件定義をしっかりと行えずに開発フェーズに進んでしまいました。
この場合どうなるかというと、要件が詰め切れていないため、後から仕様が変更してしまうことが多くなります。
そのため、予定より多くの追加開発が発生してしまいました。
時間がないからと言って上流工程を雑にすることは、問題を先送りにしていることと同じです。
必ず下流工程で痛い目をみることを改めて再認識できました。
長々と前置きを書きましたが、今回は上流工程において重要となる「要件定義」について、これまでの経験をもとに重要なポイントをまとめてみました。
ぜひ、一読いただければと思います。
1. 要件定義とは
プロジェクトの計画がまとまり、お客様が導入したいシステムの概要がまとまったら、システムに対する要件をまとめていく必要があります。
お客様がもつ漠然としたイメージを明確にしていくのが要件定義フェーズとなります。
なお、本来要件定義はお客様が行う作業ですが、ITに詳しくないお客様がほとんどのため、こちらが主導して行った方が確実かと思います。
要件定義を行う上では、「要件定義書」を作成する必要があります。
「要件定義書」は、お客様へヒアリングした内容、実装するべき機能、性能など、システムの全体像を明らかにしたものを資料化したものです。
この資料は、IT、システムに詳しくない人（経理、経営層など）も読むことがあるため、誰が読んでも理解できるように簡潔にまとめることを意識しましょう。
2. 事前準備をしっかりしよう
要件定義を進めるにあたり、お客様へ具体的にヒアリングを行いながら要件を詰めていきますが、
その際に、ある程度こちらで事前に要件を簡単にでもお客様から聞いておき、
提案資料を作成してから臨んだほうが確実かと思います。
要件定義に限らずですが、私たちは仕事を依頼された際に、「お客様が全て答えを持っている」と思いがちです。
しかし、お客様が全ての答えを持っていることはほとんどありません。（だから私たちに依頼がきています）
それを念頭に置いて、お客様の既存サービスや期待するサービスを理解したうえで、実現方法のアイデア出しを行いましょう。
私の場合は、まず「何を実現したいか」のゴールを先に確認したうえで、
ヒアリングの場までに実現方針を2、3案作ってから持っていくようにしています。
こうすることで、前提の要件のFixがすぐに実現でき、残りの細かな要件詰めに集中することができます。
手ぶらの状態でヒアリングに臨まないよう気を付けましょう。
3. 要件の実現方法の調査
要件を詰めるにあたり、実現方法を検討する場合、
まずは「社内で同様の事例が無いか」を確認してみましょう。
まるっきり同じとは言わなくても、似た機能が既に実装されているケースは多いです。
その場合、過去事例をもとに要件を詰められるため、要件定義のコストが下げられる可能性があります。
次に実施する内容としては、「ネット検索」です。
多くの情報を参照することができ、あらゆる方法を見つけることができるかと思います。
なお、汎用的な情報が多いかと思いますので、プロジェクト用にプラスアルファで何をカスタマイズする必要があるか、情報に信頼性があるか等をしっかりと確認しましょう。
4. 既存機能でどうにかならないか？を検討する
手動運用は発生しますが、既存機能で要件の実現が行えることもあります。
何でもかんでも「開発！」としてしまうと、コスト、スケジュールに沿わなくなってしまうこともあるため、
お客様とのヒアリングにおいて、開発する部分と運用でカバーする部分を仕分けしましょう。
また、開発の優先度を設けて、どの機能が要望度合が高いかを見えるようにしておきましょう。
私の場合は、どの機能においてもまず「既存機能」でカバーできないかを考えるようにしています。
そうすることで、「開発できません。」という回答ではなく、「開発はできないが、こうすれば実現できる」というプラスの提案を行うことができます。
最後に
最後に、要件定義の重要性をお話ししようと思います。
要件定義とは、お客様との合意をとるためのもの（資料）となります。
あとから要件定義書を変更すると、スケジュールや次工程以降のドキュメント、作業に大きく影響が出るため、
できるだけしっかりした要件定義書を作ることを意識しましょう。
前置きにも書かせていただきましたが、要件定義を雑に行うと、必ず下流の工程で痛い目を見ます。
そうならないよう、「要件定義はしっかりとやるんだ！」という意識のもと、プロジェクト進行をしていただければと思います。
以下、参考文献となります。
本のタイトル：みんなが知っておくべき運用設計のノウハウ
とてもためになる書籍です。
是非、読んでみてください！
以上です。これを読んだ人のお役に立てたら幸いです。
コメント