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

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

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

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

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

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

プロセス面での障壁

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

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

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

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

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

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

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

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

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

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

人材・役割面の障壁

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

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

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

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

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

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

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