要件定義フェーズは、プロジェクトの今後を左右します。最初が肝心です。
呼び名は、いろいろあると思います。要は開発の方向性や開発範囲を明らかにする作業です。
私は以下がポイントと考えています。
社内メンバーだけで先に打ち合わせをする
システムを発注するとベンダーは早く自分のペースで進めたいので、同席での打ち合わせをしたがります。SEをアサインしているので、その稼働の都合があるのです。
要は遊ばせず働かせて、さっさと次のプロジェクトに投入しないといけないわけです。
そこを敢えてベンダーを入れず、社内メンバーだけで話し合うことが大事です。
「まず社内で方向性を決めたい」などと言って、ベンダーからの打ち合わせ要請を拒否します。
ベンダーがいると、その場でいろいろ質問できて、一見良さそうです。
が、彼らに話を振ると、画面のボタンをどうするなど、最初から細かい話に脱線しがちです。
客から振られた話をバッサリ切り捨てるわけにもいかないでしょうし。
情シスが「その辺で・・・」と話を元に戻すのも大変なのです。
現場のユーザ側にも問題があります。
新しいシステムを入れたくないので、わざと細かい話をする輩もいます。
画面や帳票の項目などの細かい内容は、次のフェーズで議論すべきです。
このフェーズでは
「○○の業務ルールは廃止すべきではないか」
「○○業務をもっとシンプルにできないか」
など業務中心の話をするべきです。
業務改善・コストダウンに大きくつながる話は、このフェーズでしかできません。非常に貴重な機会です。大事にすべきと思います。
ただ、大体時間に余裕がないですし、上記の通りベンダーからは早く打ち合わせをスタートさせて欲しい、とプレッシャーも来るので、なかなかゆっくりは話せないと思います。本来はもっと余裕のある段階で話しておくべきだと思います。ベンダーへの発注前に、普段から話し合っているのが理想です。
ベンダーに話を聞いてもらっても、彼らが決断をしてくれるわけではないです。最後に決めるのはこちらです。
その前提となる意思統一を社内で図っておく必要があるのです。
叩き台をもって臨む
打ち合わせをするときに、「何か改善点を出してください」
「今のシステムの不満を自由に話してください」
というスタンスでは、思いつきで話をすることになるので、抜け・漏れが発生します。
議論も拡散し、まとまらなくなります。
打ち合わせをする際は、手ぶらではなく、必ず何か叩き台となるものを用意します。
具体的には、現行システムの業務フロー図を手に入れるのがベストです。
ベンダーも活用します。フロー図を持っているかもしれないので、もらいます。
古いものでも、何も無いよりは100倍良いです。何か基準になるものがないと効率よく議論できません。
このフロー図を元に現状の業務との差異をヒアリングします。ヒアリングした内容は、部署ごとに色分けして追記します。
以下のような感じになります。小さい図で申し訳ありません。
私は前社では運良くPDFで手に入れられたので、1ページずつPowerPointに貼って、その上からヒアリング結果を追記しました。
※PDFを1ページずつJPEGに出力するには、フリーソフトのPDF-XChangeViewerが便利です。
https://www.vector.co.jp/soft/dl/winnt/writing/se492489.html
[ファイル]-[エクスポート]-[イメージへエクスポート]で出力できます。
フロー全体を俯瞰してチェックすることで、開発範囲の抜け・漏れを防ぎます。
差異・改善・要望をヒアリングし、漏れなく記録する
上記フロー図を見ながらヒアリングした内容は、漏れなく記録する必要があります。発言してくれた人の顔を立てるのも大事です。
自分の言ったことが記録されていないと、次から話をしてくれなくなります。
記録の書式としては議事録形式ではなく、ヒアリングした内容をExcelシートにずらっと打つ表形式のほうが、後々に生かせる情報になると思います。
議事録は後から見づらいので、このフェーズでは無理に作らなくても良いと思います。
大きな会社で議事録を取る人を立てられるなら別ですが。
ヒアリングシートの書式は私は以下のようにしています。
いくつか項目を説明します。
■区分
ヒアリング内容の区分をします。
【選択肢】
・差異：フロー図と現実の差異
・改善：現状非効率なところなど改善したい点
・要望：全く新しい要望
■関連部門
非常に重要な項目です。次フェーズで打ち合わせに呼ぶ部門を絞り込めます。
関係の無い部門を打ち合わせに呼ぶと、モチベーションが下がったり、議論が拡散しがちなので、それを予防できます。
「主管部署はどこだか知らないが、ウチも少し関係している」
「この業務は廃止したいが、どの部署に確認したら良いかわからない」
のようなケースも記録し、はっきりさせていきます。
ヒアリングシートはこまめに周知することになりますので、よくわからない場合は「○」をつけておいて、該当部門に本当に関連業務なのかを判断してもらいます。
間違っていれば「－」に修正すれば良いのです。
【選択肢】
・◎：主管部門…業務的にメインとなる部門。仕様策定の決定権を持つ。その代わりテストの責任ももつ。
・○：関連部門…業務的に関わりを持つ部門。
・ー：関係なし
■ベンダー方向性
ヒアリングした内容を一度ベンダーに投げて、ベンダーの意見を確認します。
新しいバージョンのアプリだと、カスタマイズしなくても、標準で機能を持っている場合もあります。
それがわかれば議論の効率を上げることができます。
【選択肢】
・標準機能利用
・運用で回避
・カスタマイズ
・何もしない
■方向性
ベンダーからの回答を踏まえた、このフェーズで決めたこちら側の方向性です。
詳細な打ち合わせが必要な場合は、「要社内打ち合わせ」「要ベンダー打ち合わせ」を選択します。
次のフェーズへの先送りのようになってしまうこともありますが、要検討のステータスとして認識できるようにしておきます。
【選択肢】
・要社内打ち合わせ
・要ベンダー打ち合わせ
・標準機能利用
・運用で回避
・カスタマイズ
・何もしない
■実装する場合のメリット、実装しない場合のデメリット
強硬にカスタマイズを主張する人対策です。
予算オーバーの場合は、これを基に経営者に交渉しに行きます。経営者から錦の御旗をもらって、声の大きい現場の人を押さえつけます。
私は書いたことがありませんｗ
上記の項目や選択肢はまだ手探り状態です。これからもブラッシュアップしていきたいと思います。
ヒアリングはシステム利用各部門と最低1回は行います。
複数部門にまたがる業務で不明点が出た場合は、別途関連部門を集めた打ち合わせも必要です。
その際もこのヒアリングシートを見ながら行えば、無駄な時間を減らせます。
ヒアリングシートを更新したら、その都度メンバー全員に周知し、同意を得ます。
同意の意思をはっきり示さない人も多いので、
「同意の場合は返信不要。○月○日○○時までに意見なき場合は、同意したものとみなします」のように記載して周知します。
異論がある場合のみ返信させるのです。
異論がある場合はもちろん「全員に返信」させます。
こっそり情シス一人に「さっきの打ち合わせでは●●でしたが、本当は・・・」と送ってくるズルい人もいます。
打ち合わせできちんと話しているはずなので、この期に及んで異論などないはずです。
異論を言うのはだいたいがやりたくないからです。そういう人の心理的ハードルを上げます。
このフェーズでの頑張りが次のフェーズで生きる
このフェーズで頑張ると、以下のメリットがあります。・開発の方向性について社内の意見がまとまりやすくなる。
・開発範囲の大きなズレがなくなるので、見積もり精度が上がる。
・成果物（追記したフロー図・ヒアリングシート）をベンダーに渡せば、次フェーズでの作業効率が上がる。ベンダーも助かる（はず）。
※前社にいたときベンダーは思いっきり利用していました。
ベンダーとの打ち合わせに入って、社内の人間同士で議論が紛糾することがよくあります。
あれをベンダーはものすごく冷ややかに見ています。「あーあ」という感じです。
ベンダーはパートナーですが、所詮他社の人です。こちらの混乱は相手を利するだけです。恥ずかしいところは見せないようにすることが大事です。
だからベンダーを入れず、最初に社内メンバーだけで話し合うことが必要なのです。
こちらが一枚岩できっちりやっていると、ベンダーも気が抜けなくなります。
あまりに話がまとまらない場合は、以降のスケジュールを延期するなど、経営者に相談することも大事な判断だと思います。
上で書きましたが、大きな方向性については、このフェーズでしか議論できないのです。後で莫大な開発費用を損するよりはマシでしょう（経営者が理解してくれるかが問題ですが）。
本当は、発注前に十分な時間を取りメンバーと何度も議論をして、意思統一を図っておきたいのですが、経営者には「コソコソやるな！プロジェクトとしてやれ！」と怒られます。
プロジェクトとしてやると、成果物や報告の義務が出てきてしまうし、ベンダーも絡んできてしまう。
そもそもITの問題ではなく、業務の問題なんですが。
このあたりも理解があると助かるのですがなかなか難しい・・・
次回は、ベンダーとの打ち合わせフェーズを見ていきます。
関連記事：
