みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。
『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰り返しています。
だからこそ、『Agile Journey』では、読者のみなさんの「実践」につながる情報発信を追求したいと思っています。それぞれの現場・組織によって人や状況、コンテキストは異なり、アジャイルを実現するうえで、注力すべきポイントや実践手法も異なります。さまざまな現場で培われた「アジャイルの実践事例」を数多く世の中に提供し、記事を読んでくださった方々が、それぞれの現場でアジャイルを実践していく。このメディアを通じ、選択肢と気づきを得てくだされば嬉しいです。
さて、「実践」をコンセプトとするメディアならば、本稿もただのご挨拶ではなく、なんらかの実践事例をお伝えするべきでしょう。私自身、15年にわたってアジャイルに取り組んできました。ここからは、私がさまざまな現場で経験した「アジャイルの実践」と、その時々の試行錯誤をお伝えしていきたいと思います。
- 「これでいいのか？」への回答がアジャイルだった
- まずは自分が実践する
- アジャイルを始める第一歩。成果を上げ、信頼関係を構築する
- 「1人アジャイル」を実践してみよう
- 【1人アジャイルの手法①】テストファーストを実践してみる
- 【1人アジャイルの手法②】正確な見積もりを実践してみる
- 【1人アジャイルの手法③】ふりかえりを実践してみる
- 【1人アジャイルの手法：発展編】1人でも開発全体を経験してみる
- 【1人アジャイルの手法：発展編】少人数で実践してみる
- 会社や事業経営へと拡大するアジャイル
- まとめにかえて
「これでいいのか？」への回答がアジャイルだった
私は2004年にプログラマーとしてのキャリアをスタートし、以降、3年程の間に実にさまざまなプロジェクトを経験しましたが、当時はいわゆるデスマーチと呼ばれるプロジェクトは珍しくありませんでした。こうした環境で育ったので「開発とはデスマーチで当たり前」。そんな思考停止になっていた自分がいたのです。しかし、周りを見渡してみると、過酷な状況で肉体的、精神的に病んでしまう人がいましたし、大事な出産に立ち会えなかった、など、多くの不幸がありました。こうした状況を見聞きするほどに、「はたしてこれで良いのだろうか？」と疑問が次から次に湧いてきたのです。
2000年代中盤に主流だったウォーターフォール開発は、良くも悪くも開発の各フェーズであらかじめ決められた型のなかで仕事をすることが要求され、プログラマは「良い歯車」としての役割が期待されていました。とくに大規模開発では、「決められた書き方や、設計書に準じてコーディングすることで、プログラマのスキルの多寡にかかわらず、アウトプットを平準化する（品質を保つ）」という考え方がときに存在していました。高いプログラミングスキルを持っていたとしても、その能力は必要とされない状況だったのです。
しかし同時に、2000年代中盤とは、先鋭的な開発手法としてアジャイル関連の本が多く出版され、日本でも徐々に注目度が高まってきていた時期でもありました。XP、スクラム、リーンソフトウェア開発といった、さまざまな開発手法やフレームワークを学んでいくなかで、私が感じたのは「アジャイルとは『人』に焦点を当てているのだな」でした。人の可能性を信じ、プログラマーの能力を最大限発揮させ、プロジェクトに関わるメンバーの協調を大事にし、ビジネスの変化やユーザーの要求の変化に対応する。こうしたアジャイルの根本にある考えは、ウォーターフォール開発の渦中で私が感じていた疑問すべてに、答えを出してくれていたのでした。開発するのは「人」なんだ、と。プログラミングスキルを磨くことには価値があるんだ、と。ビジネスサイド、プログラマーなど、開発に関わるすべての人達はともに進んで行っていいのだ、と。
まずは自分が実践する
アジャイルに大きな可能性を感じた私でしたが、それを現場に落とし込んでいくためには、さまざまなインプットやプロセスが必要でした。まず、当然ですが、アジャイル導入のためにはさまざまなプラクティスの具体的な内容やメリット・デメリットを把握せねばなりません。しかし、個人的に概要把握と同じくらい重要だと思っているのは「自分自身がそれを実践する」ということです。
書籍にある概念やプラクティスを読むだけで100%理解するのは難しいでしょう。私自身、書籍を繰り返し読み概念把握に努めましたが、理解が深まった、と感じられたのは「実践」のなかにおいてです。さらに、周囲を巻き込んでアジャイルを展開していくのであれば、その意味や効果を伝えられなければなりません。だからこそ自らが誰よりも実践し、日々の開発の中でプラクティスを体現することで、他のメンバーへの「アジャイルの意味」の説得力を上げるのが大事になると思います。
アジャイルを始める第一歩。成果を上げ、信頼関係を構築する
では、アジャイルをどのように実践していくか。恥ずかしながら私は昔、アジャイル開発の導入に関して否定的だったり積極的ではない上司に反発的な態度を取ることが少なくありませんでした。しかし冷静に振り返ってみると、思うような反応が得られなかったのは、私自身の提案力に課題があったこと、なによりその人達と私の間に十分な信頼関係を構築できていなかったことが大きな要因だったと思っています。アジャイル実践においては、まずは私、ひいてはアジャイル開発への信頼を醸成する必要があったのです。
まずは「現状」で成果を上げることに集中する
私が取り組んできた、過去十数年のアジャイル開発導入経験において、「上手くいった」と思えるケースにはパターンがあるように思います。まず最初はアジャイルやプラクティスなどを一旦抜きにして、その開発現場のやり方をリスペクトし、従来のやり方で最大限努力し、成果を上げることに集中する。これが成功パターンの端緒です。成果を上げることで周りのメンバーやマネージャーとの信頼関係が得られます。十分に信頼関係が構築できて自分の提案などに耳を傾けてくれる状況になってから、初めてアジャイル開発などの改善提案をするとスムーズに物事が進みやすいです。もちろん、改善提案であればどのような状況でも常に検討されるべき、という意見は正しく理想的です。しかし、現場やそこに関わる人たちのことをなにも知らない状況で、「こうするべき。こうしたやり方が正しい」とあれこれ言っても、それは現状批判と受け取られかねません。そしてなにより、信頼関係が築けている状況であれば、改善に向けたサポートが受けやすくなってきます。なので私は最初はまず現状で最大限の成果を出し、信頼関係というアジャイル開発導入への下地づくりにフォーカスします。
アジャイルで成果を出すコツ
アジャイルなき現場に、アジャイル開発導入の端緒が得られた。もちろん、ここがゴールではありません。当たり前ではありますが、アジャイル開発というのはソフトウェア開発を進めていくうえでの手段の1つです。ですからアジャイル開発（それ以外でも、なんらかの新たな手法）を導入した場合、導入前以上の成果が期待されます。逆に言えば、成果が出なかった場合は「やっぱりね」となり、せっかくの変化の兆しが失われてしまう可能性があります。ですから、新たな手法を導入する場合は"必ず”成果を上げなければなりません。ひとたび成果が上がれば、ステークホルダーとの信頼関係はさらに向上し、より踏み込んだ提案ができる可能性も生まれます。
それができれば誰も苦労しないよ、と言われそうですが、まずは大きな成果を目指さず小さく始める、というのがポイントになってきます。これをもう少し具体的な言葉にすると、
- 自ら実践すること
- 可能なかぎり小規模で始めること
- 小さい成果を積み重ねること
と表現できます。
最初期においては、「まずは1人で実践する」くらいの意識でもいいでしょう。仮に1人でアジャイルを始めたとしても、「手を動かして初めて見えてくること」もあると思います。私自身、「やって分かった」と実感したことが何度もありました。
ですから本稿では、私が実践してきた1人でも取り組めるアジャイルをまずはお伝えしたいと思います。私が最初に取り組んでみたのは、アジャイル実践手法のごく一部に過ぎず、また、すべて私自身の経験に基づくやり方ですが、ひとつの事例・サンプルとして捉えていただき、皆さんの今後の開発において何かしらの気付きになってもらえれば嬉しいです。
「1人アジャイル」を実践してみよう
アジャイル開発というとチームや組織として取り組まないといけない壮大なもののように聞こえるかもしれません。しかし、その中身を分解してみると意外と1人でも取り組めるようなプラクティスも存在します。「以前取り組んでみたけど上手く行かなかった」「アジャイル開発をやってみたいけど、今のチームの方針だと不可能だ」「どこから手を付ければいいのかわからない」といった方は、まずは1人で気軽に取り組んでみることをおすすめします。なぜなら、複数人でやるよりも1人でやる方がコストも難易度も低くなるからです。また、1人で実践してみて得られたコツや課題を自分のなかで整理すれば、複数人で取り組む際の難易度も下げられると考えるからです。書籍などでこうした「1人アジャイル」に言及されることはあまりないですが、私個人はかなり重要な「始め方」ではないかなと思っています。
【1人アジャイルの手法①】テストファーストを実践してみる
私の場合、20年近く前にガチガチのウォーターフォール開発の中でこっそり1人でテストファーストを実践してみたことが、アジャイル開発（XP）の第一歩でした。当時はまだエンジニア歴2年目ほどで、開発全体をアジャイルにする権限は当然ありませんでしたし、アジャイルの知識も本を読んだくらいでした。ですが、「テストファーストは1人でもできそうだ」と思い、これに取り組んでみたのです。あくまで自分が担当する開発の範囲でテストファーストを実践し、JUnitやDBUnit、Selenium IDEなども使って、他の開発者の迷惑にならないようにひたすらテストを書いていました。当時、テストを通してIDEのテスト結果を表示するバーが緑になり、テストの件数が少しずつ増えていくのが異常に楽しかったのを覚えています。
部分的とはいえ、1人でもXPは実践できるし、その中でスキルを磨くことができた、という体験は自分の中でとても大きなものでした。当然ながら最初から上手くテストが書けたわけではなく、私個人の導入コストが必要でしたが、「自分のスキルが足りないからコストがかかっているはず」「どうすればもっと上手くテストファーストを実現できるだろうか」と自分に問いかけ続けたのは今振り返っても良い経験だったと思っています。「守破離」の「守」は強く意識していました。
「1人テストファースト」の実践手法
「1人テストファースト」実践の前提は「自分のためだけに、とにかく書いてみる」です。現場によっては単体テストのプログラムを成果物として納品する必要があったり、チームや組織の方針で開発におけるテストの方法や書き方が決まっている場合などがあると思います。そのような状況では、いわゆるTDDにおいて一般的に良しとされているやり方や書き方を実践するのが難しく、もどかしい気持ちになっている人もいるかもしれません。そんな時にはまず「自分のためだけ」にテストファーストを実践してみるのも良いかもしれません。
さて、多くの場合、単体テストも含めたプログラムはGit等にPushされると思います。方針と違うプログラムをPushすることが禁止されている場合もあるかもしれません。ですから、ローカルに自分だけのブランチを作成し、そこに自分のためだけのテストコードを書きます。ブランチにコミットもできない場合はローカルの適当な場所に保存し続けるでもいいでしょう。私もそういう事をやっていました（笑）。
自分だけの場所を確保したら、あとはテストファーストの実践です。といっても自分が書くプログラムすべてでやる必要はありません。最初は1日1ケースで十分かもしれません。小さな関数やメソッドを作成する際に最初にテストケース、Assert文、テストの中身を書き、テストを失敗させ、実装し、テストをパスさせ、リファクタリングをする。これを1日（もしくは数日）のプログラミング作業の中で一番やりやすい小さな箇所でやってみます。既存のプログラムに手を入れる時に同じようにする必要はありません（既にテストがある場合は別です）。あくまで自分のためにやるテストなので自分で一から書く小さなプログラムから始めてみるといいでしょう。
こうしたスケールの小さなテストファーストでも、効果は感じられます。私の場合、まず実感できたのは「不安が減る」でした。まだ経験の浅い当時の私にとって、日々の仕事は「コンパイルは通るけど、ちゃんと動くのだろうか……」という不安との戦いでした。しかし、「一人テストファースト」を実践することで、こうした不安は少しずつ減っていき、自信を持ってコードを書けるようになったのです。これは私の中ではとても大きな変化でした。また、バグの減少、設計の洗練、リファクタリングのしやすさの確保といった、テストファーストやTDDのメリットとして挙げられる要素も肌で感じられました。
では、どの程度テストを書くのか。これも、最初からたくさん書く必要はないと思います。仮に毎日1ケース書くだけでも、100日繰り返せば100ケースです。100ケースも書けば、それなりに書けるような気持ちになってくるものです（笑）。また、積み重ねていくなかで既存のテストをパスさせ、そこにさらにテストを追加していくことになるわけですが、自分のためだけに書いているコードなので、完全にコントローラブルな状況でテストの経験を積めるのです。
既存の作業に追われ時間を作れない方でも1日1ケースだけ自分のために書いてみる、というやり方ならば、なんとか時間を捻出できるのではないでしょうか。
E2Eテストをテストファーストで実践してみる
手元でのテストが回り始めたら、次はE2Eテスト（現場によっては「UAT：受け入れテスト」と表現されているかも知れません）です。E2Eテストも1人で取り組めますし、その意義は十分あると思います。
アジャイルかどうかに関わらず、開発においては作業を細かく分割し、ストーリー、タスクといった単位で管理されている場合があるでしょう。E2Eテストは自動化が重要ではあるのですが、開発プロセスのなかで捉えると「そのタスクやストーリーにおいて、なにを実現すれば完了とみなすのか」をきちんと言語化（定義）するのが大変重要です。ですから、チームや組織として取り組まなければ効果がないわけではなく、自分自身に割り振られたストーリーやタスクを終わらせるために、自分自身のために取り組むというのは十分に合理的かと思います。
E2Eテストのケースを洗い出す
タスクが割り振られた際、「なにを、どこまでやれば完了といえるか」というのは誰しも考えることかと思います。このプロセスは、言い換えれば自分のタスクによってシステム化（機能追加）される箇所の「仕様」を考えていることと同義のはずです。E2Eテストのテストファーストとは仕様を言語化し、その言語化された内容にそってテストの自動化をするということです。つまり、自動化は一旦置いておいて、自分のタスクを問題なく終わらせるための「完了の言語化」をタスクに組み込んでみるといいでしょう。
TDDには「アサートファースト」という考えがあり、単体テストを書くとき、最初にAssert文（Expectation）を書きます。こうして、記述する単体テストのゴールを最初に明確化するわけですが、これと同じことをタスクレベルで行うわけです。
このケースはあくまで自分のためのものなので、ローカルのテキストファイルでもGoogle Docsでも好きな場所に記述して保存すれば問題ありません。また、使い方によってはこの記述をリーダーやマネージャー、QAメンバーにレビューしてもらって認識の齟齬がないことを確認する役にも立つでしょう。
E2Eテストを自動化してみる
上記に慣れてきたらE2Eテストの自動化を試みます。ただし、数あるアジャイルのプラクティスの中で、この作業が一番難易度が高いと個人的に思っています。単体テストに比べて環境の準備にコストがかかること、実行時間が長くなりがちなこと、テスト結果が不安定になりやすいことなどがその理由です。
最も取りかかりやすいのは、まずブラウザ操作をレコーディングし、その後（2回目以降）はそのとおりに再実行してくれるツールを使う方法です。変更が発生した時のメンテナンスに多少の難はありますが、お手軽に試せるのでE2Eテストファーストの自動化の最初の一歩としては十分かと思います。ケース数がある程度増えてくると上に挙げたE2Eテスト特有の難しさに直面してきますが、なによりまずは試してみることが重要です。その後に出てきた課題に対して適切に取り組んでいくのが早道だと思います。
この自動化も、あくまで「自分のため」です。自分が担当している部分に関しては、どのような形であれ動作確認やマニュアルのテストなどをしている方がほとんどかと思います。なので、自分の作業負荷（動作確認やマニュアルテスト）を減らすために自動化を試みる、というわけです。いきなり複雑なテストケースの自動化に取り組むのではなく、簡単に自動化出来そうな場所から自分のために自動化してみる、というスタンスで気軽に臨むのがいいと思います。
【1人アジャイルの手法②】正確な見積もりを実践してみる
さて、プログラミングに入る前の段階でも「1人アジャイル」の実践は可能です。たとえば、見積もりです。アジャイルは決して無計画に進めるものではなく、計画し、さらに計画を変化に適応させていくことが重要です。そして、計画にこうした柔軟性を与えるためには、適切な見積りが必要になってきます。もちろん、見積もり能力とはステークホルダーから信頼・リスペクトを得るためにも重要な要素といえます。
マネージャーから「100個のタスクを完了させてほしい」とお願いされたとします。自分としてはそれが難しいことはわかっているけれど、なんとかなるかも、と思ってオーダーを受け入れた結果、80個までしか完了できなかった。別の世界線があったとして、同じようにお願いされたけど「80個までしかできないですがよいでしょうか」と答え、実際に80個完了したとします。どちらの場合もアウトプットは同じ80個ですが、マネージャーとより信頼関係が築ける可能性が高いのは後者の受け答えのはずです。
自分が受け入れられるタスクを試算する、つまり見積もりとは、他のメンバーやリーダー・マネージャーといった人たちから信頼を得るための有効な手法なのです。見積もり手法としてはプランニングポーカーがよく知られていますが、「1人見積もり」においてこれは必要ありません。見積もりにはポイントを使う、時間を使う、大・中・小で分ける、すべて同じくらいのサイズに分けるなど、さまざまなやり方がありますが、まずは0、0.5、1、2、3、5、8くらいのポイントを使って見積もりをしてみるのが手っ取り早いでしょう。
規模とベロシティを分けて考える
ポイントで見積もる場合、基本的に類似したタスクやストーリーは同じポイントにします。類似タスクが複数あった場合、後半のタスクは最初にやったタスクより早く終わらせられる可能性が高いでしょう。それでも、すべて同じポイント（規模）を付けるのが原則です。なぜなら、ポイントで見積もる場合、規模（ポイント）とベロシティ（スピード）を分けて考えるのが重要だからです。これは規模の測り方は変化することがなく、変化するのはベロシティだ、という考え方に基づいています。
例えば、100mを20秒で走れる人がいたとします。その人がトレーニングの結果、100mを10秒で走れるようになった（ベロシティが変化した）としても、走った距離（ポイント / 規模）は100mであり、70mでも200ｍでもありません。プログラマーは開発を続けるなかでさまざまな経験をし、成長します。同じ処理を共通化し、生産性を上げることもあります。結果、走るスピードは上がりますが、対象タスクの規模が小さくなっているわけではないのです。
見積もりにおいては、ベロシティという変化する要素、つまり不確実なものを除外することより確実性の高いものになります。仮にベロシティ向上によってタスクが早く完了したとしても、「タスク完了」の価値は変わらず、確実性の高い見積もりを上司やメンバーに提示できれば、より周囲からの信頼獲得に寄与してくれるでしょう。
また、ベロシティを変化させるのは個の能力だけではありません。プロジェクトの置かれた状況やメンバーのスキル・業務知識の習熟度によっても変化していきます。こうしたさまざまな変動要素を考慮してベロシティを算出するのは決して簡単ではありませんが、重要なのは過去の実績を参考にすることです。なお、見積もりをするうえで祝日や会社やチームのイベント、自身の休暇予定を計算に入れることを意外と忘れがちだったりするので、この点も注意が必要です。
見積もり直しと、過去の実績の参照
頻繁な見積もり修正はおすすめしませんが、「修正に適したタイミング」はあります。それは、大きなリリース直後など、なんらかの理由で区切りがつくタイミングです。こうしたタイミングで自分の見積もりを見直し、「思ったよりポイントの低いタスクだった」「思ったより大変（ポイントを高くすべき）なタスクだった」など、ポイント（規模）評価が間違っていたものを修正します。こうした評価軸の修正によって、以降の見積りの精度はさらに高くできるでしょう。もちろん、2回目以降の見積もりの時は、過去の見積もりと実績を参考にするのを忘れないようにしてください。
そもそも見積もりとは最初から正確に行うのはほぼ不可能な作業です。慣れないうちは大きく外すこともあるかと思いますが、大事なのはその結果をきちんと自分の資産・知識にできるかどうかです。上手く見積もれなかった場合は、問題がポイント評価にあったのか、それともベロシティ算出方法に問題があったのか、など、きちんと分析し自分のナレッジとして蓄積させていくわけです。
【1人アジャイルの手法③】ふりかえりを実践してみる
「1人アジャイル」の実践手法はまだあります。アジャイル開発においては「ふりかえり」は重要なイベントの一つと位置づけられますが、これも1人で実践可能です。1日の業務を終える最後の5分だけでもいいので、ふりかえりの習慣をつくってみることをおすすめします。もちろん、これも自分のために実践するという前提です。
自分自身のためのふりかえりなので、自分が担当しているプロジェクトや事業といったトピックは一旦置いておき、自分のスキルアップにフォーカスするのがポイントです。
たとえば
- テーマを設定する
- 情報を集める
- 課題などを深ぼり、カイゼン点を決める
- アクションを決める
という流れで「1人ふりかえり」を実践します。毎日行うことなので、1週間くらいは同じテーマで振り返るのもいいでしょう。大事なのは習慣化することと、上記の流れを意識することです。
私は「1人ふりかえり」を今でも実践しています。その理由はごく単純に自分の成長のためです。たとえ5分であってもふりかえりができれば、自分の課題を見つけ、改善するための小さなアクションも発見できるようになるでしょう。プログラマーとしての成長に銀の弾丸はなく、毎日の積み重ねが大事です。そのための助けになるのが、「1人ふりかえり」だと思っています。
【1人アジャイルの手法：発展編】1人でも開発全体を経験してみる
ここまで述べてきたのは、基本的には自分の手元で実行できるアジャイルのプラクティスです。極めて適用範囲の小さなアジャイルですが、それでも得られるものは多いはずです。そして、「1人アジャイル」に慣れてきたら、少しスケールを広げ、今度は「1人で開発全体を経験する」というチャレンジをしてみるのがおすすめです。もっとも、組織や開発現場によってはこうしたチャレンジができない場合もあると思いますので、汎用的な実践手法とはいえず心苦しいのですが、状況が許せばチャレンジする価値があると、私は思っています。
すべての開発フェーズに関わり、ステークホルダーのインサイトを学ぶ
本稿を読んで下さっている方は、システムの開発には多くのステークホルダーが存在していることをすでにご存じかと思います。そして、各ステークホルダーがそれぞれの役割を担っているからこそ、開発を進めていけると実感されていると思います。それぞれのステークホルダーに、それぞれの価値がある。これは紛れもない事実だからこそ、私は「すべての開発フェーズ」に1人で関わることをおすすめしたいのです。
究極的には、開発に関する事業計画を作り、予算を管理し、仕様を考え、エンドユーザーと直接コミュニケーションを取るといった感じですが、ここまではできなくとも、開発全体の流れを経験することで、ある役割を担うステークホルダーがなにを考え、なにをしたいのかが推測しやすくなるはずです。相手の立場になって考えることができれば、コミュニケーションはよりスムーズになる可能性が高まりますし、ステークホルダーの解像度を自分の中で高められれば、エンジニアとしてより良い技術提案などもしやすくなると思います。
私は過去、ある事業会社の情報システム部門で2年間ほど1人で社内システムを開発し続けるという機会に恵まれました。自分で仕様を考え、サーバーを構築し、エンドユーザーと対話をし続けたのです。こうした経験を得る前までは、常にエンジニアとしての立場でしか物事を考えられなかったのですが、「すべての開発フェーズ」を経験したことで、開発に関わるステークホルダーに目を向けられるようになったと思います。結果、プロジェクトや事業のステークホルダーからの信頼を得やすくなったのを実感しています。
「なにを開発すべきか？」開発のサイクルを回すための視座を養う
開発全体を見渡す経験から得られるのは、ステークホルダーのインサイトだけではありません。アジャイルにおいては「素早くリリースし、ユーザーの反応を分析しながら開発し続ける。フィードバックサイクルを高速に回す」という考えが基本にあります。
「素早く開発してリリースし続ける」だけであれば、技術やリソース次第でどうにかなるかもしれませんが、難しいのは、「ユーザーにとって本当に価値の高いもの」「開発の費用対効果が高いもの」を見極めることです。ユーザーの声が必ずしも本質的なカイゼンに繋がらないこともあるので、「なにを開発すべきか」を考慮する上では、多角的な視座が求められます。こうした視座を養う意味でも、1人ですべてに関われそうなくらいのサイズのプロジェクトを経験するのは非常に有意義だと思います。こうした開発に関わる機会を得るのはなかなか難しいですが、社内向けの便利ツールや小さいシステムなどを提案するのもひとつの手です。売上を立てる前提のプロダクト開発を実行に移すのは骨が折れますが、社内向けのものであれば、開発承認を得るためのハードルは比較的低いでしょう。
【1人アジャイルの手法：発展編】少人数で実践してみる
「1人アジャイル」が板に付いてきたら、次はいよいよスケールを考える段階です。ただし、いきなり大人数のアジャイルにチャレンジするのではなく、まずは少人数でチームを構成しているといいでしょう。繰り返しになりますが、アジャイルを取り入れていくためには、小さく始めてフィードバックサイクルを回し、ある程度成熟させてから、徐々にスケールするという考え方が重要です。
スケール最初期は、3人のチームで十分でしょう。コラボレーションの価値を上げるためには、4〜5人が適切だと思いますが、複数人での実践経験がなければ、3人という極めて小さなチームで始め、アジャイルに対するメンバーの共通認識を高めることが大事だと思います。さらなるスケールを検討するのは、メンバーが「もう1〜2人増やしてもいけるよね」と手応えを得られてからでいいと思います。
なお、私が「1人アジャイル」を経て、初めて複数人でアジャイルを実践した時のチーム規模は私を含め5人でした。前述の通り、ウォーターフォール開発のなかで一人アジャイルを実践していた私の動きを評価してくれたあるマネージャーが、「どうすればもっといい開発ができるか」「テストはどうすればいいか」と相談してくれるようになったのです。そして、それならば、と着手したのがアジャイルの拡大、具体的にはかねてから1人でも取り組んでいたXPの実践でした。
4人のメンバーとペアプロをしながら、メンバーそれぞれにテストファーストやリファクタリングの意味を伝え、JenkinsでCIを回していくといった流れを実践してみたのです。当時私が関わっていたのは非常に規模の大きなプロジェクトだったので、最終的には50人程度までXPは拡大しました。しかし、メンバーのスケールにはかなり気を配り、一気に増やすのではなく、既存メンバーの成熟度が上がったタイミングで人を増やす、というアプローチを基本としていました。また、1チームの人数は可能な限り5人前後にするといったアプローチを心がけていた記憶があります。
意欲のあるメンバーを集める
人は本質的に変化に対して不安を感じやすく、大きな不安はときに変化の障壁になります。ですから、アジャイルという新しいやり方、変化を取り入れるためには、新しいやり方に賛同する人、やりたいという意欲もった人を集めるのが非常に重要です。アジャイル開発導入に失敗したり、思ったように進めることができていないケースでは、メンバーの意欲形成が上手くいっていない場合が多いようです。
当然、組織や会社によっては意欲のあるメンバーのみを集めて、プロジェクトを始めるのが難しい場合もあるでしょう。極論であることを覚悟して述べれば、こうしたメンバー構成が実現できないのであれば、そもそもアジャイル導入はやらない方がいいとさえ思います。なぜなら開発というものには絶対的な正解などなく、人の価値観も多様だからです。アジャイルに馴染めないという人もいますし、アジャイルの考えは好きだけどいくつかのプラクティスは好きではない、という人もいるでしょう。もちろん、こうした価値観が間違っている、などと言えるわけはありません。その人たちなりのスタイルやモチベーション高く取り組めるやり方があるのであれば無理にアジャイルのやり方を押し付けない方が、プロジェクトが上手く進むこともあるでしょう。だからこそアジャイルに取り組むのであれば、アジャイルに対して意欲のあるメンバーを集めることが重要なのです。まずは、意欲的なメンバーで構成されたチームで成功体験を得る。アジャイルに馴染めない人にその効果をプレゼンテーションするのは、次の段階で取り組むこと、と考えるといいと思います。
会社や事業経営へと拡大するアジャイル
「1人アジャイル」から始まり、その範囲を少しずつ拡大し15年以上が経ち、いま私はCTOとして組織全体のアジャイル化に取り組んでいます。いまでも私がアジャイルにこだわる理由のひとつとして、「成長のしやすさ」が挙げられます。フィードバックサイクルを素早く回し、カイゼンし続ける。それにより個人、組織、プロダクトが素早く成長する。さらには、「開発者」としてだけでなく、人としての成長がある。アジャイルに取り組むなかで、いくどもこんな実感を得てきました。
アジャイルは「プロジェクト」を走らせるための考え方ですが、その本質はプロジェクトを駆動させる「人」にフォーカスしたものだと、私個人は捉えています。だからこそ、人としての成長を促してくれるのだろうし、私にとって大切な考え方なのだと思います。
近年では会社や事業の経営というレイヤーでもアジャイルの考えを導入するという潮流が、世界中で生まれてきています。ビジネスの変化のスピードが加速しており、それに適応できる会社や事業でなければならない、という考えからです。
「アジャイルソフトウェア開発宣言」で明言されているように、アジャイル開発とは特定のプラクティスを指すのではなく、開発をするうえでの「考え方」に過ぎません。しかし、多くのいわゆる"IT企業”にとって、ソフトウェア開発とは事業を具現化したものであり、その主体である会社組織が、「開発」にとどまらずアジャイル化していくというのは、ビジネス環境の要請に応じた自然な流れではあると思います。また、「会社全体がアジャイル」を実現できている会社だからこそ、ビジネス環境の変化に継続的に適応し、成功する事業を生み出す余白を持ち続けるのだと考えています。
「アジャイルソフトウェア開発宣言」が発表されて20年以上が経ち、「開発」という範囲を飛び越え、「アジャイル経営」という言葉を耳にする機会が増えてきました。今後、アジャイルという考え方はその適用範囲をさらに拡大し、事業や会社がアジャイルに進んでいくというのが珍しくない時代に突入するかもしれません。また、アジャイルを前提とした組織構造のなかで、エンジニア個々をどのように評価するか、そしてエンジニアはどのようにキャリアパスを構築するか、といった、新たなトピックも存在しますが、こうした点に関しても機会があれば筆を執ってみたいと考えています。
まとめにかえて
駆け足なのに長くなってしまいましたが、以上が私にお伝えできる「アジャイル実践の第一歩」です。言うまでもありませんが、私の実践を支えてくれたのは、世界中の先人たちが残してくれた書籍、記事、講演、ブログなどの数え切れないほどの発信でした。これら発信から数多くの概念やプラクティスを学ばせてもらったからこそ、「これを自分の開発に取り入れてみよう」と楽しんでアジャイルに取り組んでこられたのだと思っています。
『Agile Journey』では「実践」を発信していきたい、と冒頭お伝えしましたが、私が先人の発信からカイゼンのヒントを得たのと同じように、みなさんが本メディアの発信からアジャイル実践のヒントを得てくだされば、これ以上ない喜びです。そして、アジャイルにまつわる情報発信に寄与していくことが、先人の発信から多くを学ばせてもらった、私たち後進からの返礼となってくれれば、これもまた望外の喜びです。
編集：はてな編集部
- 著者：林 尚之（はやし・たかゆき）@t_hyssh
- 2003年に松山大学経済学部を卒業後、福岡のSI企業に入社。2009年にフリーランスとして独立後、2013年からSPEEDAの開発に参画。2017年にユーザベースに正式に入社し翌年1月、SPEEDA事業 執行役員CTO（Chief Technology Officer）に就任。2020年にはSaaS事業（現スピーダ事業）CTO、2021年10月からUB Datatechの代表取締役も兼任する。
