アジャイルジャパン初心者向けセミナー

アジャイル開発の提案から開発まで！
～基幹業務システム再構築編～
2015年11月27日

copyright (c) DSK. all rights reserved.

本日のアジェンダ

1. 会社紹介／自己紹介
2. 開発事例概要
3. 基幹業務システム再構築～提案編～

4. 基幹業務システム再構築～開発編～

copyright (c) DSK. all rights reserved.

1

会社紹介
商号

株式会社電算システム（Densan System Co.,Ltd.）

代表者

代表取締役会長執行役員CEO 宮地 正直
代表取締役社長執行役員COO 田中 靖哲

設立

1967年（昭和42年）3月14日

資本金12億2,048万円

上場取引所

岐阜県下の民間企業・諸団体を対象に、情報処理受託業務を主たる目的として、地元4銀行並びに主要企業の共同出資（払込資本金2,000万円）によって、岐阜電子計算センターとして設立。

東京証券取引所市場第一部
名古屋証券取引所市場第一部

従業員

単体/569名、連結/690名

所在地[岐阜本社]
501-6196 岐阜県岐阜市日置江1丁目58番地
TEL：058-279-3456 FAX：058-279-5848

岐阜本社

大垣テクノセンター[東京本社]
104-0032 東京都中央区八丁堀2丁目20番8号 八丁堀東急ビル
TEL：03-3206-1771 FAX：03-3206-1774[大垣テクノセンター]
503-0006 岐阜県大垣市加賀野4丁目1番21
TEL：0584-77-2345 FAX：0584-77-2349

各種認定

プライバシーマーク付与認定事業者（11820356）
ISMS認証取得（JQA-IM0090）
資金移動業者（東海財務局長第00001号）
東濃データセンター

copyright (c) DSK. all rights reserved.

2

会社紹介

収納代行サービス Webサイト
http://www.dsk-ec.jp/

copyright (c) DSK. all rights reserved.

3

自己紹介

自己紹介
 北川和男（きたがわ かずお）

＜役割＞
プロジェクトリーダー、業務統括＜経歴＞
ホストコンピュータの時代からシステム開発に携わり２０数年、Androidの黎明期には、東京でアプリ開発のＳＥ兼プログラマーとしてアジャイルを実践する。現在は主にWebシステム開発のマネジメントを担当している。

 棚橋啓介（たなばし けいすけ）＜役割＞
提案営業（提案資料作成、プレゼン）、プロジェクト立ち上げ時のアーキテクト担当＜経歴＞
提案から開発までこなす何でも屋～最近はデジタル教科書開発を主に取り組んでいる。
copyright (c) DSK. all rights reserved.

4

開発事例概要
2012年２月 Ａ社のＲＦＰにもとづき、基幹業務システムの再構築の提案をすることになりました、開発規模／予算／スケジュールといった厳しい要求にどのように対応したかをご紹介します。
提案編

開発編

現行システムの開発運用をしている会社含む、複数社のコンペが行われました。その中で弊社が行ったアジャイル開発を中心とした提案内容をご紹介します。

今回の開発で行った、プロジェクトの進め方や適用したプラクティスを紹介します。

copyright (c) DSK. all rights reserved.

5基幹業務システム再構築 ～提案編～

提案編

copyright (c) DSK. all rights reserved.

6基幹業務システム再構築 ～提案編～

RFPの概要 1/2
 受注～請求までの販売管理システム全体の再構築を行う案件

 社内システムの統合

事業セグメントが異なる、VB6、PHPと二つのプラットフォームで動いているシステムを統合し、かつ、新規展開予定の事業にも対応する。

 新システムはWebシステムで構築する
copyright (c) DSK. all rights reserved.

7基幹業務システム再構築 ～提案編～

RFPの概要 2/2
 インフラ要件

データセンターを活用し、災害にも対応できる新しいインフラ基盤を構築する。

 開発対象機能数は200超
 希望開発期間は９ヵ月

 開発手法、プロジェクトの進め方の指定なし
copyright (c) DSK. all rights reserved.

8基幹業務システム再構築 ～提案編～

ウォーターフォール型開発の検討
RFPを元に従来通り積算の見積りを行いました
・機能を洗い出し、重みづけ・要件定義～移行までの作業項目洗い出し・短納期、初めてのお客様 等々様々なリスク

予算／期間内 にできそうな範囲

ウォーター
フォール型

要件定義

設計
（基本・詳細）実装・単体テスト

結合・総合テスト

通常の提案では難しいと判断しました
copyright (c) DSK. all rights reserved.

9基幹業務システム再構築 ～提案編～

何か工夫はできないか・・・ 現行システムを分析

RFPのフロー、機能は現行＋新規要件のto beモデルのため、現行システム資料をお願いして入手し徹底的に調査。また、システム担当者へのヒアリングを何度も行い、幹になる部分を分析しました。

 開発手法の検討

社内の成功事例をもとに、過去に行ったアジャイルを適用することを検討。

copyright (c) DSK. all rights reserved.

10基幹業務システム再構築 ～提案編～

提案骨子 その１ 開発機能絞り込み

現状分析した結果を元に、開発を複数ステップに分割し、ファーストステップは最低限業務運用できる機能だけを製造。

RFP開発範囲

機能A

機能B

機能C

機能D

機能E

機能F使用頻度が少ないマスタメンテ／補助的な機能／ちょっとした便利機能 etc

機能G

機能H

機能I

機能J

機K

ＳＴＥＰ２ （別契約） で開発する※「希望期間内に全機能の開発は無理」 と正直に伝えました。
copyright (c) DSK. all rights reserved.

11基幹業務システム再構築 ～提案編～

提案骨子 その２ システム統合の分割
システム移行はユーザの負担大、２システムの移行を別タイミングで提案

SETP1開発

基幹システムＡ
移行

SETP２開発

基幹システムＢ
移行

ＲＦＰ開発対象機能 ２００超 → ＳＴＥＰ１開発機能 ９０まで絞りこむ※当初予定９０機能でしたが、最終的に１００機能超となってしまいました・・・

copyright (c) DSK. all rights reserved.

12基幹業務システム再構築 ～提案編～

提案骨子 その３
 アジャイル開発を取り入れ、効率的に開発を行う。
アジャイル開発 適用範囲
ウォーター
フォール型

要件定義

設計
（基本・詳細）実装・単体テスト

結合・総合テスト

アジャイル開発の実績を紹介し、基本設計～単体テストまでのフェーズに適用することを提案※進め方の詳細は開発編で。

copyright (c) DSK. all rights reserved.

13基幹業務システム再構築 ～提案編～

顧客プレゼン
プレゼンのポイント いかにスコープを絞るか一大イベントということで、各部署から「あれもこれも」と要望が多いことは想像できますが、極力「無駄なものを作らない」ことを提案。
 アジャイル開発の品質
通常のウォーターフォールと同様の結合・総合テストのフェーズをこなすことで、最終的な品質で差異がでないことを説明
結果 僅差でＤＳＫの受注が決まりました！
copyright (c) DSK. all rights reserved.

14基幹業務システム再構築 ～開発編～開発編

copyright (c) DSK. all rights reserved.

15基幹業務システム再構築 ～開発編～

問題解決のコンセプト＜短納期＞
提案、契約等で日数がかかり１００機能以上ある開発の総合テスト完了まで、実際の開発期間は８か月。
（ユーザによる運用テスト開始まで）＜お客様の体制＞
システム部のSEは2名、要件とりまとめや、設計書レビューのパワー不足が懸念される。また、新規事業の要件がまとまりきっておらず、残作業をしながらの開発となる。

copyright (c) DSK. all rights reserved.

アジャイルにて開発を行い設計書ではなく、実際に動作するプログラムで要件と機能の確認を行う。開発中のドキュメント作成は最低限とする。
⇒動作するプログラムをリリースすることを最優先にする。
⇒動作するプログラムなら、ユーザ部門担当者でも確認ができる。
⇒新規事業に関しては、要件の変更が多く発生すると想定されるが、アジャイルを適用し、柔軟に対応できる前提とする。

16

基幹業務システム再構築 ～開発編～

お客様体制の確立
 システム2名、業務責任者1名の３名チームが全ての窓口となり、仕様を統括する。
 3名の統括と、実際の業務毎の担当者がリリースされたプログラムを元に仕様を確認する、そのための環境を初期段階から構築する。
 機能に関しての指摘事項は、DSK側と協議の上バグ／仕様変更の区分けをし、優先順位を決定し対応を協議する。
copyright (c) DSK. all rights reserved.

17基幹業務システム再構築 ～開発編～

アジャイル開発の適用範囲
基本・詳細設計 ～ 実装・単体テスト工程をアジャイルで実践。テスト期間を明確に設定し品質担保。

要件定義
アジャイル開発
プロト開発

アジャイル開発
基本・詳細設計
実装・単体テスト
常時結合

結合・総合テスト
アジャイル開発
バグ・仕様変更対応

設
計
ド作キ成ュ
メン
ト

システムメンテナンスに詳細な設計書が必要、その作成作業は総合テスト完了後とした。
copyright (c) DSK. all rights reserved.

18基幹業務システム再構築 ～開発編～

適用したアジャイルのプラクティス
 朝会（スタンドアップミーティング）
 ペアプログラミング ストーリー計画
 タスク

 バーンダウンチャート 常時結合 KTP（振り返り）

copyright (c) DSK. all rights reserved.

19基幹業務システム再構築 ～開発編～

アジャイル開発の進め方 イテレーションの設定。期間は１週間 or ２週間（今回は2週間）
プランニング
タスクだし

設計／実装

リリース

振り返り

 ストーリー計画（スケジュールはこれのみ）

 タスクの管理（タスクカード／タスクボード）

 バーンダウンチャート（進捗状況を見える化） 実績のトラッキング（チームパフォーマンスの評価）
copyright (c) DSK. all rights reserved.

20基幹業務システム再構築 ～開発編～

ストーリー計画

copyright (c) DSK. all rights reserved.

21

基幹業務システム再構築 ～開発編～

タスクの管理（タスクカード）
理想時間（見積時間）

担当者（タスクを取った時に決定）

実績時間

copyright (c) DSK. all rights reserved.

22基幹業務システム再構築 ～開発編～

タスクの管理（タスクボード）【To Do】
未着手のタスク、追加削除は随時実施。担当者は決まっていない。

copyright (c) DSK. all rights reserved.

【Doing】
現在着手しているタスクを貼り付け。
誰が何をしているか一目でわかる。

【Done】
完了したタスク。

23

基幹業務システム再構築 ～開発編～

バーンダウンチャート

400

実績時間
350

残工数が理想線の上になると進捗遅れのサイン

300

残作業時間

時間数

250200150

理想消化時間の線

10050

0
開始時点

7月19日

7月20日

7月23日

7月24日

7月25日

7月26日

7月27日

期間

copyright (c) DSK. all rights reserved.

24基幹業務システム再構築 ～開発編～

バーンダウンチャート（普段の運用）
 スタンドアップミーティングの前に前日分を集計し記入。

日々進捗を見える化し、チームで共有する。
 遅れが発生した理由解析、キャッチアップ等、素早く対応可能。

普段はホワイトボードを活用。
誰でも一目で状況がわかる。
copyright (c) DSK. all rights reserved.

25基幹業務システム再構築 ～開発編～

トラッキング（パフォーマンス）
タスクの消化数

理想時間（左）と実績時間（右）のグラフ。
理想時間と実績時間のズレが少ない方が見積精度が高いと判断できる。

copyright (c) DSK. all rights reserved.

26

基幹業務システム再構築 ～開発編～

品質担保
特に特殊なことはしていません。地道にテストケースをこなします。
バグ発生件数と修正完了件数 累計
バグ発生件数の累計

バグフィックス数の累計

実際には12日から着手していますが、１５日に管理表作成し集計が記入日になっているため角度が急になっています。

copyright (c) DSK. all rights reserved.

27

基幹業務システム再構築 ～開発編～

アジャイルを適用してよかったこと 1/2


最終段階でユーザとの機能／仕様の齟齬が少ない。
動作するアプリをユーザが見ていることと、イテレーション毎の指摘事項で、対応しているため。（※）

ストーリー計画の優先度を随時見直し要求変化に対応。結果として無駄なものは作られなかった。



コア機能から取り組むため、リスクが初期段階で明確になる。



多能職となるため、要員の空きがでにくい。
（設計待ちで実装できない等々）※ 本事例の場合、321件の指摘。（半分以上は仕様変更）
copyright (c) DSK. all rights reserved.

28

基幹業務システム再構築 ～開発編～

アジャイルを適用してよかったこと 2/2


いろんな仕事（要件定義から実装まで）をこなすため、飽きがこない。



ペアプロの採用で開発メンバーが短期間でスキルアップできた。



実際の出来高が分かるため、進捗、パフォーマンスがわかりやすい。



常時結合による開発のため、結合テストに入った瞬間から一通りの処理は動作する。



テスト終了後に詳細な設計書を作成したため、精度が高いドキュメントとなった。また、設計書作成工数を押えることができた。

copyright (c) DSK. all rights reserved.

29

基幹業務システム再構築 ～開発編～

大変だったこと

ストーリ計画、仕様変更事項の調整
実際に動かしてみると指摘事項や要望が多くでるため、仕様調整の難易度が高い。対応すればするほどシステムの完成度、顧客満足度は高くなるが、開発期間／予算もあるため、未開発機能を含め優先順位管理と顧客調整が必要となる。
立ち上げ初期段階（軌道に乗るまで）の負荷が高いフレームワーク、システム基盤も一緒に作りこむ必要があるため。今回スケジュールがタイトなこともあり、タスクが膨らんでいく圧迫感で精神的にきつかった。
お客様を含めたチーム作り／プロジェクト進め方の確立
要件整理をしながら、次々リリースされる機能のレビューをしなくてはならない。その場で意思決定できる人や権限が必要。
臨機応変に色々な作業をこなさないといけない多能職であることが必須。

copyright (c) DSK. all rights reserved.

30

基幹業務システム再構築 ～開発編～

うれしいプレゼント
開発も一段落し運用フェーズに入った後の打ち上げで、お客様からプレゼントがありました。
・システムロゴがデザインされたピンバッジ！

・お客様各部署責任者／運用者からのビデオレター！

copyright (c) DSK. all rights reserved.

31

基幹業務システム再構築 ～開発編～

今後の課題


プロジェクトの立ち上げ・チームの維持
立ち上げ初期のパフォーマンスが不安定、人の素養によるため初期段階の生産性の予測が難しい。また、せっかく立ち上げたチームが、ＰＪが終わると解散してしまう。



標準化、横展開
プラクティスをとりまとめることはできるが、実際会社の標準として取り入れたり、実践したことのないチームへの横展開が難しい。
経験した人が展開していく、のれんわけ のイメージが効率的。



お客様を含めた進め方
お客様の体制／プロジェクトの進め方／契約について、明確なガイドラインがなく、初めてアジャイルを導入する際調整が大変。

copyright (c) DSK. all rights reserved.

32

ご清聴ありがとうございました！

copyright (c) DSK. all rights reserved.

33