Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルを手放して得られたこと
2014/9/6
鈴木雄介
B-5

Copyright© Growth xPartners, Inc. All rights reserved.
自己紹介
•鈴木雄介
–グロースエクスパートナーズ（株）
»執行役員
»ビジネスソリューション事業本部本部長
»※がちのエンタープライズ
–略歴
»ユーザー系システム子会社で保守とか開発とか（5年）
»オンラインマーケベンチャーでプログラマとか（2年）
»フリーランスでITアーキテクトとか（3年）
»GxPでSI事業の部長とか（7年）
▸日本Javaユーザーグループ会長（2年）
1

Copyright© Growth xPartners, Inc. All rights reserved.
心構え
•アジャイルが好きな時もありました
•アジャイルが嫌いな時もありました
•アジャイルがどうでもいい（でも気になる）時 もありました
•いまはアジャイルといい距離な気がします
•なので、今の「俺のアジャイル」を話します
2

Copyright© Growth xPartners, Inc. All rights reserved.
話したいこと
•まずは「ソフトウェアを作る」こと
•そして「アーキテクチャとマネジメント」
•そのうえで俺が見ている「アジャイルとは」
•最後に「いまやっていること」を話して終わり
3

Copyright© Growth xPartners, Inc. All rights reserved.
ソフトウェアを作る
4

Copyright© Growth xPartners, Inc. All rights reserved.
ソフトウェアを作る
•ソフトウェア品質モデルから考える
5
利用時の
品質
利用時の
品質
プロセス
品質
内部
品質
外部
品質
利用時品質
影響を与える
依存する

Copyright© Growth xPartners, Inc. All rights reserved.
ソフトウェアを作る
•ソフトウェア品質モデルから考える
6
特徴
例
利用時の品質
・利用状況によって評価が異な る
・ユーザーＡさんと ユーザーＢさんで評価 が異なる
外部品質
・システムの振る舞い
・誰がテストしても同じ結果
・一般的な仕様策定の対象
・テストケース
・外部仕様
内部品質
・システムを構成している要素 すべて（含ドキュメント）
・後に残り、評価が可能
・エンジニアがこだわるところ
・クラス図
・フレームワーク
・ドキュメント
プロセス品質
・後に残らない行動
・コミュニケーション
・作業手順

Copyright© Growth xPartners, Inc. All rights reserved.
ソフトウェアを作る
•最近は「サービス」まで考えるのが大事
–ユーザビリティ、UI/UX
–リーン、エクスペリエンスマップ、ユーザーストー リーマッピング
–ようは、利用時の品質を積極的に管理していくこと
–でも、「それだけ」が大事なわけじゃない
7

Copyright© Growth xPartners, Inc. All rights reserved.
ソフトウェアを作る
•品質相互の関係が良好であることが大事
–個々の品質だけではない
8
利用時の
品質
利用時の
品質
プロセス
品質
内部
品質
外部
品質
利用時品質
影響を与える
依存する

Copyright© Growth xPartners, Inc. All rights reserved.
ソフトウェアを作る
•品質相互の関係を良好にするのは大変
–納期は間に合ったけど、いまいち出来が良くない
–理想はいいんだけど技術的に実現性がない
–使い勝手は悪くないけど、保守性がボロボロ
•大きな開発だとチームで考えないといけない
–だから、アーキテクチャが大事
–だから、プロジェクトマネジメントが大事
9

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
10

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•アーキテクチャとは
11
IEEE-Std-1471-2000Recommended Practice for Architectural Description of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
12
利害関係者の
関心事
ビューポイント
ビュー
ミッション
システム
制約（環境）
モデルによって記述

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•アーキテクチャとは
–システムのミッションに従い、システムのおかれた 制約を前提としながら
–システムに関わる複数の利害関係者の関心事を整合 させ、
»経営者、オーナー、ユーザー、プログラマ、DBA、インフ ラ屋、PM、上司、保守メンバー
–ライフサイクル（設計から保守）まで意識した
–システムの分け方と組合せ方のこと
13

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•プロジェクトマネジメントとは
–計画すること
–計測すること
–調整すること
•「計画と実行のズレを見つけて調整していく」
–そのために計画するし、計測する
14

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•ちなみにPMBOK
15
立ち上げ
計画
遂行
コントロール
終結
統合
計画策定
計画実行
統合変更管理
スコープ
（目的と範囲）
立ち上げ
スコープ計画/定義
スコープ検証/変更管理
時間（期間）
アクティビティ定義/順序設 定/期間見積
スケジュール作成
スケジュールコントロール
コスト（予算）
資源管理
コストの見積/予算化
コストコントロール
品質
品質計画
品質保証
品質管理
人的資源
組織計画
要員調達
チーム育成
コミュニケー ション
コミュニケーション計画
情報配布
実行報告
完了手続き
リスク
リスク・マネジメント計画
リスク識別
定性的/定量的リスク分析
リスクの監視・コントロー ル
調達
調達/引合計画
引合
発注先選定
契約管理
契約完了
計画
実行
調整

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•アーキテクチャとマネジメントの違い
16
アーキテクチャ
マネジメント
目的
プロジェクトの目的 を技術的に表現する
プロジェクトの目標 を達成する
手法
予測し、方向性を設 定する
計画し、計測し、調 整する
成果
対象物の分け方と組 み合わせ方
プロジェクトの成果 物そのもの
行動
事前的に決定
事後的に対応

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•品質相互の関係を考えるのに必要
–アーキテクチャは「何がどうできてるか？」
»利用時→外部→内部→プロセスと考える
–マネジメントは「ちゃんと作れてるか？」
»プロセス→内部→外部→利用時と考える
17
利用時の
品質
利用時の
品質
プロセス
品質
内部
品質
外部
品質
利用時品質

Copyright© Growth xPartners, Inc. All rights reserved.
アーキテクチャとマネジメント
•アーキテクチャとマネジメントは大事
–チームで仕事するなら「とりあえず好きな流行の技 術を選択」も「思いつきの計画変更」もありえない
–とはいえ、考え過ぎても分からないことはある
»ソフトウェアの適用領域が広がり、要件が複雑化
»オープン化・標準化による技術要素の複雑化
»エンジニアのスキルの多様化・規模の肥大化
–では、どうすればいいのか？
18

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルとは
19

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルとは
•広義には”態度”
–アジャイルソフトウェア開発宣言（2001年）
»プロセスやツールよりも個人と対話を
»包括的なドキュメントよりも動くソフトウェアを
»契約交渉よりも顧客との協調を
»計画に従うことよりも変化への対応を
–当時の時代背景が透けて見える
»プロセスやドキュメントや契約や計画が重要だったころ
20

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルとは
•狭義にはプロジェクトマネジメント”手法”
–ソフトウェア開発では「計画精度をあげて調整の無 駄を無くそう」が難しい
»製造業に比べると、目に見えないので計測がしにくい
»製造業に比べると、調整コストが小さい
–なら、調整を前提にすればいい
»小さく計画→動くもので確認→新しい計画＝調整
»顧客を巻き込んで調整する
»計画は定期的にする
21

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルとは
•”手法”としては画期的
–プロジェクトマネジメントにありがちな失敗
»計画の失敗：計画の精度が悪かった
»計測の失敗：進捗を測り間違えた
»調整の失敗：方向修正する話し合いができなかった
–だから、アジャイル手法は
»計画：精度が出るぐらい小さな計画にすればいい
»計測：動くソフトウェアで計測すればいい
»調整：定期的にみんなで見直すことにすればいい
22

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルとは
•アジャイルは素晴らしいが課題はある
–１．全体整合性の軽視
»主に「アーキテクチャの軽視」につながる
»「考えすぎは良くない」だけなのに“象牙の塔のアーキテク ト”に対する嫌悪感から事前的な設計を軽視しがち
▸アーキテクチャを後から直すのはコストがかかる
»日本の優れたアジャイルエバンジェリストって優れたエン ジニアばかりで「言わなくても当然」だった
–２．「言い訳」に使う人が出てきてしまう
23

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルとは
•アジャイルを「言い訳」に使う
–アジャイルは不確実性に立ち向かうための道具
–より良いものを作るための覚悟
»不確実だけど、より良い選択をするんだという覚悟
»顧客や仲間と対話して向き合うという覚悟
»最初はダメでも、いつかは良くするという覚悟
–覚悟がない人間が使うと、ただの「言い訳」になる
24

Copyright© Growth xPartners, Inc. All rights reserved. 25
アジャイルのダークサイド
https://www.flickr.com/photos/soulnoire/3217872979/
他者への傲慢や軽蔑
不確実性からの逃避
責任回避

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルのダークサイド
•アジャイルのダークサイド
26
よく使う言葉
ダークサイド思考
顧客が欲しいものを作る
ダメなのは顧客の責任
あとで変更できる
最初に決めるのが面倒
動くコードがすべて
説明しても分からない
イテレーションごと計画
全体にはコミットしない
自動デプロイしています
お前がテストしろ
優れたメンバーを確保
委任契約でリスクは発注元

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルのダークサイド
•自分で運用する人は落ちにくい
–手を抜くと自分に降りかかってくるから、いやでも 覚悟をしないといけない
–降りかかることが想像できずに落ちる人はいますが
•運用をしない開発者とか偉い人は落ちやすい
–SIerとか
–情報システム部の部長とか
27

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルのダークサイド
•ダークサイドに落ちないために
–まずもって「良いものを作りたい」という覚悟
»不確実だけど、より良い選択をするんだという覚悟
»顧客や仲間と対話して向き合うという覚悟
»最初はダメでも、いつかは良くするという覚悟
–その上で、どう作るかにコダワル
»「良いものを作るためにはどうすればいいか？」
»そうすれば「アジャイルで作ったか」は関係ない
28

Copyright© Growth xPartners, Inc. All rights reserved. 29
https://www.flickr.com/photos/kaptainkobold/3186086975/
アジャイルを手放す

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルを手放す
•再び、アジャイルソフトウェア開発宣言
–プロセスやツールと個人と対話
–包括的なドキュメントと動くソフトウェア
–契約交渉と顧客との協調
–計画に従うことと変化への対応
•俺は「どちらにも価値がある」と思う
–何に価値があるかは状況で変わる
30

Copyright© Growth xPartners, Inc. All rights reserved.
アジャイルを手放す
•アジャイルであることは重要じゃない
–アジャイルでないことも重要じゃない
–良いものを作るためにアジャイルが適切であれば使 えばいいだけ
•与えられたもので思考停止しない
–とりあえずやってみようは良い
»経験から学べばいい。何が課題かを考えればいい
–現実を無視しない
»「これはアジャイルではあり得ない」と他責しない
31

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
32

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
•企業と持続的な開発モデルを実現しています
–弊社の主要クライアント
»流通小売/1.3兆円
»医療機器/3000億円
»情報サービス/150億円(*)
»通信/4.5兆円(*)
»製造/9500億円
»出版/400億円
–もちろん、しがらみは色々とあります
33

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
•事例：情報サービス1/2
–リリース後の3つのプロセス
34
対象
タイミング
意志決定
特徴
新機能
年に1,2回
企画/設計/開発など、それぞれの段 階で役員承認
必要な時間をかけて合意形成
ウォーター フォール的
定期
改善
年に4回
(日付固定)
工数枠は事前承認。実施内容はバッ クログから優先順位で選択後に承認
アジャイル的
(3ヶ月定期)
保守
随時
毎月定額保守。実施内容はシステム 本部内で決定。
問合対応、障害対応、ちょっとした 改善など
いわゆる保守
(2週間定期)
(緊急あり)

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
•事例：情報サービス2/2
–顧客組織内での改善が素晴らしかった
»特に組織間のコミュニケーション
»結果として、組織がプロダクトオーナーの役割を果たせた
–ちなみに、リモート開発体制で完結
–詳細はこちらに
»「組織をプロダクトオーナーにする、ということ」
▸http://arclamp.hatenablog.com/entry/2014/08/05/151250
35

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
•事例：通信
–オンサイトでスクラムを採用して開発
»最近、無事にサービスイン！
»でも、いろいろな成功と失敗があった
»そして、組織内の誰でもがアジャイルの態度や手法でやれ るわけではないことに気づいた
–他の部署に展開していくために
»アジャイルに向けたステップを用意する必要がある
»組織の文化に沿って、やり方を定型化する
▸設定中：プロセス、成果物定義、完成基準…
▸ちゃんとお仕事をするために必要なものはそろえる
36

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
•組織に最適なITマネジメント手法を見つける
–チームから組織にスケールを変えていく
–一番重要なのは組織が判断するペースに合わせる
»企業によって異なるけど「3か月定期」がいい感じっぽい
»EnterpriseAgileってやつ？？
»まだまだ試行錯誤をしています
–手法を見つけることにはこだわるけど、既存の手法 で満足することはない
»その手法がなんと呼ばれるかに興味はないです
37

Copyright© Growth xPartners, Inc. All rights reserved.
いまやっていること
•ITで、世の中をもっと良くしたい
–でも「ITだけ」では変わらない
–社会基盤を担うような組織に、ITの使い方を変えて もらわないといけない
–だから、エンタープライズの「現実」を受け入れる
–「今の現実」を変えない限り、未来は変わっていか ないから
»そのための”手段”や”手法”は何でもいいと思う
38

Copyright© Growth xPartners, Inc. All rights reserved.
まとめ
39

Copyright© Growth xPartners, Inc. All rights reserved.
まとめ
•ソフトウェアを作るのは簡単じゃない
–それぞれの品質の関係を考えることが大事
40
利用時の
品質
利用時の
品質
プロセス
品質
内部
品質
外部
品質
利用時品質
影響を与える
依存する

Copyright© Growth xPartners, Inc. All rights reserved.
まとめ
•アーキテクチャとマネジメントは両輪
–アーキテクチャは「何がどうできてるか？」
»利用時→外部→内部→プロセスと考える
–マネジメントは「ちゃんと作れてるか？」
»プロセス→内部→外部→利用時と考える
41
利用時の
品質
利用時の
品質
プロセス
品質
内部
品質
外部
品質
利用時品質

Copyright© Growth xPartners, Inc. All rights reserved.
まとめ
•アジャイルは優れている
–態度としても、手法としても素晴らしい
–プロジェクトマネジメントにありがちな失敗を逆転 の発想で切り抜ける
»計画：精度が出るぐらい小さな計画にすればいい
»計測：動くソフトウェアで計測すればいい
»調整：定期的にみんなで見直すことにすればいい
–でも、完璧なわけじゃない
»片輪のアーキテクチャをお忘れなく
42

Copyright© Growth xPartners, Inc. All rights reserved.
まとめ
•アジャイルのダークサイド
–不確実性を受け入れる覚悟がない人にとっては、自 分に責任が来ないようにするための言い訳
–偉い人とか運用をしない開発者が落ちる
»自分で運用しなきゃいけない人は落ちにくい
•落ちないために「アジャイルを手放す」
–どう作るかではなくて、何を作るべきか
–与えられたもので思考停止しない
–現実から逃げない
43

Copyright© Growth xPartners, Inc. All rights reserved.
まとめ
•組織が、より良いITサービスを作るために
–会社にとって大事なものをマネジメントするのに、 ”ある1つの優れた方法”なんかない
»たとえば人事制度って企業の文化が反映されますよね
–だから、”ある手法”へのコダワリを手放して、より 最適な手法を考えたほうがいい
–どう作るかではなく、どこに至りたいのかを考える
»そのために何をすべきかを考える
44

Copyright© Growth xPartners, Inc. All rights reserved. 45
あなたが考える
https://www.flickr.com/photos/sudhamshu/3202963823/