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

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

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

金融系の開発で求められる高い品質などをアジャイル開発の特性を活かしながらどのような手法で確保したのか。そして厳格なプロセスで開発してきた文化を持つ企業の中でアジャイル開発を成功させた要因は何だったのか。事例から読み取ることができるでしょう。

本記事ではその事例セッション「金融系IT企業におけるスクラムへの挑戦」の内容をダイジェストで紹介します。

会社としてアジャイル開発を試す方針に

ニッセイ情報テクノロジー株式会社 上席プロジェクトマネージャ 中野安美氏、システムエンジニア 嶋瀬裕子氏。

生保業界でも最近はタブレットの導入など新しい技術の採用が始まっていて、弊社としてはそういう新しい技術を活かしてお客様のニーズに応えていきたい、そうしないと生き残れないよね、という危機感を持っています。

一方で金融系システムの特長として社会インフラを担っている側面があります。そのためQCDに求められる水準も高いとされていて、品質などに大きい問題があると、お客様への重大な影響につながる可能性があります。

そのため、開発プロセスを事前に決めて、厳格に管理することとなっています。

これまではこうしてウォーターフォールでの開発をしてきましたが、しっかり上流工程に時間をかけることによる開発コストの増大や、市場検証スピードが遅くなるという課題も感じていました。

そういう背景があり、アジャイル開発を試してみようという方針が会社として決まりました。

そこで開発プロジェクトに選ばれたのが、福利厚生の申請など事務サポートのシステムです。これをASPやオンプレミスで提供します。

最初の3カ月でウォーターフォールにより基本設計まで行い、承認をとってからスクラムで開発を行いました。

開発中も、ここを見直したいねとか画面はここはいまひとつだよね、というところはそのつど設計も見直しました。

スプリントは2週間を12回、最終スプリントとしてテスト／リリーススプリントを設けて、実装からテストを7カ月で行いました。

メンバーはこんな感じです。PO（プロダクトオーナー）がなぜ2名いるかというと、私は客先に出かけることが多いので、POを2人立てました。また、社外パートナーの方とは準委任契約としています。

最初に全員でアジャイル開発の研修を受けて、基礎の基礎を学びました。

社内規定「標準開発工程」の逸脱申請

私達の部門ではCMMI レベル3を取得していて高いマネジメントレベルを求められています。また、社内規定として「標準開発工程」があり、アジャイル開発はそれに適合しないという問題がありました。

そこでこれを統括している品質管理部門に相談すると、標準開発工程の「逸脱」の申請をしてくださいということで、なぜ標準開発工程ができないかという理由を書いて申請しました。

セキュリティの関係で、開発ドキュメントを出しっ放しにして帰ってはいけないことになっています。そのため、最初はタスクボードにタスクなどを書いてたくさん貼り付けていた付箋を、毎日帰る前に会社所有のデジカメで写真にとって、はがして片付ける、という手間をかけていました。

そこでセキュリティを統括しているリスク管理部門に相談したところ、これが見られてもほかの人にはなんのことか分からないだろうということと、入退室のセキュリティ管理はされていることもあり、掲示したままでいいということになりました。

見よう見まねから改善へ

アジャイル開発の導入開始時には、株式会社豆蔵の山田さんにアジャイルコーチをお願いし、いろいろサポートしていただきました。

最初は見よう見まねで、プランニング、デイリーミーティング、スプリントレビュー、振り返り（KPT）などのイベントを行い、プロダクトバックログ、タスクボード、バーンダウンチャート、席替えなども採用してみました。

そこから改善を進めて、デイリーミーティングは前日やったこと、今日やること、課題を話し合うようにし、発言の順番はくじ引き。

新たなミーティングとしてお昼のミーティングでバーンダウンチャートの確認や、POとの中間確認ミーティングなどを行うようにしています。

タスクボードもいろいろルールを変えて分かりやすくしました。

振り返り（KPT）では、Tryの実践が2週間のスプリント内に実行されないことがあったので、スプリントの中間で思い出して実践できるように改善しました。

コミュニケーションの活性化に取り組む

アジャイル開発を進めていく中で、仕事場で周囲から見ても楽しい雰囲気にしたいという思いから、コミュニケーションの活性化にも取り組みました。

例えば、スプリントごとにスローガンを決めました。これを考えるときもアジャイル的に、時間を決めて20分以内に決めるようにしました。

キャラクターも作りました。

お菓子神社。いまでは毎日活用しています。

ヘルプカード。これは振り返りの中で生まれたのですが、作業で詰まったときに自分だけで解決しようとして時間がかかってしまうより、時間を有効に使うために、何かあれば全員が気づけるように、という効果がありました。

≫後編に続きます。後編では、アジャイル開発において進捗と品質をどう管理し報告するか、そしてプロジェクト成功の要因は、など。

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