厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（後編）。Regional SCRUM GATHERING Tokyo 2016

金融系システム開発会社として、しっかりしたプロセス管理の下でウォーターフォールによる開発を続けてきたニッセイ情報テクノロジー株式会社。

同社は、1月19日と20日に都内で開催されたアジャイル開発手法の1つ「スクラム」をテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」で、同社として初めてスクラムを採用したプロジェクト開発の事例を紹介しました。

（本記事は「厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（前編）。Regional SCRUM GATHERING Tokyo 2016」の続きです）

進捗と品質を上司に定期的に報告する方法に悩む

アジャイル開発を進めていく上でぶつかった課題は進捗と品質の報告をどうするか、どう上司に報告するかに悩みました。

ウォーターフォールではQCDの基準を決めて、その計画を立てて、その達成状況を管理するやり方なのかなと。アジャイル開発ではQCDの目標を立てるのは同じですが、要求の変化を受けて入れていくのが大きな違いかなと思います。

アジャイル開発では要件が分かっているわけでも、WBSがあるわけでもないので、進捗を管理するのならばどうすればいいのか。

進捗管理に使える要素としてプロダクトバックログの「ストーリーポイント」と、スプリントバックログの「タスクの作業時間」があります。また、進捗管理を「プロジェクト全体」と「スプリント内」に分けました。

プロジェクト全体は、残ポイントとベロシティで収束予測をしました。

スプリント内では、残作業時間で収束予測をしました。

アジャイル開発で品質を定量的に管理するには？

では、品質を定量的に管理するにはどうすれば良いでしょう？

アジャイル開発ではプロジェクトごとにプロセスや成果物が異なるため、品質管理標準をそのままでは設定できないと考えまして、でも品質の重要度などに応じた施策を考えなくてはいけないと。

品質保証には、プログラム品質、そして要件を満たしているか、という2つがあります。

プログラム品質保証には、ツール導入で品質の数値を拾うように、JenkinsやSeleniumなどの自動化ツールで効率化もはかりました。

要件はスプリントレビューでPOなどと見るようにしていました。

アジャイル開発が成功した要因

こうしてアジャイル開発のプロジェクトがうまくいった要因として、改善を繰り返して、どんどん変えていこうという姿勢を保ったことがよかったと思います。

例えば、ルールを守れなかったときに、そのルールを守れなかったことが悪いのか、ルール自体が悪かったのか、そのルールが必要なのか、などと深掘りをして改善していきました。

ルールはシンプルにして、効果が薄かったらやめるとか、KPTで振り返って徐々に改善していったので慣れていったし、良くなっているという変化をメンバーが体感できたのも良かったのかなと思っています。

外部からの阻害要因が少なかったことも挙げられます。

ふだんはリスク管理や生産管理などの部門が厳しく目を光らせ、チェックされている状況ですが、今回は初めてアジャイル開発をするということで、あたたかく見守ってくれたのも成功の要因の1つだと思います。

アジャイルコーチを活用した点も、立ち上げがスムーズに行きましたし、悩んだこともすぐに相談できてすごく助かりました。

アジャイル開発の効果と今後の展開

プロダクトの開発面の効果としては、製品開発はアーキテクチャから考えるケースが多く、やってみないと分からない部分が大きいと思います。

それを実際に開発しながら、コストと機能面のバランスなどを決めていけるので、アジャイル開発手法が活用できる点かなと思います。

チームメンバーが自主的に活動して、コミュニケーションが活発になりました。

開発メンバーからは「やってて楽しい」「面白いですね」という声がどんどん出てきました。私はPOとして関わっていましたが、そちらに入りたいくらいうらやましく思っていました。

ウォーターフォールでは、WBSを組んで担当者を割り当てて作業していくので、そのあとは個人で作業する面が強くなります。作業の遅れも個人の遅れとして見られがちです。

アジャイル開発では「チームで終わらせる」という意識が強くなるので、そういう面が大きな違いだと感じました。

アジャイル開発への取り組みはまだ始めたばかりですが、今後は社内にさらに展開して行きたいのと、もう少し規模の大きなものでも試したいと思っています。

最終的には、開発を行うときに、そのプロジェクトではアジャイル開発がいいかウォーターフォールがいいかを選択できるように持って行きたいです。

そのためには、アジャイル開発を支援する組織があったほうがいいと思いました。ナレッジを共有したり人材を育成することで、社内全体のアジャイルの底上げが早くできるかなと。

今回、アジャイル開発をやってみてすごく良かったですし、チームも、メンバーも成長したと思います。結果としてウォーターフォールで見積もったよりも早くできたとも思うので、今後ももっとチャレンジしていきたいと思います。

Regional SCRUM GATHERING Tokyo 2016

• 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
• 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016
• 厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（前編）。Regional SCRUM GATHERING Tokyo 2016
• 厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（後編）。Regional SCRUM GATHERING Tokyo 2016