XP祭り2014「アジャイルを手放して得られたこと」

Copyright© Growth xPartners, Inc. All rights reserved.

アジャイルを手放して得られたこと2014/9/6

鈴木雄介

B-5


自己紹介

• 鈴木雄介

–グロースエクスパートナーズ（株）

» 執行役員

» ビジネスソリューション事業本部本部長

» ※がちのエンタープライズ

–略歴

» ユーザー系システム子会社で保守とか開発とか（5年）

» オンラインマーケベンチャーでプログラマとか（2年）

» フリーランスでITアーキテクトとか（3年）

» GxPでSI事業の部長とか（7年）

▸ 日本Javaユーザーグループ会長（2年）

1


心構え

• アジャイルが好きな時もありました

• アジャイルが嫌いな時もありました

• アジャイルがどうでもいい（でも気になる）時もありました

• いまはアジャイルといい距離な気がします

• なので、今の「俺のアジャイル」を話します

2


話したいこと

• まずは「ソフトウェアを作る」こと

• そして「アーキテクチャとマネジメント」

• そのうえで俺が見ている「アジャイルとは」

• 最後に「いまやっていること」を話して終わり

3


ソフトウェアを作る

4



• ソフトウェア品質モデルから考える

5

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

影響を与える

依存する



• ソフトウェア品質モデルから考える

6

特徴例

利用時の品質・利用状況によって評価が異なる

・ユーザーＡさんとユーザーＢさんで評価が異なる

外部品質・システムの振る舞い・誰がテストしても同じ結果・一般的な仕様策定の対象

・テストケース・外部仕様

内部品質・システムを構成している要素すべて（含ドキュメント）

・後に残り、評価が可能・エンジニアがこだわるところ

・クラス図・フレームワーク・ドキュメント

プロセス品質・後に残らない行動・コミュニケーション・作業手順



• 最近は「サービス」まで考えるのが大事

–ユーザビリティ、UI/UX

–リーン、エクスペリエンスマップ、ユーザーストーリーマッピング

–ようは、利用時の品質を積極的に管理していくこと

–でも、「それだけ」が大事なわけじゃない

7



• 品質相互の関係が良好であることが大事

–個々の品質だけではない

8

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

影響を与える

依存する



• 品質相互の関係を良好にするのは大変

–納期は間に合ったけど、いまいち出来が良くない

–理想はいいんだけど技術的に実現性がない

–使い勝手は悪くないけど、保守性がボロボロ

• 大きな開発だとチームで考えないといけない

–だから、アーキテクチャが大事

–だから、プロジェクトマネジメントが大事

9


アーキテクチャとマネジメント

10



• アーキテクチャとは

11

IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）



12

利害関係者の関心事ビューポイント

ビュー

ミッション

システム制約（環境）

モデルによって記述



• アーキテクチャとは

–システムのミッションに従い、システムのおかれた制約を前提としながら

–システムに関わる複数の利害関係者の関心事を整合させ、

» 経営者、オーナー、ユーザー、プログラマ、 DBA、インフラ屋、PM、上司、保守メンバー

–ライフサイクル（設計から保守）まで意識した

–システムの分け方と組合せ方のこと

13



• プロジェクトマネジメントとは

–計画すること

–計測すること

–調整すること

• 「計画と実行のズレを見つけて調整していく」

–そのために計画するし、計測する

14



• ちなみにPMBOK

15

立ち上げ計画遂行コントロール終結

統合計画策定計画実行統合変更管理

スコープ（目的と範囲）

立ち上げスコープ計画/定義スコープ検証/変更管理

時間（期間）アクティビティ定義/順序設定/期間見積スケジュール作成

スケジュールコントロール

コスト（予算）資源管理コストの見積/予算化

コストコントロール

品質品質計画品質保証品質管理

人的資源組織計画要員調達

チーム育成

コミュニケーション

コミュニケーション計画情報配布実行報告完了手続き

リスクリスク・マネジメント計画リスク識別定性的/定量的リスク分析

リスクの監視・コントロール

調達調達/引合計画引合発注先選定契約管理

契約完了

計画実行調整



• アーキテクチャとマネジメントの違い

16

アーキテクチャマネジメント

目的プロジェクトの目的を技術的に表現する

プロジェクトの目標を達成する

手法予測し、方向性を設定する

計画し、計測し、調整する

成果対象物の分け方と組み合わせ方

プロジェクトの成果物そのもの

行動事前的に決定事後的に対応



• 品質相互の関係を考えるのに必要

–アーキテクチャは「何がどうできてるか？」

» 利用時→外部→内部→プロセスと考える

–マネジメントは「ちゃんと作れてるか？」

» プロセス→内部→外部→利用時と考える

17

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質



• アーキテクチャとマネジメントは大事

–チームで仕事するなら「とりあえず好きな流行の技術を選択」も「思いつきの計画変更」もありえない

–とはいえ、考え過ぎても分からないことはある

» ソフトウェアの適用領域が広がり、要件が複雑化

» オープン化・標準化による技術要素の複雑化

» エンジニアのスキルの多様化・規模の肥大化

–では、どうすればいいのか？

18


アジャイルとは

19



• 広義には”態度”

–アジャイルソフトウェア開発宣言（2001年）

» プロセスやツールよりも個人と対話を

» 包括的なドキュメントよりも動くソフトウェアを

» 契約交渉よりも顧客との協調を

» 計画に従うことよりも変化への対応を

–当時の時代背景が透けて見える

» プロセスやドキュメントや契約や計画が重要だったころ

20



• 狭義にはプロジェクトマネジメント”手法”

–ソフトウェア開発では「計画精度をあげて調整の無駄を無くそう」が難しい

» 製造業に比べると、目に見えないので計測がしにくい

» 製造業に比べると、調整コストが小さい

–なら、調整を前提にすればいい

» 小さく計画→動くもので確認→新しい計画＝調整

» 顧客を巻き込んで調整する

» 計画は定期的にする

21



• ”手法”としては画期的

–プロジェクトマネジメントにありがちな失敗

» 計画の失敗：計画の精度が悪かった

» 計測の失敗：進捗を測り間違えた

» 調整の失敗：方向修正する話し合いができなかった

–だから、アジャイル手法は

» 計画：精度が出るぐらい小さな計画にすればいい

» 計測：動くソフトウェアで計測すればいい

» 調整：定期的にみんなで見直すことにすればいい

22



• アジャイルは素晴らしいが課題はある

–１．全体整合性の軽視

» 主に「アーキテクチャの軽視」につながる

» 「考えすぎは良くない」だけなのに“象牙の塔のアーキテクト”に対する嫌悪感から事前的な設計を軽視しがち

▸ アーキテクチャを後から直すのはコストがかかる

» 日本の優れたアジャイルエバンジェリストって優れたエンジニアばかりで「言わなくても当然」だった

–２．「言い訳」に使う人が出てきてしまう

23



• アジャイルを「言い訳」に使う

–アジャイルは不確実性に立ち向かうための道具

–より良いものを作るための覚悟

» 不確実だけど、より良い選択をするんだという覚悟

» 顧客や仲間と対話して向き合うという覚悟

» 最初はダメでも、いつかは良くするという覚悟

–覚悟がない人間が使うと、ただの「言い訳」になる

24

Copyright© Growth xPartners, Inc. All rights reserved. 25

アジャイルのダークサイド

https://www.flickr.com/photos/soulnoire/3217872979/

他者への傲慢や軽蔑不確実性からの逃避責任回避

https://www.flickr.com/photos/soulnoire/3217872979/



• アジャイルのダークサイド

26

よく使う言葉ダークサイド思考

顧客が欲しいものを作るダメなのは顧客の責任

あとで変更できる最初に決めるのが面倒

動くコードがすべて説明しても分からない

イテレーションごと計画全体にはコミットしない

自動デプロイしていますお前がテストしろ

優れたメンバーを確保委任契約でリスクは発注元



• 自分で運用する人は落ちにくい

–手を抜くと自分に降りかかってくるから、いやでも覚悟をしないといけない

–降りかかることが想像できずに落ちる人はいますが

• 運用をしない開発者とか偉い人は落ちやすい

–SIerとか

–情報システム部の部長とか

27



• ダークサイドに落ちないために

–まずもって「良いものを作りたい」という覚悟

» 不確実だけど、より良い選択をするんだという覚悟

» 顧客や仲間と対話して向き合うという覚悟

» 最初はダメでも、いつかは良くするという覚悟

–その上で、どう作るかにコダワル

» 「良いものを作るためにはどうすればいいか？」

» そうすれば「アジャイルで作ったか」は関係ない

28


https://www.flickr.com/photos/kaptainkobold/3186086975/

アジャイルを手放す



• 再び、アジャイルソフトウェア開発宣言

–プロセスやツールと個人と対話

–包括的なドキュメントと動くソフトウェア

–契約交渉と顧客との協調

–計画に従うことと変化への対応

• 俺は「どちらにも価値がある」と思う

–何に価値があるかは状況で変わる

30



• アジャイルであることは重要じゃない

–アジャイルでないことも重要じゃない

–良いものを作るためにアジャイルが適切であれば使えばいいだけ

• 与えられたもので思考停止しない

–とりあえずやってみようは良い

» 経験から学べばいい。何が課題かを考えればいい

–現実を無視しない

» 「これはアジャイルではあり得ない」と他責しない

31


いまやっていること

32



• 企業と持続的な開発モデルを実現しています

–弊社の主要クライアント

» 流通小売/1.3兆円

» 医療機器/3000億円

» 情報サービス/150億円(*)

» 通信/4.5兆円(*)

» 製造/9500億円

» 出版/400億円

–もちろん、しがらみは色々とあります

33



• 事例：情報サービス 1/2

–リリース後の3つのプロセス

34

対象タイミング意志決定特徴

新機能年に1,2回企画/設計/開発など、それぞれの段階で役員承認必要な時間をかけて合意形成

ウォーターフォール的

定期改善

年に4回(日付固定)

工数枠は事前承認。実施内容はバックログから優先順位で選択後に承認

アジャイル的(3ヶ月定期)

保守随時毎月定額保守。実施内容はシステム本部内で決定。問合対応、障害対応、ちょっとした改善など

いわゆる保守(2週間定期)(緊急あり)



• 事例：情報サービス 2/2

–顧客組織内での改善が素晴らしかった

» 特に組織間のコミュニケーション

» 結果として、組織がプロダクトオーナーの役割を果たせた

–ちなみに、リモート開発体制で完結

–詳細はこちらに

» 「組織をプロダクトオーナーにする、ということ」

▸ http://arclamp.hatenablog.com/entry/2014/08/05/151250

35

http://arclamp.hatenablog.com/entry/2014/08/05/151250



• 事例：通信

–オンサイトでスクラムを採用して開発

» 最近、無事にサービスイン！

» でも、いろいろな成功と失敗があった

» そして、組織内の誰でもがアジャイルの態度や手法でやれるわけではないことに気づいた

–他の部署に展開していくために

» アジャイルに向けたステップを用意する必要がある

» 組織の文化に沿って、やり方を定型化する

▸ 設定中：プロセス、成果物定義、完成基準…

▸ ちゃんとお仕事をするために必要なものはそろえる

36



• 組織に最適なITマネジメント手法を見つける

–チームから組織にスケールを変えていく

–一番重要なのは組織が判断するペースに合わせる

» 企業によって異なるけど「3か月定期」がいい感じっぽい

» Enterprise Agileってやつ？？

» まだまだ試行錯誤をしています

–手法を見つけることにはこだわるけど、既存の手法で満足することはない

» その手法がなんと呼ばれるかに興味はないです

37



• ITで、世の中をもっと良くしたい

–でも「ITだけ」では変わらない

–社会基盤を担うような組織に、ITの使い方を変えてもらわないといけない

–だから、エンタープライズの「現実」を受け入れる

–「今の現実」を変えない限り、未来は変わっていかないから

» そのための”手段”や”手法”は何でもいいと思う

38


まとめ

39


まとめ

• ソフトウェアを作るのは簡単じゃない

–それぞれの品質の関係を考えることが大事

40

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

影響を与える

依存する


まとめ

• アーキテクチャとマネジメントは両輪

–アーキテクチャは「何がどうできてるか？」

» 利用時→外部→内部→プロセスと考える

–マネジメントは「ちゃんと作れてるか？」

» プロセス→内部→外部→利用時と考える

41

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質


まとめ

• アジャイルは優れている

–態度としても、手法としても素晴らしい

–プロジェクトマネジメントにありがちな失敗を逆転の発想で切り抜ける

» 計画：精度が出るぐらい小さな計画にすればいい

» 計測：動くソフトウェアで計測すればいい

» 調整：定期的にみんなで見直すことにすればいい

–でも、完璧なわけじゃない

» 片輪のアーキテクチャをお忘れなく

42


まとめ

• アジャイルのダークサイド

–不確実性を受け入れる覚悟がない人にとっては、自分に責任が来ないようにするための言い訳

–偉い人とか運用をしない開発者が落ちる

» 自分で運用しなきゃいけない人は落ちにくい

• 落ちないために「アジャイルを手放す」

–どう作るかではなくて、何を作るべきか

–与えられたもので思考停止しない

–現実から逃げない

43


まとめ

• 組織が、より良いITサービスを作るために

–会社にとって大事なものをマネジメントするのに、”ある1つの優れた方法”なんかない

» たとえば人事制度って企業の文化が反映されますよね

–だから、”ある手法”へのコダワリを手放して、より最適な手法を考えたほうがいい

–どう作るかではなく、どこに至りたいのかを考える

» そのために何をすべきかを考える

44


あなたが考える

https://www.flickr.com/photos/sudhamshu/3202963823/

https://www.flickr.com/photos/sudhamshu/3202963823/

Technology

XP祭り2014「アジャイルを手放して得られたこと」