XP祭り2014「アジャイルを手放して得られたこと」
Upcoming SlideShare
Loading in...5
×
 
Like this presentation? Why not share!

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

on

  • 727 views

2014/9/6に開催されたXP祭り2014での講演B-4 「アジャイルを手放して得られたこと」

2014/9/6に開催されたXP祭り2014での講演B-4 「アジャイルを手放して得られたこと」
鈴木雄介

Statistics

Views

Total Views
727
Views on SlideShare
700
Embed Views
27

Actions

Likes
7
Downloads
8
Comments
0

2 Embeds 27

https://twitter.com 21
http://arclamp.hatenablog.com 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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/