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

エンジニア向けの名著と呼ばれる本は数多くありますが、今回は『アジャイルサムライ――達人開発者への道』(オーム社、2011年)を取り上げ、著者の経験やアジャイル手法の実践例を挙げていきます。

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

数多くの開発者から支持を受け、読み継がれてきた名著。そこには読み継がれる理由があります。

名著には、内容・ボリュームともに充実した書籍が多く、概要に目を通しただけで本を読んだつもりになっていたり、腰を据えて読む時間がなく「積ん読」してしまいがち。「エンジニアが絶対読むべき書籍●選」といった記事をブックマークするだけで読んだつもりになっていないでしょうか。

ポイントを押さえつつ内容を深掘りし、名著の根底に流れるエッセンスを開発に活かしましょう。

アプリエンジニアの池田惇と申します。iOS/Androidそれぞれでフルスクラッチ開発を行ったり、PMや開発チームリーダーを経験しました。最近はAndroid TVのアプリをKotlinで開発しています。

エンジニア向けの名著と呼ばれる本は数多くありますが、今回は『アジャイルサムライ――達人開発者への道』(オーム社、2011年)の内容にふれるとともに、私の経験やアジャイル手法の実践例を挙げてみたいと思います。

アジャイルの本流を汲む『アジャイルサムライ』

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

【用語】アジャイルとは、変化に対応しながら素早く価値を届けるための開発手法の総称です。近年は従来型の開発手法では変化のスピードに対応することが難しくなってきたため、多くの企業で採用されています。代表的なフレームワークとして、スクラムやカンバンがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 我われはなぜここにいるのか?
  2. エレベーターピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. 「ご近所さん」を探せ
  6. 解決案を描く
  7. 夜も眠れない問題
  8. 期間を見極める
  9. 何を諦めるのか
  10. 何がどれだけ必要か

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

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

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

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

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

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く