「アジャイル開発は銀の弾丸ではない」、適用に必要な要件とは
課題と制約があまりにも多岐にわたり、どこから着手すべきか、どの課題にどれほどの工数がかかるのか、見通しを立てること自体が難しい……こうした不確実性の高い状況に直面したとき、選択肢として挙がりやすいのがアジャイル開発だ。
ところが川上氏は、「アジャイル開発は“銀の弾丸”ではない」と指摘する。不確実性の高い課題に対してアジャイルを適用するには、いくつかの前提条件が必要になるというのだ。
まずは、抽象度の高い課題をそのまま一つのタスクとして扱わないことだ。例えば「Cloud Code Actionの基盤構築」という、一見すると明確に見える課題も、実際には複数の要素に分解できる。Google Cloud上での認証方式の検討、GitHub ActionsやGitHub Appsの設定、IAMの設計、関連サービスの調査など、多くの隠れたタスクが内包されているのだ。アジャイルで進めるには、これらを意識的に洗い出し、段階的にタスク化することが不可欠になる。
また、短いスパンでタスクを評価し、途中で明らかになった課題を即座に記録していく姿勢も欠かせない。タスク起票時には「何をするか」だけでなく、「何のためにそれを行うのか」というゴールを明確にする必要がある。
そして何より重要なのが、関係者間での課題意識のすり合わせだ。今どこに取り組んでいるのか、何をゴールとしているのか、その認識が揃っていなければ、いくらチケットを切っても優先順位は定まらない。川上氏は、アジャイル開発を機能させるうえで、この認識合わせこそが最も重要だったと語る。
こうして、ようやくアジャイル開発を適用できる余地が生まれたものの、次なる壁はシステム自体の複雑さと制約だった。これを乗り越えるため、川上氏らが採用したのが「段階的な刷新フェーズを設ける」というアプローチである。
まず行ったのは、依存関係の整理だ。ステークホルダーや他チーム、既存システムへの影響を洗い出し、「誰に、どのような影響が及ぶのか」を明確にした。その上で、対応優先度や技術的な都合を踏まえ、複数の段階に分けて刷新を進める方針を定めた。方針策定に当たっては、各フェーズごとに技術的課題を列挙し、それに対してどの技術が適切かを検討した上で、PoCを通じて実際に有効性を検証していった。
具体例として川上氏が挙げたのが、Javaベースの独自パッケージ依存からの脱却とクラウド化である。この課題は影響範囲が極めて広く、そのままではスコープが大きすぎる。そこで、フロントエンドとバックエンドを分離し、ページ単位で段階的にマイグレーションする方針を採った。この方針を実現するため、CDNやリバースプロキシ基盤の構築、認証・認可基盤の見直し、アーキテクチャの再設計などを段階的に進めていく必要があった。
LIXILでは全社的にGoogle CloudとAkamaiのCDNを採用しており、その前提を活かしたネットワーク構成が検討された。CDNからGoogle Cloudのロードバランサーへ、リバースプロキシを設定し、オンプレミスとクラウドを行き来できる構成を取ることで、段階的な移行を可能にしている。認証はCDN上で完結させ、バックエンドへの通信はロードバランサーを経由することで、セキュリティと可用性の両立を図った。コスト、機密情報の取り扱い、障害時の影響範囲といった観点も含め、慎重な技術選定が行われた。
ページ単位での刷新を進める中で浮上したのがAPI仕様の問題だ。現行システムでは、API仕様がExcelベースで簡易的に管理されており、詳細なレスポンスの定義が不足していた。フロントエンドを段階的に刷新するには、正確で視認性の高いAPI仕様が不可欠である。そこで川上氏らは、OpenAPIとTypeScriptを用いた仕様管理に踏み切った。
TypeScriptからAPI仕様を定義し、OpenAPI形式へ変換することで、型定義と仕様書を一元管理する。これにより、仕様書と実装の乖離を防ぎ、スキーマ駆動での開発体験を向上させるねらいだ。静的HTMLとしての仕様書出力も可能となり、開発者自身が継続的にAPI仕様を保守できる仕組みが整えられた。
