動くコードでは不十分

Transcript

1. 動くコードでは不十分 A Philosophy of Software Design 第３章から 1 / 20
2. 目次 戦略的プログラミン グ 将来の変更コストを下げ るための「投資の思考姿 勢」と両者の対比 どの程度の投資が必 要か 10〜20％の継続投資、 技術的負債の回収期間、 AI時代における設計の価 値 設計と組織 荒れたコードベースが新 メンバーの認知負荷・採 用・定着に与える影響 戦術的プログラミン グ 小さな妥協の蓄積が生む 複雑さの悪循環と「タク ティカル・トルネード」 の問題 2 / 20
3. 戦術的プログラミング 目の前のタスクを最速で終わらせる思考姿勢 3 / 20
4. 戦術的プログラミングとは 特徴 よくある場面（締め切りに追われているとき） 「今動くかどうか」が中心的な判断軸 短期的な進捗が価値基準 将来の保守性や拡張性は後回し 最速で動く方法を選びやすい 少し複雑な部分が残っていたり 既存の実装とは異なる特別な処理を入れたり 局所的なパッチを適用したり その場では「妥当な妥協」に見える 4 / 20
5. 小さな妥協の蓄積が複雑さを生む 一つひとつは小さな妥協でも、それが数十、数百と積み重なることで システム全体が理解しづらく、変更しにくくなっていく この悪循環により、複雑さはさらに増幅される 5 / 20
6. タクティカル・トルネード 特徴 非常に速いペースで機能を実装 設計を一切顧みない 後に大きな混乱を残す 組織によっては英雄視されることも 実際に起きること 後始末を他の開発者が担うことになり、チーム全体の生産性を下げる 6 / 20
7. タクティカル・トルネードがもたらしたもの 私が過去に所属していたチームでの新規サービス立ち上げにて 起きたこと シニアエンジニアが圧倒的な速度で開発 しかしコードの可読性が低く
 適切なモジュール化もされていない 他メンバーが実装する際、副作用の調査に
 多くの時間を取られる スクラムでのストーリーポイントの見積もりに
 大きなブレが発生 最終的な帰結 複雑な機能や品質を要する実装は結局その人 だけが担当するようになり、他のメンバーは メイン開発から離脱してしまった 個人の速さ ≠ チームの速さ 7 / 20
8. 戦略的プログラミング 「動くコードでは不十分だ」という認識から始まる 8 / 20
9. 戦略的プログラミング 特徴 マインドセットの転換 ただ動くものを作るのではなく、
 優れた設計を生み出すことを目指す システム全体の構造を長期的に改善して、
 将来の変更を容易にする 「今動くか」ではなく
 「この先も変更しやすいか」で判断する 戦術的プログラミングが「とりあえず動かす」ことに フォーカスするのに対して、戦略的プログラミングは 「動いた後も変更しやすい状態を保つ」ことにフォー カスする 動くコードは良い設計の結果として手に入るもの であって、設計を犠牲にして手に入れるものではない 9 / 20
10. 投資の思考姿勢 将来の開発コストを下げるために、今あえて少し立ち止まって時間を使う 事前の投資 新しいクラスやモジュールを作るとき、いきなり
 書き始めず複数の設計案を比較してみる 変更に強い構造を選び、後から読む人のために
 ドキュメントも残しておく 事後の投資 コードを触っていて設計上の問題に気づいたら、 見て見ぬふりをしない 今のタスクのついでに、少しだけ周辺のコードも 整えておく 戦術的プログラミングの悪循環に対し、戦略的プログラミングは好循環を生む 10 / 20
11. どの程度の投資が必要か 10〜20％の継続的な投資 11 / 20
12. 投資の指針 やるべきこと 総開発時間の 10〜20％ を設計改善に充てる 手を動かしながら、日々の作業の中で少しずつ
 設計を改善していく やるべきでないこと 最初からシステム全体を完璧に設計しようとする 有効なのは一度に大きく設計することではなく 日々の作業の中で小さな投資を継続すること 12 / 20
13. 投資の回収 戦術的プログラミング（負債） 戦略的プログラミング（投資） 短期： 速く進んでいるように見える 数ヶ月後： 小さな妥協が積み重なり、 コードの理解や変更に時間がかかるようになる 長期： 技術的負債が膨らみ開発速度は低下し続ける 財政的負債と違い、完全に返済されないことが多い 短期 10〜20％遅く見える 数ヶ月後 設計への投資が効き始め、戦術的アプローチより 10〜20％以上速く開発できるようになる 長期 差は広がり続ける。著者の経験では、 6〜18ヶ月程度で投資を回収できる 13 / 20
14. AI時代における投資回収の加速 本書が書かれた時代からの変化を踏まえた私見 コードベースの腐敗が加速している AIを使うことで、とりあえず動くコードを書くこと が以前よりも簡単になった。設計を考えない開発が かつてないスピードで進み、コードベースをより短 期間で腐敗させうる 相対的に、投資の回収期間は短くなっている 戦術的プログラミングによる腐敗が加速した分、
 戦略的プログラミングとの差がより早く開くように なった 著者が述べた6〜18ヶ月という回収期間は、今では もっと短くなっていると考えられる AIが開発速度を上げた今こそ、設計という土台の価値はさらに高まっている 14 / 20
15. 戦術的プログラミングの不可逆性 負債を積み上げた人は、その負債を返済する力も失っている コードの「所有感」の喪失 AIを使った戦術的な開発を続けていくと、 自分が書いたコードへの所有感が薄れていく 戦略的プログラマーとの違い 戦略的にプログラミングしている人は、 自分のコードをコントロールしている感覚がある 何がどこにあるかわからない コードベース全体の見通しを持てない 変更の影響範囲を把握できない 構造を把握している リファクタリングの方針を立てられる 大きな構造改革にも対応できる 戦略的設計はできるだけ早い段階から取り組むべき ── 後からでは立て直せない 15 / 20
16. 設計と組織 コードベースの品質がチームに与える影響 16 / 20
17. 開発現場で陥りやすい罠 よくある判断 設計に10〜20％の時間を使う余裕はないと感 じてしまう 設計にはほとんど手間をかけず、問題が出ても 整理に時間を割かない 「成功すればエンジニアを追加採用して整理で きる」と正当化する 著者の指摘 設計を後回しにするほど、開発はどんどん遅く なっていく スピードを優先しても、最初のリリースが必ずし も早くなるとは限らない コードの品質が低いと、採用競争力も下がる 人が来ない → 品質が下がる → さらに人が離れ る、という負の循環に陥る 品質を犠牲にするのではなく、作る機能の範囲を絞るべき 17 / 20
18. 荒れたコードベースが新メンバーにもたらすもの オンボーディングの現実 新メンバーはプロジェクト固有の
 マインドセットを持たない状態で参加する 負債の溜まったコードベースに対して
 一から向き合うことになる 入社前の期待値と実際のコードベースに
 大きなギャップが生じる 自分のコードが何に影響するか把握する
 認知負荷が極めて高い 新卒にとっての断崖 研修では真っさらな状態から始められるため
 認知負荷が低い 本番プロダクトに入った瞬間、
 設計が敗北したコードベースと直面 開発への無力感 
 → モチベーション喪失 
 → 離職 後から入った人の仕事が技術的負債の解消ばかりになると 開発の楽しさが失われ、人が定着しない 18 / 20
19. コードベースの品質は採用・定着戦略である 優秀な人材が離れる構造 優秀な人が入社 OKR・KPIが技術的負債の解消中心に 最初は学びがあるが、次第に学びがなくなる より高いレベルの組織を求めて転職 コードの品質についてくる人材 優秀なエンジニアの中には、コードベースの品質に 惹かれて残る人が一定数いる そういう人は良いものを作り続けてくれる存在 つなぎとめるには入った時点での第一印象が重要 コードベースを魅力的に保つことは 技術的な投資であると同時に採用・定着戦略でもある 19 / 20
20. まとめ 本章から 戦術的プログラミングは小さな複雑さを蓄積 させ、やがて開発速度そのものを低下させる 戦略的プログラミングは設計に継続的に投資 することで、長期的な生産性を高める 設計は「後で考えるもの」ではなく、毎日の 仕事の中に組み込むべきもの 修正を後回しにすればするほど、問題は大き くなっていく 経験から タクティカル・トルネードは、チーム全体の生産 性を低下させる 戦術的に作り続けると、自分のコードすら把握で きなくなり、立て直しが困難になる コードの品質が低いと新メンバーの認知負荷が高 く、人が定着しない AI時代では設計なき開発の破壊速度も加速し、設 計の価値はさらに高まっている 20 / 20