「すべてを作らない」 ～アジャイルを使った新しいシステム開発 (3)
これまで見てきたように、システム開発のプロジェクトに「すべてを作らない」視点を持ち込むことは、コスト削減・顧客満足度の向上・プロジェクトの短期化などの様々な効果が見込めることがわかります。そして、それを実現するためのプログラミング手法としてアジャイルが適していることを書いてきました。
では、アジャイル型開発手法がなぜ「すべてを作らない」ことに繋がるのでしょうか? それを考える前に、アジャイル型開発手法とはどのようなもので、それにはどのような目的があり、どのような効果があるのかを見てみましょう。
スクラムやエクストリーム・プログラミングなど、アジャイルが採用している手法については、雑誌やWebでもいろいろ紹介されていますし、ご存じの方も多いことと思います。一般的には、ソフトウェア開発の効率化という面で語られることが多いと思うのですが、今回一連のブログでご紹介しているのは「すべてを作らないためにアジャイルを活用する」ことですので、今回はその切り口から一連の流れを見ていきたいと思います。
とはいえ、アジャイルはソフトウェア開発の効率を上げることができることもまた確かですし、様々な効果もありますので、ウォーターフォールなど、一般的なプロジェクトにも応用できる内容だと思います。
アジャイルの手法 ～スクラムとエクストリーム・プログラミング～
戸田社長の行うアジャイル開発は、スクラムとエクストリームプログラミングを基本としているようですので(他にも様々な工夫があるとは思いますが)、これらの手法を中心に説明していきます。各々の手法については、様々なところで紹介されていますので詳細は避けますが、例えばいくつかのサイトで解説されているキーワードを抜き出してみると、
スクラム
- バックログ
- 「私の仕事、あなたの仕事」ではなく、「チームの仕事」
- デイリースクラム（昨日やったこと、今日やること、障害になっていること）
- タスクボード
- これからやること、着手していること、完了したことを見える化して共有
- ロール
- チーム主体のセルフマネジメント
エクストリーム・プログラミング (XP)
- テスト駆動開発
- ペアプログラミング
- リファクタリング
- ソースコードの共同所有
- 継続的インテグレーション
- YAGNI
などが紹介されています。本ブログのこれからの説明にもこれらのワードが関連します。
前回のブログでご紹介した「動くプロトタイプを作る」はテスト駆動開発、ミニマムな機能から作って徐々に機能を増やして行くのが「継続的インテグレーション」、毎日テストし、開発期間中常に改善を行っていくのが「リファクタリング」に相当するかと思います。今回は、日々の開発がどのように行われていくかをご説明します。
アジャイルプログラミングの実際
開発の開始とスプリント期間
開発の一番初めに、システムのどの機能から手を付けるかを決めます。最も基本となる、最も重要なプロセスから作り始め、それを拡張していくのです。この全体像をチーム全員で共有するのがスクラムでいう「プロダクトバックログ」です。プロダクトバックログから「次にやるべき作業（タスク）」を抜き出したものがスプリント・バックログです。スクラムでは顧客に対して1〜4週間毎にソフトウェアをリリースしますが、これを「スプリント期間」と呼び、その期間中に達成すべき目標がスプリントバックログとなります。
スクラムで言う「スプリント」とXPや反復型開発で言う「イテレーション」は概ね同じ意味のようですが、違いについては私自身まだ整理できてません。わかり次第また書きますが、この辺ご存じの方がおられましたら、コメントいただけますと幸です。
プロダクトバックログは適宜見直されますが、チームが完了をコミットできるスプリント・バックログを明確に決めることが目的で、余り先のことは細かく決めないのがコツです。先のことは変わる可能性が高いですし、「今」に集中するのが効率的だからです。
毎日の作業
朝会
日々の開発は、朝会（デイリースクラム）から始まります。このミーティングはチーム全員参加で、全体で15分程度で終了させます。朝会では各自が昨日やったこと、今日やること、障害になっていることを発表し、その日行うタスクを決めます。
タスクは、バックログを細かい単位に分割した作業目標で、１タスク30分〜1時間程度で完了できるくらいの粒度で設定されたものです。このタスクを付箋に書き、タスクボードに貼ります。タスクボードは「これからやること」「着手していること」「完了したこと」の3つに分けられており、最初はすべての付箋は「これからやること」に貼ります。
ペアプログラミング
XPで最も特徴的なプログラミング手法が、このペアプログラミングです。タスクボードもそうですが、これらの手法はアジャイルだけで無く、ウォーターホール型開発にも応用できるのではないかと思います。
ペアプログラミングは、その名の通り、2人のプログラマがペアになってひとつのタスクを完了させることです。タスクボードから付箋を1枚取り、「着手していること」のエリアに移動させ、完了予定時間を書き込みます。そして1人がコードを書き、もう1人はよこからそれを見ながら、いろいろとアドバイスをします。プログラミングをされた方ならおわかりでしょうが、プログラミングの際に多いのは、コマンド名や変数名を打ち間違えるなどのケアレスミスです。1人が横から見ていれば、この種のミスは激減します。また、アルゴリズムなども、片方が突っ込みをいれながら作っていくことにより、シンプルで他人が読んでも理解しやすいものになり、可読性が向上し、ドキュメント作成の手間も軽減されます。また、ソースコードを知っている人が2人になりますから、片方が休んでも作業が中断することもありません。
集中力が高まるのも、効率を上げる上で効果があります。特にベテランが初心者の前でコーディングする際など、その緊張は並では無いようで、「こんなに疲れたことは無い」という声も聞かれるそうです。
現実の運用ではいろいろなやり方があるでしょうが、戸田社長のところでは、プログラマのペアは毎日変えるということです。毎日違う相手とペアを組むことによって、緊張感が維持されますし、問題があれば過去のタスクに遡ってそれを修正するで全員が様々なタスクに関わることになり、全体のソースコードに対して参画意識を持つことができます。また、そのような環境だからこそ、見通しの良いコーディングが求められるということでもあり、ソースコードの可読性が高まるインセンティブになります。
見える化
こうしてひとつのタスクが完了すると、付箋を「完了したこと」のエリアに移動させ、完了時間を書き込みます。これでひとつのタスクは完了です。これにより、作業の進捗がどれだけ遅れて (進んで) いるか、どのタスクが予定より時間がかかったか等が一目瞭然でわかります。各タスクで起きた問題点は翌日の朝会で共有され、その日の作業予定に反映されます。
結合テスト
1日の終わりに、その日の成果と前日までの分を統合してビルドし、テストを行います。その日のタスクや過去のタスクにバグや問題があれば、翌日修正します。
デリバリー
アジャイルの最大の特徴です。1週間から4週間程度のスプリント期間 (戸田社長が関与するプロジェクトでは、原則1週間だそうです) を定め、スプリントの終了時に、それまでの成果を実際の動くコードとして顧客に納品します。サンプルでもモックアップでも無く、そのコードがゆくゆく本番コードになるという「本物」です。そのコードを顧客にテストして貰い、バグや顧客の想定と違っていた部分、新たな要望などを出して貰い、次のスプリントに反映させていきます。
これにより、機能の検証が可能な実際のコードを継続的に提供していくことが可能になります。これがプロジェクトの最後にならないと全貌が見えないウォーターホールとの最大の違いです。
いかがでしたか? こうして実際の流れを見てみると、あちこちに効率化のヒントや工夫が見て取れると思います。次回は、これにより「すべてを作らない」ことが可能になる仕組み、今回触れることができなかったロールの話、YAGNI、そしてアジャイルとTPS (Toyota Production System) の関係について、書いてみたいと思います。
新刊「【図解】コレ一枚でわかる最新 IT トレンド」 2月5日発売
ネットコマースさんと共同開催している「IT ソリューション塾」でお話ししている内容を再構成し、IT の最新のトレンドをわかりやすく解説した本を出版します。既に予約受付も始まっています。是非、お手にとって内容をご確認下さい。
ネットや雑誌には、最新の IT キーワードが溢れています。しかし、多くの場合、これらのキーワードは単独で解説されており、他のキーワードとの関連や、そのキーワードの持つ歴史までは解説されていません。しかし、新しい技術やサービスには、必ずそれが出現するに至った歴史、必要とされた背景、他の技術との関連があります。それらを理解せずに、単にネットの説明を丸暗記しても、他の分野への応用や他の技術と組み合わせた際の可能性について考えを広げることはできないのではないでしょうか。
本書は、約100枚のわかりやすい図表と平易な解説で、最新 IT の歴史・トレンドをわかりやすく解説します。さらに、本書に掲載されている全ての図表は、ロイヤリティ・フリーのパワーポイントでダウンロードできます。ご自身の勉強のため、提案書や勉強会の素材として、ご活用下さい。
