システム開発では、疑問を徹底的に追及することも大事という話
先日、情シスではまっとうな感覚を持つことって大事ですよねという話をしました。
まあ、情シスに限らず仕事ってそうですよね。
素朴な疑問を追求する
これ、よくあります。現場の担当者は何の疑問を持たずに「ハイハイ」みたいな感じのことが多いですけど、これがわりと大事。突っ込んでみると、下記のような思いが隠れていたりします。
・本当はAの要求なんだけど高そうだからBにした
・本当はこんなことしたくないんだけどシステム上必要だと思った
・今のシステムでこの範囲しかできないから、新システムでも要求としては同じ範囲しかできないと思った
で、大事な話なんですけど、こういったユーザの「前提」って結構ハズレます。感の良い方もいますが、とくに最後の部分が危険。
せっかくシステムを新しくするのに同じ前提を置いてたら、意味なくない？
だったら、何もしないで今のものを使い続けたほうが、よくない？
要求をもとにあるものを会話して、疑問点をつぶしていくというプロセス
情シスってたくさんのタスクをかかえていますので、小規模の案件だとどうしても「右から左」になりがちですが、上のようなミスリードが発生したままで進めていると、だいたいうまくいきません。
こういった「ずれ」を最初のうちに正しておいて、ユーザと情シス、同じ方向を向いていき、言語化していくというプロセスがとても大切。
このあたりのポイントさえおさえられて腹落ちすれば、あとの機能や画面の詳細化はどちらかというと決まりきったプロセスなので、中規模開発くらいまでは成功が決まります。
同じことを何度も聞かれるのは開発の常
疑問を追求するためによく聞くのが「オウム返し」ですね。同じことをリピートして確認する。また、言い方を自分の言葉に変えて確認したりもします。
さらに、ステップごとの違いもあります。一定規模の開発なら、要件定義から基本設計、詳細設計と、言葉を変えながら同じことを徐々にプロセスに落とし込んでいきますから、何度も同じことを確認することになります。これがユーザには耐えられないことも多いです。丁寧に進めないといらつかせちゃう。
あらかじめ伝えておいて遠慮なく聞こう
以前は弊社でもユーザがもっと強くて「この要件なら〇〇さん（ベンダー）が取りまとめられていてご存じなのでそちらに聞いてください。私は知りません」なんてことを言われたこともあります。
そして、後になってからユーザが「要求通りじゃない！」とプロジェクト大炎上。昔の歴史をたどるとこんな案件、結構転がっています。
なので今は初回ヒアリングあたりで、「システム開発って同じことを何度も聞くんですよ（だからまた聞くけど許してね）」ということを伝えるようにしています。これをしっかりキーマンがそろっている場で伝えることで、コミュニケーションはずいぶん楽になります。
しかし、ちょっと言われただけで「じゃあいいです」と下がってしまう部下もいますね。こういった人は上流工程にはあまり向いていないのかな、とも思ったりします。
上流工程の本も結構出てますね。
まず日経ですが、これはしっかりしていてとても良い本です（マニュアル的だけど）
こちらだとUnlimitedに入っていれば無料。レビューの評価もよさそう。
これは持ってます。具体的ですし、とても踏み込んで書かれていますので、しっかり目を通していると安心。ただ、若干文字が多くてとっつきづらいです。
質問力の本もたくさん出ていますね。難しい本も持ってるけど、こういうのも欲しいなあ。
おしまい。
この記事が気に入ったらサポートをしてみませんか？