2021-07-01

開発案件において、やっておけばよかったと思う反省

投稿者: KuRo

この記事で紹介していること

認識齟齬は作ってから発覚する

開発が結構進んでから、お客様に「イメージと違う」と言われたことがしばしばあります。
そんなとき、「あ~、上流工程で伝えておけばよかった」「作る前にやっておけばよかった」と思うことを、自戒を込めて列挙してみました。

とはいえ、伝えておけば、齟齬が発生しなかった、とは言い切れないのは辛いですが、伝えないよりはマシでしょうか。

なお、この記事は以下のような開発案件を想定しています。

  • 開発担当が少人数
  • プロジェクト管理担当は不在(自分でやらなきゃならない)
この記事でわかること
  • 開発案件でどんなトラブルがあるのか
  • どんな対策があるのか

作る前にやっときゃよかったこと

お客さんがよく言うこと 言っておけば、やっておけばよかったと思うこと
思ってより動作が遅い とか 上限が低い
  • 性能保証はできない(限界がある)ことを伝える
  • 機能ごとに簡単にでも品質基準を定めておく
見積価格に見合った開発量なの?
  • 見積額、単価、基準を示しておく
  • 開発リソースの実数や所要時間を記録しておく
デザインがイメージと違う
  • 静的イメージを(再利用できるレベルで)作成して、あらかじめ見てもらう
  • デザインは後からでも比較的直しやすい(ように作る)から、あまり時間をかけずに調整する
不具合がたくさん出てるけど、この数は妥当なの?
  • ドキュメント納品はなくても、調整したことはスプレッドシートにして、記事にリンクを貼れるようにする
  • 品質基準を定めておく(ステップ数とかFPとか規模係数とか、簡単に出せる指標で)
●●って言ったつもりなんだけど、そうなってない
  • 言った言わないになると時間浪費になるので、誤解がありそうなことはその場でしつこく解決
  • 口頭調整したことは、必ず明文化して、確認してもらう
  • 作った後も、👆の明文化したことに紐づけて、結果が想定通りかその場で確認
  • 記事をスレッド管理する(Redmine とか JIRA などのチケット管理がおすすめ)
こう言ったのは確かだけど、こんな副作用があると思わなかった
  • 要求に対するネガティブな要素は、その場で思いつく限り絞り出す
  • 第三者の知見を収集する(ネットの失敗談を探す)
  • Pros / Cons をちゃんとする

まとめ

お客さんはできるまで不安なんですよね。
エンジニアもそれは同じです。

まだ見ぬ成果物をいかに正しく、双方同じイメージで想像できるかが大切なんです。
そのために設計書やデザイン指示書など、工程をフレームにする活動をするのがセオリーなんですね。

しかし、上流工程にお金をかけたくないと思う気持ちもわかりますし、ないがしろにしちゃいけないことも理解してもらえると思います。
なので、お客さんに納得してもらうためには「仕事が戻ることがないようにすること」で、出来上がった時の満足感に直結すると思います。

疑問や不明点、イメージの不一致は、わかった時点で丁寧に解決していけば、「ちゃんとに進んだ」感が出せます。
その時は面倒でも、あとで「あの時ちゃんと確認してよかった」と思えるでしょう。

面倒くさい、と思ったときこそ、踏ん張り時ですよ!