砂日記ばーじょん2.0

IT関連の仕事中に浮かんできたポエムとか読んだ本の感想とか書いていきます。

規模の大小に関わらず準備は十分に行わねば必ず失敗する

何の話?

最近案件規模が大小2つの案件を並行で要件定義したら小規模の案件の方で失敗した話

背景

案件(大)

要件定義1人月、開発工数5人月くらいの開発案件

案件(小)

 総工数4人日程度、リポジトリ管理されていないユーザ向けメールのテンプレートテキストをリポジトリ管理できるようにしたり社内の全文検索システムで検索できるようにするための運用方法をインフラ部隊と協議、作業依頼するお仕事。案件(大)の片手間に進めてた。

どうなったのか

案件(大)は期間をしっかりもらって念入りに要件定義を進めたので、開発が始まるのはこれからだけど少なくとも役員向けの開発承認レビューまではうまく行った方だと思っている。

事前に関係者集めてレビューのリハーサルしたのが特に良かったと思う。本番前に言うことを知っておいてもらうことで言うべきこと言わなくていいことの客観的な境界線を知ることができたし、本番時に援護射撃をとらうことができた。

 

逆に案件(小)については自分の方で運用案を考えて、企画部門とインフラ部門に説明したら両方からよくわからないとダメ出しされてしまい、要件を練り直して再提案したため1回で済むと思っていた打ち合わせが2回、3回と増えてしまった。

案件(大)に注力していたためアドリブな対応をとってしまったこと、小規模な話だからと依頼者からロクに要望のヒアリングをせずに自分の思い込みで提案してしまったのは本当に悪手だったし反省している。

最終的に提案はとてもシンプルでわかりやすいものになり、双方からOKもらえそうな状況になった

結局何がいけなかったのか

案件(小)で失敗した根本的な原因は一言で言えばナメてたってだけの話なんだけど。

  • 案件規模がどんなに小さくても手を抜いてはいけない
  • 案件規模がどんなに小さくてもクライアントが何をしたいのか注意深くヒアリングして要件定義すること。主観で考えないこと

小規模な案件のため影響は少なめ(想定より余計な時間がかかったこと、関係者に不要な打ち合わせをさせてしまったことくらい)だったので、この程度の痛みで知見を得られたのは良かった。

忘れないために備忘録としてブログに残しておく。