アジャイルなのに正せない? 開発の行き詰まりを打破するポイントを市谷聡啓さんに聞く

アジャイルなのに正せない? 開発の行き詰まりを打破するポイントを市谷聡啓さんに聞く

よりよいプロダクトを作り、高い価値を届けようと、アジャイル開発のアプローチで真剣に取り組んできたのに、「なんか違うよね」「それより、もっと早くリリースできないの」といった予想外のフィードバックに直面し、立ち止まってしまう──そんな現場は珍しくないのではないでしょうか。

20年以上にわたり現場と組織の両面からアジャイルを実践し、さまざまな現場を支援してきた市谷聡啓さんは、そんな行き詰まりの原因を、個々のスキルやプロダクトではなく、チームを取り巻く「構造」にあると分析しています。

こうした「構造」を捉えながらアジャイル開発を進めていくには、どんな取り組みが必要なのでしょうか。具体的なポイントを市谷さんに伺いました。

アジャイルが成熟してきたがゆえに直面する「構造」の問題

── 長年、アジャイル開発を支援してきた市谷さんですが、現在の開発現場で起きている問題をどう見ていますか。

市谷 これまでアジャイルの支援を続けてきた中では、その時々で「どうすれば開発がうまく進むのか」「プロダクトオーナーはどのように振る舞うべきか」といった、自分にとっての大きなテーマがありました。

そして最終的に、これらの諸活動が現場でうまく機能するためには、「母体となる組織にどうアジャイルの考え方を取り入れていくか」という「構造」の問題にたどり着きました。

── その時々でテーマが変わってきたのはなぜでしょう。アジャイルが浸透し、成熟してきたがゆえの課題もあるのでしょうか。

市谷 そうですね。最初は一つの開発チームにおけるアジャイルが焦点でしたが、チームが複数になり、事業部のような大きな単位になり、さらに組織全体としてどうアジャイルに取り組むか、といった具合にスコープが広がり、成熟してきたからこその課題もあると思います。

よくあるケースで言うと、アジャイルを取り入れる際には「本や教科書ではこのように書いてあるから」と、“やらなければいけないこと”を列挙し、それをなぞって書かれた通りにやろうとしがちです。

それはそれで最初の一歩として必要なことですが、本来の目的が見えず、ただタスクをこなすだけの「Do Agile」に留まっていることが多いんです。そうではなく、アジャイルな考え方をみんなが身に付け、状態としてアジャイルになる「Be Agile」にたどり着くことが大切です。

ではどうすればそこにたどり着くのかというと、取り組む本人だけでなく周囲の関係者、さらには顧客やユーザーも含め、どんな関係性──いわば構造があるのかを整理する必要があります。

そして、よりよく機能させていくには構造そのものをどう変え、適応させていくべきかに着眼する必要があると思うんです。最新刊の『作る、試す、正す。』はそういった構造についての話をテーマにした本です。

※編注:市谷さんの著書では「システム」と表現されていますが、本記事ではITシステム等との混同を避けるため「構造」に統一して表記しています

── アジャイルの本質的な動きを「正す」と表現されているのが非常に印象的です。これは具体的にどういう状態を指すのでしょうか。

市谷 「作る」「試す」「正す」というのは、アジャイルの適応プロセスそのものを言い換えたに過ぎません。何かしらを生み出す「作る」、その生み出したものを使ってみたりして「試す」。そして試すことで「もっとこうした方がいい」といろんなことが分かり、それを元に、より良くするために変化させていく。それが「正す」ということです。

互いの「正義」が衝突し、「正す」ことができなくなる

── 多くのアジャイル開発現場では「作る」「試す」はできていても、最後の「正す」で行き詰まるケースもあるようです。原因はどこにあると思いますか。

市谷 これはまさに構造の話とつながる問題です。

そもそもプロダクト開発は、開発チームだけで完結するものではありませんよね? 事業責任者や経営層など、チームの外側にいるステークホルダーを含めた構造の中で成り立っています。当然、それぞれの立ち位置によって「何が成果か」は全く変わってきます

── 開発チームと経営層では、見ているゴールが違うわけですね。

市谷 その通りです。だからこそ、作り、試して、いざ「正そう」としても、お互いの期待値がズレてしまうんです。

同じ「正す」でも、開発チームにとっての「正す」は、「ユーザーからの学びを反映してより良くすること」。しかし経営側にとっては、予定通りに早く市場へ出すために「進捗させること」だったりする。

── 全然違うのですね。

市谷 この期待値がズレたまま経営側からプレッシャーをかけられると、現場はやろうとすることがブレてしまい、本来やるべき軌道修正、つまり正すこと自体ができなくなって行き詰まってしまうわけです。

── みんながそれぞれの立場で一生懸命アジャイルに取り組もうとするがゆえに、空回りし、絡まってしまうイメージでしょうか。

市谷 はい。以前であれば、そもそもアジャイルへの理解がなく、最初から話が噛み合わなかったんですね。

しかし最近は「新しい価値を生み出すにはアジャイルが必要だ」と知っている人が増えています。だからこそ、厄介な事態が起きていると思っています。

── 理解は進んでいるのに、厄介な事態とは。

市谷 どこの組織も、とりあえずアジャイルを始めてみるわけです。2週間単位でスプリントを回し、途中途中で「こんなアウトプットになりました」と、ちゃんとお披露目(レビュー)をしながら進めていく。

それなのに、3カ月ぐらいたったときに突然、周囲から「これじゃない」「いつになれば完成形が見えるんだ」と、お互いの認識が全く違っていたことが発覚するケースがよく起きています。現場からすると「毎回レビューで見せてきたのに、なぜ今さら?」という感覚ですよね。

── つらい「ちゃぶ台返し」ですね……。なぜ3カ月もたってからそんなズレが発覚するのでしょうか。

市谷 最初から意見が噛み合わなければ、揉めながらでも調整できます。しかし今の現場で起きているのは、「お互いにゴールが共通だと思って、進み始めてしまう」ケースなんです。

「これじゃない」の裏側には、関係者それぞれの「仕事ってこういうものでしょう」「これこそが大事だよね」という価値観があります。

「一度決めたものを早く形にすること」を重視する人もいれば、「作りながらフィードバックを得て、より良い形を模索すること」を重視する人もいます。両者には結構な隔たりがありますよね。残り時間が少なくなるにつれ、その「期待違い」が現れやすくなるように思います。

── 誰も悪くないのに、そうなってしまう、と。

市谷 本当にそうなんです。どちらにも一理あるからこそ、開発チームの「正義」を貫いても、事業責任者や経営者の「正義」で押し切ろうとしても、結局うまくいかなくなってしまう。だからこそ、誰がどの立ち位置で、何をゴールとして置いているのか──ということを、構造的に捉えておくことが大事だと思います。

それぞれの立ち位置を整理し、方向性を可視化する

── そこで目を向けるべき「構造」とは、具体的にどのようなものなのでしょうか。

市谷 例えば、開発チームはユーザーからの学びを反映しようとしているのに、事業側は「いつリリースできるのか」を最優先に見ている──そんなズレが起きることがあります。

「この人がダメだ」とか「こんなロールがないからダメだ」といった、個々の要素だけに着眼すれば解決できる話ではありません。

そうではなく、ヒトやコト、モノがどのように絡み合って活動を織りなしており、どんな関係があるのか、という部分に目を向けない限り、うまくいかないと思います。

加えて、状況は常に動いていきますから、ある時点では合っていても、しばらくたてば変わるかもしれません。ですから、ヒト、モノ、コトに加えて、時間軸である「トキ」。この4つの軸で、現在の状況を捉えていく必要があります。

ヒト、モノ、コト、トキ
▲ ヒト、モノ、コト、トキの全体像で構造を捉える(「作る、試す、正す。」より)

市谷 プロダクト開発も一つの「構造」ですし、事業活動も同じです。そもそも会社や組織自体、いろいろな人の協力で成り立っている一つの「構造」ですよね。ITシステムもまた、いろいろな要素が噛み合って業務を効率よく行えるようにするものですから、「構造」の一つと言えます。

── では、その構造を捉えていくためのポイントは何でしょうか。

市谷 先ほどお話ししたように、関係者それぞれが自分なりの期待や評価軸を持っています。ただ、それが分かりやすく見えているわけではなく、暗黙知になっていることが少なくありません。

自分がプロダクトオーナーだとすると、相手からすれば、「このチームはどんな方向性でやろうとしているのか」が見えないから、不安になるんです。そうすると、それをかき消そうとして「進捗会議にいないなんてありえないでしょ」「毎週、毎月ちゃんと報告を上げなきゃダメでしょ」という話が突然降ってわいたりします。

── 現場のエンジニアからすると「今はそんな詳細な報告をやっている場合じゃないのに」と感じる場面ですね。

市谷 ええ。ですから、チームとして、リーダーとして、「今の時点ではどんな方向性を向いているのか」を可視化し、明らかにしていくことが大切だと思います。その方法はインセプションデッキでも、スクラムで言うプロダクトゴールでも、あるいはOKR(Objectives and Key Results)でも何でもかまいません。

チーム内外の人たちとコミュニケーションを取ることが最初の一歩だと思います。

── 方向性が見えていれば、「正す」こともやりやすくなりそうですね。

市谷 そうですね。「リーダーの考えていることがよく分からないな」とか、「なんだかゴールとして考えていることがみんなバラバラだな」と感じることはよくあると思います。そんなときに、インセプションデッキを作ったりして自分たちの姿を映し出し、ギャップに気付くのはいい手だと思います。

ただそれも、あくまでその時点での方向性でしかありません。時間がたち、活動を進めていくと「もっとこうした方が良かったな」といろんなことが分かってきます。

ですから、1カ月単位くらいでインセプションデッキを更新したり、プロダクトゴールを置き直したりして自分たちを顧み、点検して、方向性を正す、「むきなおり」をやっていくことがいい動き方なんじゃないかと思います。

意見が衝突したら「アクションの順番」で合意する

── 場合によっては意見が衝突することもありますが、そんなときのコツはありますか。

市谷 例えば「この機能を作るべきか、否か」について、どちらかが正解というような分かりやすい状況なんてほとんどありません。どちらにも一理ある状況はざらにあります。

そこで一方的に言い負かしたり、強引に説得したり、とにかく拒絶したりしてもあまり本質的ではありません。双方を尊重しつつ順番を付けたり、「では別の検証を行って、その上で判断しましょうか」と提案したりすることで、折り合いが付けられると思います。

試して、その結果に基づいてその後のアクションを決め直していけば、合意を形成しながら最適な選択ができるのではないでしょうか。もし全く順番を付けられないような場合ならば、それは、判断に要する情報やデータがなさ過ぎるんだと思います。

── 市谷さんが実践している「仮説展開ストーリー」もそうした際の武器になるでしょうか。

市谷 そうですね。事業開発の局面なんて、たいていはいろいろなことを同時にやらなきゃいけないとか、早くやらなきゃいけないとかで、全体がごちゃっとしているわけです。分かりやすく「1個これを進めればいいですね」となっていないことが多い。

なので、仮説展開ストーリーで「一手目はこう、二手目でこうして、三手目はこう」と手番を示すことで、複雑な状況が非常に分かりやすくなります。

── ストーリーの中に位置づけてあげる。

市谷 みんながそれぞれ「これが大事だ」「これを先にローンチした方がいい」と思っています。そこに対してどれかを拒絶するわけではなく、「仮説展開ストーリーの順番の、ここで出てきます」と表現するんです。

そうすると、「そこでは出てくるね」と自分の意見がちゃんと拾われている状況になるので、納得するというか、場が収まってくるということはやっぱりありましたね。

仮説展開ストーリー
▲ 問いを立てることで仮説検証のサイクルを回す(「作る、試す、正す。」より)

── スタートアップに近い、まだ小さな企業では、距離が近いからこそのハレーションも起こりがちだと思いますが、そうした際のポイントはありますか。

市谷 大きな企業には多くのステークホルダーがいていろんな意見を出してくるという難しさがある一方、小さな企業ではステークホルダーが近くにいてコミュニケーションがしやすいからこそ、毎日のようにフィードバックしてくる、といった別の難しさがあります。

ただ、どちらにしても「今は何を手がかりに、どこを目指しているのか」をきちんと表しておく必要があります。後から「ちゃぶ台返し」が起こるにしても、まずは前提や期待といった「ちゃぶ台そのもの」を見えるようにして、認識を揃えておくことが必要でしょう。

俯瞰的に「どんな期待の中で動いているのか」を顧みる

── 市谷さんご自身がアジャイル経験の中で、「正す」ことがうまくいかなかったことはありましたか。

市谷 そんな経験ならば山ほどあります。むしろ、新たな取り組みを始め、新しい価値を目指そうとする時なんて、うまくいかないことの方が圧倒的に多いでしょう。

近年のDX推進の流れの中で、組織の価値観をガラッと変えようとする局面が増えました。僕はそこでやってみて改善していくアジャイルの本質的な動きを支援してきたわけですが、どうしても、あらかじめ決めたスケジュールやコストを守り切るといった「これまでの組織の考え方」と真っ向からぶつかってしまうんですね。なかなか容易に乗り越えられそうもない、激しい衝突になることもあります。

── 規定路線を良しとする文化から見れば、「やってみないと分からない」という進め方はリスクに見えるんでしょうね。

市谷 だからこそツッコミも激しくなります。そこで大切なのが、何度も申し上げてきた通り、「何を考えているのか」という方向性を明らかにし、見えないことに対する周囲の不安を解消することです。デッキを使ったりして明らかにし、認識を合わせていくことは大切にしています。

ただ、認識を合わせたから終わりではなく、この答えのない課題に対してトライアルし続けるしかないのが難しいところです。

── 終わりがない分、メンタル的に弱気になってしまう瞬間もあると思います。どう対処してきましたか。

市谷 新しいことをやろうとすると、うまく行かないことの方が多いですから。

僕の場合は、家の近くに海があるのでそれを眺めに行きますね。で、「自分がやっていることって、自然に比べたらたいしたことないな」と思って持ち直したりしていました(笑)。

全てを一気に解決できるわけじゃないという視点に立って、「ちょっとこれだけ試してみよう」と小さなことを織り交ぜて、意識的に時間を少し先送りしてみるのも乗り越え方の一つだと思います。

── 今まさに「正せない」という壁にぶつかり、立ち止まってしまっている現場の読者へ、アドバイスをお願いします。

市谷 得てして僕らは、プロダクトづくりに集中し、自分の理想を注ぎ込みがちですが、それでは思いもよらぬフィードバックを受けて立ちゆかなくなることがあります。

ですから、自分が組織やチームという構造のどこに位置しているのかを意識することが大切です。そうすることで、自分たちとは異なる評価軸の存在に気付くことができます。

アジャイルのプロセスを改善するだけでなく、まずは自分たちを俯瞰し、「周囲からどんな期待を背負っているか」「自分たちの発信は十分なのか」を顧みてはいかがでしょうか。

取材・構成:高橋 睦美
編集・制作:はてな編集部

現場の行き詰まりを「正す」視点を知る

市谷聡啓
市谷聡啓(いちたに・としひろ) X: @papanda
株式会社レッドジャーニー代表。プログラマーとしてキャリアを始め、SIerでのマネジメントや大規模インターネットサービスの運営を経て独立。20年以上にわたり現場と組織の両面からアジャイルを実践し、「正しいものを正しくつくる」あり方を探究してきた。主な著書に『カイゼン・ジャーニー』 『正しいものを正しくつくる』『組織を芯からアジャイルにする』、最新刊に『作る、試す、正す。アジャイルなモノづくりのための全体戦略』がある。