メインコンテンツに移動

2021.11.15

アジャイル型開発チームへのIT組織変革と日本企業ならではの障壁を乗り越えるポイント

デジタル化が一気に進む中、急務となっているのが、開発組織の変革です。デジタルプロジェクトでは、これまでのウォーターフォール型の開発プロセスから、ユーザーのニーズを素早く取り込み柔軟に対応できるアジャイル型の開発を進めていくことが求められています。

では、そういった開発スタイルを実現するには、組織・人材・プロセスをどう変革すれば良いのでしょうか? これまでの経験談も踏まえて、株式会社リコー CDIO付DXエグゼクティブ Red Journey inc. CEO Energizer, 政府CIO補佐官, founder of DevLOVE 市谷聡啓氏と電通デジタル デジタルコンサルティング事業部 グループマネージャー 萩原伸悟の解説をお伝えします。

本稿は2021年9月6日から4日間にわたって開催された「電通デジタルCXトランスフォーメーションウェビナーWeek」のセッションの採録記事です。


アジャイル型開発チームへのIT組織変革

冒頭でも示した通り、デジタル化で開発組織変革は急務になっている今日。ですが、開発領域では「いきなりウォーターフォール型からの変革は難しい」との声は少なくありません。しかし、ユーザーニーズを素早く取り込み、柔軟に進めていくにはどうすれば良いのか、という考えに立てば、IT組織の変革は避けられないといえます。

t-t-i-o-i-a-a-d-t_01

そこで、まずは、いま求められている開発のあり方「アジャイル型」とはそもそもどのようなものなのか、改めて整理しておきましょう。

アジャイル型が注目され始めたのは、外部環境の変化がきっかけだと考えられます。VUCAの時代と言われ未来の予測が難しくなっている今日、不確実性が高まる中で、「あらかじめゴールややり方を決めて作るより、より良い手段」として登場したのが「アジャイル型」です。

また技術面の進化のスピードも非常に早くなっています。クラウドサービスを展開するAWSは2020年に200あるサービスに対し、1年間で2,757回のリリースを行いました。これは単純計算で1サービスあたり約13回のリニューアルやアップデートが行なわれているということになります。決して全てのアップデートを取り入れる必要はありませんが、「これまでのように年に数回の改善では間に合わない」ということは言えるのではないでしょうか。

一方、これほど高速な開発を実現するには、要件の確定は極めて流動的で最小範囲で始めてみる、という“速さ優先”の意識と、できたものから使う、という発想の転換も必要だと想像できます。

萩原は、アジャイル型について上述の内容を示した上で、「今日のような変化の大きい時代にこのような考え方はマッチしている。しかし、迅速な対応ができる体制づくりが不可欠だ」と指摘しました。

では、アジャイル型の開発を可能にする組織をどのように組成していけば良いのでしょうか? ここでは3つのステップをご紹介します。

t-t-i-o-i-a-a-d-t_02

1. 業務プロセス・人材定義
まず、あらかじめ業務の課題点を抽出するべく、現状の業務プロセスや人材アセスメント、社内環境といった事柄を整理し、現状を見定める必要があります。この時、各種ドキュメントの整理も行なうと良いでしょう。
課題点を洗い出すと同時に、アジャイル型を実践した時に起こるであろう問題点を洗い出すことも欠かせません。

2. 人材育成
1と同時に行ないたいのが人材育成です。いま在籍する人材のスキル等を把握し、「自組織に不足している人材とはどのようなものか」を明らかにしていきます。そうした上で、アジャイル開発を運営して行く上でのノウハウを習得するため、アジャイル基礎講座やサービスグロースの研修を実施する、基礎スキルの育成(座学)と実践知の習得や演習(OJT)を進めていきます。
こうした取り組みによって、最終的にアジャイルプロジェクトマネジメントスキルなどを向上させていきます。

3. アジャイル開発実行定着化
実際のアジャイル開発プロジェクトを実施し、OJTにて組織を変革していきます。STEP1で定義した業務プロセスの改善も行なうほか、想定していた人材像にズレがないか、1on1形式のヒアリングを通して改善を進めていきます。

アジャイル型に挑戦した際に日本企業が直面しやすい障壁

上述の3つのステップを実際に行なった際に、「特に日本企業が直面しやすい障壁がある」と、萩原。プロセス面の3つと人材・役割面の2つ、計5つに分けて項目をそれぞれ解説しました。

t-t-i-o-i-a-a-d-t_03

プロセス面での障壁

1. 開発途中で要件が変更になり、予算が超過しそうなときにどう対応するか?
アジャイル型で進行していくプロジェクトにおいて、要件変更がつきものです。しかし、予算はあらかじめ決まっていることがほとんどで、場合によっては要件を満たすための予算が確保できないことも想定されます。

萩原は、「この問題について悩まれるクライアント企業は非常に多い。開発しながら見積りは変わっていき、既定の予算では入らないというのはよくあること」と補足しました。

これを受け、市谷氏は、「アジャイル開発では、定められた期間内に決められた開発内容を実現し、動作するようにもっていく『スプリント』をいくつもこなすことになる。各スプリントの終了毎に目先を見るようにし、予算の過不足状態を把握しておく必要がある。プロジェクト全体の終盤になって帳尻合わせをしようとすると大きなズレが起きていた場合に対処ができないので、常に見直し、調整し続けることが大事だ」と、アドバイスしました。

萩原は、「予算変更のプロセスやエスカレーションのプロセスを事前に定めておくことも後々の助けになる。どれくらいなら対応可能な予算か?あらかじめ決めるとブレが少なくなると感じる」としました。

2. スプリント毎に、どの程度のテストを実施すれば良いのか?
ひとつの開発タスクが終了した後、テストを行なうことは快適なユーザー体験を提供するためにも必須なことです。しかし、詳細なテストを行なうことでスプリント内でのテストの割合が大きすぎるのも問題だと言えるでしょう。

この“匙加減”について、市谷氏は、「開発完了後、同じスプリント内でディベロッパーレベルでテストをすることは当然行なうべきだ。また、プロダクトオーナーの詳細な受入テストは同スプリント内で行うことは時間的に厳しいので、次のスプリントで行なうものだと言える。だからこそ、スプリントレビューのタイミングで受入テストに入るかどうかの判断は重要だ。ここをすり抜けて別のタイミングで問題が見つかり、結局手戻りが起きてしまったり、改善の対応によってリリース時期をずらさなくてはいけなかったり、といった状態に陥らないように注意する必要がある」としました。

萩原は、「大幅なリニューアルや決済機能の導入といったことは影響範囲も広く、対応に十分注意が必要だ。それ自体をスプリントにするのもひとつの手だと言える」としました。

3. 急なバグが発生!開発チームが対応する場合、割り込みタスクをどう対処するか?
バグはどうしても発生するものなので、対応は不可欠ではあります。しかし、スプリントに組込む数が多すぎれば、“正規”のスプリントが破綻してしまうことにもなりかねません。

市谷氏は、「関係する開発の割込みタスクについて、急遽対応が必要なら、Aというスプリント内で起きたのなら次のBというスプリントの優先順位を再考して対処する必要はあると思う。その際、何があったのか、どういう経緯でそのようになったのかを把握しておくことも大事だ。ただ、当然ながら割込みが多すぎると全体の開発が進まなくなる。そのため、割込みタスクが発生した原因究明も大切だ」と指摘しました。

萩原は、「どのレベルなら割り込みを許すか、あらかじめ基準を決める必要もあるだろう。
判断が属人的になったり、全部が緊急にならないようにするための工夫が欠かせない」としました。

人材・役割面の障壁

4. 現場も把握し、権限も必要なプロダクトオーナー(PO)を誰が担えば良いのか?
POを誰が担うのか? という問題は、多くの企業にとって最大の課題とも言えるでしょう。企業内にそれを担える人材は少なく、実際は「現場は現場のリーダーが。POになった人は予算管理を主に担当する」といった体制になることも少なくありません。

こうした状況について市谷氏は、「決定権者と現場を推進する人が分かれることは少なくない。アジャイル開発において、何を決めるにもC×Oの参加が求められるが、そうした決定権者が普段から現場を見てないというケースは厄介だ。スクラムの範疇から外れるが、PO代行となる人を立て、POとPO代行が連携を密にして対応する、というやり方もあるかもしれない」との考えを示しました。

一方萩原は、「現場判断をPOができないとなると、現場の“自然発生的なPO”は判断を迷ってしまうことになる。それならば、現場の方に権限委譲できるか? という新たな問題も出てくる。本来POになるべき人がスキル面で不安を抱えているなら、伴走するアドバイザーを入れるのもひとつの手段だ。
POが複数になると判断・役割が曖昧になる。バックログのリファイメントレベルなら現場で、障害や予算に関わることならPOにエスカレーションする、というように決定のレベル感を決めておくことで解決できることは少なくない」との意見を述べました。

5.運用チームと機能・改善チームの棲み分けをどうするか?
開発・リリース後に改善や軽い修正といった運用になることは開発のよくあるパターンだと言えるでしょう。そうした運用を専任するチームを組成することもよくある話です。

このことについて市谷氏は、「運用タスクの粒度と機能改善の規模感が違うので、リリースまでの開発を担うチームと運用チームとを分けるのはひとつの考え方だ。ただ、その場合、2つのチームが1つのプロダクトに関わることになるので、どのタイミングで情報交換をして同期するか? という問題も出てくる。互いに何をやっているか分からない、という状態が一番避けたいこと。もし分ける場合、意識としてワンチームであるようにすることが大切だ」と強調しました。

市谷氏の発言を受け、萩原は、「実施内容や求められるスキルも異なるため、基本的に開発と運用は別チーム、別タイムボックス(スプリント)にする方が良いだろう。ただし、経緯や行なっている内容を共有できる時間は必要なため、同期ポイントだけは設けておくべきだ」としました。

以上が、アジャイル型開発チームへ変革していくステップと、変革に際して発生する障壁と乗り越えるポイントです。今後、プロダクトやサービスのデジタル化を行なうにあたり、企業はますますアジャイル型の開発体制を強くしていく必要に迫られるでしょう。そうした際の参考になれば幸いです。

t-t-i-o-i-a-a-d-t_04

ichitani_toshihiro

株式会社リコー CDIO付DXエグゼクティブ
Red Journey inc. CEO
Energizer, 政府CIO補佐官, founder of DevLOVE
市谷 聡啓
サービスや事業についてのアイデア段階の構想から、
コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。
プログラマーからキャリアをスタートし、
SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自らの会社を立ち上げる。
それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。

shingo_hagiwara

萩原 伸悟 Shingo Hagiwara

デジタルコンサルティング事業部 プラットフォーム戦略グループ  グループマネージャー
メーカーでシステムエンジニアを経験後、ウェブマーケティング会社を設立。その後、インターネット広告代理店、スマホサービス向けSaaS企業を経て、2017年に電通デジタル入社。
エンジニアのバックグラウンドからテクノロジー起点でのコンサルティングに強みを持つ。これまで数多くのアジャイル開発プロジェクトにエンジニアやPM、コンサルタントとして参画。
直近では、大手企業のDXコンサルティングに従事し、事業戦略立案から業務プロセス改革、データ基盤構築支援を担当。

記事一覧

CX UPDATES TOP