開発生産性Conference2024無料公開！視聴メモ①
「顧客価値向上による開発生産性向上」を視聴したので感想や気づきをメモ。
開発生産性と顧客価値
「開発生産性向上とは、適切に投資して投資を最小化し顧客価値・事業価値を最大化する」
テスト工数２割削減しました！レビュー品質１．５倍向上しました！って言っても、作ったものが誰にも使われないと意味ない。だけど誰しも最初からゴミになるとわかっていたら作らない。いかにゴミを作らないかは、作ろうとしているものにどれほどの顧客価値があるかを見極めることで決まるのではないか。
狩野モデル
こちらから画像を拝借。
「当たり前品質」ばかり高めすぎても顧客価値にはつながらない。銀行アプリで考えると、アクセス性や性能は当たり前品質。今時アプリがサクサク使えるのなんて当たり前だし、いっつも「メンテ中」なんて使う価値はないですよね。「通帳が見れる」「振り込みができる」は、一元的品質かな？コアに使われる機能なので、一か月の収支がグラフで見れたりよく振り込む先が記録に残ってると顧客はうれしい＝価値が高まる。NISAの申し込みができたり、目的別の積み立て貯金はできなくても構わないけどできたらうれしいから魅力的品質。でもアクセス性や性能が高ければ高いほど評価されるプロダクトもあるので、自分たちが作るものの「当たり前品質」や「魅力的品質」は何なのかを知ることは大事。
フェーズによって異なる開発の内容
「0→1のときに雑に作って後から作り直せばいいよという話がありますが、後なんて永遠に来ないです」
真理・・・！その後も開発は続き、技術負債が拡大コピーされていくのはあるある。データスキーマなど、後から変更するとなると大がかりなものはある程度後を見越して、フロントエンドの細かい部分やログ出力など変更容易な部分は最低限など、プロダクトごとに濃淡つけておくのが大事。
ある程度大きな組織だと、デザインやUX部分はガイドライン化されていると楽ですよね～。
ジョブ型雇用の誤解と理想
プロダクトマネージャーは「何（What）を」「なぜ（Why）」「いつ（When）」を決定する。エンジニアは「どうやって（How）」に責任を持つ。これは最終的なオーナーシップを意味し、他のメンバーにその責任がないというわけではない。
スポーツでも、自分のポジションにこだわって目の前のボールを追わないなんてないでしょ？プロダクト開発も、全員が「プロダクト志向」を高めて同じマインドを持とう。
「何のために作るか」「作ったものは事業にどう貢献しているか」はエンジニアが組織でものづくりするうえで大切な観点ですよね。チームでプロダクトを成功させるために越境上等！だけど、いつもこのバランスに悩むときは「開発者としてのキャリアパス」とか、「オーナーシップが曖昧になる」ラインが見極めきれないときな気がする。中長期的に考えたときにどうなの？と。
感想
冒頭で登壇者もおっしゃってましたが、一昔前はそもそも「生産性」以前の話で「ビルドするのに〇時間」とか、「開発終わってインストーラー作成、導入まで３か月」なんていう世界だったんですよね。今みたいにCIツールも充実してなかったし。ものによっては秀丸やサクラエディタでコーディングしてたり。でも今はいろんなIDEが出て幅広く言語もサポートしてるし、フォーマッターや校正を動的にかけるのは当たり前。e2eや自動テストツールも一般的になりテクノロジーで開発の「ものを作る」部分は大幅に改善されたと思います。
現代における開発生産性向上は、「何を作るか」や、「どんなチームで作るか」の部分を改善していくフェーズなのかもしれないと感じました。