「お前らのアジャイルは間違っている」と彼は言った
少し前にマネージャ層にアジャイル開発事例を話す機会がありました。皆さん「アジャイル」という言葉に抵抗があるようです。さてさてどうやって伝えたらいいものか。発表資料を作りながら悩んだことをここに書いておこうを思います。
アジャイルを語ると胡散臭い
前にもちょっと書いたんですが、アジャイル開発を話す人は胡散臭いです。
たとえば、アジャイルサムライの著者をお呼びしてトレーニングをしたときに思ったんですが、本のファン以外の人にトレーニングの価値を伝えにくかった感触がありました。おそらく「有識者」と名乗る見ず知らずの人(しかも外国人)の話を「信じてください」には無理があるんでしょう。
そのほかにも、別の誰かの話をしだす人は胡散臭いです(海外では〜、○○社では〜、書籍には〜)。これはリーンソフトウェア開発の提唱者メアリー・ポッペンディークさんの本が顕著です。すぐに3Mの話をしだすし具体的な要素が少ない。いいこと書いているんですけどね。
そして、アジャイル研修やスクラム認定試験も胡散臭い。お墨付きは世界的に人気なのかもしれません。しかし、バズワード誕生 > コンサルタント登場 > トレーナー登場 > 有料セミナー登場 > 認定試験誕生・・・の黄金パターンがもう怪しすぎる。
さらに、これであなたもアジャイルだ的なツール業者も胡散臭さを倍増させます。これを買えば幸せになれるという壺とおんなじ。
既存システムに当てはめにくい
よくパイロットプロジェクトを立てて様子を見てから横展開・・・とかありますが、新規案件でハマっても、既存案件でそうはいかないものです。
新規案件が多いところは、パイロット作戦を進めれば、徐々に置き換わっていく・・・とできるかもしれませんが、既存システムやプロジェクトの割合が大きいとそうもいきません。
そもそも、新規での結論を既存に当てはめるのが間違いです。
これって勝間和代理論のように「私はできる。私は幸せ。あなたはなんでできない? あなたはなんで不幸せ? わたしがなんとかしてあげる」的なおせっかいと同じなんですよね。ますます警戒しちゃう。
動機が不純な人がいる
経験上、「アジャイル開発成功させました」みたいな履歴書を書きたい人や、社内で成功させて偉くなりたい人が残念ながらいるみたいです。そらうまくいきませんよ。
「アジャイルやりたい」とか「スクラムをしたい」という相談をしてくる人もたいがい怪しいです。話を聞いてみると問題が別にあったりするんですよね。多分、良かれと思ってるんでしょうが、その人が良いと思うことが誰かにとって良いこととは限らなかったりする。
結果的に受け入れてもらえず「わかってくれない」とフンフンしている人もたまにいますが、一概に励ませないんですよね。もしかしたら、「その人に」問題があるのかもしれない。
さらに「アジャイルってさー」と語りだす人は、自分なりの答えが欲しいだけだったり、それが決めつけだったりする。「いや、ちゃうでしょ」って言うとムッとされたり。なので、人に語って「いいね!」をもらいたがってる暇があったら、勝手に幸せの青い鳥を探せばいいと思います。
漠然とした不安がある
昔、Amazonの玉川さんが(うるおぼえですが)こんなことをおっしゃってました。
データを外にあるクラウド環境に預けたくないと言われる。しかし、そういう人でも、自分の大切なお金を銀行に預けている。
この言葉は、技術では解決できない不安をとてもうまく言い表しています。さすがにこういった不安は自分で乗り越えてもらわないとどうしようもない。
また、アジャイル開発に興味を持って話を聞きに来る方は、なにかしらの問題意識を持っていて、なにかしらの不安を抱えていることが多く思います。よくある不安は導入コストです。
たとえば、ペアプロすると2人で1つの作業をするので、単純に考えると開発量は半分になります。しかし、ペアプロによって将来のリスクを減らす効果が期待できます。期待が実ればリターンとして元がとれます(「元が取れる」は適切な表現ではないかもしれませんが)。
しかし、今かかってないコストを払うとなると「もったいない」と感じてしまうのが人というもの。リスクを取らずにリターンを得るような話は、かぎりなく少ないんですが、頭では理解していてもなかなか乗り越えられないものです。
だったらどうすればいいんだろう?
こうやって思うところを書いてみると、成功する方法は書けないのに、失敗するパターンはいろいろ出てきます。思わず「アジャイルは死んだ!」とか「お前らのアジャイルは間違っている」いう記事を書きたくなりました。
しかし、そんなことしても世界に平和は訪れない気がします。もしかすると、このパターンを克服すれば成功が見えるのかもしれない。ということで問題に向き合って自分なりの回答を考えてみました。
コミュニケーションコストをかける
まず、胡散臭さを回避しつつ、本質を伝える必要があります。そこで現場事例が活躍してくれます。現場は嘘をつきません。
たとえば、ありもしない経験や本の話は、誤解を招きやすいので避けます。また、同じ現場はひとつとしてないので、現場のコンテキストを必要以上に詳しく語るように気をつけました。特に「どういう状況でどういう判断をしたか?」はよくある状況・経験の共有として伝わりやすい気がします。
そして、実際に取り組むのであれば、一番いいのは「一緒に」取り組むです。一緒に働くことができれば、相手のコンテキストの理解も進みますし、相手も自分の目で見たり体験したりできるので、胡散臭さや不安の解消を期待できます(これはすごくコストがかかるんですが、それ以外の解決策があれば教えて欲しい・・・)。
週1回顔を出して「調子どう?」とかいうコンサルに「たゆまぬ改善」のサポートができる気がしませんし、アジャイルコーチって売り手が責任持たないアンフェアな取引だと思ってるので、きちんと契約内容を考えるのをおすすめします。
もし外部に助けを求めるなら、サンフランシスコに住む友人が言ってたんですが、「まず1ヶ月〜3ヶ月で契約し、その間、イテレーションをぐるぐる回してもらう。その結果が自分たちの期待にマッチすれば契約を継続する」というのがいいアイデアだと思います。
ゴールと期間を必ず決める
次に、導入をすすめる前にこの取り組みの価値を必ず定義します。「流行ってるから」「誰かがやりたいって言ってるから」ではなく、「アジャイル開発をはじめることで○○を実現したい」というように具体的に取り組みの価値を定義します。
これは開発的な価値からはじめても良いと思います。もちろん、ビジネス的な価値は重要ですが、「売上○倍」とかになっちゃうと、ゴールが遠すぎて迷ってしまいます。まずは短期的な視点や身近な問題をターゲットにしてみてはどうかと思います(流れに乗ったら短期と長期をセットで考えるとか)。
そして、関係者全員がその価値に納得した上で、いつでも見える場所にその価値を掲げ、忘れないように何度も繰り返し関係者に伝えてみてはどうでしょう?
実施と定期的なチェック
さらに、実行と検証を忘れずにやります。価値によって期待値はおぼろげに見えるはず。あとは、自分のところで使えそうなプラクティスを実際に自分たちでやってみます。その実行結果を定期的に検証して、価値に近づいているかをチェックし、微調整していきます。
よく「このやり方であっているか?」を聞かれますが、正解の判断が難しいので「このやり方よりもスマートな方法がないか?」と考えたり質問したり相談したりするといいと思います。正解を探すのではなく、よりよくアップデートしていくのが本質だと思います。
信じて続ける。あきらめる
最後に、続けることです。
心配であれば3ヶ月、6ヶ月、1年といった実験期間をはじめに決めるといいと思います。それでダメなら別の方法探したほうがいいと思うのですっぱりあきらめてます。
間違っていたらやりなおせばいい
マネージャ向けのアジャイル事例共有では、思った以上に質問が出て、とても有意義な話し合いができました。
僕は、どんな環境でもたゆまぬ改善を続けてよりよくしていくのは可能だと思っていますが、やっぱり自分は当事者じゃないので、答えられることに限界を感じたのも事実です。
作り方を現場以外の人間に押し付けられる筋合いはないですし、現場の人が考えるのが一番いいはず。すぐには無理かもしれないけど機会があれば一緒に取り組んでみたいと思いました。
何が正しいなんて答えはありません。枝分かれした道は神のみぞ知るです。止められないスピード加速するほど鼓動は高く高く高鳴り覚えていくものです。
そうそう、そもそも僕自身が胡散臭くてニセモノかもしれないですから。
記事に関係したモノ
この記事に関係している話題
ご意見
僕について
Dai Fujihara
藤原大はアジャイル実践者だ。そしてマネージャ、プロジェクトリーダー、チェンジ・エージェントでもある。彼はアジャイル開発を活用した創造的なソフトウェア開発の支援や『リーン開発の現場』の翻訳にも関わっている。さらに、趣味は沖縄離島巡りらしい。
翻訳しました
最近の人気
永久保存の本
Venkat Subramaniam (著), Andy Hunt (著), 木下 史彦 (監訳), 角谷 信太郎 (監訳) アジャイルな習慣とは一体何なのか?本書ではプラクティスを交えながら、その姿勢を読者に問いかけている。世代や役割をこえて色褪せない「アジャイル」に対する良書。Amazonレビュー
Mike Cohn (著), マイク コーン (著), 安井 力 (翻訳), 角谷 信太郎 (翻訳)
採用した現在のタイトルは、見積りや計画づくりといったプロセスを、アジャイルに進めなければならないと謳っているのだ。見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。(イントロダクションより)
Jonathan Rasmusson (著), 西村 直人 (翻訳), 角谷 信太郎 (翻訳)
アジャイルサムライ―それはソフトウェアを顧客に届ける猛々しきプロフェッショナルだ。本書では、圧倒的なアジャイルプロジェクトの姿を見せる。2011年爆発的にヒットしたアジャイル開発に情熱を持つエンジニアに届けたい本。タグ
Agile ant Apache bash Eclipse GlassFish install Java Javascript kobo Linux log4j Management Maven Open Source PHP Pukiwiki Python Redmine Ruby Ruby on Rails Scrum Spring Struts Struts2 Subversion Test Tomcat Trac VBA Web WebDriver WebLogic Windows WordPress 働く 勉強会 嫁(ベータ) 思い出し笑う 我思う 旅する 映画/ドラマ 英語を話す 読むと聞く 過去を語るアーカイブ