【ryuzee｜吉羽龍太郎】アジャイル開発のエキスパートが語る「エンジニアはビジネス視点を持て」の裏に隠れた本当の問題

事業とテクノロジーの関係が深まるにつれ「エンジニアもビジネス視点を持つべき」という声をよく耳にするようになりました。その結果、ビジネスに関心が薄いエンジニアへの風当たりは強くなる一方、「ビジネス視点とは何か」と悩みを深めるエンジニアも少なくありません。

アジャイルコーチとして知られる吉羽龍太郎さんは、「エンジニアがビジネス視点を持つべきという意見に異論はないものの、これをエンジニアだけの問題と捉えると本質を見誤る」と懸念を表します。なぜ吉羽さんはそう感じるのか、お話を聞きました。

• keyboard_arrow_down 便利さゆえに濫用されがちな「ビジネス視点」という言葉
• keyboard_arrow_down 大半の問題は「ゴール」が共有されていないから起こる
• keyboard_arrow_down プロダクトのゴールが曖昧なら、疎まれても問い続けるべき。それができればチームは変わっていく

——早速ですが、吉羽さんはアジャイル開発とビジネスとの関係をどう捉えていらっしゃいますか？

時代の変化とともに、アジャイルであることがビジネスの成功要件になってきたように思います。

僕が社会人になった1990年代当時は、まだITの手が及んでいない業務がたくさんあったので、その業務をシステムに乗せること自体が、課題解決と同義だったんです。エンジニアが目指すゴールも、「業務をシステム化すること」であって、あらかじめ決められた仕様と設計通りに開発すればいい。だからこそ、上流から下流へ順番送りで開発が進むウォーターフォール型の開発スタイルが隆盛を極めたわけです。

しかし、インターネットやスマホの普及で状況が一変しました。誰もが手軽にインターネットにつながる時代が訪れた結果、トレンドの移り変わりが速くなり、多様性を帯びるようになりました。つまり、じっくり時間をかけて煮詰めた企画が、リリースするときにはすでに市場にフィットしなくなっている、といった問題が起こりはじめたわけです。

この十数年の間に起こったのは、つくるべきものがはっきりしていた時代から、環境の変化を前提に探索や改善を繰り返す時代への移り変わりといえます。これは明らかにウォーターフォール型の開発スタイルとは相容れない世界観です。アジャイル開発が発展したのは、市場やビジネスの行く末が予測不能で、しかも変化のスピードが速くなっていく流れを受けてのことです。

ですから、アジャイル開発とビジネスは切っても切れない関係にあるといえるでしょう。

——昨今、エンジニアもビジネス視点を持つべきだという声をよく聞くのですが、これも時代の変化と関係があるんでしょうか？

確かに「ビジネス視点を持て」という言葉は最近よく耳にするようになりましたね。時代の変化とともにその声は大きくなってきたと思います。もっともらしく聞こえるセリフですが、果たしてここでいう「ビジネス視点」とは、一体何を指しているのでしょう？

——そう言われてみると、話す人やシチュエーションによって色々な意味が含まれている気がします。

そうですよね。一見便利そうなのでつい使いたくなる言い回しですが、主語が大きすぎるがゆえに捉え方は人それぞれ。何を意味するか曖昧なのは否めません。

たとえばビジネス側の人たちが「ビジネス視点を持ってほしい」とエンジニアに伝えたとします。でもエンジニアにしてみれば、売上貢献を求められているのか、開発スピードを上げろといわれているのか、それともビジネス側の意向を汲んで開発しろといわれているのか、すぐにはわかりません。そんなあやふやな状態でエンジニアに「ビジネス視点を！」といったところで、戸惑った表情を返されるのがオチでしょう。

——結局、「ビジネス視点」って何なのでしょう？

顧客が抱えている課題を解決することや、顧客体験の最適化もそうですし、投資対効果や、会社の戦略と開発しているプロダクトの整合性、あとはプロダクトやユーザーの現状に基づいた判断もそのうちに含まれるでしょうが、一つひとつ挙げたらキリがありません。だからこそ混乱や軋轢のもとになっているわけです。

——言葉の意味が曖昧なら、明確にするしかないですね。

そうですね。いくら便利に使えるからといって「ビジネス視点」という言葉で済ませていたら、いつまで経っても問題は解決しません。

少し前に「デジタルトランスフォーメーション（DX）」という言葉がバズワード化しましたが、その際にも人によって何を意味するのか定義がバラバラで、議論が噛み合わないシーンを何度も目にしました。いうなれば、あれと一緒です。

具体的に何が足りないのか、何が求められているのかはっきりさせることからはじめなければ、混乱が混乱を呼ぶばかりです。丁寧なやり取りを通じて、「何を求めているのか」の認識をすり合わせなければなりません。

——こうした問題が起こる理由を知りたいです。

会社の経営方針や戦略は経営陣が決めますよね。経営陣は決定事項をマネージャー層に下ろし、マネージャーはそれらをどんな戦術で実現するかメンバーに示します。メンバーはそれを受け、自らの職能に応じて目標達成に向けて尽力する。ここまではほとんどの会社で実現できています。でも、そもそものところに大きな欠落があることが少なくありません。

——どういうことでしょう？

よくあるのは、開発に着手する前に「我々はそもそも何を達成するために集まっているのか」「なぜこのプロダクトをつくるべきなのか」「プロダクトがどのような状態になったら成功したといえるのか」についての議論がないまま、とりあえずつくりはじめてしまうケースです。

アジャイル開発のフレームワークの1つであるスクラムの場合だと、プロダクトオーナーが中心となって顧客のどんな課題を解決するのか明確にした上で、スケジュールを考え、KPIを設定してプロダクトを動かしていくわけですが、うまくいっていないチームの多くは、形ばかりに気を取られ、プロダクト開発の意義やゴールをチーム全員で正しく共有できていないんです。ひとことで言えば、困難に直面したときに立ち戻るべき指針がないわけです。

そうなると、背負っているミッションや職務が異なる人たち同士が協力するのは難しくなります。それぞれの立場を主張するばかりで、折り合わない状況が生まれてしまうからです。

こういった状況になってしまうのは現場のエンジニアだけのせいではなく、開発の意義やゴールを共有できていないまま進むことを選んだプロダクトオーナーや、ひいてはマネージャー層や経営層にも責任があります。

——なるほど。となると、エンジニアだけが「ビジネス視点を持て」と求められるのはさすがに酷な気がします。「ビジネス側もエンジニアリング視点を持て」と言いたくもなります。

同感です。登り方はおろか、登るべき山さえも周知されていないにもかかわらず、装備や日程、メンバーだけが決まっている状態で山登りに出発しても、山頂にたどり着ける確率は極めて低いでしょう。それと同じことが多くの開発現場で起こっているんです。

——こうした環境を改善するために、現場のリーダーやメンバークラスのエンジニアにできることはありそうですか？

プロダクトとしての目的やゴールが明らかになっていないと感じるなら、率直に聞くべきですね。「これは何を達成するためのプロダクトなのか？」「何をもって成功と定義するのか？」「このプロジェクトの目的と、プロダクトが目指すゴールとの整合性はどこにあるか？」と、わかるまでしつこく聞くんです。

もし、単にプロダクトオーナーやマネージャーの説明不足だったら、すぐに疑問は解消できるでしょうし、「曖昧なままにせず明確にしてほしい」と働きかけることで、事態が打開できるかもしれません。

——吉羽さんはアジャイルコーチとして、さまざまな開発チームと接点をお持ちかと思います。こうしたことはよくあるのでしょうか？

よくある失敗の典型ですね。

ゴールが明確に示されて共有されていれば、もしプロダクトオーナーが間違った決断を下しても、エンジニア側から「これをこの日までに開発したいのなら、こっちから先に手をつけたほうがリスクが少ないのでは？」などと進言できます。しかし、プロダクトオーナー自身も、目指すべきゴールを明確に定められていない場合、軌道修正すら難しいときがあります。そうなると、エンジニアは疑問や不満を感じながら開発マシンに徹するほかありません。

本来なら一定の期間内でどんな成果を出したいか明確に定義した上で、スプリントごとに開発を進め、「このまま進めても大丈夫か」「想定外のリスクはないか」を全員で検証しながらゴールに向かうべきです。しかし、そもそも土台になる「ゴール」が共有されていなければ、こうした動きがとれなくなってしまいます。

——こうなってしまう背景には何があるのでしょうか？

経営層やマネージャーが現場と密にコミュニケーションを取らず「次はこんなプロダクトをつくる」と、開発ありきで動き出すケースで起こりがちです。

エンジニアにしてみれば、何をいつまでにつくるかが決まっている以上開発せざるを得ないわけですが、上位者の判断に口を挟みにくい社風の会社なら、疑問や不満が解消される機会は最後まで訪れません。当然プロダクトの成功は覚束ないわけですが、もっと怖いことがあります。それはエンジニア自身がこうした環境に慣れてしまい、変化に対応できなくなってしまうことです。

——不満を抱えながらその環境に慣れてしまう。確かに恐ろしいですね。

エンジニア側であれビジネス側であれ、真っ先にフォーカスしなければいけないのは「誰の、どんな課題を解決するか」という点です。それがあってはじめて、解決に向けたアイデアや手段が生まれてくるし、顧客の業務や新たな開発手法を学ぼうというモチベーションが湧いてきます。

そうした前向きな開発体験を経験できない環境に居続けることは、エンジニアのキャリアに悪影響をおよぼしかねません。かなり恐ろしい状況だと思います。

——逆に開発が円滑に進み成果につなげられるチームが多い企業に特徴はありますか？

ステークホルダー全員が集まって何をつくるべきかを定め節目節目で状況を確認しながら、その精度を高めていける企業です。こうした企業は総じて部署の壁を越えたコミュニケーションが盛んで、エンジニア側とビジネス側の間に一定の信頼関係が築かれているので、立場の違いを超えて「顧客のために何ができるか」と綺譚のない意見が出やすくなります。

それに、私の経験上、うまくいっているチームには、いい意味で空気を読まず本質に斬り込んでいく人がいるものです。少々うるさがられても、「ゴールが曖昧だ」「ここに問題がある」など指摘したり説明を求めたりする人が1人でもいてくれると、他のメンバーにも伝播して「自分も意見をいってもいいんだ」と思う余地が生まれます。もし、周囲を見渡してこれに当てはまる人がいなければ、勇気を持って自ら声を上げてほしいですね。

——なるほど。とはいえ、声を上げるためには、業務経験の長さや知見の深さが必要そうな気がしますが…。

そんなことはありませんよ。必要に応じて足りない知識を補っていけばいいので、気負う必要はありません。まずは顧客のニーズや課題に関心を寄せることからはじめてみれば、顧客の課題解決にはどんな知識や視点が必要なのかが見えてくるでしょう。

上司に言われたことだけをただひたすらやり続けるエンジニアになるか、それとも率先して顧客の課題に向き合うエンジニアになるか。若い世代にとって将来を決める大事な選択です。開発がうまくいっていない現状を変えるために一歩踏み出せば、エンジニア側、ビジネス側からも賛同者が出てくるはず。粘り強くチャレンジしてほしいと願っています。

取材・執筆：武田 敏則（グレタケ）