IT領域だけではない、ビジネスアジャイルに向けて

MSOLにはビジネスアジャイルに適応できる優秀な人材が渡会以外も沢山在籍しています。今回は、その中から天野弘仁さん、能勢大輔さんをご紹介します。

私はインターネット事業会社で開発マネージャーを務めた後、MSOLに参加することになりました。アジャイルに出会ったのは2015年頃。当時は自社の開発のため、外部から研修講師を招き、一緒にスクラムを導入するところから始めました。現在は材料開発や業務プロセス改善のアジャイル適用などビジネス領域へアジャイルを導入・支援と並行して、7名の部下を率いて8クライアントのアカウントマネジメント業務を行っています。

私は新卒で入社したSIerでシステムエンジニアとしてキャリアをスタートしました。在籍12年の間では多くがウォーターフォールでの開発でしたが、途中でアジャイルに出会いました。アジャイルでの開発に衝撃を受け勉強を始め、世の中にもっと浸透させたいと思うようになり、MSOLに参加することにしました。現在は金融系のクライアントの合計4チームのDevOpsに対するアジャイルコーチや、地方電力会社の自社システム開発の統括スクラムマスターを務めつつ、5名の部下を率いて8クライアントのアカウントマネジメント業務を行っています。

最近はIT領域だけでなく、それ以外のビジネス領域でもアジャイルを活用する事例が増えています。実際、私たちが過去4年間で実施してきた70案件のうち、ITシステム開発は24件であるのに対し、組織改革、業務改革、新規事業開発などビジネス領域に関するものが46件と上回っています。特にビジネス領域ではコンサルティング要素が多いほどニーズが高くなっています。今回は、様々な案件の中から具体的な支援内容についてケースごとにお話ししたいと思います。

まずアジャイルコーチとして参画している金融系クライアントの「合計4チームに対するDevOpsでのエピソード」を紹介します。この案件では関連するシステムの開発都合など複数の要件を期日までに同時並行で進めなければならない状況にありました。
しかし、同時並行で要望に応えていたため、プロダクトオーナーやステークホルダーの立場から見ると、本当にゴールに向かって着実に進んでいるのか、わかりづらいところがありました。そのため、認識齟齬があり、完了できると思っていたタスクが完了できないという問題が生じていました。
 その際、私がやったことが、目標に対するタスクの全量を「見える化」することでした。オンラインホワイトボード「Miro」というツールを使い、ホワイトボード上にゴールや作業内容をすべてマッピングして現場だけでなく、プロダクトオーナーやステークホルダーも含めた全てのメンバーがタスクの全量を把握できるようにしました。その結果、認識齟齬がなくなり、現場で問題が生じたときも話し合いが頻繁に行われるようになりました。

これは私が著した『アジャイルに困った時に読む本』（ダイヤモンド社）の中のヒント29「情報を顧客にもフルオープンして、隠し事はゼロに」にでも言及しています。1つのチームが同じ目標に向かうときに大事なのは、相手が隠し事をしていないとお互いに信頼し合うことです。プロダクトオーナーに対して、開発チームが理由も告げずに「できません」と答えたら、そこには不信感が生まれます。そのため、目に見えるかたちで、現在の状況をプロダクトオーナーと開発チームで共有することで、誰が何をやっていて、次に何に取り組む予定なのかがわかるようになるのです。

私はプロダクトオーナーのケースについてお話しします。プロダクトオーナーの仕事は非常に多く、かつ重要です。プロダクトバックログの管理、ステークホルダーとの調整、プロダクトの細部にわたる部分のビジネス的な決断を即座に行う、開発チームの成果物をレビューし受け入れるなどです。
そのため、最近はプロダクトオーナーを1人ではなく、複数で担当する場合も増えています。例えば、ステークホルダーとの調整役と、開発チームとの連携役の主担当をそれぞれ別の人で行うことです。しかしそのためには、各プロダクトオーナー同士の日頃からのコミュニケーションが欠かせません。

こちらのケースも、ヒント35「プロダクトオーナーは本当に1人でないといけないのか。チーム制も選択肢の1つ」で言及しています。プロダクトオーナー1人で多大な役割を担うのは時間的にも難しい場合が多く、プロダクトオーナーの作業が多すぎてプロジェクトのボトルネックとなったり、判断が雑になったりするのを避けるためにも、役割の一部を分担して複数人のチームで行うことは有効です。ただし、その場合でも、最終決定権を持つ人は1人のみとすることが重要です。複数の合議制を取ると、意見が揃うまで決断できず、プロジェクトのボトルネックになってしまう場合があります。

確かに私もプロダクトオーナーが複数人の現場によく出会います。理想論で言えば、あらゆる権限をプロダクトオーナーに与え、自由にやってもらうのがいいのですが、現実的にはそうもいきません。統括プロダクトオーナーのもと1～2人ほどプロダクトオーナーがいれば、ステークホルダーとの関係性もつくりやすいと思います。私が担当している現場では、プロダクトオーナーだけの朝会やふりかえりを開催しているところもあり、そこで認識を一致させることを毎朝行っています。

プロダクトオーナーだけのチームミーティングや振り返り、プランニングをやっているケースもあります。または、プロダクトオーナーのチームだけで、1つのアジャイルプロセスを回したうえで、アジャイルチームの一員としてプロダクトオーナーの役割を果たしているケースもあります。さらに、プロダクトオーナーだけで7～8人いて、ステークホルダーと開発チームへの対応を役割分担しているケースもあり、様々なケースが見られますね。

次にペアワークやモブワークについてのケースをお話ししたいと思います。通常、このペアワークやモブワークはアジャイルとの相性が良いとされています。基本的にアジャイルは個人の成長を促進するものであり、それによってチームとして学習し成果を高めていくという考え方があります。そのときキーとなるのが、個人が持っている知識を他の人にいかに共有していくかということです。
従来の考え方では全員で分担し、1人が1つのタスクをこなし、その成果を合わせていくということが一般的でした。しかし、ペアワークやモブワークでは、複数人で１つのタスクを担当するというかたちをとります。いわば、お互いが持っている知識を共有しながら、１つのタスクを最小限の時間で確実にやり遂げていくのです。

２人でやるペアワークや、複数人で行うモブワークは、複数人で見ることで様々な視点を取り入れられるメリットがあり、間違いも減らせます。結果が出たときには、そこに至るプロセスまで含めて関わった人全員が内容を共有しているので、改めて共有のためにドキュメントを作成したり、ミーティングを設定したりする必要がなく、効率的だというメリットがあります。

しかし、その一方で私が担当したチームでは、すべてをモブワークでやっていくことを必須事項にしてしまいました。どのような場合もモブワークしか選択肢をとれなくしたことで、それぞれが分担した方が効果的なものですらモブワークを用いざるを得なくなり、結果的に全体の生産量が減ってしまったことがありました。手段のひとつとして、モブワークを使うべきなのに、モブワークという手段が良いからと言ってこだわり過ぎた結果、本来の目的であった効率的に仕事を進めることからかけ離れてしまったのです。

アジャイルのプラクティスを気に入ってしまって、それを使うことが目的になってしまうことはよくあります。しかしそれではダメなのです。こちらは、ヒント106の「ペアワークやモブワークは本当に効果的なのか。義務化して選択肢を奪うのは危険」だというところで言及しています。なぜ効果的なのかを考えずに、「このチームではモブワーク以外認めない」と選択できる余地を奪ってしまうのは危険です。義務を守るためにかえって結果を出すことが遅くなり、効率が落ちてしまいます。ペアワーク、モブワークと分担は要所ごとに上手に使い分ける必要があるのです。

私もそうしたケースに遭遇したことがあり、私が介入して「何のために開発するのか」というところを何回もチームメンバーに話したことがあります。本来、ノウハウを共有すること、手戻りを減らすことは目的ではありません。エンドユーザーに成果物を届けることが最終的な目的であり、仕事なのです。そこを見失って、やり方にこだわってしまうのは本末転倒です。「今つくっているプロダクトは会社としてどの目標に紐づいているのか」「それをエンドユーザーに提供することで世の中の何が変わるのか」を情報として出して、毎週のように繰り返し進捗状況を確認していくことで、チームも「こだわる」ことから抜け出すことができたのです。

では、最後にヒント72「生産性の高いチームほどコミュニケーションコストを惜しまないようになるのはなぜか」についてのケースをご紹介しましょう。

次のケースですが、ベンダーとプロパーの２つの開発チームがあり、プロパーが長く担当していたこともあり、ベンダーの生産性が低いという問題がありました。そこで、多少チームの人数は多くなりましたが2チームを合体させ、全員でスプリントプランニングを行い、全員でタスク出しを行いました。そのタスク出しは通常より時間は掛かってしまったのですが、結果として2チーム体制のときよりも2倍のアウトプットを出すことができたのです。

プランニングをきちんとしていないと、タスクの粒度は粗くなっていきます。１つ１つのタスクが抽象的になり、結果的に目的と違うものができてしまい、メンバーの仲も悪くなることが起きがちです。タスク出しで、具体性をもったレベルまで細かくブレイクダウンしていれば、プランニングの時間は確かに伸びますが、結果的に手戻りは最小限になります。

確かにプランニングするときは多くの時間をとってしまいますが、そこで全員のやるべきことが共有されているからこそ、その後のタスク実行時には各メンバー迷いなく作業ができるのでとてもスムーズに進みました。

私の経験からすれば、良いチームはプランニングだけでなく、現場でよく打ち合わせをしています。それが健全な状態だと言えます。一方、皆が手を動かしているだけで現場がシーンとしている場合は、大抵うまくいっていない状況に陥っていると見ていいでしょう。

従来型アプローチでは、生産性を上げるために「ムダな会議はなくしましょう」と言われ、会議は最小限に、出席者も限定してなるべく短い時間で行うことがよいとされてきました。しかし、アジャイル型アプローチでは「手を動かす時間を最小にするために対話を増やす」という真逆の考え方をします。そのほうが生産性は高くなる、つまり、コミュニケーションコストを惜しまないほうが生産性は高くなるのです。

今回お話しした内容は、アジャイルとはいえ、IT領域とは関係ない話も多かったと思います。だからこそ、IT領域だけでなく、ビジネス領域でもアジャイルを活用できるというヒントが隠されていると思います。例えば、ITではない開発（材料開発など）や、新規事業の創出、業務プロセス改善、不確実性の高い事象に対する意思決定もアジャイルを使って行うといった事例も出てきています。そんなIT領域に限らないビジネスアジャイルサービスを提供できる人材がMSOL Digitalには揃っています。MSOL Digitalのアジャイルサービスにご興味のある方は、ぜひお気軽にお問い合わせいただきたいと思います。