未経験のアジャイル開発に挑戦

経営再建の旗印にPSS「JALCOM」の刷新を図る「SAKURAプロジェクト」を進めていた日本航空（JAL）は2017年7月、スペインのITベンダー、アマデウスと基本契約を締結した。

本番稼働を2017年11月に定め、全体計画を作り直して、本番稼働に向けたタイムテーブルを設定し、プロジェクトがきちんと進んでいくことを明確にした。

このとき基幹システムはウォーターフォールで開発が進められたが、カスタマイズされる部分についてアマデウスはアジャイルでの開発を選択した。

アジャイル開発とは、ソフトウェア開発手法の一つで、反復的かつ漸進的なアプローチを採用していることが特徴だ。

プロジェクトを複数の小さなサイクル（スプリント）に分け、各サイクルごとに機能を追加・改良していく方法を取り、プロジェクトが進行する中で変更や修正が容易に行える。しかも

頻繁にプロダクトをリリースするので、ユーザーやステークホルダーからのフィードバックを迅速に取り入れることができ、要件や仕様の変更に対応しやすく、プロジェクトの進行中でも方針を調整できる。それだけではない。

チームメンバーが密に連携し、コミュニケーションが活発に行われることで、協力的な環境が整い、継続的なテストとレビューを通じて、プロダクトの品質を維持・向上させることができる。

しかしその一方で、短所もある。長期的な計画を立てることが難しく、プロジェクト全体の見通しが立ちにくく、頻繁に変更が行われるため、プロジェクト管理が複雑になることがある。

また、チームメンバー間のコミュニケーションが多くなりすぎると、生産性が低下する可能性があり、他のプロジェクトやチームとの依存関係がある場合、アジャイル開発の柔軟性が制限される、という課題も抱えている。

しかもJALは、開発プロセスを段階的に進めるウォーターフォールの経験しかしていなかった。そのようなJALがなぜアジャイルという開発手法を取り入れたのか。

SAKURAプロジェクトを推進していた路線統轄本部の旅客システム推進部に所属していたデジタルCX企画部部長の杉原均氏は次のように語る。

「我々にとっては、かつて経験したことがない規模のプロジェクトです。そんなプロジェクトで全てを綺麗にゴールまで見通して進めていくことは非常に難しいだろうということで、局面を切って局面ごとに計画を正視しながら進めざるを得ないんじゃないかと考えたわけです。そうした取り組みを『アジャイル』と総称しているわけです」

目指すのは100点満点ではなく80点

「SAKURAプロジェクト」が進み始めた当初、社内では「プロジェクトがきちんと進むのかどうかの不安を感じる」「アマデウスはいい加減だ」「100％追求したいのにされていない」という不満が鬱積していった。

そのような中で全体計画については西畑執行役員が役員会で説明し、利用部門には青木部長が部長会で説明したが、このときITがわからない聞き手にも状況を正確に理解できるよう課題ごとに「赤」「黄」「緑」の3色に分け、「赤」は本番稼働を妨げる状況、「黄」は本番稼働はできるが注意すべき状況、「青」は計画通り本番稼働できる状況であることを示した。

不明瞭な課題に対しては次の会議までに問題の解明を進めた。

さらに一人一人のプロジェクトの不安を払拭するため3か月ごとに個別面談を行い、タスクの進捗状況をチェック、次の3か月で取り組む具体的問題について話し合った。

「例えばJALCOMに接続していた100種類の旅客系周辺システムのうち、約70種類をAlteaに接続することになっていました。そこでそれらの開発スケジュールとテストスケジュールの平仄を合わせるんですけれども、品質によって全然テスト期間が違う。しかも詳細な要件がわかってなかったので、開発期間や規定数も当初は、なかなか決まらなかった。そこである程度ターゲットスケジュールが逆算して、ハイレベルなマスタープランを作成し、それを半年もしくは一定期間、毎回レビューしなから、その解像度を高めていくという手法を取りました。ただ単に、何の定義もせずにやると、バラバラになってしまいますので、矢羽根（プロジェクトスケジュールや処理順序を表現する右側のみ矢印形状の横棒グラフの図形）の1個1個が、例えばAというやばねがあったらAというやばねの責任者が、1枚のドキュメントを共用し、局面局面で、『この状況に対するコンフィデンスが十分あるか』『十分ではないのか』『十分ではない要素は何なんだ』といったことを明らかにしながら、最終的に進めていくというマスタープランの前提資料としてのMaster Plan Strategy Document（MPSD）の策定をセットで実行しました」（杉原氏）

アジャイルに対する不安を払拭するため、西畑執行役員や青木部長がJALメンバーを集めてアジャイル開発とはどういうものかを説得した。説得だけではない。アジャイルプロジェクトを円滑に進めるためにはさまざまな工夫をしている。

「プロジェクトを進めていく中で現業部門から『これは使えないよね』という声も上がってひっくり返えされることが一般的によくあるということも聞いていました。そこで現場も含めてコミュニケーションを深めることにより、どうすれば巻き込んでいけるのかをいろいろ考えました。一方的な押し付けにならないよう物事の運び方には最善の配慮をし、『One Boat(ワンボート)』という理念を胸に刻んで仕事を進めていきました。気持ちを一つにするために『SAKURA Project』のロゴをあしらった旗に寄せ書きをしたり、プロジェクトのチェックポイントごとに300人のメンバーで通過のお祝いをしたりしました」（杉原氏）

こうした取り組みの中でメンバーの一体感を醸成していった。

アジャイル開発で100点満点を目指せば、切りなくテストをしなければならなくなってしまう。そこで80点満点主義をとり、残り20点は全機能の開発を終えた後で行うという方針を示し、スケジュールファーストを徹底した。

開発を進めていくための三つのピラー

これだけの巨大プロジェクトを進めていくためには会社全体の協力が不可欠だ。そのためにはプロジェクトの開発関係者だけでなく、全社的にプロジェクトを知ってもらわなければならない。そこでプロジェクトを透明化するために積極的にプロジェクト内外の関係者と情報を共有化した。

３カ月に１度は取締役会で進捗状況の報告を行い、１カ月に一回は関係役員以外の役員が参加する会議体でも報告、経営陣に対して見える化を徹底。一方でプロジェクトの現場でもプロジェクトオーナーに対してもチェックポイントを設定して３か月に一回報告して可視化を進めた。

「私たちがシステム開発を仕上げていくときに注意したのは『ビジネスレディネス（事業準備）』『ソリューションレディネス（解決策準備）』『カットオーバーレディネス（切り替え準備）』という三つのピラー（プロジェクト管理やITフレームワークにおける成功のための基本的な原則や柱）です」（杉原氏）

ビジネスレディネスは事業側のプロセス改革や教育などを含むシステム受け入れ確認、ソリューションレディネスは、開発・テストを踏まえたソリューションの品質確認、カットオーバーレディネスは、新しいシステムやプロセスへの切り替え（カットオーバー）時に、スムーズかつ迅速に移行を完了し、業務への影響を最小限に抑える準備の確認を指す。

「業務側の教育も含めて、遠隔プロセスの受け入れということをしっかりやれているのかということを業務改革プロジェクト的な要素と、要するに開発をやり切るっていうところで、最後は当夜にどう移行をしっかりやるのか、そこに向けた準備がしっかりできているのかという大きな三つのピラーに最終的に集約して、やりきったっていうふうに理解します」（杉原氏）

SAKURAプロジェクトを振り返り、DX構想策定支援などを行うDNTIの西村大輔氏は次のように語る。

「JALが結果的に良かったのは、こうした取り組みを、多くのユーザーが直接体験できたことだと思います。アジャイル開発は、小さな開発が多く、大規模な開発に適応するには、多くの苦労もあったはずです。そういう経験を経て、自分たちなりのノウハウの蓄積や、ルールというものに辿りついたことは貴重な財産です。こうした大型プロジェクトというのは、頭でわかっているだけでなく、やってみて学ぶことが多いものです。システム開発をシステム部門とITベンダーだけに任せているのでは、いつまでたっても目的にかなったシステム開発はできません。JALは自分たちの体験を生かしながら、その境地にたどり着いた。しかも彼らの体験は実証実験レベルのちょっとしたものではなく、全社レベルの規模で行われた本格的な体験だったことが大きな成功につながったのだと思います」