2021-07-01
開発案件において、やっておけばよかったと思う反省
認識齟齬は作ってから発覚する
開発が結構進んでから、お客様に「イメージと違う」と言われたことがしばしばあります。
そんなとき、「あ～、上流工程で伝えておけばよかった」「作る前にやっておけばよかった」と思うことを、自戒を込めて列挙してみました。
とはいえ、伝えておけば、齟齬が発生しなかった、とは言い切れないのは辛いですが、伝えないよりはマシでしょうか。
なお、この記事は以下のような開発案件を想定しています。
- 開発担当が少人数
- プロジェクト管理担当は不在（自分でやらなきゃならない）
この記事でわかること
- 開発案件でどんなトラブルがあるのか
- どんな対策があるのか
作る前にやっときゃよかったこと
| お客さんがよく言うこと | 言っておけば、やっておけばよかったと思うこと |
|---|---|
| 思ってより動作が遅い とか 上限が低い |
|
| 見積価格に見合った開発量なの？ |
|
| デザインがイメージと違う |
|
| 不具合がたくさん出てるけど、この数は妥当なの？ |
|
| ●●って言ったつもりなんだけど、そうなってない |
|
| こう言ったのは確かだけど、こんな副作用があると思わなかった |
|
まとめ
お客さんはできるまで不安なんですよね。
エンジニアもそれは同じです。
まだ見ぬ成果物をいかに正しく、双方同じイメージで想像できるかが大切なんです。
そのために設計書やデザイン指示書など、工程をフレームにする活動をするのがセオリーなんですね。
しかし、上流工程にお金をかけたくないと思う気持ちもわかりますし、ないがしろにしちゃいけないことも理解してもらえると思います。
なので、お客さんに納得してもらうためには「仕事が戻ることがないようにすること」で、出来上がった時の満足感に直結すると思います。
疑問や不明点、イメージの不一致は、わかった時点で丁寧に解決していけば、「ちゃんとに進んだ」感が出せます。
その時は面倒でも、あとで「あの時ちゃんと確認してよかった」と思えるでしょう。
面倒くさい、と思ったときこそ、踏ん張り時ですよ！
