「アジャイル開発」から本当に価値を生みだすために組織がやるべきこと――スクラムを実践するエンジニアとアジャイルコーチが経験から導く処方箋

企業におけるアジャイル開発導入の成功のコツ、失敗のワケ

2018/12/07 11:00

　急速に変わり続けるビジネス環境やユーザー要求に対応するため、仕様の変化を前提にソフトウェアを作り上げていく「アジャイル」と呼ばれる開発手法への関心が高まっています。その一方で、とりあえず「アジャイル的」な手法を導入してみたものの、思ったような成果が出ないと不満を感じている組織が存在することも事実です。では、アジャイル開発から、本当の意味で成果を生みだすには、どのようにその手法を取り入れ、運用していけばいいのでしょうか。今回、ヤフーの大阪開発部で「スクラム」によるプラットフォーム開発を統括している伊藤純一氏と、アジャイルコーチとして多くの企業におけるアジャイル開発の導入をサポートしているギルドワークスの中村洋氏に、「企業がアジャイル開発を導入する際のポイント」をテーマに、お二人が拠点としている大阪の、ヤフーオフィスで語っていただきました。

認知が高まる「アジャイル」――相談内容は千差万別

伊藤：今回は、アジャイル開発やスクラムを組織にどう取り入れていくかというテーマで、アジャイルコーチの中村さんとお話しができるということで楽しみにしていました。どうぞよろしくお願いします。

中村：こちらこそ、よろしくお願いします。

伊藤：中村さんは、所属されているギルドワークスに設立から関わられているとのことですが、現在は大阪を拠点に活動されているのですか。

中村：ギルドワークスを立ち上げたのは2014年でしたね。当初は、世の中にアジャイルコーチの需要がどれだけあるか見えないところもあったのですが、実際に始めてみると、アジャイル開発をしたいがどうすればいいかというご相談を多くいただき、これまで約20社の企業、40～50のチームに対するコーチをさせていただいています。現在は1週間のうち半分は大阪、半分は東京で仕事をしているといった感じです。

伊藤：アジャイル開発に関わる相談事というのは、具体的にどんな形で持ちかけられるのですか。

中村：本当にいろいろですね。マクロな話だと、経営者の方が「自社のビジネスをもっと加速したい」という思いを持って相談に来られることもありますし、よりミクロなケースだと特定のプロダクトを作っているチームがうまく回っていないので、ピンポイントで改善してほしいというものもあります。それ以外にも、「自分たちのやり方でスクラムを回しているのだけれど、うまくできているか見てほしい」といった依頼もあります。

伊藤：アジャイルコーチを依頼してくるクライアントに、傾向のようなものはありますか。

中村：タイプとしては大きく2種類ですね。一つは、ヤフーさんのように自社でサービスを開発している事業会社で、開発プロセスをより良いものにしたいと考えておられるケース。もう一つは、企業や組織で新しいことに取り組みたいが、旧来の事業に組織が最適化されてしまっているので、マインドセットを変えるところから始めて、より良い開発体制を作っていきたいというケースです。CTOや経営者の方からの相談が多いですね。

伊藤：たしかに、CTOのような立場の人が、組織の作り方や開発プロセスの改善について相談できる場所って、あまりないですよね。

中村：そうですね。社内でCTOが何か発言すると、メンバーには命令と受け取られてしまいがちですからね。私の場合は、CTOの方から、組織の状況や課題を聞いて「ほかではこんな感じですよ」と壁打ち的にアイデア出しの相手をするようなこともあります。あと、若くしてCTOになったような人の場合には「自分はもっとコードを書きたいけれど、経営もやらなくてはいけなくて、この先どうすればいいのか」といったキャリア相談的な立場でお話しを聞くこともあります。

　伊藤さんは、ヤフーのプラットフォーム開発本部の大阪開発部を立ち上げられたそうですが、現在はどのようなチーム構成でやっておられるのですか。

伊藤：2017年の10月に、これまで東京にあった、社内向けのプラットフォームを開発する部署を一部切り出す形で大阪に新設しました。プラットフォーム開発本部の大阪開発部はほとんどのメンバーが中途採用なのですが、当初30人でスタートし、現在は約50人の組織になっています。私は、その部長の立場で、立ち上げと管轄をやっています。

中村：プラットフォーム開発ということは、プロダクトのユーザーは社内のエンジニアということになるのでしょうか。

伊藤：はい。細かい機能で言うと、例えば「画像の変換や保存」のような、社内のサービス開発エンジニアが共通で使う基盤を作っています。そうしたプラットフォームは、ヤフー社内で大小すべて合わせると100を超えるのですが、よりプラットフォームを強化していくという会社の方針もあり、人員を増やしつつ、大阪に新たに拠点を設けたという感じですね。

伊藤純一（いとう・じゅんいち）氏

　ヤフー株式会社テクノロジーグループシステム統括本部大阪開発本部テクノロジー部部長。システム統括本部プラットフォーム開発本部大阪開発部部長（兼）シナジーマーケティング取締役最高技術責任者（CTO）。シナジーマーケティング株式会社の設立に関わった後、同社の上場を機に2008年に退社。2012年にヤフーに入社し、2018年より現職。2014年にシナジーマーケティング株式会社がヤフーグループに参加したことをきっかけに、2018年より同社のCTOも兼任する。

「アジャイル」は開発現場だけでなく組織全体に変化を求める

伊藤：中村さんがコーチとして多くの企業に関わってこられた中で、アジャイルの導入について企業側が共通して抱える「課題」のようなものは感じておられますか。

中村：そうですね……。昔ほどではありませんが、「ヨソがやっているからウチもやりたい」とか「メディアに出ていたアジャイルというのをやりたい」といった形で相談を受けるケースは、やはりまだありますね（笑）。アジャイルな開発プロセスやスクラムのような手法を取り入れようという最初の段階で「では、それでどんな課題を解決したいのか」といった目的の明確化が十分に行われていないケースは、結構あると思います。

　あと、アジャイルというのは、開発現場だけでなく組織全体や経営者にも何らかの「変化」を求めます。それに対する覚悟がいるというのはありますね。アジャイルには、基本となるマインドセットや姿勢はありますが、やり方そのものの教科書があるわけではありません。つまり、現場や市場の状況に応じて、何かを探求していく姿勢が組織全体に求められるのです。それについては、なるべく早い段階で経営者の方にも理解しておいてほしいと思うのですが、「いや、俺は別にええねん。開発チームだけアジャイルにしてくれへん？」とか言われてしまうと「……やめといたほうがええんとちゃいます？」って感じにはなってしまいますよね。

伊藤：（笑）。たしかに、アジャイルやスクラムというと、どうしても「ソフトウェア開発」という文脈に限った話に捉えられがちというのはあるかもしれないですね。

中村：ビジネス的な目標と開発プロセスとがきちんとひも付けられていないために、形をなぞるだけの「なんちゃってアジャイル」になってしまうというケースは多いですよね。「うちはアジャイルで開発してます」という経営者に、「それでなんぼもうけてますのん？」と聞いて明確な答えが得られないというのは、良くない状況だと思います。

伊藤：そういう状況にならないために、組織として気を付けたほうがいいことというのはあるのでしょうか。

中村：やはり「何のための仕事をしているのか」という共通の意識を持つことですね。開発現場にいる人は、どうしてもコードを書いてプロダクトをリリースすることをゴールにしてしまいがちです。そうではなくて、多くの人にサービスを使ってもらうことや、ユーザーのフィードバックからサービスやプロダクトをより良い物にしていくことが「価値」の源泉になっているということを、組織の共通意識として持てるようにするというのは大切だと思います。

中村洋（なかむら・よう）氏

　ギルドワークス株式会社現場コーチ。さまざまな規模のSIer、事業会社でのシステム開発を経験した後、「正しいものを正しく作る現場を増やす」ことを目指して現場コーチに。「お客様を含めたチームがより良い仕事をできるように」を第一に考え、豊富なアジャイル開発の経験をもとに現場や組織が変化する支援をしている。

導入よりも「使いこなせている」段階に進むための努力が必要

中村：ヤフーの大阪開発部ではスクラムを実践しておられるそうですが、導入にあたって課題になったようなことはありましたか。

伊藤：導入そのものについては、特に難しいことはなかったですね。もともと東京ではスクラムでアジャイルを回していましたし、世間的にもアジャイルに対する認識は浸透してきています。大阪のメンバーにも変な拒否感や、逆に「アジャイルで何でも解決できる」といった誤解はなかったです。

　ただ、実際にやってみると、スクラムで設定されている「スプリントレビュー」や「スプリントプランニング」「スプリントレトロスペクティブ（ふりかえり）」といったセレモニーを形としてはできるものの、本当に使いこなせていると言える段階になるのが大変だったような気がします。

　先ほど、中村さんも指摘されていましたが、アジャイルで重要なのは、最終的に「どれだけの価値を生みだせるか」なんですよね。例えば、スプリントレビューでは、現場のメンバーに、ユーザー視点で「このスプリントでどれだけ価値を出せたか」という議論をしてほしいのですが、どうしても「どう作るか」「技術課題をどう解決するか」という話になってしまいがちです。全員が「自分たちが何のためにこの仕事をやっているのか」という視点を持って議論できるレベルになるまでに時間がかかったように思います。

中村：伊藤さんが見ておられる部署の場合、コンシューマー向けのサービスではなく、社内エンジニア向けのプラットフォーム開発を行っているというのも「ユーザー視点」に立つことを若干難しくしているかもしれないですね。

伊藤：それもあるかもしれません。サービスであれば、よりダイレクトに結果のフィードバックがあるのですが、われわれのプロダクトを使っている社内のエンジニアにしてみると、基本的には他の選択肢がないんですよね。そのニーズをどう把握するのかは、いまだに大きな課題です。

中村：われわれも、そういう相談をいただくことがあるのでよく分かります。現状、ヤフーでは社内ユーザーのニーズを捉えるためにどんなことをやっておられますか。

伊藤：実際に動いているものについては、ログデータなどから利用率を把握して改善していくということはやっていますね。あと、プラットフォームという意味で言えば、AWSやGCPなどをはじめ、世の中には機能として競合するようなサービスが多くありますよね。そうしたものを評価して、社内のプラットフォームをそれらよりも使いやすいものにしていくという取り組みもしています。

　もちろん、社内でのインタビューを通じてユーザーのニーズを把握するといったこともやっているのですが、これは聞き手のスキルに依存する部分もあって、課題の一つだと感じます。エンジニアは、ともするとユーザーに「正解」を聞きがちになってしまうのですね。実際には、ユーザー自身も自分が本当に欲しいものを言語化して把握できているわけではありません。それなのに「正解」を聞こうとしてしまうと、結果的に「これが欲しい」と言われたものをそのまま作ればいいやという話になってしまいがちです。そうした状況を避けるために、メンバーにはよく「インタビューする際には自分なりの仮説を持っていくように」と言っています。

中村：たしかに「言われたとおりに作ります」というのは良くないパターンですね。アジャイル開発の現場でユーザーインタビューはよく使う手法なので、その課題意識については、私もとても腑に落ちます。ちなみに、実際のチームはどのような体制をとっておられるのですか。

伊藤：チームはだいたい5～7人で作り、プロダクトオーナー（PO）とスクラムマスター（SM）を置くという形です。私のチームの場合は、社内の組織体制とスクラムのチームを合わせるようにしているので、POやSMがメンバーの上司になります。

「情報」の共有と同等以上に重要な「価値観」の共有

中村：先ほど「スクラムを使いこなせていると言える段階になるまでに時間がかかった」と伺いましたが、使い始めの段階からステップアップするために、どんな点で工夫をされたのでしょう。

伊藤：チーム全体がモチベーションをどれだけ強く持てるかという点には気を遣いますね。スクラムという手法を使うことについては、若干トップダウン気味に決めていますが、それをうまく回すためには、プロダクトチームのモチベーションが必須です。

　理想的なのは、どこかのチームがうまくいって、他のチームが「自分たちもああなりたい」と思いながらノウハウを横展開していく状況だと思っています。なので、各チームがやっている仕事自体は独立しているのですが、チームのSMによるミーティングを設定して、横軸での情報共有をなるべく活発に行えるようにしています。

中村：SM同士で課題解決のための知恵を出し合えるようにするわけですね。

伊藤：各チームのプロダクトは別のものなので、極論を言えば、仕事を早く進めることだけを考えるなら情報共有はいらなくなってしまうんです。でも、実際にはチームをどう作っていくかという点で、同じような課題にぶつかっているケースは多い。そのあたりを、横のつながりで解決していけるようにしたいという思いはあります。

中村：SM同士が定期的に集まって、チームでの課題や解決状況について話し合うというのは、私の見ている現場でもよく行われています。さらに進んで、SMが他のチームのふりかえりに参加するというケースもありましたね。また、今度はPO同士も同じようなことをやるようになったんですよ。そういう流れが現場で自発的に回り出す組織は、スクラムをうまく回せるようになりますね。

　あと、情報共有にあたっては、開発という仕事が生みだす「価値」についての感覚を共有するのも大切だと思うのですが、その点では何かチームに働きかけていることはありますか。

伊藤：チームのリーダーにことあるごとにお願いしているのは、チームのプロダクトは何を達成しようとしているのか。その方法と進捗をチーム全体で常に把握してくれということですね。

中村：「価値」の共有というのは、個人の価値観の違いをどう吸収すればいいのかという意味で、アジャイルでは難しいテーマでもありますよね。スポーツに例えるなら、まずは自分たちは「野球」をするのか「サッカー」するのかの認識を合わせなければいけません。そして「サッカー」をするのであれば、ワールドカップを目指すのか、健康増進を目指すのかといった、最終的な目標の違いが、チームのやるべきことや動き方を変えます。チームで決めたそうした目標に「価値」を認めて、個々がコミットできるかどうかというのは、モチベーションにも大きく影響してきます。

　ビジネス上の売上やKPIといった指標への貢献も大事であることは変わりませんが、チームと個人のモチベーションを高めるためには、こうした価値観の共有が重要な位置を占めます。逆に、それができていれば、結果は後からついてくることも多いです。

伊藤：価値の共有という点で、何か工夫できることはあるのでしょうか。

中村：アジャイルコーチとして提案していることの一つに「価値の相対化」というのがあります。バックログでは重要度に応じた「ポイント」をつけるじゃないですか。「ビジネス価値」についても、何らかの形で計測できる数値に換算するというのは、一つのやり方です。例えば、「ダイヤ」という単位をつけて、ビジネス価値を相対化して表現するということを実際にやっているところもありますね。

　「ここ、直したい言うてたけど、ほっとくとどないなんの？」「まー、ざっくり500ダイヤ減りますね」「あかんやん。ほなやろか」みたいに話を進められるんです。

伊藤：「ダイヤ」ですか。それは面白いやり方ですね。

中村：最初は「円」みたいに、お金に換算しようとしたのですが、それだと「生々しすぎる」ということで「ダイヤ」と（笑）。このやり方は、組織の中である程度の共通認識が生まれれば、例えば、チームが抱えている技術負債をリソースを使って返済しておきたいというとき、ビジネスオーナーに対して、その意義を説明するといった場合などにも使いやすいと思います。

ユーザーに対する「無知の知」からアジャイルへの取り組みは始まる？

伊藤：スクラムに限らなくてもいいのですが、中村さんがコーチとして関わられる中で、アジャイル開発の導入にあたって必要とされる優先度の高い事項というのがあれば聞かせてください。

中村：そうですね……。そもそも「自分たちがユーザーのことを何も分かっていない」ことを知るということでしょうか。多くの組織は、ユーザーについて「知っているつもりになっている」状況からはじめようとしますね。

　「自分たちのアプリがどうしてもインストールされない」という課題を解決したいというので、ターゲットユーザーへのリサーチから始めてもらったところ、「ユーザーってこういう人だと思っていたけれど、我々が思ったような行動はしておらず、こちらのメッセージも伝わっていなかった」ということが分かって、「さて、これからどうしよう」みたいなケースは結構あります。

　例えば、アプリのログを見ても、アプリを使った時間とデバイスくらいまでは分かりますが、「何のために見た」のかまでは分からないですよね。ユーザーは、本当に自分たちが意図したようなプロセスで行動しているのか。こういう人に対して、これを渡したら「A」という行動を「B」という行動に変えることができるのか。そういったものが「仮説」であり、その仮説を実証していくことが、本当の意味で「ユーザーを知る」ためには必要なんです。

伊藤：「何も分かっていないことを知る」ですか。なんだか哲学めいてきましたね。

中村：実際、アジャイルというのは哲学的な側面もあります。だいたい、最初から、作る目的も、どうやって作ればいいかも分かっている「カップラーメン」のようなプロダクトであれば、わざわざアジャイルで作らなくてもいいわけです。答えのない中で、何を、どうやって作れば、チームの目指す目的地により早く近づけるのかを考え、学びながら手を動かし続けるというのが本質ですよね。

　そして、実際にサイクルが速く回り始めると、どうしても手元だけに意識が向きがちになります。かといって、時間がありすぎると、余計なことを考えたりして無駄に時間を使ってしまう。その両方のバランスをうまく取りながら前に進んでいくというのが、一番のポイントかもしれませんね。

伊藤：そういうバランスをとったり、進むべき方向へ導いたりという役割は、誰がやっていくのが最もふさわしいのでしょうね。中村さんのような、第三者的な立場のアジャイルコーチに入ってやってもらうというのも一つの方法なのでしょうか。

中村：その役割を担うのは、アジャイルコーチではないですね。コーチは「気付いてもらう」ことが仕事ですから。

伊藤：クライアントに「気づけていないことに気づかせる」というのは結構大変ではないですか。

中村：それについては「ふりかえり」と「むきなおり」の併用で気付いてもらうように仕向けますね。手元の状況をどう改善するかは短期の「ふりかえり」。2～3か月に1度くらいのペースで「自分たちがそもそもどこに向かっているのか」を立ち止まって考えるのが「むきなおり」です。この立ち止まっての「むきなおり」というのは、結構大切なんですよ。

伊藤：そういう習慣というのは、アジャイルコーチが指摘することで、徐々に根付いていく感じなのですか。

中村：経営側が、区切られた期間の中でチームの状況を良くすることに明確な意思を持っているような場合は、多少介入度を高めますけれど、だいたいはそうです。私のスタンスとしては「いっぺん、死ぬ間際まで、いいと思うやり方でやってみたらええ」なのですが、状況を見て、完全に死にそうなときは、さすがに止めます（笑）。

伊藤：（笑）。完全に死にそうなこととか、あるんですか。

中村：たまにあるんですよ。靴ひもがほどけてるどころか、足首にひも結ばない状態でバンジージャンプしようとするところとか（笑）。

　ヤフーでは、アジャイルを通じたチーム作りに関して、何か優先的に実現していこうとされていることはあるんですか。

伊藤：ヤフーの中でも、チームや現場の体制はいろいろな形があるのですが、私の管轄では、今はチーム自体の成長を促すような形でプロダクトを渡すように心がけていますね。

中村：優秀なチームは企業にとって大きな財産ですからね。

伊藤：メンバー数やチームの数は多少変動しますが、チームとしての成長を考えると、しばらくはあまり大きく組織ややり方を変えないようにするのがいいのかなあとも考えています。

中村：チームの規模を変える、変えないといった判断は伊藤さんがされるのですか。それとも、チームリーダーに権限があるのでしょうか。

伊藤：事前にチームリーダーと話をして、今のチームで受け入れが可能かという点と、本人の志向とマッチするかどうかを考えながら、最終的な決定は私がするといった感じですね。私自身も仮説は作るようにしていますが、やはり、現場のことは現場が一番よく知っていると思うので、リーダーの意見は意思決定にあたって大きなウェイトを占めます。

中村：よく「バスの乗り降り」などと言われますが、チームのバスに誰を乗せて、誰を下ろすかはチーム自身で考えたほうがいいのではないかというのが、伊藤さんのスタンスなのですね。そう考えるようになったきっかけはあるのですか。

伊藤：うーん、それについては、業界で20年近く働いた経験から……ですかね。正直なところ「どの人がどこに配属されるべきか」なんて問題に、正解はないと思いますし、あったとしても、比較検証ができるわけではないので、結果的に分からないですよね。

　より大きな視点で、世の中の情勢やビジネス環境を見据えた企業としての意思決定などは、部長や社長など、組織でそれなりの権限を持っている人が行うのが適切だと思いますが、正解のない現場の問題は、自分たちで試行錯誤しながら正解に近づいていくというやり方のほうが合っていると思います。もちろん、自分はそこでの最終的な決定に責任を負いますが、それにあたっては現場での状況や希望をなるべく聞くようにしているつもりです。それに「自分たちの意見が反映された」という思いを持つことが、結果的には現場のモチベーションにも影響してくると思いますし。

中村：たしかに、アジャイルは「他責」の余地をあまり作らない仕組みですから、チームもそういうふうに作っていくほうが良いかもしれませんね。誰とやるかも、どう進めるかも自分たちで決めていく。自分たちで決めたことであれば、結果を他人のせいにして言い訳がしづらい。言い訳ができなければ、必死でうまくなろうとするし、そういうチームであれば、アジャイルをうまく回せるようになるだろうと思います。

アジャイルに向く人の特長は「変化への適応力」と「価値への敏感さ」

中村：そういう形でチームを作り、育てていくことを考えている中で「こういう人材がほしい」と思われる条件はありますか。

伊藤：いわずもがなですが「変化への対応力」というのは大切でしょうね。1年で市場の勝者が変わるような世の中で、かたくななこだわりがあるような人だとやりづらいだろうなとは思います。

　あと「自分が生みだす価値」に敏感であるかどうかというのは、非常に得がたい特性だと思うのですが、どうでしょう。こういう感覚というのは、何に由来するのでしょうね。例えば「過去の成功体験」が、場合によっては悪影響をおよぼす可能性がありそうというのは何となく分かるのですが。

中村：たしかにそれはありますね。ただ、そういうのって、年齢などはあまり関係なく、過去の仕事のスタイルにどれだけ浸ってきたかというのも影響するのかもしれません。例えば、伊藤さんも私も、SIerの出身ですが、やはりSIerでの仕事が長くなると「納品」を仕事のゴールと捉えてしまいがちになりますよね。

伊藤：たしかに、最初は苦労すると思います。われわれの場合も、スクラムを始めてしばらくの間は、SIer出身者から「全然、先の見通しが立ちません」「この先、何をすれば良いか分からないのが不安です」といったリアクションがありました。まぁ、それについては、次第に慣れてしまうのですけれど。

中村：コードを書くことや、リリース自体に価値があるわけではなくて、それをどれだけ使ってもらったかが、自分たちの仕事の価値になるというマインドセットを作っていくのが大変なケースもありますね。ヤフーさんの場合は大丈夫だと思いますが、そうした意識がまったくない組織で、一から価値の捉え方を変えていくというのは大変な作業になることが多いです。

伊藤：そういう場合には、どのような形で気づきを促すのですか。

中村：経営者の方には、そもそもの話として「まず、採用時に間違えないようにしてください」とはお話しします（笑）。次に、リリースをゴールにしないで、「リリースしたものがどれくらい使われたか」「ユーザーからの反応はどうだったか」といった切り口の話を、経営者やマネージャーが率先して社内でしていくことで雰囲気を作っていくことが大切だと理解してもらいます。

伊藤：そういう視点を大事にする文化を社内にどう広げるかというのは重要ですよね。われわれのチームでも、スクラムで開発を進める中で、メンバーからいろいろな課題が上がってきたのですが、その中で象徴的なものに「スピードが出ない」というのがあったんです。たしかにリリースしたコードの量で見ると、劇的に増えているわけではないのですけれど、それは、生みだしている「価値」の量とは違うということに気付いて、発想の転換をしてほしいという思いはあります。

中村：「スクラムにしたのにスピード出ない問題」というのは、よくマネージャーや経営者の方からも相談されるのですが、では、そこで問題にしている「スピード」って、何のスピードですか？コードを書くスピードですか？と問うと、案外、きちんと定義されていなかったり、ビジネス上の価値とひも付けて考えられている場合でも、評価できる形で計測されていなかったりというようなことはありますね。

　最近では、こういった説明をすることも減ってはきているのですが、経営者の方には「スクラムを導入すると、目に見える問題は今よりも増えますよ」とお話しをすることがあります。スクラムは、これまで見えていなかった問題を可視化して、それらへ逃げずに立ち向かうことで、価値を継続的に届けるための方法論だからです。その状況に向き合う覚悟がありますか？というのを、他社の事例などを見せながら説明することはありますね。

伊藤：そこに至る意識の転換というのは、結構難しいですね。よくアジャイル開発プロセスは「ツール」だという言い方をしますが、個人的には、それはちょっと正しくないのではないかと思っているのです。

　「ツール」と言ってしまうと、自分とは切り離された存在で、それをどう使いこなすかを考えるといった視点になりますよね。私はむしろ、アジャイルは、自分自身や組織の価値観や仕事の進め方を変えるためのフレームワークだと捉えるほうが、より本質に近いのではないかと思うんです。

中村：ますます哲学っぽくなりましたね（笑）。エンジニアを含む、組織で働く人がいかに自分の価値を出していくかというのは、その人の「生き方」につながる部分でもあるので、どうしても「エモい」話になりがちですよね。

　でも、そういう視点がないと、ただ付箋を貼って、ふりかえりをするだけが「アジャイル」になってしまって、その先に何をしようとしているのかを見失ってしまう。「いついつまでにこれをリリースする」という話は出てきても、「このプロダクトでユーザーに喜んでもらう」という段階にまで、意識が進まなくなってしまうのです。

アジャイルを推進するエンジニアのキャリアパスをどう考える？

伊藤：今日、中村さんにお聞きしたかったことがもう一つありまして、それは、組織の中でアジャイルを推進する立場に就く人材に、どのようなキャリアパスを考えておくべきなのだろうかということなんです。

　例えば、SMをお願いしたとき、その人が開発に使える時間、具体的にコードを書く時間は減りますよね。それが、当人のキャリアにとって悪影響を及ぼすのではないかという懸念が、現場からの不安として上がってくることがあるんです。このあたり、ほかの組織ではどう考えているのでしょうか。

中村：アジャイルを推進する立場の人とSMというのは、必ずしも同一ではないと思いますが、たしかにそうした立場の人が一つのチームに収まり続けるというのはあまりないですね。組織全体の変化について触媒となる立場なので、事業部をまたいで異動するといったこともあるでしょうし、場合によっては、別の組織へ飛び出していくこともあります。

　ただ、SMについては、必ずしも「コードが書けなくなる」というわけではないと思います。というのも、チームが抱えている、その時々の課題に応じて、SMも変えていけばいいからです。例えば、チームが「人間関係の改善」に課題を抱えているなら、その分野に適性のあるSMがふさわしいと思いますし、次に課題が技術的なものに変わったら、今度は、その分野に詳しい人をSMにして巻き込んでいけばいいのです。

　また、SMにとって「自分がコードを書けない」ことが不満なのであれば、「自分がコードを書けるようなチーム」を作るよう促してみるというのはどうでしょう。やり方はいろいろあって、ペアプログラミングのような手法を取り入れてみるというのも一つの方法です。そもそも、SMがコードを書かないと、チーム内での信頼が得にくいという側面もありますし、そのあたりは悩ましくて面白い部分でもありますよね。要は、自己組織化を促進するようなチーム運営を目指すべきだろうということです。

　とはいえ、コードを書くことだけに執着するよりも、SMの醍醐味はPOやチーム外の人と話をすることで、これまでとは違った視座で、組織や自社のビジネスを見られるようになることだろうと思います。半年や1年といったスパンでのそうした経験は、エンジニアとしてのキャリアにおいてプラスになることはあっても、決してマイナスにはならないと思いますよ。

伊藤：大阪開発部の中でも、SMを経験してもらった上で、他チームへ移ってもらうといったケースはありますね。今、中村さんは「視座」と表現されていましたが、組織全体をどう動かすか、組織のどこに課題があるのかといった視点で物事を見る経験は、人材としての成長につながるだろうと思います。本人にも、自分のキャリアについて、そういう価値観で見てもらえるようにサポートしていくことが大切かもしれませんね。

　今日、中村さんにお話しを伺って、アジャイルでは、チームの仕事がどれだけの「価値」を生み出せるかが最も重要だということを再確認できました。特に社内向けのプラットフォーム開発を行っていると、ユーザーのニーズや思いが見えづらくなりがちなのですが、自分たちが手を動かすことが、組織の中でどういう価値につながっているのかというのは、常に意識をして、忘れてはいけないなと感じました。本日はどうもありがとうございました。

中村：そう言っていただけると、私としてもうれしいです。こちらこそ、どうもありがとうございました。