右下：日本電気株式会社 第二都市インフラソリューション事業部 西川徳光氏
アジャイルは、システム開発のデジタルトランスフォーメーション
はじめに、NECのソフトウェアエンジニアリング本部に属する水野浩三氏が、同社のアジャイル開発の現状を簡単に紹介した。水野氏は、社内におけるアジャイル開発の推進・支援を担当しており。2018年度にIPAのアジャイルワーキンググループや、IPAのモデル契約書の策定にも携わっている。
冒頭、水野氏は「大企業など従来ウォーターフォール開発が中心だった企業にとって、アジャイル開発への移行は大きなテーマです」と語り掛けた。
「アジャイルはシステム開発手法として捉えられていますが、ビジネスの一環と考えると成功させるのは簡単ではありません。チームだけアジャイルになったとしても、お客様や組織などのステークホルダーが連携して変わっていかないと、本来のアジャイル開発がうまく進んでいかないのです」
つまり、アジャイル開発をシステム開発ビジネスのデジタルトランスフォーメーション（DX）ととらえる必要があるというのだ。
水野氏は、経済産業省の発表した「DXレポート2.1」では、DXの課題を次の3つのジレンマとして整理していると説明した。
- 危機感のジレンマ：目先の業績が好調なため変革に対する危機感がない
- 人材育成のジレンマ：技術が陳腐化するスピードが速くて時間をかけて学んだとしても習得したときには古い技術となっている
- ビジネスのジレンマ：ベンダー企業がユーザー企業をデジタル企業へ移行する支援を行うことで、最終的には自分たちが不要になってしまう
「DXレポートでは、こういったジレンマの解消に経営トップの関与が必要としています。しかし、それだけでなく組織・チームも連携をはかって変革をしていかないとうまくいかないと考えています」
ウォータフォール開発で調和が取れていた企業がアジャイル開発に取り組んで価値を生み出していくには、ビジネスと組織とチームがお互いに連携し調和をもたらしながら回していく必要があるのだ。
そこで、チームと組織の変革にフォーカスして2つの事例を紹介した。
市場や仕様が確定していないプロダクト開発でチーム変革に取り組む
アジャイル開発によるチームの変革事例を説明するために登壇したのが、NECの第二都市インフラソリューション事業部に所属する西川徳光氏である。西川氏は、リソースアグリゲーション事業者向けに分散するエネルギーリソースを統合制御するクラウドサービスの開発を担当している。この開発プロジェクトでアジャイル開発を実践しており、西川氏はプロダクトオーナーとしてスクラム開発を進めると同時に、複数スクラムチームの運営にも挑戦中だという。
リソースアグリゲーションビジネスとは、太陽光や風力発電といった変動が大きい再生可能エネルギーなどを対象とした新しい事業で、当初から市場や仕様が確定しておらず、実証を重ねながら仕様化したものをアジャイルにより機能を改善しているという特徴を持つという。
「正解がわからない中で、自分たちで仕様を決めて、プロダクトを先行で開発して、実際のフィールドで試して新たな改良を加えていくサイクルを実践しています。たとえば、蓄電池がこういうタイミングで動くと市場にうまくマッチしないとわかったら、次のスプリントでその仕様を反映させて効果を確認するといった具合です」
そのなかで、一般的にいわれるアジャイル開発の課題に加えて、複数チームでのアジャイル開発の課題に直面してきた。
「まず、どうやって投資を認めてもらうかという課題です。アジャイル開発は、状況によりバックログの優先度やスコープを変更できるのがメリットです。アジャイル開発でやる限り、最終的な仕様をコミットできません。そのため、投資判断していく上で何を作るか分かりづらい面があります」
そこで、西川氏たちは、今考えているバックログアイテムを提示して、そのストーリーポイントを積算して投資規模を判断してもらったという。さらに、開発実績がある場合はチームのベロシティをもとにして、予定内でどこまで開発が可能か示して投資判断してもらった。
「2つ目の課題は、ミニウォータフォールになってしまったことです。自分たちでやっていても、うまくいってないという想いがありました」
そのため、アジャイルのあり方をあらためてチーム全体で学習した。有識者に助けてもらいながらワークショップを開催して、自己組織化を浸透させていった。プロダクトオーナーとスクラムマスター・開発チームのメンバー全員が、ビジネス目線で何が必要か考えられるようになったという。
「3つ目の問題は、複数チームで開発したために直面した課題です。当初は、例として、画面開発チームと通信機能開発チームというように、システム機能に合わせてチームで構成していました。しかし、一方が忙しいのに他方はバックログがない、忙しいチームを他方が助けようと思ってもヘルプできないという状況が発生しました」
そこで現在は、チームをシステム機能横断で再編成しているという。つまり、各チームのなかに画面開発の担当者と通信機能の担当者がいるといった具合に配置したのだ。
「アジャイルの取り組みと同じように、このような課題も検証と改良のサイクルを繰り返して改善してきました。現在も継続してチームビルディングに取り組んでいます」とチーム変革の様子を語った。
アジャイル開発を推進するため組織自体も段階を踏んで変革していく
続いて、水野氏が再度登場して、組織の変革事例について説明した。
「アジャイル開発では、チームが自律していることが重要です。しかし、それだけで成功するとは限りません」。たとえば、3つのチームがそれぞれが自律して動いているとする。うまくいっているチームもあれば、うまくいっていないチームもあり、さらに、うまくいっていても方向性が異なるチームもあるとなると、果たして成功とは言えるだろうか。
自立したチームがさらに方向性も合わせるためには、組織が関与し、最低限のルールや規定を共有する必要がある。つまり、自律だけじゃなくて自律と規律とのバランスが重要だというわけだ。
水野氏は、こうした組織の関与の仕方として「組織のDoneの定義」と「事業プロセスにおける審査の適用」を例に挙げた。
「組織のDoneの定義」は、組織として守るべき品質を定義したもの。「事業プロセスにおける審査の適用」は、従来ウォータフォールでやっていた企画や検証段階でのゲートにあたる。「アジャイルでこうした関与が必要なのか疑問を持つ人もいるかもしれませんが、組織のなかでチームを運営する以上は最低限必要になると考えています。ただし、チームの規模や重要性などでレベル分けして権限を委譲するといった進め方をしています」
そして水野氏は、組織としてアジャイル開発を推進するためには、組織自体も段階を踏んで変革していく必要があると語った。そのために、ジョン・コッターの組織変革の8ステップを順に取り組んでいくといいと述べた。
「具体的には、まず変革をリードするチーム作りを行いました。変革推進に必要な人材を巻き込んでチームを構成します。また、組織としてのコミットメントも必要になります。たとえば、このチームもアジャイル的に進めたいので、アジャイルを理解して組織内の推進をリードできるアジャイルリードを配置するといった具合です」
さらに、社内外問わずステークホルダーとの調整ができるコーディネーターという役割の人を配置した。このコーディネーターがハブとなって、ステークホルダー間の調整や情報共有をはかり、全体をとりまとめて円滑に動くように仕向けていったという。
最後に、こうした成功事例をどのように組織に定着させようとしているのか。そのための重要な要素として、水野氏は「アジャイルリード」という役割を紹介した。
組織内でアジャイルを推進するチームを作ったら、そのチームのスクラムマスターがアジャイルリードとして参加し、新規チームの立ち上げを支援する。ここで立ち上がった新規チームのスクラムマスターが、さらに別の新規チームの立ち上げ時にアジャイルリードになる。これを繰り返していくことで、組織内の横展開をはかっていくというわけだ。
「このように組織の変革を推進していきましたが、まだまだやりはじめたばかりです。今後も、こうしたスキームにのっとって定着化をはかっていきたいと考えています。もしも、こういった事例が皆さんの参考になれば、持ち帰って活用いただけることを期待しております」
水野氏はこのように語り、セッションを締めくくった。
