最初に、開発プロセストラックのコンテンツ委員の和田さんから挨拶がありました。
漆原さんモデレータで、製造金融業界で基幹業務をアジャイル開発した事例を聞くパネルでした。
アジャイルを成功させるにはお客さん次第。
以下適当なメモ。嘘かいてあるかもしれません。
ウルシステムズ 漆原さん
今までの「アジャイル開発」
- 理想目標←→弊害・懸念
- 「幸せな開発をやりたい」←→アジャイルが目的化、ユーザ理解が希薄
- 大事なところから作りPDCAサイクルを回す←→採集成果物が不明、責任所在が曖昧
- 少数の優秀なメンバーで切れ味良く仕上げる←→小規模Webのみ、業務系はムリ！
- 開発工程の無駄を省く←→ちゃんと設計しない、ドキュメント書けない
本セッションの目的
- 基幹業務システムまでアジャイル開発しちゃいました！
- 効果、苦労、リスク、工夫、反省、学び
東邦チタニウム 浜津さん
- チタン生産部門の部門長→リーダ→チームリーダ→業務見当チームと開発チーム
- 会誌の半年ほど前から、業務検討チームと開発チームが基本的なところを固めた
- 開発はいってからアジャイル
- 業務フロー検討 4ヶ月
- 開発 9イテ
- 予定よりも2ヶ月前倒しで運用開始できた
アジャイル開発採用の理由
- 工場の運転開始時期が決定 ウォーターフォールでは間に合わない
- 業務設計との併行開発で仕様変更を迅速に反映
- 利用者満足度の向上と早期の運用定着
成果
- 間に合った
- 予定より2ヶ月早く5月から全面運用をかいし
- 当初計画したすべての機能(295UC)を開発
- 予算に対して3%減の費用
マネースクウェア・ジャパン 森川さん
サブシステム
- フロント
- チャート
- バックオフィス
- ミドルオフィス(ディーリング) ← これをアジャイルでリフォーム、高速化
開発スケジュール
アジャイル開発採用の理由
成果
- たった4ヶ月でリフォーム完了。運用後のバグゼロ
- 性能は10倍、既存ハードの更改不要
- フロント・バックのシステムを継続して活用できた
- 全面更改に比べて 1/3 程度のコストで済んだ
どうして「普通に」作らなかったんですか？？
浜津さん
- 時間がなかった
- ウォーターフォールがまず選択肢から外れた
- グランドデザインを決めると頃から運用まで絶対に逃げないとコミットされた
森川さん
- 回転がすごくはやい
- それが普通
- ウォーターフォールがいいとかアジャイルがいいとかじゃなくて、そうせざるを得ない
- ウォーターフォールできちっと作った方がコードも綺麗になるしいいと思うけど、結局手を入れるんだから、アジャイルでやった方がいい。
浜津さん
- 変化することが当たり前。それに対応するためには有用。
経営者をどうやって説得しましたか？？
浜津さん
- チタンの生産現場の活動
- 新しい工場を作るという話が突然持ち上がった
- 現状の改革をしようと思ってるのに。
- このまま行ったらグチャグチャになる。
- そうならないように一生懸命考えます。と上に言った。
- 100%下駄を預けられた。
- 社長と部門長からは積極的に指示された
- 他の役員からは集中砲火
- 負傷しながら逃げない
- まずいと思ったタイミングでボコボコにされる場を作った
森川さん
- システムの課題に対して直すために全面改修が必要と言ってその気にさせた
- いくらかかるかを提示したらひかれた
- じゃあどうすればいいか
- 部分的に改修することで解決
- 部分的にやることで 1/3 の工数でできると説明
漆原さん
- どちらも検討の土壌があった
- 経営陣をまずおどすというやり方w
どんな苦労がありましたか？？
漆原さん
- 基本設計やらないドキュメント作らないという不安は？
浜津さん
- 半年間でグランドデザインをきちっとした上で、方向性を固め、開発の仕方の基本ルールも固めた
- ユーザーサイドから見た画面を最初におおかた決めた
- 作ってく過程でどんどん変わっていったけど。
漆原さん
- ユーザー部門に画面を見せるのは効果的だった？
浜津さん
- そうだった。そうじゃないとどんなものができるかわからなくて不安
漆原さん
- 短くやるための秘訣は？
森川さん
- 一人で行動するのではなくいろんな人を巻き込んでコミュニケーションしていく。
- 基本アーキテクチャはドキュメントとしてきっちり作る。
- 必要ないものはドキュメント化しない → Trac などを使う
- 基本アーキテクチャがぶれるとまずい
浜津さん
- システム開発していく上でウルシステムにコンサルと設計のリードをしてもらった
- グループ会社のシステム部門で作り込んだ。
- アジャイルは始めてだった。
- 中には向いてない人もいた。ウォーターフォールでは優秀な人だけど。
- 最初は開発メンバの雰囲気が良くなかった。
- 泣く泣くアジャイルに向くメンバと入れ替えた。
- ウォーターフォールに向く人→決まった通りにものを作る人
森川さん
- ユーザーに見せたところ、予想していた倍以上の要望が発生。
- 全部断ると怒られる
- 全部受け入れるとパンク
- ユーザーとの調整
業務部隊とうまくやる秘訣は？？
浜津さん
- システム開発部隊の部屋にマネージャーが毎朝9時〜6時までつめた。
- 何をするかしないかをその場で決定した。
- プロジェクトの中にオーナーを巻き込んだ
- 二次的効果 マネージャーの下の人間の実力もついた
- 人事権を持ってる部門長が親分にいたのでできた。
森川さん
- ユーザーは動いてあたりまえ
- 我々が気持ちを受け止めないといけない
- ユーザー部門にテストケースを書いてもらった
- 「ここまでテストしないといけないの？」と言われたが、「テストしないと困るのはあなたです」
- 大変さをわかってもらった
- 追加要求のムリさもわかってもらった
Developerへ期待していることは？？
浜津さん
- ITの専門家じゃないので、IT業界のやり方はわからないけど、ユーザー部門とのコミュニケーションをうまくとれるかが、いいシステムを効率よく信頼性高くできるポイント。
- 使う側の気持ちを専門家としてどう反映させるかが大事。
森川さん
- 最新の技術を追っているのをユーザー側に押し付けないで欲しい。
- ITは我々の求めているものを満たす手段の一つでしかないことを考えてほしい。
- もっとアプローチして。たとえば1ヶ月は無料でコンサルするとか。
