始めに
自社サービスを内製でアジャイル開発している場合の話となります。
バックログでwho,why,whatが理解できるか
前回qiitaに書いたんですが、アジャイルで内部開発している場合は、
何を作るのかではなく、何でつくるのかを伝えることが最も重要であり、
エンジニアが空気を読んで開発するために必要です。
(Who)は、(What)を実現したいなぜなら(why)だから
エンジニアとして依頼を受けたら、このように文章にしてみて
何を解決したくてバックログを書いたのか理解できるか考えるようにしています。
why(背景となる課題、ユーザのペイン）が理解できないものは
誰も欲しがらない独りよがりなソリューションなことが多いと感じています。
納得するまで依頼してきた人に説明を求めましょう。
依頼された通り作らない。顧客へ価値が提供できる最小限のプロダクトになっているか？
開発依頼されたプロダクトは、本当にユーザへ価値を提供できているでしょうか？
エンジニアならわかるはずですが、一つのif文を追加するだけでも掛け合わせると
とんでもないテストパターンが必要になります。
安易な発想のプロダクトを、ただ言われた通り実装していくと
どんどん技術的負債を積み上げ自分の首を締めることになります。
作りたい衝動を抑え、最小限で価値を提供できる方法（仕組みや実装）を一緒に考えて
提案・設計することもエンジニアの仕事だと考えています。
社内にいるエンジニアはプログラム製造マシンではない
以前所属していた会社の代表にこんなことを言われたことがあります。
「エンジニアにはアメとムチが必要だ。アメ見せておけば必死に開発するんだよ」
当時、私はエンジニア部門の管理職だったので、私自身がエンジニアだということを
忘れての発言だったのでしょうが、衝撃的すぎて一生忘れられないインパクトがありました。
依頼された開発をその通り作るだけだと、このようにエンジニアは製造マシンだと思われてしまいます。
普段からロジカルな仕事をしているエンジニアこそ、何で作るのか、これで顧客へ価値を提供できるのか、最小限の開発になっているかをロジカルに提案する力が必要だと考えています。