読書「はじめよう！要件定義」で気付いた怖い話

はじめに

今の部署に来て、４月から２年目がスタートしました。
昨年度を振り返ると、
・ITベンダーに頼んでもしっくりこない内容が返ってくる
・要件が決まって、いざ見積を取ってみると予算オーバーでPJが頓挫する
・ツールの導入想定をしていたけど、
　ユーザーのスキルを考えると導入できてないと後から気づく

最初の要件をちゃんと固められていなくて、それを上司とも合意が取れていないのが今の問題なんじゃないかと感じ、この本を読んでみました。

そして、読んで気づいてしまいました
「この本で言うところの準備もできていないじゃん！！」ってことに。

はじめよう! 要件定義 ~ビギナーからベテランまで

所感

準備すらできていないことに驚いたのには２つあって、
❶システム会社出身の方がPJに入っているものの「超上流」と呼ばれるPJ企画については得意としないかもしれないことに本を読んで気づいてしまった
❷プロジェクトマネジメントの本の感想でもあった通り、私の所属部署では文書化して残すという習慣があまりないためにPJが難航していることに気づいた

特に❶については、正直この人についていけばいいと思って１年間働いてきたものの実際準備の部分はほとんど社内の人間ではできておらず外部ベンダーやコンサル会社に任せっきりになってしまっていたので、まずはここから自分たちでする努力が必要なんだと感じたし、その人に任せるのではなく自分自身のちょっとした違和感に対して調べて学んで実践しないといけないなと考えさせられました。

❷についてはプロジェクトマネジメントでも感じますが、上流なので毎週のように変わる時は変わってしまい作るのがなかなか手間で怠ってしまいがちですが、要件定義でも書かれているということは「誰にでも見てPJ内容がわかる状態」というのはPJ推進にとって必要不可欠なんだなと改めて学びになりました。

印象的な内容

準備が「要件定義」になっているのは危険

まずここで言う要件定義はソフトウェア開発のものを指します。
その要件定義には３つの要素があり、UI・機能・データとのことです。

でも、それを決めるための準備段階として
・プロジェクトを端的に紹介できる企画書
・全体像
・実装技術
・実現したいことリスト
が必要であるのに特に企画書がないケースが多いと気づきました。

ここで言う企画書は「企画を通すため」ではなく、
「企画内容を関係者が理解するために必要なもの」と言うことで
・作るものを利用する人
・利用する人が得られる便益
・作るための体制
などが一応企画書には書いているけど、いつも同じ内容を貼り付けているもので
ちゃんと考えて作られていない＋上長ともコンセンサスを取れていないからこそ、途中で頓挫しちゃうんだなと改めて認識しました。また今から始まる予定のPJもこれがないので、このままではまた炎上しちゃう・・と少し怖くなってしまいました。

また本を読んですぐにこの企画書を書こうとしましたが、意外と手が詰まる。
良い企画というのは、
在庫管理システムができることで→便利になる→在庫回転率が○％UP
のように「便利になった」ことの評価が行える基準があり、そのストーリーも一貫性があることのようなのですが、この流れを描くのにもすごく悩んでしまい、いかに企画段階を疎かにしてしまっているかを実感しました。

実現したいことリストの本質的な課題って何？

周りの部署と連携して実現したいことリストは作成したものの、その総括をコンサル会社に任せてしまっていて、社内のPJメンバーが本質的な課題について考える場面がなかったことが問題だったのだと気づけました。

特に思い浮かべているPJだと多くの部署に協力いただいた分リストの数も膨大で、スコープ外になりそうなものはすぐ外してしまい自分たちの都合のいいものばかり見てしまっていたような気がしますが、「無茶に思える要求も丁寧に分解すると本質が見えてくる」とのことで端折るポイントではなかったんだと大反省しました。

さいごに

読めば読むほど今入っているPJがいかにヤバい状態か気づける怖い本でした（笑）
今の段階で気づけて良かったと思って、まずは企画書を作るところから早速取り掛かってみようと思います。とは言え、まだ２年目ということもありPMなどの役割ではないので作ってみて、社内に提案して上司とコンセンサスを取るところまでいってみたいです。

そして今は準備編が一番印象的だと感じてしまったけど、準備を終えた後には次のフェーズに入りこの本の後半部分から今よりもっと多くの学びを得られる状態になっていたいなと思います。