アジャイルサムライを読んだ

どこかのタイミングで読もうと思ってて読めていなかった名著。

読まなかった理由としては仕事で体系的にスクラムをやっていたことに加えてスクラムマスターから、アジャイルソフトウェア開発宣言とスクラムガイドだけ読めば十分と言われた事もあって読まなかったのですが、自社サービスから受託会社に転職してスクラムから遠ざかっていたということもあって読んでみました。

エンジニアとしての覚悟というか心構え

この本を読む前までは、アジャイルな開発手法のプラクティスが詰まった本なのかなと思っていました。確かにそういう部分もあるけど、この本の本当のテーマは、マスターセンセイなる師匠と弟子の会話を通じてエンジニアとして生きていくための心構えを教えてくれる本でした。

• スクラムに答えはなくプロジェクトメンバーで全員で決める
• 決めたことに一人一人が責任を持つなど

などなど名言が多く書かれていました。

インセプションデッキ

言葉だけは知っていたけど具体的にプロジェクト初期段階のアジャイルは経験がなかったこともありよく理解できていませんでした。

インセプションデッキは、プロジェクトの全体像がどういったものなのかを端的に伝えるためのドキュメントです。

参照:アジャイルサムライ 47ページ

上記の大項目ごとにプロジェクトメンバー内で議論して指針を決めていきます。この作業でメンバーの共通認識を揃えることができるので、プロジェクト進行中によくありがちな「自分はこう思って開発してたんだけど違うの？」とか「この追加機能は本当にお客さんに必要なのかわからない」みたいなこともインセプションデッキがあると立ち返ることができます。

今回読み終わって改めて、インセプションデッキって受託開発でも絶対やっておくべき内容だと思いました。

受託開発あるあるとして、スケジュールがタイトだからとりあえず作り始めて納品前にドキュメントまとめたりとか、本当にお客さんが何を求めるのか分からないままプロジェクトが走り始めてそのまま開発が進んでしまう。みたいなケースがあって、本質が分からないまま進行していくことがただあります。

インセプションデッキを一番最初に作ることで何のために開発するのかなどが見えてくると思います。（要件定義が近いイメージだがもう少し深堀りしたやり方になる。）

自社サービスの場合は、ジョインした時には既に指針があるケースがあって数年単位で見直すことが重要そうと感じました。

アジャイルなプログラミング

他の章は、アジャイル開発の進め方的な話が多くプラクティスが紹介されていますが、特に最後の「アジャイルなプログラミング」の章が、エンジニアとしは肝に銘じておきたい素晴らしい章でした。

内容的には

• ユニットテスト
• TDD
• リファクタリング
• 継続インテグレーション（CI）

について解説してます。ざっくりまとめるとリファクタリングとテストはセットで、そのためにテスト駆動で開発していくことが重要で、デプロイは誰でも簡潔にできる仕組み作りにすること

何か機能を作る時も、まずプログラミングが失敗するテストをすべて書き出すことが重要だとこの本では書いていました。

自分はマークアップからフロントエンドに転身した身なのでしっかりテスト駆動を理解しているか微妙ですが、テスト駆動を日々意識している人のコードと自分のコードは明らかに何かが違うことが分かります。 自分で実装したプログラミングは絶対にバグを生み出さないコードだなんてありえないので、やはりテストは改めて重要だと感じました。

結構古い書籍ですが、今でも学びが多い本なのでおすすめです。