最後の原則は「正直は割に合う」です。

――岡島幸男[1]

はじめに

本連載ではアジャイル開発を「アジャイルに開発する人たち（アジャイル開発者）が開発するからアジャイル開発」と考え、アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。

今回は、まずアジャイルな開発を現場に根付かせている人たちが実践している習慣を「信頼貯金を増やす」というキーワードから考えます。そのあとで、信頼貯金を増やすために重要な、アジャイル開発者としてのスキルの構成と磨き方を整理します。そして、最終回らしく連載のこれまでを総括します。

アジャイル開発者と信頼貯金

アジャイルに開発できている開発者と、そうでない開発者の違いは、技術スキルの優劣だけではないと私は考えています。うまく開発をアジャイルにできている開発者は、スキルを磨いているのはもちろんですが、それと併せて信頼貯金を増やすことも習慣の一つとして身につけているように見えます。

というのも、信頼貯金とはあなたの周囲の人が持っている、あなたに対する信頼の蓄積だからです。預けるのも引き出すのもあなたではなく、あなたの周囲の人たちです。

お客様はもちろん、社内の同僚など、周囲を巻き込んで何か新しいこと、これまでと違うことを始めるにあたっては、一定の信頼貯金が不可欠です。「⁠それが正しいことだからだ」というだけでは、なかなかうまくいきません。

習慣 #5　信頼貯金を増やす

信頼貯金を増やすにあたっても重要なのはマインドセット（心構え）とプラクティス（実践⁠）⁠、そしてそれを継続させることです。

私自身の過去の反省と成功体験、周囲での成功例を踏まえて順番に紹介します。

マインドセット「正直は割に合う」

正直であること。誠実であること。嘘をついたり隠し立てをしないこと……。改めて言われるまでもない、当たり前のことです。しかし残念ながら、ソフトウェア開発の現場ではそれが守られないことも少なくありません。

誤魔化すための労力はムダ

その原因はさまざまだとは思うのですが、自分自身を振り返ってみても、正直であることへの恐れや不安は、短期的な言い逃れとしての嘘や誤魔化しへとつながります。

そして、たとえば進捗を誤魔化して報告すると、その誤魔化しを打ち消すため、あるいはさらに誤魔化すために余計な労力を割くことになります。

本来ならチームの成果を上げるために注がれるべき労力を、問題を誤魔化すのに費すのはムダです。もちろん、精神衛生上もよくありません。

信頼貯金を増やしていくには、自分自身の仕事について正直であることや、自分のエネルギーを、問題の誤魔化しではなく解決に向けることはとても重要です。

場づくりを心がける

「正直が割に合う」と思えるかどうかは、チームの日常やミーティングといった場の雰囲気によります。

自分が正直であることはもちろんですが、それと同じぐらい（あるいはそれ以上に）重要なことは、ほかの誰かが誠実であろうとした際に、それに応えることです。

進捗が遅れているからといって責めても進捗は早まりません。進捗が早かったからといってどんどん仕事を押しつけていては、誰も予定より早く仕事を終えたと報告しなくなります。

「ここは正直でいてもよいんだ」と思える雰囲気は自分自身が正直であるためにも欠かせません。

マインドセット「変化を強要することはできない」

チームのこれまでの習慣を変えたいとか、新しいプラクティスを導入したいと思ったときこそ、それまでに蓄えた信頼貯金を使うときです。しかし焦ってはいけません。まずは深呼吸です。

その習慣やプラクティスをみなさん自身は試しましたか？[2]⁠ チームのみんなはそれを受け入れる備えができているでしょうか？

人は自分の速度でしか変われない

相手に変化を強要することはできません。人が変えられるのは自分自身だけです。しかも、人は自分の速度でしか変われません[3]⁠。相手があなたと同じタイミングで同じように変われるとは限りません。

「これは良いものだ」と思っていると自分でも気づかないうちに独善的になっていることがあります。「⁠なぜ気づかない」「⁠わからないほうが悪い」……。こうした態度は遅かれ早かれ信頼貯金の取り崩しにつながります。信頼貯金はためるのは大変ですが、なくすのは本当にあっという間です。

時には我慢や譲歩も必要

何かを変えていこうとするときには、自分の変化のタイミングだけでなく、周囲が変化への準備ができていることも大切です。そして、周囲が変化の準備を整えたとき、それに応じられるかどうかが何よりも重要です。普段の備えが問われる瞬間です。

いきなり自分の主張を押しつけるのではなく、相手の受け入れ具合を見ながら、少しずつ様子を見ながら始めてみましょう。自分の目の前の現場からのフィードバックを大切にすること、状況の改善のためにバランスを取ること。こうしたループが回りはじめるまでは、先を急がないことが大切です。

マインドセット「ベストプラクティスは存在しない」

ここで残念なお知らせです。開発をアジャイルにしていくための唯一無二の回答は存在しません。あるのはただ、みなさんそれぞれの開発現場と、その現場ごとの課題です。

経験上、アジャイルな手法を取り入れるプロジェクトのパターンのようなものは存在します。一番スムーズなのは発注時に「アジャイル開発で」と指定される場合です :-)　その次にうまくいくのは実は「状況が芳しくない」プロジェクトです。

たとえば、参加した時点ですでにプロジェクトが炎上している。お客様がどう進めていいかわからずに途方に暮れている。どんなシステムが納品されるのかイメージをつかめなくて不安を覚えている。あるいは、そもそも自分たちが具体的に何が欲しいのかがわからない。開発をアジャイルにできた現場はいずれも「困り具合」に切実さや切迫感がありました[4]⁠。

ただし、状況が切迫していれば必ずプロジェクトをアジャイルにできるとは限りません。

唯一手がかりがあるとすれば、開発をアジャイルにできたプロジェクトはいずれも、最初に与えられた状況の中からフィードバックループを形成していたことです。

まずは開発チーム内で、そして可能な限り顧客やユーザも一緒になって定期的な「ふりかえり」を実施してみましょう。そこから先はみなさん次第です注5。

プラクティス「まず自分が相手を信頼する」

信頼貯金を増やすためには、相手から「この人は信頼できる」と思われなければなりません。では、信頼に足る人物であるにはどうすればよいでしょうか。それは、信頼できる人物であることを示すしかありません。……これでは誰も身動きできません。

情けは人のためならず

この状況を打破するためのアドバイスが、Tom DeMarcoの著書『ゆとりの法則』（⁠注6）にあります。それは「いつも信頼に足ることが示されるより少し前に信頼を与えなさい」というものです。

自分の信頼貯金を増やすためには、まずは自分から回りの人に信頼を貯金しましょう。人は自分を信頼してくれる人を信頼してみようと思うものです。

リスクはチャンス

本当に信頼に足ることを示される前に相手を信頼することには「信頼に応えてもらえないかもしれない」というリスクがあります。

リスクというと避けるべきことのように思われるかもしれませんが、リスクはチャンスでもあります。挑んでみる価値があるものととらえる視点も忘れないでください。

自分がまず信頼して、同僚に仕事を任せてみる。マネージャに自分の仕事に対する考えを話してみる。お客様に正直に状況を打ち明ける。できますか？

人について何を本当に信じているか？

『リーン開発の本質』（⁠注7）によれば、リーン活動[8]に着手する前に答えるべき最後の問いが「人について、何を本当に信じているか？」です。ソフトウェアをつくるのは人だ、とよく言われますし、本連載でも言ってきました。では、「⁠人」について何を本当に信じていますか？

私は周囲の人に対して次のように信じています――少なくとも信じようとしています。

もちろん、判断するには判断を下すための材料が必要です。また、時間が必要なこともあります。自分の主張が論理的に正しかったとしても、それを受け入れてもらえるとは限りません。

あなたは人について何を本当に信じていますか？

プラクティス「ユーザ価値のある成果を届ける」

ソフトウェア開発で最も確実な信頼貯金の増やし方は、ユーザ価値のある成果を届けることです。これはつまり、お客様に「ありがとう」と思ってもらえるような仕事をするということです。お客様からの評価は必ず社内での評価にもつながります。

定期的に目に見える成果を出す

お客様に評価してもらうためには、目に見える成果を出さねばなりません。ソフトウェア開発であれば、設計書よりも実際に触れるプロトタイプ、プロトタイプよりも実際に機能するソフトウェアのほうが喜ばれるはずです。

連載の第2回で紹介した、反復を繰り返しながら（イテレーティブ）少しずつ進んでいく（インクリメンタル）という、ソフトウェアを「育てる」アジャイル開発の手法はそのためのものです。

図1[9]はVersionOne社が提唱する、従来型の開発に対するアジャイル開発のメリットの一つ「可視性」です。インクリメンタルかつイテレーティブにソフトウェアを提供すると、従来よりも早い段階から開発の成果を目にすることができます。

早い段階から頻繁に成果を確認できれば、開発するソフトウェアの成果と、開発チームに対するお客様の不安の解消につながります。お客様に安心してもらうことも立派なユーザ価値の一つです。

タイムボックスと信頼

定期的にユーザに見える価値を提供するには、タイムボックス化が欠かせません[10]⁠。そして、タイムボックスを厳守できるように、作業には優先順位をつけて取り組みます。

タイムボックスに作業が収まらない場合は、タイムボックスを遵守できるように作業の分割や優先順位の見直しを行います。作業の見直しでも重要なのは「正直は割に合う」というマインドセットです。

無理をして作業を詰め込んでも、それは長続きしません。本当に緊急であれば仕方がないこともありますが、それが常態化するのは危険です。

タイムボックス化と、そこで成果を出すことを何度か繰り返せれば、ユーザは1回のタイムボックスで達成できるおおよその成果への見通しと期待を持てるようになります。そして、チームが適切に期待に応えることは安心感をもたらします。たとえ遅れが生じたとしても、誠実に対応し、タイムボックスを遵守し続ければ、それは信頼につながります。

プラクティス「素振り」

相手から信頼されたときに信頼に足る存在であることを示すには、常日頃からの備えが大切です。

四六時中こうしたことに取り組んでいるべき、とは言いません。しかし、私の周囲のアジャイルな開発者たちは、自分で考えることや手を動かすことに自然体で取り組んでいる人が多いのは確かです。

アジャイル開発者のスキルは二階建て

本連載では何度も繰り返していますが、アジャイルは形容詞です。「⁠アジャイル開発者」と呼ぶとき、それは開発者がアジャイルであるという状態を指しています。

ということは、アジャイル開発者とは「アジャイルな」開発者である以前にまず「開発者」であらねばなりません。

スキルの構成も同じです。まず「開発者としてのスキル」があり、それに支えられて「アジャイルな」開発者としてのスキルがあります。図2に示すように、このスキルは二階建てになっています。

開発者のスキル

二階建て構造の一階部分を構成する開発者のスキルは次の3つです。

これらは、開発の進め方がアジャイルであるかどうかにかかわらず必要とされるスキルです。この3つが一体となって、二階部分の「アジャイルな」開発者のスキルを支えます。

このうちどれか一つが欠けても、アジャイルな開発は進められません。開発をアジャイルにしていくための前提と言ってもよいでしょう。

それぞれについて詳しく説明すると、文字どおり書籍になってしまいます（⁠『⁠達人プログラマー ― ソフトウェア開発に不可欠な基礎知識 バージョン管理／ユニットテスト／自動化』（⁠注11）がそれです⁠）⁠。ここでは簡単に紹介しておきます。

バージョン管理

ソフトウェア開発には、成果物の信頼のおけるリポジトリが欠かせません。バージョン管理なしにユーザ価値のあるソフトウェアの提供を継続することは難しいでしょう。

この分野にはすでに実績のあるツールが存在しており、そのメリットは必ず習得コストに見合います。

もしもまだバージョン管理を導入していないのであれば、本誌Vol.39の特集1「構成管理 実践入門 ― バージョン管理、ビルド、リリース」などを参考に今すぐ取り組んでください。今から始めるなら、まずはSubversionの使い方を一通り身につけましょう[12]⁠。

ユニットテスト

ユニットテストのスキルとは、いわゆるxUnitツールを利用して具体的なテストケースを記述するスキルです。本誌であれば、Vol.35の特集1「実演! テスト駆動開発」が参考になります。

テスト駆動開発（TDD）とユニットテストとを別のスキルにしているのには理由があります。TDDは開発をアジャイルにしていくうえで重要なスキルですが、xUnitを使って自分の書いたコードをユニットテストできることは開発がアジャイルであろうとなかろうと重要なスキルです。自分が書いたコードのテストの実行を自動化する手段は身につけておくべきです。

別の言い方をすれば、テストに開発を駆動させていくためには、まずテスト自身の書き方を身につけていなければならない、ということです。

自動化

人は繰り返し作業が苦手です。一方、コンピュータは繰り返し作業が非常に得意です。コンピュータが得意なことはコンピュータに任せましょう。

故石井勝さんは「自動化できないか考えること」を優れた技術者になるために必要な態度だと述べていました。

自動化による作業の効率化も、開発手法を問わず重要な開発者のスキルです。本誌でいえば、バージョン管理の項目で紹介したVol.39の特集1は、自動化という観点からも参考になります。

「アジャイルな」開発者のスキル

開発者の3つのスキルに支えられて存在するのが、本連載で取り上げてきた「アジャイルな」開発者のスキルです。それは次の4つです。

開発者の3つのスキルとの関連を中心にこれらを見ていきます。

ストーリの作成

ストーリは、ユーザにとっての価値を、ユーザの語彙であらわしたものです。連載を通じて説明してきたとおり、私たちはユーザ価値をソフトウェアとして継続的に届けるために開発をしています。

ソフトウェアを正しく届けるためには、適切なユニットテストとバージョン管理された信頼のおけるリポジトリが必要です。ユーザ価値の提供を効率良く繰り返し継続するには自動化は欠かせません。

計画づくり

計画づくりは、タイムボックスを遵守するために作業を見積り、優先順位をつける活動です。

プロジェクト計画に合わせてコードベースにタグを打ったり、ビジネス状況に応じてブランチを作成したり、ブランチ間でのマージを行ったりするにはバージョン管理ツールのスキルが欠かせません。

テスト駆動開発（TDD）

TDDはツールの使い方やテストコードの書き方よりも上位レベルの、ソフトウェア設計の技法であり、開発の進め方についてのスキルです。TDDでは、作業に先立って、作業の完了条件をテストできるコード（または言葉）で定義します。

テストをコードとして表現するにはユニットテストのスキルが、テストコードをリポジトリに格納するにはバージョン管理のスキルが、そして実行を効率良く行うには自動化のスキルが欠かせません。

リファクタリング

リファクタリングとは、プログラムの外部から見た振る舞いを変えることなく、ソフトウェアの設計を改善していくことです。時間の経過に応じた環境の変化にソフトウェアを適応させていくためのスキルです。

リファクタリングで重要なのは、変更した設計が壊れていないことの確認です。そのためにはユニットテストが欠かせません。リファクタリングに失敗した際には、以前の状態へ巻き戻すためにバージョン管理のスキルも必要です。

スキルの磨き方

開発者のスキルとアジャイル開発者のスキルを紹介しました。これらのスキルの磨き方は、私の考えでは「全体を少しずつ育てていくべき」です（図3⁠）⁠。

全体を少しずつ

まずは開発者の3つのスキルに取り組みましょう。そのあとで、なるべく早い段階からアジャイル開発者の4つのスキルにも挑戦してみてください。

スキルを1つずつではなく、全体を少しずつ磨いていくように心がけるのは、開発の現場では、スキルの要素が単独で役立つというよりは、全体が補完しあって効果を発揮するからです。

知識は分け与えても減らない

得手不得手があるのなら、チームメンバーの助けを借りましょう。ここでも「正直は割に合う」です。知らないこと、わからないこと、自信のないことを口にする勇気（と、それを歓迎する雰囲気）も大切です。

もちろん、自分の得意なことはメンバーとも共有しましょう。知識は分け与えても減ることのない珍しいものの一つです。

アジャイル開発者の習慣

以上で、この連載の目的であるアジャイル開発者に必要なスキルを磨く習慣の紹介はおしまいです。ここからは連載の内容をふりかえって、もう一度、サブタイトルの「acts_as_agile」に込めた意味を確認します。

紹介した習慣

私の経験と観察からは、アジャイル開発者たちは次のような習慣を身につけています。

そして、この習慣の実践と継続を通じて今回紹介した開発者の3つスキルとアジャイルな開発者の4つのスキルに磨きをかけ、ユーザ価値のあるソフトウェアを提供しています。

こうした習慣を身につけている私の周囲の開発者は、みなさん優秀だし偉大だなと思います。

「偉大な習慣を身につけたプログラマ」

私は自分自身をアジャイル開発者の端くれだとは任じています。しかし、彼らのように偉大になれるかと自問すると自信をなくすこともよくあります。

そんなとき私は、連載第1回の冒頭で引用したKent Beckの言葉に立ち返ります。

僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。

習慣を身につけることも一つのスキルです。習慣を支えるマインドセットを意識し、プラクティスを実行に移し、継続する。ただそれだけのことです。

誰でも身につけられるものがスキル

スキルは才能ではありません。偉大であることは才能かもしれませんが、偉大な習慣を身につけることはスキルです。スキルなのであれば、身につけられる／られないの違いは、やるか／やらないかです。

acts_as_agile

連載の副題である「acts_as_agile」という言葉に込めた思いはここにあります。繰り返しますが、人はアジャイル開発者であるかのように振る舞うことでアジャイル開発者になるのです。

本連載ではアジャイル開発とは「アジャイルに開発する人たち（アジャイル開発者）が開発するからアジャイル開発」なのでした。

アジャイル開発者とは、アジャイル開発者になろうとしていて、それを続けている人たちのことです。

まずはアジャイル開発者として振る舞うことから始めてみる。実践した結果からフィードバックを受ける。そこから学習する。それを踏まえて実践する。フィードバック。学習。実践。……繰り返し。

本連載をきっかけに、アジャイル開発者として振る舞ってみようと思う方が一人でも増えてくれたら、執筆者としてこれ以上の喜びはありません。

「腑に落ちる」ということ

そして、アジャイル開発者としてのスキルを磨いていくうえでは「腑に落ちる」瞬間を大事にしてください。私の経験では「腑に落ちる」とは、言葉にすると非常にバカバカしいけれども、体験している本人にとってはとても貴重な瞬間です。

個人的な経験をいくつか挙げます。「⁠テスト駆動開発って、テストが開発を駆動するんだ!!」「⁠ユーザストーリは、ユーザの言葉でストーリを書くべきなんだ!!」「⁠リファクタリングって振る舞いを変えないで設計をきれいにするんだ!!」「⁠タイムボックスは時間枠を重視するんだ!!」などなど。

自分で書いていてもバカみたいですが、こうした瞬間を体験したときが、そのスキルをあなた自身がモノにした瞬間です。健闘を祈ります。

もっと詳しく

アジャイル開発者が身につけるべき習慣について、さらに詳しく知りたくなった方には、『⁠アジャイルプラクティス』（⁠注14）を推薦します。

手前味噌ですが、本書は私が同僚の木下史彦さんと監訳しました。この連載とは別の切り口で、アジャイル開発者が身につけるべき45の習慣を紹介しています。連載と重なるところもありますが、連載では取り上げられなかった内容にも踏み込んでいます。

おわりに

この連載は次のみなさんの協力でできています。

本連載の核をなすアジャイル開発者の4つのスキルを教えてくれたXPの父の一人、Ron Jefferiesさん（資料のコピーをありがとうございます⁠）⁠。

いつも気づきを与えてくれる『バカが征く』のgreenteaさん。blikiをはじめMartin Folwerの記事の数々を翻訳してくれているkdmsnrさん。オブジェクト倶楽部のサイトに翻訳記事を投稿してくださったみなさん。

最後に、勤務先の永和システムマネジメントの同僚とそのお客様のみなさん。そして読者のみなさん。

1年間ありがとうございました。またいつか、どこかでお目にかかりましょう。acts_as_agile!