アクトインディ開発者ブログ

子供とお出かけ情報「いこーよ」を運営する、アクトインディ株式会社の開発者ブログです

背景を知る

要求されたものを要求されるままに実装することは日常で頻繁に発生していると思います。
仕様が決まり実装フェーズに入り、マンパワーで乗り切るといった場合に特に多いように思います。
こうなると設計書だけ渡され、十分な理解をしないまま設計書通りに実装するということがどうしても起きてしまいます。

例えば、実装フェーズからテストまで参画予定、その後はまた別プロジェクトへ移動となる技術者が担当する場合
人が足りないからアサインされ、長時間労働前提での参画が少なくありません。
考える時間の余裕がないため設計書と本来の目的がずれていても、
実装者の役割:設計書通りに実装する
実装者の目的:同上
となりがちです。

結局「別の誰か」がやらなければなりません。
ツケがプロジェクトの最後の方にやってきて・・・
後はご想像にお任せします。

実装者は価値を生み出すためにアサインされたはずが、
本来な目的と実装者の目的が異なるため
時間とコストだけかかってしまった
といった局面を何回も見てきました。
誰しもが少なからず経験があるのではと思います。

設計書には大抵「なぜそうするか」は書いていません。
説明があっても、本当に理解していない限りずれが生じます。
そのツケは結局本人に返ってきて、
長時間の単純作業を自分自身で延長するはめになるということもあるでしょう。


ではどうすればいいかという話ですが、

背景を知る

ということが大きい価値を生むと考えています。
例えば

無駄が生じてしまった例
・10人月かけたのに実際には使われない機能だった
本当に必要かどうかユーザへヒアリングをして、その要求に至った経緯を把握していれば
発生しなかった。

無駄を防げた例
・プロジェクト後半に文字化けする箇所があるため文字コードを変更してくださいとユーザから要求があった
影響が大きいため改修の見積もり工数は300時間だったが、本当に必要かユーザへヒアリングすると、
実は影響を受ける箇所は1箇所で、考え方をちょっと変えるだけで工数は1時間で済んだ

といったものがあります。
ちょっとヒアリングして背景を知るだけで、
とんでもなく時間がかかるはずだったものを回避できるなら
やったほうがいいですよね。

何事もまずは、背景を知る
を意識してやっていこうと思います。