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

――岡島幸男（注1）

注1）

『プロジェクトを成功させる現場リーダーの「技術⁠」⁠』⁠（⁠岡島 幸男（著⁠）⁠，ソフトバンククリエイティブ）p.139

はじめに

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

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

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

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

「貯金を増やす」と聞くと何だか打算的な印象を受けるかもしれません。しかし，実際に意識してみるとすぐに気づくことですが，打算的なだけでは信頼貯金を増やすことはできません。

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

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

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

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

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

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

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

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

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

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

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

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

場づくりを心がける

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

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

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

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

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

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

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

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

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

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

時には我慢や譲歩も必要

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

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

注2）

本連載第1回の「まずは自分，それからチーム」を参照してください。

注3）

Kent Beckの言葉。

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

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

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

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

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

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

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

注4）

ただし，何事にも限度はあります。どうしようもなく取り返しのつかない状況については，どうしようもありません。

注5）

ふりかえりについては本連載の第1回「フィードバックを重視する」を参照してください。