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

イベント第7回目は、皆さまからの3つの質問と1つのトピックについてお話しします。
対談の中で「”組織の変化”をプロダクト捉えること」がヒントになるのでは?と中村が提案。

「組織をもっと良い感じにしたい」あなたへ、手がかりがきっと見つかるふたりの対話をご一読ください。

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

話し手

市谷 聡啓 Toshihiro Ichitani

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

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

中村 洋 Yoh Nakamura

株式会社レッドジャーニー
CSP-SM(認定プロフェッショナルスクラムマスター)・CSPO(認定プロダクトオーナー)

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

目次

情報処理部門をどうにかしてほしいというリクエストが増えてきた

中村:それでは、この質問から始めていきます。

最近、ユーザ企業で情報処理部門をどうにかしてほしいとのリクエストが増えてきた

中村:いわゆる「ディフェンシブな姿勢の情報システム部門をどうにかしてほしい」という話なのでしょうか。開発部門に比べると、情シス部門はDXやアジャイルに関する取り組みに対して及び腰である場合が多い印象ですが、市谷さんはどう関わっていくことが多いですか?

市谷:一旦、蚊帳の外に置いてはどうでしょう。チームメンバーと話をして前に進めばいいのですが、それをやったけどうまくいかないんだと思います。情シスを別にして組織改革を進めたらどうなるかを実験してみても良いのでは。

中村:当然、情シス部門の人たちに悪意があってうまく立ち回れていないわけじゃないですよね。今ある仕事を一生懸命やっている中でのことだと思います。そこに「アジャイル大変革だ」と言われても対応するのは難しいです。情シス部門を切り離してみた後、どんなことが起こりそうですか?

市谷:時間軸が長めの話ですが、情シスを切り離して組織変革を進めていくと1〜2年後には情シスのメンバーも「自分たちはこのままではダメだ」と感じるようになってくるんですよね。情シスなりに進化できる状況が作れると良いのではないでしょうか。

中村:情シスとは別の、社内のデジタルトランスフォーメーションをする「攻めの情シス」のようなチームを作るパターンが多いですよね。情シスはこれまで通り保守を担当して、新しいチームが現場の支援をする。それがうまく行くと「旧来の情シスよりこっちの方がいいじゃん」と社内の空気が変わって、情シスの進化が問われます

市谷:変革のターニングポイントで私が組織を支援する時には「ビジネスにどう向き合っていくか」という判断軸があります。そこに向けて段階的に変革を進めるのですが、いきなりすべてを変えるのはハードルが高いです。緩やかな段階の引き方で進めるのが大事だと思います。

中村:まずは「情シスの人たちがどのようにビジネスに貢献していくか」という問いと向き合い、その中で組織の形や仕事の仕方が変わっていく、というのが一つのアプローチですかね。

市谷:そもそも、必要性に駆られないと人間は動かないものだと思います。情シスの皆さんにとっての大きな課題が今ないのなら、力でこじ開けようとしても無理がありますよね。情シスは別に置いて組織変革を進めることは決して過激なやり方ではなく、多くの組織がそうしていると思います。

中村:例えば、カスタマーサポートとカスタマーサクセスの場合。名前が似ているので二つを同じ部署にするという話を聞いた時は、乱暴だなあと思ったんですよね。名前は似ていてもマインドが全然違います。

カスタマーサポートは何かあった時に迅速に対処する。カスタマーサクセスはアクティブに動いてお客様と伴走して成功に導いていく。これってスキルとマインドがまったく違いますよね。同じように、守りの情シスと攻めの情シスを同じようにするのはちょっとしんどいだろうなと思うんです。

アジャイル中級者向けにおすすめの本を教えて欲しい

困りごとではないが、アジャイル中級者向けにおすすめの本を教えて欲しい

中村:「中級者」とは、アジャイルと言われるものを見よう見まねで1〜2年やっている感じでしょうか。もちろん年数だけの話ではないですが。

質問への直接の答えではないですが、この質問に私は二つ思うことがあります。一つは、本を読むよりも誰かと対話をして自分の意見をぶつけてみることの繰り返しが実は大事なのでは、と考えています。勉強会後の懇親会で「自分は本の内容はわかる。ところであなたはどう考えるか?」と、誰かと話すことによって自分自身が鍛えられたなあと思っているんですよね。

もう一つは、アジャイルは単にソフトウェア開発の話ではなくて、人間や集団の話にも及びます。だから、アジャイル中級者はアジャイルやスクラムそのものではなく「人や組織はどう動くのか」などの本を読むと良いのではと思っています。

市谷:エッセンシャル スクラム』は中級者向けだと思います。その辺りの本を読んだり、リーンにも手を出したりと、「深める」と「広める」をやってみてはどうでしょうか。そこで語彙を手に入れて、達者そうな人と問答してみるのは良いですね。実地でやってきたことを踏まえてぶつけてみるとより良いのではないでしょうか。

中村:古いですが『アート・オブ・アジャイル デベロップメント』もどうでしょう。最初に読んでから数年経った後にもう一度同じ本に目を通してみると新たな発見があると思います。市谷さんが中級者だった頃は、どのように知識を深めていましたか?

市谷:昔のアジャイルはそもそも実践している人が少なかったので「一歩踏み出したらもう中級」という感じでした。そんな中でどうやっていたかというと、ずっと苦労していた気がします。コミュニティでの活動よりは、イベントで発表することが多かったですね。自分の経験や思いを言語化して、発信して、意見をもらって……を繰り返していました。

中村:私が中級者だった時は、コミュニティで2週間に1度集まって飲みに行き、そこで話をぶつけることをしていました。「そういう切り口があるんだな」と引き出しを増やすために対話が役立っていましたね。

プロジェクトへの向き合い方を「プロダクトの価値最大化をする」に変えるためには?

開発メンバーのプロジェクトへの向き合い方を「プログラミングをする」から「プロダクトの価値最大化をする(プロダクトをプロデュースするくらいのスタンス)」に変えるためにはどうすればいいでしょうか。

質問者:私はグループ会社から現場に駐在する形で、社内で初めてのアジャイルプロジェクトに携わっています。アジャイルに取り組んでいると、プログラミング以外のいろいろな視点を持つことが必要だと私は感じています。

ただ、メンバーの中には「私はプログラミングが好きなのでそれだけやりたいんです」というタイプの人がいます。現場にこういったメンバーがいたら、ユーザーの価値最大化を実現できるのでしょうか。

中村:正攻法として、ユーザーの姿や声を開発メンバーへ届けるのはよくある形です。使っている人の姿を見ると、「ただ綺麗で動くコードを書けば良い」ではなく、「どうやったらこの人がもっと楽になるんだろう」と考える視点が増えるので、見方が変わる人もいますね。

もう一つは、メンバーに対する期待を明確にすること。「あなたの仕事はプログラミングではなく、顧客の課題解決が仕事ですよ」と伝えるのが大事ですね。『カイゼン・ジャーニー』では「あなたは何をする人ですか?」と問う部分がありました。この二つのアプローチをよく実践します。

質問者:以前、メンバーから「アジャイルって、やったら次のタスクを取っていくので、やったらやった分だけ損しますね」と言われてしまいました。前向きなマインドに変わっていくにはどうしたら良いのか、経験談があれば聞きたいです。

中村:私の経験では、全員が理想的なマインドを持つようになるかというと、そうはならないですね。スクラムの本にもある通り「チームとして価値を届けること」が軸にあります。もちろん、メンバーそれぞれがスペシャリストであり、オープンなマインドを持つのは大事です。そうは言っても、全員が本当にユーザーのことを考えて、さまざまなことを同じレベルで理解する必要があるかと言うと、そこまで平等にしなくてもいいと思います。メンバーの特性もあるので、問題ないと思っています。

市谷:「自分たちのミッションって何だろう?」と、メンバーで対話する時間を設けていますか?

質問者:プロジェクトがスタートした時はチーム全体で自分たちの目指すところは何かを話す場がありました。ただ、今は個人の雑談の中で話す程度になっています。スプリントの時間との兼ね合いがあるので、時間を取るのは難しいと思ってできていません。

市谷:スクラムイベントを一個潰して時間を確保してもいいくらい、チームでゴールを確認するのは大事なことですよね。

中村:もしあなたがアジャイルを始める最初に戻ったとしたら、どうやりたいですか?

質問者:時間をかけてじっくりインセプションデッキを作りたいです。プロジェクトの目的がざっくりとしていて、開発チームのメンバーが腑に落ちるまで噛み砕いていませんでした。字面通りに捉えるのではなく、自分ごと化できるまでしっかり取り組みたいですね。

市谷:ご自身の中で「これはできた方がいいな」と思うことを一つ考えて、実現に向けて動いていくと良いのでは。「プロジェクトの目的をチームのみんなで共有できたら、一緒にやっている感覚が持てて、気持ちも高ぶっていいかな」と考えてみるなど、まず一個にフォーカスしてやってみるのが良さそうです。

中村:今はいろいろな思いがあると思いますが、今できていることに目を向けてみて、そこにプラス1するために何かしてみてはどうでしょう。それを繰り返すことで、前向きな姿勢になれるのではないでしょうか。

インセプションデッキについては、私の体験談からすると、そんなに最初から噛み砕けないです。「なんとなくこんな感じかな?でもこの辺はふわふわしてるよね」と、ふわふわ度を認知した上でやっていきます。2週間くらいでうごくものを作ると「やっぱりこの辺がわかっていなかったよね」と、デッキをアップデートできるようになると思います。最初からガッツリやるより、序盤では「自分たちの拠り所となるインセプションデッキをアップデートする」という活動に取り組んでもいいのかなと思いました。

“組織への変化” をプロダクトと考えてみる

中村:最後に、私が今日取り上げたいと考えていたトピック「“組織への変化”をプロダクトと考えてみる」について話したいです。

組織に変革を起こす時、突然「これ良いからやりなよ」ではダメだと思っています。相手には相手の環境やペインがある。「そのペインにこれがこんなふうに効くよ」と伝えたり、実績を見せてあげることが必要です。相手が何を解決したいかをわかった上で提案して、相手が興味を持ち、試しながらやってみる、という段階があります。マーケティングと同じですよね。

組織の変化というプロダクトを、それをやってほしい人に送り届けるにはどうするか、プロダクトをセールスしたりマーケティングしたりするにはどうしたら良いか、と最近考えていました。市谷さんはプロダクト作りと組織の変化の関連性について考えることはありますか?

市谷:Radical Product Thinking』には「プロダクトで変化を起こす」と書いてありました。私は、組織の変化をプロダクトと考えるのはアリだと思います。仮説キャンバスでもこのように話すことが多いです。

「プロダクト作りが組織変革を牽引する」という仮説を私は持っています。組織変革ってどこまで行っても曖昧なのでは。何が組織変革の中心なのかと考えてみると、人とパワーポイントしかないので、ふんわりしたりネジ曲がったりすることが多いと思います。

「アジャイルな組織になっていく」を From To の To として描くのなら、プロダクトづくりが変格活動の中心にありますよね。プロダクト作りの中でアジャイルを学ぶことができるので、そこが組織変革の求心力になると考えます。

それに、プロダクトができてくると放っておけないので、注目を浴びて行くんです。組織の中に存在しやすく、求心力になります。関係ないように見えて、実はプロダクトづくりが変革の中にあると、それを軸に組織を動かしていけるのではないでしょうか。

中村:たしかに、組織変革をしたら明確に何が変わるのかと考えると、分かりづらいですよね。例えば「エンゲージメントが高まる」と言われても、効果が見えづらいです。

一方、プロダクトであれば物ができていきます。使うユーザーが増えたり、もしくは全然使われなかったりすると、「じゃあどうしようか?」と行動せざるを得ない。物理的に向き合える対象が組織の中にあるのが大きなポイントかもしれないですね。

仮説キャンバスは、最初はプロダクトやサービスについてのものだったと思います。市谷さんがその概念を組織に当てはめるようになったきっかけは何でしたか?

市谷:「仮説だから」が大きいです。組織の変革は「こうすれば変革できる」と明確な答えがあるわけではないし、答えがあってもその通りにできません。仮説を立て続ける必要があるので、とても不確実性の高い活動です。組織変革だけは、ウォーターフォールで進めるのは無理です。

中村:複雑性の高い個人の営みが生み出していることなので、最初から何もかもうまく行かないですよね。三か年計画で組織変革計画を立てるのもナンセンスです。プロダクトマネージメントに必要な概念は、やはり組織変革に使えますね。それらを駆使して、現場からトップまでを巻き込む大きな渦を作っていけたら良さそうです。

良いプロダクトマネージャーは、どのセグメントをどう倒していけばユーザーがグロースするのか、社内をどう巻き込んでいくかなどと、戦略を立てます。これはまさに組織変革の旅と同じです。思いを軸に走る熱い人と、プロダクト作りに情熱を持ちつつ戦略を立てる人が一緒に変革を進めるのが、勝ちのパターンの一つかもしれません。

アフタートーク

市谷:変革していくのは大変ですが、昔に比べると今は変革の研究が進んでいます。現在では仮説が立てられるようになっているので、突破口がありますよね。ただ、「自分が変革を背負わなくていい」と思ってその会社を辞めたとしても、日本のほとんどの組織で変革が必要な状況なので、残念ながら楽な道はないです。

中村:確かに、以前に比べて変革を進めている仲間がいるのは大きな変化です。今回のような場を通じて何かを得て、試して、どうだったのかをまた聞けると良いですね。

ご参加いただいた皆さまからの感想も届いています。

組織変革について仮説キャンバスを使って考えてみようと思います。

「プログラミングだけしていたい」は、今日まさにチームメンバーから届いた言葉でした。チームのビジョンをみんなで再確認します。

アドバイスいただきありがとうございました。いきなり多くを求めるのではなく、地に足をつけて頑張りたいと思います。

中村:現場で何かのお役に立てば嬉しいです。今日もご参加いただきありがとうございました。

市谷:ありがとうございました。

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