2001年に公開された「アジャイルソフトウェア開発宣言」から20年以上が経過しています。この間、現場で自ら試行錯誤を繰り返しつつアジャイルへ挑み続けてきた、レッドジャーニーの市谷 聡啓と中村 洋。イベント第5回目は、5つのご質問にお答えしました。

チームや組織でアジャイルを実践する皆さまのリアルなお悩みに向き合った1時間。
「アジャイルがうまくいっていない」「何から始めたらいいのかわからない」
そんな方々にとっては、「人を知ること」が課題解決のポイントなのではないでしょうか。ネクストアクションへの手がかりが詰まった、ふたりの対談です。

第4回の内容はこちらをご覧ください。

話し手

市谷 聡啓 Toshihiro Ichitani

株式会社レッドジャーニー 代表
元政府CIO補佐官
DevLOVE オーガナイザー

サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自らの会社を立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。訳書に「リーン開発の現場」がある。著書に「カイゼン・ジャーニー」「正しいものを正しくつくる」「チーム・ジャーニー」「いちばんやさしいアジャイル開発の教本」「組織を芯からアジャイルにする」がある。

中村 洋 Yoh Nakamura

株式会社レッドジャーニー
A-CSM(アドバンスド認定スクラムマスター)・CSPO(認定プロダクトオーナー)

様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。
「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
【発表資料】 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。

目次

システム開発に縁のない人へアジャイルの必要性を伝えるのが難しい

質問者:現在、商社の情報システム部門に所属しています。全社をフリーアドレス化するプロジェクトにてアジャイルを実践したいです。

チームメンバーは10人で、アジャイルという言葉に縁のない人がほとんどです。「アジャイルをやっていこうよ」と説明しても伝わりません。システム開発以外の部門でもアジャイルをできるようにする、という経験を積みたいと思っています。どのように進めれば、アジャイルが浸透しやすいでしょうか。

中村洋(以下、中村):この場合、私はアジャイルという言葉を使わず、日本語で説明するようにします。そして、実際にやってみて「こういう風にやってみようよ」と、体感から始めるパターンが多いですね。

市谷聡啓(以下、市谷):ふりかえりからやってみるのはいかがでしょう。アジャイルの説明をしても、理解してもらうのは難しい。実践すれば誰もが効果がある施策として、ふりかえりから始めるのはおすすめです。プロジェクトが始まっていなくても、今の自分たち、組織、今までの業務についてなど、振り返る材料はありますよね。

中村:新プロジェクトのスタート時、インセプションデッキの「やらないことリスト」を応用して、「どんなやり方でやりたい?」を問う場合もあります。「今度はどんな風にやりたい? 今まで楽しかったプロジェクトはどんなやり方だった?」とメンバーに聞く。そして、今回もそういう風に進めよう、とスタートしても良いと思います。

市谷:アジャイルの本質は「変化や状況への適応」。それを体感できるものとして、ふりかえりの導入は有効だと思います。一方、見える化から始めるのは、意外と大変なんです。ルーチンワークとそれ以外の業務の線引きがしづらいし、ルーチンワークを挙げるとものすごい量になります。バックログを見える化するのが難しいんですよね。

中村:スクラムを最初から完璧に実践するのは大変です。何をどうつまみ食いするかと考えた時、ふりかえりから始めてみると、「誰が何をやってるかわからない」とチームの問題点が明らかになり、「タスクボードを作ろう」と取り組みが始まる。「でも、タスクボードだけではわからないね」という議論になり、朝会が始まる。

このようなパターンでアジャイルのプラクティスに取り組み始める組織が多いと思いますね。アジャイルを理解してもらうために、まずは体験することからスタートしてみてはいかがでしょうか。

アジャイルなマインドを持っているか判断できる、良い基準があれば知りたい

質問者:アジャイル初心者のメンバー(これまでウォーターフォールのみ経験)でスクラムを実践しています。アジャイルなマインドとは何なのかが曖昧な中、取り組みを続けています。自分たちがマインドを持っている基準があれば、メンバーに自信がつくのではと考えています。何か良い基準はありますか?

市谷:「アジャイルなマインドを持っています」と言うだけでなく、行動や結果によって「持っている」と認識できれば良いと思います。例えば、アジャイルソフトウェア開発宣言をみんなで振り返って、できている点とそうでない点を照らし合わせてみると、どこまでやれているかがわかります。

中村:外部の有識者やアジャイルコーチに壁打ちしてもらうのも一つの方法ですね。問いを投げてもらって「自分たちはアウトカムが出ているのでちゃんとやれているな」などと、Diff(差分)を取って自信を得るのも良いのでは。

質問者:たしかに、マインドの話だけしていても仕方がないのは理解できます。4つの宣言や12項目をチェックして、気づきを得たいと思います。ただ、チームがスクラムという手法のみに囚われているとも感じています。「自分たちがやりたいのはアジャイルの手法をとるだけではなく、マインドを持つことだ」とメンバーに伝えたいんです。

市谷:あなたにとっての「アジャイルマインド」とは、何でしょうか?

質問者:お客様の価値を最大限にするために、その時の最適解を常に追い求める姿勢だと思っています。以前、人的リソースが限られている中でアジャイルを実践し、取り組みに価値があると体験したことからこの考えを得ました。

市谷:それを誰かに伝えて「ああそうか」と腹落ちしてもらうには、相手が体感しないと伝わらないのかもしれません。過去にあなたが経験したような状況を、プロジェクトの中で再現できると良いですね。「どうやってここに辿り着いたのか」が重要で、プロセスを体験しないとわからない。

ふりかえりの時に「アジャイルの取り組みでこういう価値を感じたよね」と、ご自身が思うアジャイルマインドを、解像度を上げてメンバーに伝えてみてはいかがでしょうか。

アジャイル開発をしているがエンジニアのスキル不足で開発が進みづらい。速度アップと品質向上に効果的なプラクティスとは?

質問者:アジャイル開発をしていますが、エンジニアのスキル不足で開発が進みづらいです。アーキテクチャ、デザインパターン検討、クラウドを用いた開発、テスト駆動等の経験がない開発者が多いので、それらに関連した施策が上がりにくいのも課題です。

また、フロントエンド・バックエンドとチームが分かれているため、共通認識を持って開発を進めるのが難しいです。開発速度や品質を上げるため、取り組むべきプラクティスがあればご意見が欲しいです。

中村:自分たちの技量が足りずに理想を実現できなかったら、ふりかえりで「テストの知識が足りなかった」などという結果になると思います。その点はいかがでしょうか。

質問者:これまでウォーターフォールをやっていたメンバーなので、ウォーターフォールで解決してきた方法で対処しがちなんです。レビューを増やすとレビュアーのタスクが逼迫し、開発が止まります。

市谷:今回の場合、方法は2つあると思います。「時間をかけて取り組む」「個人にフォーカスする」です。

前者は、一旦は動ける範囲で進めます。アウトプット量は減りますが、バックログの中で易しいタスクから取り組むなど、調整していきます。最初に設定した理想へ辿り着くには時間がかかりますが、チームの実力に合わせるのなら「From To」、「自分達の出発点はここから」と設定して積み上げていくしかないですよね。

一方、チームで動くとはいえ、個々の技量は問われると思っています。後者の取り組みでは、メンバー間にスキルのばらつきがあるなら、星取り表を作ってレベル感を可視化し、足りないところに手を打ちます。スキルレベルに応じてバックログのアサインメントを考慮することも可能ですね。

中村:アジャイルに取り組む WHY があるはず。「今まではこうやっていたけど、次の戦いに勝つためにアジャイルを身につけるんだ」というWHYがあるのなら、ウォーターフォールでの解決方法は WHY から外れますよね。ところで、チームメンバーの方々は楽しそうに開発をしていますか?

質問者:あまり楽しそうではないかもしれません。

中村:理想論のようになりますが、アジャイル開発をしていると楽しくなってくることが多いんです。アジャイル開発の特徴に、フィードバックが早く回り、その質が良くなっていき、結果が多く得られる、という点があります。すると、楽しくなってくるんですよね。「じゃあ今度はこうしたらうまくできるのでは?」と、前向きに取り組めるようになります。メンバーがそういった姿勢でないのなら、何かがうまく機能していない可能性があります。

市谷:ハードルが高すぎるのでは。意図的ではなく、無意識に自分たちでハードルを上げてしまい、手に負えていない場合もあります。

中村:手を付けられるところからやってみるのも、一つの方法ですね。

「なんちゃってアジャイル」からステップアップするには?

中村:次のご質問です。「アジャイルに取り組んでも『なんちゃってアジャイル』になりがちです。形だけの真似事から、階段を一段登るにはどうしたらいいでしょうか」

市谷:「なんちゃってアジャイル」かどうかは置いておいて、「結果が出ているか」「本来どうしたかったか」を見直すと良いと思います。「スプリントを回しています」と言いつつスケジュールを12分割しているだけでは、アジャイルではないですよね。

アジャイルに期待していたのは何だったのでしょうか。理想と現実のギャップをどう埋めるかが重要です。そもそも、理想を描けていない場合もあります。

中村:「スクラムを導入したいんです」とご相談を受け、「その結果どうしたいですか?」と聞いても、答えが返ってこない時があります。スクラムの実践が理想になっていたら、プラクティスの正しさを求めることになってしまう。本来の目的はユーザへの価値提供のはずです。「その先に何があるのか?」と考えることが必要ですね。

市谷:「なぜアジャイルをやるのか」の言語化は、意外と難しいと思っています。WHY を言葉で表現できるかどうか。

中村:WHY を見つけるのが難しかったり、持てていなかったりする場合もありますよね。少し乱暴ですが、アジャイルの実践から入るのも良いです。やってみたら「これがやりたくて自分たちはアジャイルをやろうとしていたのか」と体感できる可能性もあります。

何もせず、会議室にこもって「なぜアジャイルをなぜやるのか」と考えていてもわかりません。順番を前後させて WHY を考えるのも良いです。

今、世の中には「ベタープラクティス」、いわゆる「正しいやり方」と言われているものが溢れています。そういった情報があるために、初めから理想を高く掲げ、求め過ぎてしまうという病があるかもしれません。

市谷:プラクティスをフォーマット通りやるのは、解像度が荒すぎると思うんですよね。例えば、KPT を現場で実践するなら Keep・Problem・Try をただ洗い出すだけでは不十分。「これはどういう狙いだったのか?」と行間を埋めるために想像してみることが必要です。ベタープラクティスと呼べるものは、存在しないのでは。

中村:「なぜ Keep だと思った? 次も続けられると思う?」と問いかけて、深掘りする必要がありますよね。

市谷:スポーツと同じ考え方もできます。「イチローの〇〇打法をやろう!」と意気込んでやってみても、いきなりヒットは打てません。

中村:素振りの練習ですね。最初からモブプロがうまくいかなくても「次のスプリントではこうやってみよう」と何回も練習してうまくなる機会はあります。それに、結果に向き合う必要がありますね。理想のフォームができているのか、ヒットは打てているのか、チームは勝てているのか。

市谷:いずれにしても、最初は「なんちゃって」で良い。今こんな風にお話させていただいていてますが、私たちも初めはそうでした。なんちゃってファーストでやってみて良いと思います。

組織全体のアジャイル化に向けた道筋を描けていない

中村:最後のご質問です。「組織全体のアジャイル化に向けた道筋を、まだ自分が描けていません」

市谷:くせ者なのは「全体」という言葉です。全体とは、どこまで捉えられているのでしょうか。全体というと、一人一人の顔が見えていないと思うんですよね。「〇〇部」でもまだ粗い。全体とは誰を指すのか、もっと考えることが必要では。

中村:アジャイルソフトウェア開発宣言に「プロセスやツールよりも個人と対話を」とあります。これに基づくと、全体と表現した時に、個人が埋没してしまいます。一人一人の「こうしたいな」という想いや卓越性、可能性が埋もれてしまう。フラクタル構造のような小さなチームをたくさん作り、それが全体としてうまく機能するシステムなら、可能性がありそうです。

市谷:大人数の組織に対して、経営者からのトップダウンでアジャイルを導入するのは難しいですよね。

中村:トップがアジャイルを実践したいと考えたのなら、トップを含めた経営層がイテレーションに取り組むのは一つの手です。ある意味、経営層の顧客は従業員。従業員が抱える課題解決を2週間でやってみて、フィードバックを受け、評価する。経営層から始めるのは面白いと思います。

市谷:部や課、チームなど、フラクタル構造で進めていくと良いですよね。アジャイルの回転を繋いでいくことが重要です。組織内に一本の筋が通れば、参照先ができます。

中村:継続的にやれている組織は、言い出しっぺから実践している感覚があります。社長がアジャイルを取り入れたいと言うのであれば、社長自らやっている。決して「やらせる」意識ではないんですよね。いろいろな現場でアジャイルコーチをしていると「どうしたらこうさせられますか?」という言葉を聞くことがあります。

市谷:その言葉が出ると、怪しいですよね。どんな言葉を使っているかが大事だと思っています。このご質問だと「全体」という言葉にこだわってお話しされていますよね。

中村:その人のメンタルモデルが表出するので、言葉が非常に重要だと思います。「やらせる」「〇〇側」などの言葉が出て来た場合も、危険信号なのではないでしょうか。

アフタートーク

中村:今回、参加者の方から直接コンテキストをお話しいただいたのが嬉しかったです。

市谷:インタラクションできて良かったですね。

皆様からのご感想はこちら。

アジャイル開発へのモチベーションアップになりました。関係書籍を読んで学び直し、カイゼンできる部分がないか、改めて見直したいと感じました。

「理想を描く」「目的を言語化する」を自分ができていない部分があったので、今後は心がけようと思います。

「なんちゃって」でもやってみて、ふりかえり、適応していく。その繰り返しであることにとても共感しました。

言葉とメンタルモデルのお話を聞いて、はっとしました。自分自身の発言を振り返ってみたいと思います。

市谷:皆さんのお悩みを伺うと、結局は「人をどれくらい理解できているか・理解しようとしているか」に尽きると思いました。「これをやったら良い!」と一方的にぶつけても、うまく行きません。

中村:アジャイルでは、プロセスやチームにフォーカスしがちです。でも、そこにいる人たちがどんな気持ちなのかも大切ですね。本日もご参加いただきありがとうございました。

仮説検証型アジャイル開発 特設ページ