"Agile Conference 2013"参加して来ました。
【主催】
株式会社テクノロジックアート
【イベントページ】
http://pw.tech-arts.co.jp/act2013/
セクションごとに下記の通りまとめました。
このイベントではカンバンがメインテーマになっているように感じました。
[基調講演]戦略としてのカンバン: ビジネスイノベーションのために
概要
現在のビジネスの状況から継続的なイノベーションの必要性を紹介。
そのような状況の中でイノベーションを促進するためのカンバンを紹介。
内容
カンバンは可視化ツールである。
- プロセス監視ツールとしてのカンバン
タスクをTodo/Doing/Doneに分類して可視化するなど。 - イノベーションツールとしてのカンバン
メンバーのアイデアやビジネスのNeeds/Seedsの可視化など。
カンバンを運用していく際に注意すべき3つの原則。
- 原則1:ストーリーを知っていると仮定しない
ストーリーは課題を解決する手段の1つでしかない。
常に課題を見つめ直すことが大切。 - 原則2:適切な人たちを関与させる
決定に責任を持てる人、危機感を持った人の参加は必須。
デザイナー、エンジニア、ユーザーなど必要な人も最初から関与させる。 - 原則3:実行と確認をできるだけ頻繁に行う
現場意識を大切にする。現場を見る機会を作ること。
カンバンを運用するために必要なこと。
- 新しい機会に取り組むリズム、組織の文化を作る。
- さまざまな種類のイノベーションが役立つことを知る。
ビジネスモデル、デザイン、テクノロジーなど。
カンバンの詳細は下記書籍で紹介されている。
- 作者: David J. Anderson
- 出版社/メーカー: Blue Hole Press
- 発売日: 2010/04/07
- メディア: ペーパーバック
- この商品を含むブログを見る
所感
イノベーションの種を見える化するためのツールとしてカンバンを使えるようです。
もちろん、カンバンを使えばイノベーションが起こるわけではなく、組織文化など変えなければならないところや課題はやっていく中でたくさんあると思います。
Web系・SIerに関わらず、お客様をイノベーションの中にどのように関わらせていくかが大切だと感じました。
[Session1]アジャイルな企業のTo Beモデルを提示するScaled Agile Framework (SAFe)のご紹介
概要
アジャイルを開発チームを超えて、企業全体(企画や投資判断から)への適用を推進していくツールの紹介。
内容
ツールは次の3階層で構成されている。
- ポートフォリオ
企画・経営判断を行う。 - プログラム
チーム間の依存関係を少なくする。
チーム間でスプリント間隔を合わせる。
チーム間の同期を頻繁にとる。 - チーム
Scrumをベースに実施。
ツールのプロダクト開発フローには次の概念が取り入れられている。
所感
依存関係をなくし、イテレーティブに開発を勧めるためにはチーム間のスキルギャップを少なくする必要があると思います。
そのようなチームを構成できるか、どのように折り合いをつけるかが問題になってくると思います。
[Session2]スクラムと品質
概要
「品質」をキーワードにスクラムの枠組みとスクラムの実践事例を紹介。
内容
品質の違いについて。
-
製造業の品質:購入時の品質が最も高い。
-
サービス業の品質:運用していく中で品質が向上していく。
品質は後から挽回するのは難しい。
最初から品質が悪いものを作ろうとする人はいない。品質が悪くなる要因は次の2つ。
- オーバーコミットメント
- 階層的な組織構造
階層的な組織でオーバーコミットメントしてしまうと、「スコープ」「スケジュール」の修正が一切出来なくなってしまう状況に陥りやすい。
品質を確保するためには。
- リリースのための完了基準を事前に定義する。
- リリースまでに必要なプロセスを定義する。
プロセスとは「誰にどのようなフィードバックを得る必要があるか。」を定義すること。
所感
品質の観点でウォーターフォールとアジャイルを比較すると、次のように言われることが多いと思います。
日本の製造業では各工程で品質を作り込んでいると言われており、その観点で見るとアジャイルの方が高品質なプロダクトを生産できると思います。
また「コードの品質が低いので、現行に手を加えるよりも、一から作り直した方が早いです。」なんて話はよくある話で、品質を後で挽回するのは非常に難しいと実感しています。
[特別講演]エンタープライズ規模におけるカンバンの運用
概要
TPS(Toyota Production System)とTMS(Total Management System)とその中で運用されるカンバンの紹介。
内容
上司のマネジメントを「部下に成果を上げさせるための管理」と定義。
チーム内でSECIモデルを回すことで、価値観・プロセスを共通化させることができる。
それぞれの部署で見える化を行なっていれば、自然と部署を超えて共有が始まる。
最終的に、すべての部署を巻き込んでアジャイルな価値観の共有が必要。
改善活動にKPTは有効。改善に必要なことは次の4つ。
-
ヒトづくり
-
共通な価値観
-
共通な仕事の仕方
-
全社で顧客価値を追求
改善活動の初期段階では組織に問題点を上げる文化があるかどうか確認することが大切。
もしそのような文化がなければ、会社や業務に関係のない身近な問題点を上げるようなワークショップを行い、問題点を上げられる文化を作っていく必要がある。
所感
Redmine等のデジタルなツールだけ使っていると、アジャイルチームがどのように活動しているのか他チームの視界に入らず、あまり共有されません。
その点、アナログなツールを使えば、自然とアジャイルチームの活動が視界に入り、アジャイルチームの活動が目につくようになると思います。
アナログなツールにはこのようなメリットがあるため、アナログなツールも併用することで、アジャイルチームの活動が他チームへの普及していくのではないかと思います。
[Session3]大規模分散アジャイルを支えるプラットフォーム
概要
大規模開発案件でのアジャイル開発とそれを支える3つのプラットフォームの紹介。
内容
IBMでは大規模開発案件が多いため、ツールやインフラなどのプラットフォーム整備への投資が重要になってくる。
所感
Googleもプラットフォーム整備への投資を積極に行なっていると、下記書籍に記載されています。
- 作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2013/05/23
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
Googleの書籍でも言われていましたが、プラットフォーム整備専任のチームを作るようになるとプラットフォーム整備が目的となってい、本来の目的であるビジネス成功への意識が薄れてしまい事がよくあります。
直接ビジネスへの影響を与えない間接部門を作った時には、いかに現場意識を取り込んでいくかが課題になると思います。
[Session4]コンパクトなチームでのアジャイル開発とその実践
概要
自社サービスを提供している「シャノン」がどんなツールを利用して、具体的にどのようにアジャイル開発を実践しているかを紹介。
内容
アジャイルは開発プロセスにのみフォーカスされていたが「企画・開発・運用」にもフォーカスしていく必要がある。
少人数で「企画・開発・運用」を俊敏に行なっていくためには、テクノロジの理解とツールを上手にコラボレーションさせていく必要がある。
4つのツールを紹介。
1.Pivotal Tracker
-
ストーリ管理ツール。
-
Scrumの開発に最適。
-
Bugzilla/Githubとの連携可能。
-
各ストーリーにエピックを付けてまとめられる。
-
リリース時期をベロシティから自動で算出。
-
アナログなツールと併用して使用している。
2.github
-
パフォーマンスが良い。
-
勝手にコミットされることがない。(Pull Request)
-
ブラウザでdiffを確認できてコードレビューが容易。
-
変更の行単位でURLが振られているのでコードレビューが容易。
-
フォークして個人で自由に変更できる。
3.Jenkins
4.Heroku
- インフラ知識がなくてもよい。
- Gitコマンドだけで開発、ステージング、本番環境の構築が可能。
- 簡単にCPUプロセスを増やすことが出来る。(AWSよりも楽)
- DBバックアップのアドオンが無料。
- パフォーマンス、エラー、セキュリティ監視を行える。メール通知も可能。
- パーフォマンス分析も無料。メソッドやSQLが一覧表示される。
所感
ツールの詳細部分まで説明いただき参考になりました。
フリーのツールは積極的に使っていき、使えるものは全体に広めていくという好循環を生むための組織作りに関心を持ちました。
[Session5]事例から見るアジャイルの失敗と成功
概要
日立ソリューションズのアジャイル適用の考え方と、アジャイルの成功と失敗事例からアジャイル成功のポイントを紹介。
内容
アジャイル適用の考え方
- 目的を明確にする
アジャイルは手段で目的ではない。課題を明確にし、優先順位付けを行う。 - プロセスは目的や状況に応じて使い分ける。
・アジャイル
・ハイブリッドアジャイル:要件定義・基本設計はWF。開発・テストをAgile。
・プロトタイピング:要件定義時にプロトタイプを見せる。 - 使用するプラクティスも目的や状況に応じて使い分ける。
成功事例から学んだ成功のための要因
- 意思決定者が社内にいて意思決定のスピードが早い。
- 要件定義時から画面を見せる。
- 変更を初めから予測できる。
- アジャイルの教育を実施する。
- お客様が何を望んでいるのか明確にする。
- 変更が発生した場合は受け入れ(完了)基準を設定する。
失敗事例から学んだ成功のための要因
- アジャイルの専門家をチームに最低一人は配属させる。
- 初めから無理な工数の案件は受注しない。
- 担当者任せなコーディングは行わない。低品質になってしまう。
- 保守を考慮してドキュメントを作成する。
- 書籍通りの開発プロセスを導入するのではなくチーム内で開発プロセスを検討する。
所感
SIerにアジャイルを導入した事例を生々しくお話いただきました。
現在上手くいっている手法の中では、お客様の変更要望の規模を事前に見積もって、イテレーション内でその見積もり分をバッファとして確保しているようです。
お客様としては予算変更なく、変更を上げられる事はメリットだと思いますが、バッファを持ちつつプロジェクトを進めることには違和感を感じます。
なぜなら、バッファを持ってしまうと、学生症候群でメンバーが最大限の能力を発揮しないと考えるからです。(※学生症候群については下記書籍参照)
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
- 作者: エリヤフゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2003/10/31
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 142回
- この商品を含むブログ (118件) を見る
バッフォを持たずに、チームのベロシティ(実績に基づく能力)、スケジュールの範囲で最大限の力を発揮して出来る範囲のプロダクトを作り上げるプロセスがアジャイルだと考えています。