■
ちょっと読む
図解ビジネスモデル・ジェネレーション ワークブック
posted with amazlet at 15.04.01
理想のチームに近づくためのふりかえりはどうやったらいいのだろう
ワタシはプロジェクトチームは自律して動けるようなチームが理想であると思っているし、自律して動けるということはチームをどう推進していけばいいのかメンバ一人ひとりが同じ方向に顔を向け、考えることができるから、だと思っています。
ただ、それはとても理想な状態のチームであって、理想にすぎません。だから、少しでも理想に近づくためにできることを少しずつ、一度に何でもやると中途半端になってしまうから、試行錯誤をするようにチームにネタを振るようにしています。
そうした一環の取り組みが<ふりかえり>をさせることなのです。
ただ、一方では先ずは<自立>してほしい、自分の脳で考えて試して欲しいと思い、ふりかえりはメンバだけでやってもらっていました。まだ、やっとメンバがふりかえりをできるようになった、と思うので敢えて<自立>の漢字をあてています。まだ、自分たちを律するまでには党夏していないのです。それはケプトをすることは大分習慣になってきたように見受けられるのですが、どうにもProblemでどうして続けたくないのか、どうして止めたいのかの<なぜ>まで辿り着けないようなところからも見受けられるのです。
それがあって、あるタイミングからふりかえりに介入するようにしました。
評論をしない。どうしてそう思ったかを訊く
ついついやり方のイメージを持っていたり経験をしていると、メンバがふりかえりのケプトのProblemで話しているときに批評のコメントをしてしまいがちです。でも、それは絶対してはいけないです。それをしてしまうと、誰も意見を言わなくなってしまうからです。このふりかえりの場は、そういったコメントをする場ではなく、メンバが自分たちで改善のネタを探す場なのですから。
だから、メンバがProblemを言ってくれたとき、その気づいてくれたことがなぜそう思ったのかもやもやしたままのときは、どうしてそう思ったのかを尋ねるようにしています。
どうしてそう思っった？
嫌だと思った原因はなんだか思い当たる？
本当にそれが原因なのかな？
もしかしたら、それが原因じゃなくて違う別の理由があるのでは？
ワタシはなんとなくProblemを話してくれているメンバのネタから多分あそこが原因なのだろうと辺りがついていたりすることが多いのですがそれでもあえてワタシからは直接は言わず、メンバに探してもらうように尋ねるのです。
それは、メンバが自分たちで改善を回せるように自分たちのふるまいを自分たちがやり易いように律して欲しいからです。
カンバンは期待と現実の差異を映す鏡
ある意味、カンバン至上主義なのでカンバンを使わないタスクの進捗共有とコントロールなんて考えられません。でも、ずっと前から使っていたわけじゃなくて、あるきっかけがあって使うようになったんですね。いや、つかわせるようにした、が正しいけれど。
カンバンへの期待
ワタシがカンバン好きだから自分で自分にバイアスを掛けているのかもしれないけれど、カンバンについてdisるのって聞いたことがないです。もろ手を挙げて「カンバンバンザーイ！」という印象しかないです。
じゃあ、カンバンを「ヤロウ！」と踏み切らせたカンバンへの期待はなんだったんだけ？というのを思い出してみたんですよ。
- 情報の視える化
- 情報の一元化
- 困っていることの顕在化
ひっくり返して言えば、カンバンを導入した、カンバンを使わせたプロジェクトではそれができていなかった、だけの話です。でも、それでプロジェクトは失敗するんですよね。
そうして、終わってみてから「コミュニケーションが悪かった。」とか、「情報共有をもっとすればよかった。」とか言うんですよ。こちらからしたら、「やりながら気づけよ。」なんですが。
ワタシから見たら、そんな状態＝コミュニケーションや情報共有が「出来ていない状況であることに気づけはいいだけじゃん？」で終わっちゃうんですがそうは言っても気づけない人がいるからそういうシチュエーションになるのであってそこのところはどうしたものか、と思っちゃうんですよ。
最初からカンバンやれ！って強制できれば話は簡単なんですけどね。
カンバンは体と頭と情報をリンクする
初めてカンバンを取り入れたプロジェクトでは、
という状況になっていたんですね。WBSであろうがなんだろうがプロジェクトのタスクをコントロール出来ていないで「何をどうしようとしていたんだ？」って話ではあるんですが。
良くあるのがそのまま何も変えずに「WBSでちゃんとコントロールしなさい。」って言うケースですが、それ、ムダだよね。できるならやっているんだから。出来ないから出来ていないんですよ。
仮にWBSでのタスクの管理をすることを理解していても実際出来ていないなら、それは頭の中とPC上での情報が把握できていないということになるでしょうし、そうだとするならいくらWBSを使えよって言っても出来るわけないですよね。
頭と体が一致しないなら一致できるような物理的な仕組みにする方が現実的だし、何より、カンバンを使って頭で理解していることと差異を知ることができるし、差異があるなら現物のカンバンを使って差異を修正することもできるわけです。
それって、頭で期待する想定と実際に現場で起きている事実の情報をカンバン上でリンクさせているってことなんじゃないかなーって思います。
カンバンいいですよ。カンバン。
リーンカンファレンス2014＠東京電機大学 に行ってきて学んだのは“ありたい姿”へのアプローチ方法だった #lean2014
名称 リーンカンファレンス2014 〜ヒット商品を作るための仮説検証プロセス - 日本でリーンを進化させる - 〜
日時 2014年01月28日 (火) 11:00 - 19:00
場所 東京電機大学 東京千住キャンパス １号館丹羽ホール
“リーン”のカンファレンスをやるよとTLで知って、速攻でエントリしたつもりが枠の最後の方で、募集定員を超えたら抽選とか。でも、当選したのでえっちらおっちらと北千住の東京電機大学まで。東京電機大学と言えば、千葉ニュウに校舎があったと思うんだけどそっちの印象しかない、と言うか知らないので初めてなんだな。TDUの北千住校舎は何より駅近でいい！
ところで、丸井側のスタバはすぐに見つけられたけど東武側のスタバはどこにあるのだろう。アクセス方法がわからないまま。
サマリ
TPSがTPS-1(トヨタ生産方式)とTPS-2(大野方式)の2流に分けられていたことを知る。改善も2種類あることを知る。金田先生の講演を聞いただけでも価値がある。なので、これかな。
“ありたい姿＝絶対不可能なこと”
オープニングの風景。
11:00〜12：00 【トヨタのカタとリーン製品開発】
講演者 稲垣公夫氏 ：ゴール・システム・コンサルティング 顧問、元NECアメリカ副社長
お約束の著書紹介。タイトルは出版社が『センセーショナルにつけた。』とのこと。
ゴルフクラブメーカーのPING(ピン)のゴルフドライバの開発を例に改善の解の導き方の説明がわかりやすい。図中の左の☆から右の☆になるようにパラメータを調整した、とのこと。その開発にリーン開発を適用した。
型(米国ではKATA)には2種類ある。改善とコーチング。
改善の型とは、☆(ビジョン)に向かって、as isの現状から少し上のレベルにチャレンジしてゴールに近づく。
コーチングの型は解を教えない。傍にいて導き、深く考えさせる。
13:00〜13：45 ソフトウェア開発を加速させるリーン開発の原則
講演者 天野勝氏 ：永和システムマネジメント アジャイル導入コンサルタント
リーンとは？的なお話が中心。正直、準備不足でしたよね？
13：45〜14：45 【セールスバッファマネージャー開発事例】
講演者：ゴール・システム・コンサルティング西原隆氏
永和システムマネジメント 羽根田洋氏 市谷聡啓氏
コーディネーター：ワイクル 角征典氏
セールスバッファマネージャーというソフトウェア開発にリーンを適用した開発の事例発表。普通にリーンとスクラムで回していたらしい。インセプションデッキを使うとか、ユーザストーリを使うとか、1週間でイテレーション回すとか。
なんだけれど、写真では伝わらないけど、発注者側である西原氏が営業なので押しが強いというか声が大きいというか営業そのまんまの強い人。でも、企画を上げて、POとして開発と向き合ったのは正直エライ。写真の右側の人。
写真の左側は、会議られたスコープから何を取って、何を捨てるかを決める時に使ったらしい。先発の類似ソフトウェアが持っている機能(図の対角線)はバッサリ切ったところが漢だねぇ。
発表の後の質問であったけれど、見積もりはこれも普通にストーリーポイントでやったらしい。でも事前に要求をやり取りしていたからそれで1つの要求を見積もって、それを標準にして……という王道で。
仕様の詰め方も、業務要件を説明してもらって、それを松竹梅の案に展開して、でも、工数の範囲内で実現できるのを選ぶことを調整したらしいんだけど、西原氏はそのやり方を頭では理解して契約しても、実戦でやられたとき正直戸惑ったんじゃないかなぁ。
14:55〜15：40 【派生開発をリーンにするXDDP】
講演者 清水吉男氏 ：（株）システムクリエイツ 代表取締役。
コーディネーター：日立製作所 八木 将計氏
母体ありきの、機能追加、変更のシステム開発でのお話。組み込み開発で話されていましたが、今書きながら思い出したんですが金融でも基本開発後の追加機能開発や仕様変更に伴う開発する追加開発と言う概念持ってプロジェクトやっているところもありますね。
こちらも、準備不足でしたよね。
そうか、それでトレーサビリティマトリックスを見て、違和感なかったのか。
15:40〜16：20 【メイカーズ革命〜オートデスクにおける３Dプリンタへの取り組みとアジャイルなビジネス環境〜】
講演者 塩澤豊氏 ：オートデスクにて３Dプリンター関係のエバンジュリスト
iPadが出てきてから開発方法がアジャイルに変わったとのこと。機能重視から顧客体験にスイッチ。
iOSアプリではautodesk123Dをフリーで配っているんだって。知りませんでした。興味があるので入れてみよう。
16:30〜18：00 【大野耐一の創り方】
講演者 金田 秀治氏 ：（株）ゴールドライツ代表取締役、（株）スコラ・コンサルト相談役。
金田先生のお話がとても面白い。カンファレンスなのできちんと落ちを教えてくれようとするも散々時間をオーバーしそうになって助手の方の誘導で言っているのもお茶目。
別に、ソフトウェアだから「TPS関係ないよ。」って思うかもしれないけれど、今のプロジェクト管理手法とかシステム開発方法論に疑問や不満を持っているならTPSを聴くだけ聞いて、その方法で2-3度自分たちがやっている仕事のしくみを見直してみた方が良い。何か今のしくみがオカシイと気づくはず。
ちなみに、写真右側に写っているのは助手の人。
18:00〜19：00 質疑応答＆講演者パネルディスカッション
司会者からの感想を応えたり、受講者からの質問を受けたり。
【超トヨタ式】 「絶対不可能」を可能にする経営―逆転のチェンジingメソッド
posted with amazlet at 14.01.29
開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」
posted with amazlet at 14.01.28
リーン開発の現場 カンバンによる大規模プロジェクトの運営
posted with amazlet at 14.01.28
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)
posted with amazlet at 14.01.28
オーム社が創立100周年記念セール（2013-12-11(水)12時まで)でeStoreだと電子書籍がお得なので買ってみた
オーム社はおかげさまで2014年に創立100周年を迎えます。
長年のご愛顧に感謝してeStoreでは記念セールを開催中です。
（2013-12-04(水)12時から2013-12-11(水)12時まで）
と言うことで、アジャイル関連の書籍も電子書籍ならお買い得の1200円＋税。
http://estore.ohmsha.co.jp/titles/978427406932P
電子書籍版のメリットは、キーワードで検索できることと挿絵がカラーなこと。
挿絵の写真もカラー
PDF版なのでスマホでもPCでもiPhoneでも読める。すばらしい。Kindle本体を持っていると、Kindleに入れてしまえばアプリで読めば、読んだ端末のページの続きから他の端末で読めるのが便利なんだけど。
