IIJ社内でアジャイル開発体制を確立。案件特性に応じて最適な開発手法を提案

IIJ プロフェッショナルサービス第二本部 クラウドインテグレーション1部

副部長

西水流 隆寛

大規模基幹システムのシステムインテグレーションをはじめ、中小規模の情報系システムの開発を複数経験。現在は顧客折衝や組織のプロジェクトマネージメント能力/プロジェクト品質向上に携わっている。

執筆・監修者ページ/掲載記事:1件

技術や市場ニーズの変化に機敏に対応し、新しい価値をタイムリーに提供する。その開発手法として「アジャイル開発」の注目が高まっています。IIJはこのスキル習得にチャレンジし、組織実装を推進しています。今日に至るまでには様々な試行錯誤を重ねました。それだけに多くの学びや知見を得ています。この取り組みによってシステム開発案件に対し、アジャイル開発という新たな選択肢の提案が可能となりました。IIJがアジャイル開発の組織実装にチャレンジした狙いと、その“舞台裏”を徹底解説します。

目次
  1. アジャイル開発が求められる背景とIIJのスタンス
  2. 3ヵ年計画でアジャイルの評価と実証を実施
  3. 初年度はアジャイル開発の準備を進め、スクラム開発を選定
  4. 2つのプロジェクトへの試験適用でノウハウを蓄積
  5. 独自のプロジェクト管理手法を構築し、社内浸透を促進
  6. 選択肢が広がり、プロジェクトに応じて最適な開発手法を提案可能

アジャイル開発が求められる背景とIIJのスタンス

アジャイル開発は新しい機能を短期間で継続的にリリースしていくソフトウェア開発手法です。機能ごとに設計・開発・実装・テストといったサイクルを繰り返します。不具合が見つかっても素早く対応でき、修正の工数も低く抑えられます。

昨今は市場やニーズの変化スピードが早く、ソフトウェア開発にもその変化に素早く対応することが求められます。またクラウドの利用が広がり、開発側はインフラなどの基盤構築に多くの工数を割く必要がなく、ソフトウェア開発に注力できるようになりました。こうしたことから、アジャイル開発の注目が高まっているのです。

このニーズに対応するため、IIJはアジャイル開発の組織実装に取り組みました。その根底には「お客様のチャレンジを支援するためには、IIJ自身が新しいことにチャレンジする必要がある」という強い思いがあります。

3ヵ年計画でアジャイルの評価と実証を実施

ターニングポイントになったのが、システムインテグレーションを担当する部門で2020年に起案された中期事業計画です。この中で「リソース集約・標準化によるコストパフォーマンスの追求」という大方針が掲げられました。限られた人的リソースを有効に活用し、最大のパフォーマンスを生み出すためです。

この実現に向けて「①広範囲な開発手法・技法を適用した短期開発の実現」「②運用保守統合/標準化による作業の効率化」「③育成・採用計画の立案/実行」という3つの基本方針を立案しました。

3つの基本方針の中で①の方針に対応すべく「アジャイルを含む開発手法の選定/ノウハウ蓄積」を推進する活動を始めました。この活動は3ヵ年計画を立て、2020年からスタートしました。各年の活動目的は以下の通りです。

3ヵ年計画の概要

初年度はアジャイル開発の準備を進め、スクラム開発を選定

では各年の具体的な活動内容と成果を紹介しましょう。

【2020年の活動】

まず一般の開発手法を「ウォーターフォール」「反復型」「アジャイル」の3つに分類し、それぞれの特性を評価しました。

ウォーターフォールと反復型については「基本設計の粒度を下げて、詳細設計フェーズを削減する」「テスト自動化を推進して、トータルな時間短縮を図る」ことなどを考え、比較検討しましたが、変更要求に対する柔軟性の高さなどから、小・中規模の高速開発にはアジャイル開発が適していることを確認しました。

クラウド開発手法の定義
モデル 開発規模 リリース単位 お客様との関わり度合 変更要求に対する柔軟性 導入のハードル 評価
ウォーターフォール 小規模から大規模まで得意とする プロジェクト単位 低い(×) 低い(×) 低い(〇) 多少の変更があっても導入は容易と考えている。ただし、高速開発としては向いていない
反復型 中・大規模を得意とする プロジェクト単位 低い(×) 高い(〇) 低い(〇) ウォーターフォールと同様に導入は容易であるが、リリース単位がプロジェクト単位のため、高速開発としては向いていない
アジャイル 小・中規模を得意とする イテレーション単位 高い(〇) 高い(〇) 高い(×) リリース単位がイテレーション単位のため、高速開発に向いている。ただし、お客様の理解や既存システムの状況に影響を受けるので、導入へのハードルが高い

アジャイル開発はイテレーションと言われる「設計・開発・テスト・改善」のサイクルを1週間から4週間程度の短期間で繰り返していきます。これにはチームワークが大切になることから、優先的に推進する開発手法にはアジャイル手法の1つである「スクラム開発」を選定しました。その上でツールの抽出・整備、アジャイル開発の選定基準の策定など導入準備を進めました。

2つのプロジェクトへの試験適用でノウハウを蓄積

【2021年の活動】

お客様の理解を得た上で、2つの開発プロジェクトでスクラム開発を試験適用しました。事前に開発者/お客様双方への説明資料として「スクラム開発導入資料」を作成し、スクラム開発で使用する重要なツール「Backlog」の利用方法について説明した資料も整備。スクラム開発の作業イメージや管理方法を説明し、開発者/お客様双方の理解を深め、実プロジェクトを運営していきました。

いくつかの改善点が上がりましたが、特に重要と感じたのが開発者/お客様双方のコミュニケーションです。短いサイクルで開発と改善を繰り返すため、進捗管理が難しく、「今、何のために、何をやっているのか」が見えにくくなるからです。

試験適用のお客様評価
評価 カテゴリ 内容 改善案
全体 要件定義工程での導入が適切だったかが疑問。開発プロジェクト全体でのアジャイル導入であれば、分割リリース等のメリットがあったと思われる プロジェクトの特性により、導入可否をよく検討することが必要
ツール(Backlog) 作業の進捗、課題が可視化され、WBSでの進捗確認よりリアルタイム性があった
コミュニケーション デイリースクラムによる日々の情報共有は効果があった。
開始時のプロダクトバックログの確認が不十分で、各タスクの内容に認識ずれがあったが、後続で修正された
× QA・課題解決 お客様内で定例会等が設定されておらず、全体を通してQAの回答が遅れるケースがあった スクラム開発導入時は、お客様側でも十分なサポート体制の確保が必要

独自のプロジェクト管理手法を構築し、社内浸透を促進

【2022年の活動】

前年の活動評価をベースに改善・補強が必要と考えられるツールや方法論を整備しました。これらを活用し、スクラム開発の適用案件の拡大を目指すためです。

試験適用後の補強実施項目
実施項目 説明
スクラム開発手法の本部内共有拡大 ガイドラインの社内ポータルへの公開 開発における各種規約や標準プロセス、ガイドライン等について、当初計画通り1Q中に社内ポータルでの公開に至った
スクラム開発講習会の定期開催 適用案件の拡大を目的として、公開したガイドラインベースでのスクラム講習会を企画、開催した
スクラム開発適用案件の選定・実行支援 スクラム開発導入案件のサポート 本年度初めにサポート内容を定義し、適用候補案件を募集。4Q開始のプロジェクトにスクラム導入支援を開始した
Backlogツール活用によるスクラム手法の部分的な導入 適用候補が見つからなかったこともあり、部分的なスクラム導入拡大を目指して、当初計画になかった手順書のリバイスを追加し、22年度中に完了

この一環として、独自の進捗管理の仕組みを実現しました。前年の試験適用の経験から、ウォーターフォール型のような進捗管理が適さないことは分かっていたため、スクラム開発に適した進捗管理の仕組みが必要と考えたのです。

例えば、開発中の機能で修正・改善が必要になった場合、新たなイテレーション開発サイクルを推進することになります。これにはお客様の理解を得ることが不可欠です。「改善作業にどれだけの工数がかかり、いつまでに終わるのか」を明示する必要があります。アジャイル開発で標準的なプロジェクト管理ツール「Backlog」ではこの対応が難しいため、独自の仕組みを構築しました。

これにより、プロジェクトの残り工数とタスクを数値化し明示的に示すことが可能です。工数がこれだけあるので、残りのタスクはいつまでに完了できる。難しい場合はお客様と一緒に次の手を考える。こうした提案を説得力ある形で説明できるようになりました。

同時にスクラム開発手法の本部内共有拡大を目指し、ガイドラインなどの資料を公開しました。スキルトランスファーと開発者の意識変革を促すため、スクラム開発講習会も定期的に開催しています。こうした活動により、認定スクラムマスターの「CSM(Certified Scrum Master)」や「PSM(Professional Scrum Master)」、アジャイルソフトウェア開発技術者検定試験の資格取得者も目標を上回るペースで増えています。

選択肢が広がり、プロジェクトに応じて最適な開発手法を提案可能

この3ヵ年計画は外部のベンダーやコンサルティング会社に頼ることなく、IIJ自身による「完全内製」で進めていきました。コアメンバーの社内エンジニアがアジャイルの概念を理解し、メリット/デメリットを含めた既存の開発手法との違いを評価。その上でスクラム開発を選定し、実践で学ぶために実プロジェクトで試験適用し、その効果と課題を検証していきました。段階的にステップを踏んで進めていくため、3年という時間をかけて行ったのです。

完全内製によるチャレンジだったため、試行錯誤の連続でいくつかの壁もありましたが、それだけに学びの多い活動でした。今回の活動を経て、アジャイル開発には以下の留意点があることもわかりました。

  • 従来の開発手法は開発規模や全体のスケジュールをもとに予算を見積もるため、開発予算の上限が決まっていることがほとんど。アジャイルは俊敏な開発ができる半面、開発スケジュールやコストに変動が生じやすくなります。
  • お客様からすると全体で必要となる費用が見えづらく、予算を立てにくい。開発の進め方に対してお客様側の理解を得るとともに、費用の変動を前提として開発予算を確保してもらうなど事前のすり合わせがより重要になります。
  • アジャイルは小規模なエンハンス開発や改善開発などに適用しやすく、ウォーターフォールや反復型は大規模で高品質なシステムを必要とする開発に向いています。
  • 実績の多いウォーターフォール開発に比べて、アジャイル開発はまだ世の中に浸透しきっておらず、具体的にどのような進め方になるのかイメージしにくい。説明資料の準備、講習会の開催など、開発者/お客様双方の理解と適応を促すことが大切です。

IIJはアジャイル開発の組織実装に取り組んできましたが、すべての開発案件にアジャイルが適用できるとは考えていません。上述したようにアジャイル開発にも既存の開発手法にもメリット/デメリットがあります。案件特性やお客様ニーズを踏まえ、最適な開発手法を提案・実践することが肝要と考えます。アジャイルの組織実装により、その選択肢が広がりました。

今後はお客様の理解と協力のもと、プロジェクトによって最適な開発手法を使い分けていきます。内製化の促進や自社に最適な開発手法でお悩みがあれば、ぜひIIJにご相談ください。