大手企業でアジャイル開発に取り組むには？ 自律と規律の調和のとれた変革を目指すNECの挑戦【デブサミ2022】

【18-A-7】レガシー企業におけるアジャイルの極意 ～ビジネス/組織/チームの連携と調和～

　アジャイル開発が広く知られるようになり、多くの企業が何らかの形で取り組んでいる。それは、日本の大手テクノロジー企業でも例外ではない。NECは、システム開発において多くの実績を持っているが、その大半がウォータフォール型開発によるものだ。そんな同社において、アジャイル開発を進めるには、チームビルディングだけでなくビジネスや組織体制にも対応していく必要があるという。そこでこのセッションでは、NECの水野浩三氏と西川徳光氏が、同社におけるアジャイル開発の取り組み事例を紹介した。組織やビジネスの都合で、アジャイル開発にチャレンジしたくても進められない人たちにとって、大いに参考になるだろう。

左上：日本電気株式会社 ソフトウェアエンジニアリング本部 水野浩三氏、
右下：日本電気株式会社 第二都市インフラソリューション事業部 西川徳光氏

アジャイルは、システム開発のデジタルトランスフォーメーション

　はじめに、NECのソフトウェアエンジニアリング本部に属する水野浩三氏が、同社のアジャイル開発の現状を簡単に紹介した。水野氏は、社内におけるアジャイル開発の推進・支援を担当しており。2018年度にIPAのアジャイルワーキンググループや、IPAのモデル契約書の策定にも携わっている。

　冒頭、水野氏は「大企業など従来ウォーターフォール開発が中心だった企業にとって、アジャイル開発への移行は大きなテーマです」と語り掛けた。

　「アジャイルはシステム開発手法として捉えられていますが、ビジネスの一環と考えると成功させるのは簡単ではありません。チームだけアジャイルになったとしても、お客様や組織などのステークホルダーが連携して変わっていかないと、本来のアジャイル開発がうまく進んでいかないのです」

　つまり、アジャイル開発をシステム開発ビジネスのデジタルトランスフォーメーション（DX）ととらえる必要があるというのだ。

　水野氏は、経済産業省の発表した「DXレポート2.1」では、DXの課題を次の3つのジレンマとして整理していると説明した。

• 危機感のジレンマ：目先の業績が好調なため変革に対する危機感がない
• 人材育成のジレンマ：技術が陳腐化するスピードが速くて時間をかけて学んだとしても習得したときには古い技術となっている
• ビジネスのジレンマ：ベンダー企業がユーザー企業をデジタル企業へ移行する支援を行うことで、最終的には自分たちが不要になってしまう

　「DXレポートでは、こういったジレンマの解消に経営トップの関与が必要としています。しかし、それだけでなく組織・チームも連携をはかって変革をしていかないとうまくいかないと考えています」

　ウォータフォール開発で調和が取れていた企業がアジャイル開発に取り組んで価値を生み出していくには、ビジネスと組織とチームがお互いに連携し調和をもたらしながら回していく必要があるのだ。

ビジネス・組織・チームが調和を取りながら変革する

　そこで、チームと組織の変革にフォーカスして2つの事例を紹介した。

市場や仕様が確定していないプロダクト開発でチーム変革に取り組む

　アジャイル開発によるチームの変革事例を説明するために登壇したのが、NECの第二都市インフラソリューション事業部に所属する西川徳光氏である。西川氏は、リソースアグリゲーション事業者向けに分散するエネルギーリソースを統合制御するクラウドサービスの開発を担当している。この開発プロジェクトでアジャイル開発を実践しており、西川氏はプロダクトオーナーとしてスクラム開発を進めると同時に、複数スクラムチームの運営にも挑戦中だという。

　リソースアグリゲーションビジネスとは、太陽光や風力発電といった変動が大きい再生可能エネルギーなどを対象とした新しい事業で、当初から市場や仕様が確定しておらず、実証を重ねながら仕様化したものをアジャイルにより機能を改善しているという特徴を持つという。

リソースアグリゲーション事業におけるアジャイルへの期待

　「正解がわからない中で、自分たちで仕様を決めて、プロダクトを先行で開発して、実際のフィールドで試して新たな改良を加えていくサイクルを実践しています。たとえば、蓄電池がこういうタイミングで動くと市場にうまくマッチしないとわかったら、次のスプリントでその仕様を反映させて効果を確認するといった具合です」

　そのなかで、一般的にいわれるアジャイル開発の課題に加えて、複数チームでのアジャイル開発の課題に直面してきた。

　「まず、どうやって投資を認めてもらうかという課題です。アジャイル開発は、状況によりバックログの優先度やスコープを変更できるのがメリットです。アジャイル開発でやる限り、最終的な仕様をコミットできません。そのため、投資判断していく上で何を作るか分かりづらい面があります」

　そこで、西川氏たちは、今考えているバックログアイテムを提示して、そのストーリーポイントを積算して投資規模を判断してもらったという。さらに、開発実績がある場合はチームのベロシティをもとにして、予定内でどこまで開発が可能か示して投資判断してもらった。

　「2つ目の課題は、ミニウォータフォールになってしまったことです。自分たちでやっていても、うまくいってないという想いがありました」

　そのため、アジャイルのあり方をあらためてチーム全体で学習した。有識者に助けてもらいながらワークショップを開催して、自己組織化を浸透させていった。プロダクトオーナーとスクラムマスター・開発チームのメンバー全員が、ビジネス目線で何が必要か考えられるようになったという。

　「3つ目の問題は、複数チームで開発したために直面した課題です。当初は、例として、画面開発チームと通信機能開発チームというように、システム機能に合わせてチームで構成していました。しかし、一方が忙しいのに他方はバックログがない、忙しいチームを他方が助けようと思ってもヘルプできないという状況が発生しました」

　そこで現在は、チームをシステム機能横断で再編成しているという。つまり、各チームのなかに画面開発の担当者と通信機能の担当者がいるといった具合に配置したのだ。

　「アジャイルの取り組みと同じように、このような課題も検証と改良のサイクルを繰り返して改善してきました。現在も継続してチームビルディングに取り組んでいます」とチーム変革の様子を語った。