数ある記事の中、
私の記事に興味を持ってくださり、ありがとうございます。
2025年2月あたりから案件が変わり、
開発以外のことも多く担当するようになりました。
案件配属時に推薦図書として
選ばれていた一冊を今回手に取りました。
「達人プログラマー」を読み、
今のプロジェクトがまさにこの流れを踏襲し、
開発しやすい基盤を忠実に構築しているのだと気づきました。
もちろん全ては実現できていないですが、
今自分がとても開発しやすい環境にいることを考えると、
これは本質的に大切なことなのではないかと感じています。
そんな本書で語られている
達人プロジェクトの三本柱を
ジョジョ第二部の柱の男たちに見立てて
深掘りしたいと思います。
(ジョジョの奇妙な冒険知らない方はごめんなさい。)
柱の男エシディシ：バージョン管理
プロジェクトに関わる
すべての記録を
バージョン管理するのが
達人の基本姿勢です。
コードだけでなく、
ドキュメントや決定事項、
会話のログまで
管理下に置くことで、
いつ誰が何を決めたのかが
はっきりします。
私の所属するプロジェクトだと、
- ドキュメント：Confluence
- タスク管理：JIRA
- git：GitHub
- デザイン：Figma, Figjam
で統一されていますね。
例えばGitを使えば、
コミットメッセージに議論の経緯を残し、
タグやブランチで
重要なマイルストーンを
すぐに振り返ることができます。
作業ごとに分けておくことで、
不具合が出ても
どこに問題があるのか
素早く見つけられるんですよね。
情報を一元管理することで
チームの認識が揃い、
無駄な再作業や勘違いを
防げるんです。
ジョセフとの対決では
柱の男の中でも長く生きているエシディシにとって、
バージョン管理してきたからこそ
歴戦の叡智が発揮されたということですね。
柱の男ワムウ：容赦ない回帰テスト
テストはコードのユーザー第一号。
これ聞いたとき、「あー確かに！！」と
共感で首がもげました。
だからこそ機能追加や修正をするたびに、
すべての挙動が正しいか
自動で確認できる仕組みを
作ります。
新しい機能を追加するたび、
思わぬ部分にバグが
紛れ込むんですよね。
テストがないと、
バグを見つけるまでに
多くの時間を失います。
実際ある案件ではテストの実装が少なく、
状態どころかカバレッジも満たせていない状態でした。
その案件ではやはり小さな機能追加でも
多くの時間を要していましたね。
特に不具合調査はかなりキツそうでした。。
このように失敗したケースを
テストに追加することで、
同じミスを二度と繰り返さない
仕組みができます。
テストは正直面倒ですが、
長期的には開発スピードを
大きく向上させるんですよね。
ジョセフにとって、
戦闘の天才ワムウはまさに「容赦ない」テストです。
柱の男カーズ：完全な自動化
テストや本番環境へのデプロイ、
IDEの設定に至るまで、
手作業を介入させないことです。
手作業にはミスがつきものです。
プロジェクトの規模が大きくなるほど、
人の手が介在すると
ミスのリスクが増えます。
1コマンドで
一連の作業が終わるようにしておけば、
開発者は
お客が喜ぶことに集中できるんですね。
自動化に投資することは、
自分たちの生産性を上げ、
お客様に価値を届ける時間を
増やすことにつながるのです。
実際、私の所属するプロジェクトでは
PR作成時やマージ時にbuildやテストの全実行を
行っており、レビューで集中すべき箇所を絞れたり、
ブランチの安全なマージの保証をしたりと
大活躍です。
コレがないと怖いくらいです。
究極生命体として完全体を目指したカーズにとって
足りなかったのはまさに自動化だったのかも。
おわりに
バージョン管理、容赦ない回帰テスト、
完全な自動化。
この三本柱が整ったプロジェクトは、
チーム全体の信頼を生み、
ユーザーの問題解決に
まっすぐ向かうことができます。
ただ、本書でもあるように、
これはあくまで
「達人のスターターキット」
です。
私の所属するプロジェクトでも
この土台があるからこそ設計・開発に集中出来ているのだと
改めて実感しました。
本書『達人プログラマー』では、
ここで紹介した三本柱以外にも、
柔軟な設計やコミュニケーション術、
コードの考え方など
多くの知恵が詰まっています。
特にプロジェクト運営に
悩んでいる方や、
今より一歩先の開発を
目指したい方にオススメの一冊です。
ここまで読んでいただき、ありがとうございました。