『アジャイルサムライ――達人開発者への道』に学ぶ、開発フロー効率化のススメ！ 【今こそ読み解きたい名著】

開発サイクルを短くし、仕様変化に強い開発手法として、多くの開発現場に取り入れられているアジャイル。『アジャイルサムライ』はアジャイルプロジェクトの準備から実際にソフトウェアを作って成果を出し続けるところまでを広く解説した一冊です。期日を守るだけでなく、ユーザーがソフトウェアを喜んで使ってくれることまでをゴールとしています。

アジャイル開発の原点とされているのが、アジャイルマニフェスト（アジャイルソフトウェア開発宣言）です。この本は、アジャイルマニフェストの一部である「アジャイル宣言の背後にある原則」の12項目を重要なポイントとして取り上げており、まさにアジャイルの本流を汲んでいると言えるでしょう。

内容は硬派ですが、マスター・センセイと弟子による会話や、挿絵や軽快な文章を用いてテンポよく書かれているため、とても読みやすいです。

ソフトウェア開発のプロとして成果を出すヒントを紹介

ソフトウェア開発に関わる方であれば、以下のような経験をお持ちではないでしょうか？

• 要件が決まらないなど、開発前工程がなかなか進まない
• プロジェクトの期日が厳しくて余裕がなくなってしまう
• タスクをこなすのに精一杯で、ユーザーにとって価値の高いものを作れない

私自身、開発に携わる中でこのような状況を何度も経験しました。プロジェクトがうまく進まずに疲弊し、不満を募らせて辛く感じることもあると思います。

対して「アジャイルサムライ」の定義は、こうした苦しい開発とは対照的です。

アジャイルサムライ - それはソフトウェアを顧客に届ける猛々しきプロフェッショナルだ。たとえプロジェクトがきわめて過酷な状況であろうと、かつてなく手ごわい期日であろうと、成果をあげる力量を備え、しかも品格と平静さを失うことがないのだ。

『アジャイルサムライ――達人開発者への道』p. xiより

同書では、ソフトウェア開発のプロとして振る舞い、成果を出すためのヒントや実践的な方法が多く紹介されています。

『アジャイルサムライ』で押さえたいポイント

『アジャイルサムライ』には、アジャイルプロジェクトに取り組んでいない人はもちろん、すでに取り組んでいる人にも役立つTipsが紹介されています。

奇跡に頼らず、アジャイルで解決しよう

残念ながら、無茶な期限が設定されるプロジェクトは少なくありません。

現実には守れもしない約束がかわされることもあれば、チームがそれに対して「できません」と言えないこともある。というか、実によくある話だ。でも結局のところ、できないものはできないんだ。それでもなお、見せかけだけの「奇跡によるマネジメント」を続けるのなら、それはプロジェクト運営として実に残念であると言わざるをえない

『アジャイルサムライ――達人開発者への道』p.10より

無茶な期限設定のもとでたとえ奇跡を起こせたとしても、中長期的には大きなマイナスになります。品質を無視した開発では、サービス運用開始後に重大なバグが見つかる可能性が高まりますし、タイトなスケジュールを守るために長時間の残業をすれば、開発者が心身不調になってしまうでしょう。

同書では、奇跡に頼らず誠実に仕事を進める大切さを説きます。

アジャイル手法なら、こんな奇跡は必要なくなる。なぜなら、当初から顧客には隠し立てをせず、誠実に仕事を進めるからだ。開発者は顧客に事実をありのままに伝える。顧客は現在の状況について十分な情報を得たうえで、スコープ、予算、期日の判断を下す。 （中略） 信じることのできる計画を立てて仕事を進めていくのを選ぶことだってできるんだ。

『アジャイルサムライ――達人開発者への道』p.10より

自分が抱える問題を隠さず、顧客と一緒に解決策や計画を準備すること。透明性は、アジャイルの特徴です。計画や成果、起きている問題などを隠したりせず、常にオープンにすることで強いチームを作っていくことができます。

このように、アジャイルは開発者だけでなく、顧客（もしくはプロダクトオーナー）を含めたチームで取り組む必要があります。お互いに知っている事実を誠実に伝え、透明性を持って動けるチームを目指せると良いでしょう。

何をやるのかと同じくらい、何をやらないかが重要だ

アジャイルプロジェクトを始めるときに準備すべきものとして、10の要素から構成されたインセプションデッキが紹介されています。

インセプションデッキとは、プロジェクトの目的や背景、方向性を明らかにしたドキュメント。この10要素を事前に準備することでプロジェクトをスムーズにスタートさせ、開発途中でのスピード低下を防げます。

本の中では1つずつ書き方や例が紹介されていますが、ここでは単体で使え、すぐに効果が現れやすい「やらないことリスト」を紹介します。

やらないことリストを作ることで、何がプロジェクトのスコープ内で、何がスコープ外なのかを明確にできる。この効果は、お客さんがプロジェクトに期待できることをわかりやすくすることだけに留まらない。開発チームが本当に重要なことだけに集中できるようになるんだ。

『アジャイルサムライ――達人開発者への道』p.63より

「やらないことリスト」は、プロジェクト進行中の要件追加を防ぐことができます。ここでは、ニュースアプリを作る際の「やらないことリスト」をケーススタディに挙げてみます。

リストは、やる・やらない・あとで決めるの3つの欄から成ります。

「やる」の欄にはプロジェクトで取り組む項目を並べます。「やらない」の欄にはスコープ外のものを並べ、気にしなくてOKとします。「あとで決める」の欄には今決められない項目を入れておき、後で判断します。

やらないことを列挙しておくと、プロジェクト外の関係者に説明する際に役立ちます。

たとえば「記事をクラウドに保存する機能があったほうがいいんじゃない？」という意見が挙がったら「プロジェクト開始時に○○という理由でスコープ外にしました」と回答できます。きちんと検討した上で判断したことが伝えやすくなり、いたずらな要件追加を防ぐ効果があります。

事前にやる・やらないを判断しておくと、重要でない機能を減らせます。開発チームは価値の高い作業に集中して取り組めるのです。

必要な分だけを、必要なときに

開発を進める際には、設計や分析といった事前準備が必要です。しかし、設計や分析をしてドキュメントを作ったものの、あまり活用できなかった（もしくは使わなかった）という経験はないでしょうか。ソフトウェア開発は絶えず状況が変化するため、事前に準備をしていてもドキュメントをうまく利用できないケースがあります。

アジャイル開発では必要な分だけ分析することを推奨しています。

アジャイル分析には2つの重要な柱がある。一言でまとめると「必要な分だけを、必要なときに」だ。まず、「必要な分だけ」とは、実際に作業を進めていくうえで必要な分だけを分析するということだ。分析しすぎてもだめだし、分析しなさすぎてもだめだ。

『アジャイルサムライ――達人開発者への道』p.187より

みなさんの開発チームが数人であれば、Excelなどを用いた詳細なドキュメントはあまり必要ないでしょう。毎日集まってコミュニケーションをとっていれば自然にうまくいくことも多いと思います。一方で大規模なチームで働いているのであれば、規模にあった形式でドキュメントを準備する必要があるかもしれません。

ソフトウェア開発には不確実性がつきものであり、不安が生まれることがあります。特にPMや開発リーダーは、メンバーの不安を取り除こうとドキュメントをたくさん準備したくなる方もいるでしょう。

しかし、過剰な準備はリソースを消費して本来開発に充てられる時間を減らします。また、変化する状況に合わせてドキュメントを常に更新し続けることは難しく、古くなったものが使えないため実装のタイミングで再度最新のドキュメント作成が必要……という悪循環を生んでしまうこともあります。

このように、不安を解消しようと過剰な準備をしてプロジェクト失敗の確率を高めてしまうのは避けなければなりません。シンプルに、「このくらいで十分だ」とチームで合意ができれば問題ないため、自分たちの開発規模や環境に合わせて必要十分な情報をそろえれば良いのです。

必要なときに分析する － ジャストインタイムの分析とは、ユーザーストーリーを実装するタイミングが近づいてきてから、突っ込んで分析するということだ。具体的には、ストーリーの実装を予定しているイテレーションの1つ前のイテレーションで分析することになる。

『アジャイルサムライ――達人開発者への道』p.189より

• ユーザーストーリー：ユーザーが実現したい機能や特徴
• イテレーション：開発期間を1～2週間ごとに区切った期間

プロジェクト開始の段階では最低限のラフな分析にとどめ、実装に着手する直前で細かな分析に着手することを薦めています。

このように、チームにとって必要な粒度・量・タイミングで分析やドキュメント化を行うことで、効率と柔軟性を保つことができると言えると思います。

アジャイル開発を現場で活かすには

チーム規模やプロジェクトによって最適な開発スタイルは異なります。アジャイルのメリットを開発現場で活かすには、どのように取り入れていけば良いのでしょうか。

メンバーの目線がそろえば、自然とチームワークが生まれる

アジャイルで目指すのは、価値の高いものに集中して取り組み、短期間でサイクルを回して成果を出すこと。そのために、メンバーがプロジェクトの目的を正確に把握し、自発的に判断をする必要があります。

アジャイル開発の下地を整えるために、まずはプロジェクトの準備段階から手法を取り入れてみるのはいかがでしょうか。先ほど紹介したインセプションデッキから、いくつか選んでやってみることをおすすめします。

たとえば「我われはなぜここにいるのか？」を準備してプロジェクトの目的を明確にすれば、メンバー全員が自分で考えて判断しやすくなります。「エレベーターピッチ」と「やらないことリスト」を追加すれば、開発するプロダクトの強みや逆にスコープ外とするものが明確化します。

私がある機能の追加開発に取り組んだとき、プロジェクトのキックオフミーティングで「我われはなぜここにいるのか？」と「やらないことリスト」を作りました。仕様決定のスピードが速くなり、途中での手戻りも防げたため短期間でリリースに至ることができました。

このように、アジャイル開発の手法をプロジェクト準備段階で活用することでチームメンバー間の目線がそろい、プロジェクトのスピードアップや協力や提案が増えて自然とチームワークが生まれることが期待できます。

もし課題の多い現場に直面しても、少しずつ良いサイクルをまわすためのヒントにできるのではないでしょうか。

開発作業をアジャイル向けにしていこう

自分の開発作業をアジャイル向けにしていくのも良いでしょう。仕様変更に強くし、リリースまでのスピードを高めるためには、ユニットテストやCI（継続的インテグレーション）が有効です。

ユニットテストで修正、設計見直しの機会を作る

ユニットテストがそろっていれば、開発する機能や計画が変わった際にも、既存のソースコードに安心して手を加えることができます。手動のテストを減らしてデバッグやリリースまでの時間を短縮することもできるため、プロジェクトのスピードアップにも繋がります。

私は、一度バグが見つかったところはユニットテストを先に書いてから修正するようにしています。修正されたかどうか明確になりますし、バグの再発を防ぐこともできるからです。ユニットテストを書くことで、設計の良くない部分も明確になるため、設計見直しのきっかけになることも多いです。

CIやプルリクエストは作業単位を細かくしよう

CIはツールを使ってビルドやテストを自動化するだけでなく、作業単位を小さく保つことも大切です。GitHubを使っているプロダクトであれば、プルリクエスト（Pull Request）を作業単位にしていると思います。1つ1つのプルリクエストを小さくして取り込みやすくすれば、コードレビューの負担が減るだけでなく、お互いの開発内容が早い段階でわかるため手戻りも少なくなります。

加えて、リファクタリングにも継続的に着手していくのが良いと思います。アジャイルプロジェクトであれば、リファクタリングもイテレーションに組み込んで取り組むと進めやすいと思います。

このようなアジャイル向けエンジニアリングプラクティスについては、「第5部 アジャイルなプログラミング」に詳しく書かれています。

アジャイルフレームワークを知る

特にWeb系企業など、すでに多くの開発現場でアジャイルが導入されています。使われているアジャイルフレームワークとしては、スクラムやカンバンがありますが、ここでは最もメジャーなスクラムを紹介します。

スクラムとは

計画型のウォーターフォール開発に対し、スクラムは経験型と呼ばれます。要件やスケジュールは絶えず変化することが前提となっており、1～2週間のイテレーション（反復）ごとに計画と振り返りを行い、そのサイクルを繰り返すことでチームに経験を蓄積していく手法です。

スクラムにはいくつかの役割があります。やることの優先順位決定に責任を持つプロダクトオーナーや、周囲をサポートして物事がスムーズに進むように働きかけるスクラムマスターなどです。

スクラムでは定期イベントもいくつか設けられており、毎日のスタンドアップミーティング、おおよそ週1回の計画ミーティングと振り返りなどが行われます。

スクラムの要素だけ取り込むのも有効

うまく活用できれば開発効率が上がる一方で、形式的に取り組んでしまうとミーティングに多くの時間を割いてしまいます。そこで、形にこだわりすぎずスクラムの要素を柔軟に取り込んで実施している現場も増えてきました。

たとえばサイバーエージェントが手がけるインターネットテレビ局AbemaTVでは、毎日のスタンドアップミーティングを省略したり、ツールを活用してコミュニケーションの効率を高めながら取り組んだりしています。

特集：「差別化」をリードする、アジャイル時代のプロジェクト管理（4）：マイクロサービスベースのAbemaTV開発プロジェクトが切り開くスクラムとプロジェクト管理の“新境地” - ＠IT

スクラムについてのコミュニティもあるので、もっと知りたい方は勉強会などに参加して色んな例や経験を聞いてみるのも良いと思います。

最近ではリモートワークを導入する企業も増えてきています。自分たちに合ったスクラムの形を見つけたりツールを活用していくことは、リモートワークに強いチームを作ることにもつながるのではないでしょうか。

スクラム事例が豊富な『SCRUM BOOT CAMP THE BOOK』

初めてスクラムに取り組むときの参考書は『SCRUM BOOT CAMP THE BOOK』（翔泳社、2013年）がおすすめです。半分くらいはマンガで描かれており、初心者が困りやすいポイントをわかりやすく解説しています。

これからスクラムを始めようとするときにまず何をすれば良いのか、問題が起きたときの解決策としてどんなものがあるかなど、多くの事例を見て学ぶことができます。私も初めてスクラムを行う時はこの本を読んでから取り組みました。

おわりに

名著『アジャイルサムライ』のポイントとともに、開発現場でのアジャイルの取り組み例を紹介してきました。最後に、過去のプロジェクトでアジャイル手法を実際に取り入れたときに気づいたことを挙げてみます。

メリット：コミュニケーションが増え、意思決定速度が上がった

アジャイル手法では計画、実行、振り返りを短期間で回すので、必ずコミュニケーションの機会が増えます。毎日話すことで、メンバー同士の理解が深まり、自然に協力しあう環境（雰囲気）が生まれました。また、企画・デザイン・設計・実装、すべてのサイクルが短くなり、意思決定スピードが速くなりました。

リファクタリング・グロースハックに取り組むには工夫が必要

継続的な取り組みを行うためには、工夫が必要です。リリースして終わりにならないように、今後はプロダクトの効果を計測しつつ、新規・中止・追加開発などを素早く判断し、リファクタリングやグロースハックにも力を入れていきたいです。

皆さんも、初めから多くのことに取り組む必要はないので、活用できそうなことから少しずつ取り組んでみてください。

著者プロフィール

池田 惇（いけだ・じゅん）@jun_ikd

スマートフォンアプリエンジニア。iOS・Androidのアプリ開発を行いながらPMや開発チームリーダーを経験。エンジニアとして技術を学び続け、プロダクトマネジメントや人材育成でも活躍したい。アジャイル開発とオープンソースソフトウェアの活用を好む。

編集：薄井千春（ZINE）