2009/04/22 Agile Japan 2009 参加レポート

更新日:

本日行われたAgile Japan 2009に参加してきたので、
会場でその場で取った参加レポートを公開します。

なお、今日以降、スピーカーの許可がおりたセッションについては、
下記URLにて資料が公開されるとのことです。

http://www.agilejapan.org/

日時場所

  • 2009/04/22(水) 09:30-17:20 千代田放送会館

9:30-10:30「ソフトウェア開発現場に求められる新しいリーダーシップ ~アジャイルに見る大野耐一、デミングの影響~」

  • Taylorの視点
    • 仕事をブレークダウンして、一番良い方法を見つける
  • 職業訓練の4ステップ
    1. 準備
    2. やってみせる
    3. やってみる
    4. フォローアップ
  • 「生徒が学ばないのは、先生が教えてないのだ」
  • アレンのアプローチ
    • 仕事の教え方
    • 改善の仕方
    • 人の扱い方
  • TWI監督者訓練(Training Within Industry for Supervisors)の基本理念
    1. 人間性の尊重
    2. 無駄を取り除く
  • 良い監督者の5つのスキル
    1. その仕事自身についての知識
    2. 責任と役割についての知識
    3. 教えるスキル
    4. 手法を改善するスキル
    5. リーダーとしてのスキル
  • トヨタ生産方式
    1. ジャスト・イン・タイム
    2. 自動化
    3. たゆまぬ改善
  • 現場経営:標準
    1. 標準というのは、刻々変わるべき
    2. 標準が最善だと思ってはダメ
    3. 現場を改善することが必要
    4. 標準作業を作る際、ベストのモノを書こうとしなくてよい
    5. 標準作業を作る際、今やっていることをそのまま書くのがよい
    6. 最初に標準を作り、その後改善を行っていけばよい
    7. 「決められた」ではなく「決めた」と表現するほうがいい
    8. まず標準作業をやってみて、改善案が出たら、次からはそっちを標準にすればよい
  • エドワード・デミング博士「深遠な知識」のシステム
    1. システムの正しい理解
    2. 変動についての知識
      • ほとんどの変動は「一般原因による変動」はシステムに内在している
    3. 知識の理論
    4. 心理学
  • 成功を導くマネジメントの基本原則
    1. 部下に自己の能力をフルに発揮できる環境を与えること
    2. 会社の利益先行という古い考えは捨てるべき
  • 標準について
    1. 標準とルールはもともと不完全なもの
    2. 定期的なレビューと改善により、どんどん良くなっていくもの
  • 有名な話 in イタリア
    • 3人の石切工に質問「何をやっているのですか?」
      1. 石を切っています
      2. 生計を立てるために働いています
      3. 聖堂を造っています
  • 人間性の尊重
    • 責任と意志決定を、出来る限り最下層に移動すること
      • 最下層の人が自分の意志で仕事をしているか
        1. 文句を言う(石を切っている人)
        2. 無視する(生計を立てるために働いている人)
        3. 自分で治す(聖堂を造っている意志がある人)
ボトムアップ(開発型) グループファシリテーター 学習する組織の創り手
"みなさんの力で!" "目的と方向性はこうです。一緒にやろう!"
トップダウン(指示型) 官僚的管理者 作業管理者
"決まりに従え!" "これをこうやります。さぁ、やってください"
一般的な管理技術
  • Leadershipの3つのモデル
    1. 古き独裁者スタイル「私のやり方で」
    2. 1980sエンパワメントスタイル「あなたのやり方で」
    3. リーンスタイル「着いてきて、一緒に考えよう」
  • トヨタでのリーダーの仕事
    1. 先生としての役割
    2. 一人ひとりが主体的に問題解決し、仕事を改善するように指導
    3. 一人ひとりの仕事が、「顧客の価値」と「会社の繁栄」の両方に価値提供するように、必ず整合させる
    • 「自分で考えろ」自分で考えたのかを重視
  • トヨタのチーフエンジニア
    1. ビジネスの成功に責任を持つ
    2. 顧客の深い理解を構築する
    3. 製品コンセプトを開発する
    4. 上位レベルのシステムデザインを作る
    5. スケジュールを設定する
    6. 顧客の価値を理解し、日々のトレードオフを行うエンジニアにその理解を伝達する
    7. 必要なときにトレードオフを調整する
    8. ビジョンを維持する
  • リーダーの役割
    1. Champion
      1. マーケティングリーダー
      2. テクニカルリーダー
    2. 機能リーダー
    3. プロセスリーダー
      • 機能リーダーに吸収される
    4. プロジェクトリーダー
      • Championに吸収される
  • トヨタ自動車会長
    • 「システムを変えていく人」のシステムを作ることが必要
  • システムを変える
    • TPS(Toyota Production System)(Thinking People System)
    1. ジャスト・イン・タイムの流れ
    2. ライン・ストップの文化
    3. たゆまぬ改善
    4. 人間性の尊重

その場その場で考えて、変えていける人を作ることが重要。
それは何もアジャイルである必要は、実はない。

10:30-11:35「ソフトウェア開発に活かす、トヨタ生産方式モノづくりヒトづくり(仮題)」

  • 考えていることをオープンにしよう
    1. 一人が考えていることは、実はたいしたことない、
    2. いろんな人が支え合って、もっと良くなっていく
  • オープンにすることと、教えることは別
  • トヨタの現場におけるコンピュータは「オンライン」「リアルタイム」だった
    • 実際のモノに情報を乗せていた(トレーサビリティと呼ばれるもの)
    • IBMが後から「バッチ処理」と言ってきたが、現場は受け入れなかった
  • 自分たちのやり方の哲学を持つべき
  • トヨタの人達は、アンテナを広くして勉強はするが、採用はしなかった
  • トヨタは、石橋を叩いても渡らないような会社
  • ソフトウェア開発は「リーン/アジャイル型」に移行すべき
  • アジャイルという言葉は、「21st Century Manufacturing Enterprise Strategy」の1991年のレポート(リーハイ大学のアイアコッカ研究所)が起源
  • ハイテクよりも人間性尊重、人間力が生産性の決め手
  • 情報システム自身のムダは45%
    1. 徹底的なムダの排除
    2. お客様の引き
    3. 見える化
    4. 情報の先出しはしない
    5. 標準化(標準作業)
    6. ラインストップ
    7. 自律分散
  • トヨタのビジョン2001
    1. 知恵と改善
    2. 人間性尊重
  • トヨタのDNAとは何か
    1. お客様第一主義
    2. 現地現物
    3. 技術・生産の現場とヘッドオフィスが隣接
    4. 人材育成に注力
    5. 変革のエネルギー
    6. 危機意識の強さ
  • 今日のメッセージ
    1. ルールやノウハウより、「なぜ」が重要
    2. すべての経済活動(生産活動)は「人間・機械(ICT)系」
    3. TPSの本質は方法論やテクノロジではなく、人間力、現場力
    4. TPS/Lean/Agileのノウハウを知る(知識)のレベルから、TPSの本質、腹に落ち「実践できるレベル」へ
    5. 常にあるべき姿を目指し「改善」し続ける人間集団を創り上げる
    6. 課題解決、問題発見改善・改革力(人間力・現場力)、人と和の道
  • 人はいかなる時に充実を感じるか
    1. 自律
    2. 責任
    3. 達成
    4. 適性
    5. 仕事そのもの
    6. 向上
    7. 評価

経営層は細かいことをいちいち伝えるより
「なぜそれをしなければならないのか」という理念を伝える努力をすべき。
現場の人達が自主性を持って、改善を自発的に出来るような環境を維持すべき。

ベクトルを合わせることが重要、そのために毎朝ミーティングすることも大事

見える化をすることで、改善が生まれる

何十枚ものプレゼンテーションで説明するより、A3用紙一枚で説明せよ

11:35-12:10 パネルディスカッション

  • TPS/Lean - Agile translation
    1. PULL (プル生産)
    2. Flow (流れ)
    3. Jidouka (自動化)
    4. Kaizen (改善)
    5. Genchi-Genbutsu (現地・現物)

Q&A

  • [Q} 学習する組織を実現するための方法論として、どのようなものがあるか
    1. [A] 仕事の内容を押しつけるリーダーがいない(メアリー)
    2. [A] 現場に考える機会を与えることが重要(メアリー)
    3. [A] 自分で考えなさい、聞いてもだめ、HowToよりもWhy(黒岩)
    4. [A] いちいち許可を取らずに、まずはやってみなさい(平鍋)
  • [Q] アジャイルとプロトタイピングの違いは何か
    1. [A] アジャイルやTPSは決して宣伝する話でもない(黒岩)
    2. [A] 表層的なことではなく、本質的なことをやることが大事(黒岩)
    3. [A] 明るく楽しくやるソフトウェア開発(黒岩)
    4. [A] プロトタイピングは手法、アジャイルとは普段から改善を行うという意識(黒岩)
    5. [A] アジャイルは、ソフトウェアを育てる、作ってから学ぶ、テストする、そしてまた作る(平鍋)
    6. [A] アジャイルは、学んだことをテストとして覚えさせて、テストを育てていく(平鍋)
    7. [A] プロトタイプは、作って、最後にテストをして、そして捨てる、ドキュメントはムダに作る(平鍋)
  • [Q] 人間力が大事、フィードバックが大事、現場でおかしな事が起きているのは認められていないから、目に見えないモノを認めてもらえない、見える化が大事、これからは見えないものを現場で活用していく為に何が大事ですか
    1. [A] 何年もソフトウェア業界にいて、コンピュータ相手に活動していると、脳みその一部しか使わなくなって、視野が狭くなってしまっている(黒岩)
    2. [A] 自分の脳みそ全体を使うために、左脳も右脳も使っていく為に、いろんなことに興味を持ち、コミュニケーションを取ることが必要(黒岩)
    3. [A] コンピュータ相手にしている人は、左脳人間(黒岩)
    4. [A] 両手を握ったとき右手親指が上だと左脳、左手親指が上だと右脳(黒岩)
    5. [A] 見えないものを見えるようにして改善していくことが大事(黒岩)
  • [Q] 海外から来たなんとかかんとか・・・?質問よくわからず
    1. [A] チームみんなで良くする文化が日本にはあった(黒岩)
    2. [A] 経営者にこそ、現場による改善の必要性を認識してもらう必要がある(黒岩)
    3. [A] 当時の成果主義、マネジメントがあるが、安定したシステムでは目標などを管理する必要はある(メアリー)
    4. [A] アジャイルを阻害するような不安がある、そこを変えていかないと行けない(平鍋)

12:10-13:10 ランチ

13:10-13:50 事例セッション

  • 問題そのものが、スピードがあることでなくなってしまう(前川)
  • IT戦略・求める人物像
    1. 「自社の構想力を高める」のか否か ・・・売上/利益を増やす、コストを減らす
    2. すべてに100%を求めない ・・・成長できる構造、変化のスピード
    3. リスクヘッジではなくリスクテイク ・・・問題解決力、突破力
    4. 本質的な要件定義力を持つ ・・・設計力

ユニケージ開発

  • 「安く、早く、柔らかく」がキーワード
  • パッケージ(機能があらかじめパッキング)に比べて、ユニケージ(UNIX Uniq Unify)はスクラッチ開発の高効率化手法。
    1. コストを「安く」
      • 安いハードウェア(PCベース)
      • 安いOS(Linux)
      • 安いアプリケーション(シェルスクリプト)
      • 安いデータ管理(テキストベース)
      • システム更新なし(移植性抜群)
    2. 期間を「早く」
      • 短いアプリケーション
      • 試作型「テキストデータがあればすぐ作れる」
      • 情報系、業務系、更新系、すべてシェルスクリプト
      • オールインワン方式(シェルの依存関係を作らない)
    3. 「柔らかく」
      • ハード・ソフト・データの完全分散型配置(コンピューターズ・コミュニティ)
  • ユーザ一体型開発
    1. 業務とシステムは表裏一体
    2. システムは業務にある
    3. 業務を理解している人は、システムを語り、コンピュータを理解するよう努める
  • 非分業の原則
    1. 分業しない(=すべて自分で出来る)に越したことはない
    2. 自分でやってみると失敗する。失敗から学ぶ
  • ソフトウェアは料理と同じ
    1. 性格に仕様を記述できない
  • 日本的アプローチと国際競争力
    1. 日本は成熟した資本主義国家
    2. 単なる構造やフォーマットの違いで、企業が勝負する時代は終わった

14:00-14:30 アイスブレイク「チーム力をつくる1stSTEP」

  • 「人と組織の活性化」について、笑いあふれる参加型研修
  • 「チーム力をつくる3ステップ(翔泳社)」
  • チーム力をつくる
    1. 対立なく一緒に学ぶ事が組織
    2. 成功体験のいい循環を作る
    3. 価値の創造
    4. コミュニケーションは大事
      • 場の雰囲気を和ます
  • アイスブレイク
    • コミュニケーションの場ではりついた場を緩める
    • しゃべりやすい雰囲気づくり
  • アイスブレイク
    1. 息を吐く、笑う
    2. 自信を持つ
    3. 協働体験
    4. 相手への理解
    5. その他
  • ポイント
    1. 無碍に否定しない

14:30-16:10【スキル セッション】

16:00-17:25 クロージングセッション

  • カマスの実験
    1. 透明な壁に何度もぶつかると、透明な壁がなくなっても、餌を食べに行かなくなる

開発チームとマネージャの緊張関係

  • マネージャ(上司・営業)と開発チーム(部下・プログラマ)の間には、なにかやはり透明な壁を感じますな
  • (アジャイル)開発チームに対する誤解
    1. 個人で好き勝手
    2. 組織の成功を軽視している
    3. コードを書くことがすべて
  • 開発チームの成功モデル
    1. 組織的な成功
      • 計画の改善
      • ムダの削減
      • ROIの向上
    2. 技術的な成功
      • 技術的卓越
      • 高度なプラクティス
      • 開発の仕組み
    3. 個人的な成功
      • 生活の質の向上
      • 挑戦
      • やりがち

個人的な成功なくして、組織の成功はない

  • マネージャに対する誤解
    1. 組織のルールでがんじがらめ
    2. 人間を軽視している
    3. 売上と利益がすべて
  • マネージャの成功モデル
    1. 仕事の論理(生産性)
      • 管理手段・基準
      • プロセスの統合
      • 仕事の分析
      1. プロセス維持
      2. プロセス編成
      3. 道具の準備
      4. 順序立て
      5. 洗い出し
    2. 労働の力学(生き生き)
      • 経済・政治的次元
      • 社会的次元
      • 心理的次元
      • 生理的次元
      1. 人間関係
      2. 生活基盤
      3. 自己実現
      4. 労働の多様性
      5. 仕事のリズム

「生き生き」なくして生産性の向上はない

  • 緊張緩和に向けて
    1. お互いに、成功モデルの本質は同じであることを知り、歩み寄る
  • [Q] うちのマネージャーは、とてもそんな成功モデルを持っているとは思えないんですけど
    1. [A] ちゃんと話したことある?
  • [Q] 開発プロセスは規定だから変更できないとマネージャに言われたのですが
    1. [A] 開発プロセスだけがすべてではない。成功を目指すため、他に出来ることはない?
  • なぜ歩み寄れないのか?
    1. 実は、開発者はマネージャ(組織)に依存している
    2. 実は、マネージャは開発者に権限を渡したくない
    • 「透明の壁」を、相互に築いているのでは?
  • 「開発チーム」と「マネージャ」のWinWin
    1. 開発チームは主体性を発揮、マネージャは開発チームに権限と責任を委譲
  • 実例:アジャイル開発チームの立ち上げ
    1. 開発チーム:自分たちで、アジャイルを売りとした開発をしたい。
    2. まずは有志で合宿し、ビジネスの計画を作る。
    3. マネージャ:OK。合宿の予算は出そう。成功を楽しみにしている。
    4. ビジネスとして継続できることを検討して欲しい。
  • 実例:ETロボコンを通じた人材育成
    1. 開発チーム:会社の代表として、ETロボットコンテストに参加したい。
    2. 人材育成と、プロモーションの効果もある。
    3. マネージャ:気持ちはわかった。予算は出そう。
    4. 効果を将来につなげられるよう計画と実施を任せた。
  • 主体性を発揮する
    1. KentBeck: Social Changes Starts With You.
    2. Stephen R.Covey: 私達の行動は周りの状況からではなく、私達自身の選択によって決まるのだ『7つの習慣』
    3. Martin Luther: たとえ明日世界が終わりになろうとも、私はリンゴの木を埋める。
  • 開発チームに権限と責任を与えよ
    1. Peter Ferdinand Drucker: 仕事をいかに行うかを検討することは、働く者とその集団の責任である。仕事の仕方や成果の量や質は、彼らの責任である『エッセンス版マネジメント』
    2. Martin Fowler: アジャイルプロセスを外部から押しつけることは、アジャイルの心臓部とも言うべき「自発的決定」をチームから奪ってしまうことだ。
    3. 福沢諭吉: 人に束縛してひとり心配を求むより、人を放ちてともに苦楽を与するに若かざるなり
  • [Q] そんな主体性のある人、うちにいませんよ。
    1. [A] だから、育てるんです。
  • [Q] このご時世ですから、教育コストは出せませんよ。
    1. [A] 自分たちで、チームでの仕事を通じて、育てるんです。チームと人を。

チームの本質

  • チームとは何か
    1. 人を集めてグループにし、「チーム」と読んだとしても、それでチームができあがるわけではない。
    2. メンバーが各自持つさまざまなスキルを出し合って、共通の目的のために共同作業をする、というお互いの約束があってはじめて、グループはチームに変わるのだ。『リーン開発の本質』P155より
  • 依存的チームビルディング
    1. 誰かが「魔法の瞬間」を呼び起こすことを期待する
    • 『ワインバーグのシステム行動法』より引用
  • 主体的チームビルディング
    1. 自ら理想のチームを目指し、日々繰り返す試行錯誤
    • 『ワインバーグのシステム行動法』より引用
  • 「チーム」は最終状態ではなく、プロセスである。

チームビルディングの実際

  • 朝会
    1. 毎朝
    2. 15分だけ
    3. チームメンバー全員
    4. 立ったまま行う
    5. メンバー間のコミュニケーション
    6. 自分たちの問題を見逃さない
  • メンバーの主体性を引き出すために
    1. リーダーは場を仕切らず、話の聞き役に回る
    2. 司会役は持ち回りにする
  • KPTふりかえり
    1. 自分たちで問題を改善する
    2. 主体的で建設的な提案
  • タスクかんばん
    1. 日々のタスクをカードに記入し、サインアップ
    2. タスクは自分たちで管理する
  • キャラクターマップ
    1. 役割に対する期待感を見える化する
    • チームメンバーのキャラクターと役割をマッピングする
  • パーソナルナラティブ
    1. 期待感で主体的行動を促す
      • ナラティブ【narrative】
        • 物語。朗読による物語文学。叙述すること。話術。語り口。
    2. メンバーに期待する姿をとことん話す。
    3. 「ふりかえり」時の指標にもなる。
    4. メンバーからのフィードバックも大切。
  • ナラティブ使用上の注意点
    1. 人事考課との兼ね合い
      • この通り出来なくても、減点にならないことを伝える。
    2. 言われたとおりにしかやらない人への配慮
      • 本来は、主体的な行動を促すことが目的。
  • キックオフミーティング
    1. プロジェクトの説明
      • 目的・目標
      • 体制
      • 技術
    2. 期待感の表明
      • キャラクターマップ
      • パーソナルナラティブ
    3. 「魔法の瞬間」ではない。

自分がどのような態度で臨むかが重要。

開発チームとマネージャの成功モデル共有が重要。

「自分たちでやる」という姿勢が、リーダーシップを育む。

チームビルディングを通じて、主体性は育まれる。

17:25- 主催者の感想

  • イベントは、参加される方が作るものだ
  • 次回は、今日の参加者が成功体験を発表してくれると嬉しい
  1. 実行委員の紹介

-Blog

Copyright© fullvirtue.com プロダクトオーナー支援スペシャリストのBlog , 2024 All Rights Reserved.