第10回TOCfE関西分科会

「TOC for Education入門〜３つのツールのその１つ〜」に参加してきました。

この日のテーマは「ブランチ」でした。
ワークショップでは、ある童話をテーマにブランチを作成しました。
その成果をグループごとに発表しあったのですが、グループごとに個性があってなかなか面白かったです。
発表の中で、講師の飯室さんが次の質問を取り上げました。

「いったいどの程度掘り下げてブランチを作成すればいいのですか？」

その答えは、「いい加減に」でした。
「good enough」の状態までやる、もしくは「good enough」の状態でやめるのがよいとのことでした。

後半からは各自の成功談、失敗談をテーマにブランチを作成しました。
ここでは「ブランチ、恐るべし。。。」ということをまざまざと見せつけられることになりました。
ブランチで成功体験/失敗体験を整理するワークショップで実感したブランチの実力は、次の点です。

・ロジックが明確になる点
・見えていなかった（意識していなかった）因果関係が浮き彫りにされたこと

世話人の東さんが、「ここら辺がこれから明らかになってきますよ（笑）」と言われていた理由を体から溢れ出る冷や汗で理解しました。
グループで掘り下げたことも、ブランチが広がっていった要因だと思います。

う〜ん。ブランチ、できる子です。

第10回TOCfE関西分科会

第10回TOCfE関西分科会に参加しました。

今回のテーマは、「どんよりバイバイ！夢を叶えるアンビシャスターゲットツリー」でした。
講師の澤井 奈美さんは気さくな感じのいい方で、話もとても分かりやすかったです。
TOCとは何かと言うと、澤井さんは「ちゃんと考えましょう！」ということだとおっしゃっていました。
TOCfE ではそのためのツールが３つ用意されています。

考える大人になるための３つの道具

TOCfE では、考える大人になるための３つの道具があります。

  • ごちゃごちゃスッキリ！　ブランチ
  • もやもや解消！　クラウド
  • どんよりバイバイ！　ターゲットツリー


このうち、今回は（アンビシャス）ターゲットツリーのお話とワークショップを行いました。

ターゲットツリー

ターゲットツリーを作成する手順は、

  1. ターゲットに立ちふさがる障害を洗い出す
  2. 障害を克服するための中間目標を設定する
  3. 中間目標を達成するための行動を考える


です。
このときの注意点として、ターゲットツリーを作成する際に行動から考えてしまうと中間目標の幅が狭まってしまうと澤井さんは指摘していました。思考の幅を狭めないためにも、この順番でなければダメです。
また、このようにきちんと言葉にして表現することで、隠れたニーズやアイデアが露わになる効果があるとのことでした。

所感

ワークショップでは、原発問題をテーマとして「原発を０にする」というターゲットを題材にターゲットツリーを作成しました。
テーマが壮大であったがために、なかなかこれといった行動にまとまりにくかったです。
というのも、障害に対する目標およびそれを達成するための行動を導きだしてはみるのですが、その行動自体が大きなターゲットとなって立ちはだかるように僕たちにプレッシャーをかけてきたからです。
しかし、澤井さんによれば、それも当然でその場合はその行動をターゲットにして新たにターゲットツリーを作成すればよいということです。階層構造になったターゲットツリーという感じでしょうか。
ワークショップでターゲットツリーの作成を経験して、なんとなく雰囲気をつかむことができたように思います。
しかし、今一つ、消化不良な感じが残っています。
しばらく自分なりに実践してみてより理解を深めた後に、またこのような勉強会に参加してしっかりと自分のものにしたいです。
また、今回は体調との兼ね合いから懇親会に参加できなかったので、講師の方や参加された方との意見交換ができなかったのが残念でした。また機会があれば、皆さんの意見を聞いてみたいです。

第5回RxTstudy

第5回RxTstudyに参加しました

agenda

  • 情報システム部門のタスク管理とIT全般統制~Excel 管理からの脱却 株式会社島津ビジネスシステムズ 導入事例
  • Redmine カスタマイズの事例紹介
  • Excel管理からの脱却の別解 サイボウズデヂエについて
  • 壁と私
  • LT 「タスク管理」

情報システム部門のタスク管理とIT全般統制~Excel 管理からの脱却 株式会社島津ビジネスシステムズ 導入事例

[twitter:@akahane92] さんによる内部統制、IT 全般統制の情報基盤として Redmine 導入までの事例紹介です。
Redmine でなら必要な情報を入力してくれる理由として、
「楽やし」
というのがありました。
ただ、僕のまわりではどちらかというと Redmine(ITS) による入力の方がめんどくさくて Excel の方が「楽やし」という意見の方が多勢です。そこで、どの辺りに違いがあるのかに興味が湧きました。
発表にあった工夫の中で印象的だったのは、ITS への入力項目を削減するというものです。Excel でも同じですが、たくさんの入力項目は煩雑でそのモチベーションが減退します。その代わりに各チケットの「説明」を充実させることが重要だというのは同意できます。また、入力項目を絞ることも重要ですが、その他にもテンプレートチケットを用意するという工夫がなるほどと思いました。これは早速導入してみたいです。
また、「事務局重要」ということも納得です。「各自、好き勝手にやってね」では効果的に導入されることは期待できません。標準を定めサポートする存在は大事です。

Redmine カスタマイズの事例紹介

[twitter:@yusuke_kokubo] さんによる Redmine カスタマイズの事例紹介です。
Redmine はツールなので、そのカスタマイズに行ったコードはアドホックに書いているとおっしゃっていました。
確かに製品コードではないので、Clean Code を目指す必要はないです。
他には、おすすめのプラグインに以下のものを紹介してくれました。

  • CodeReview
  • logs
  • knowledgebaes

最後に、なんのために Redmine を使うかという発表の中で紹介された「継続的成長」という言葉が心に響きました。
これは[twitter:@yusuke_kokubo]さんがエンジニアとして大事だと考えている信条のようなもので、僕自身、いつも心がけています。エンジニアたるもの、常にこうありたいものです。

Excel管理からの脱却の別解 サイボウズデヂエについて

[twitter:@minitau]さんによる Excel 管理からの脱却の別解 サイボウズデヂエについてです。
Excel を全く排除できるのであれば、デヂエを選択するということは有効な解であると感じました。
そのためにはまず、業務を Excel に依存しないようにデザインし直すという作業が必要です。それを行わない限りは、デヂエを導入したところでそのメリットは半減するように感じました。

壁と私

[twitter:@masahirotaguchi] さんによる壁と私です。
コミュニケーションしたくないからアジャイルを選択したというのは衝撃的（笑撃的？！）でした。
その中で実行したのが朝会とタスクボードというのは、同感です。導入コストがそれほどかからないにも関わらず、その効果は絶大です。ただ、僕が現在いるチームでは、朝会が進捗報告会のようになっているのが残念です。原因は分かっているのですが、そこに手を打てない状況です。しかし、近いうちにこの現状を改善したいと考えています。
また、最初５分で行っていた朝会を、現在では１５分で行っているそうです。その設定時間が変化した理由を聞いてみたいです。

LT 「タスク管理」

「タスク管理」をテーマに以下の LT がありました。

  • タスク設計のお話
  • 「タスク管理」についてアレコレ聞いてもらいます
  • チームWMS関西の遠距離チームビルディングとタスク管理
  • どんな話が聞きたい？
タスク設計のお話

[twitter:@NoriyukiMizuno]さんによるタスク設計のお話です。
３０数枚のスライドを５分で話しきると言う怒濤の LT でした。
タスクに分割する作業を「タスク設計」という造語で説明していました。
タスク設計では、

  • タスクに情報の関連性があるとうれしい
  • フローで分解する（DFDを利用する）

といったことが説明されました。
タスクの分割にそこまでするのかと関心するような内容でした。

「タスク管理」についてアレコレ聞いてもらいます

[twitter:@chiaki99]さんによる「タスク管理」についてアレコレ聞いてもらいますです。
これまで実践されてきた、なんだかうまくいかないタスク管理の方法についての紹介がありました。
それらの方法について、懇親会などでお話ししましょうということでしたが、残念ながら懇親会には参加できませんでした。
また機会があれば、お話を伺ってみたいです。

チームWMS関西の遠距離チームビルディングとタスク管理

[twitter:@pinkmac]さんによるチームWMS関西の遠距離チームビルディングとタスク管理です。
テーマは、「母となったわたしたちのはたらくを語ろう」で、働く女性のQOL向上を目指しているそうです。
働く女性、特にお子さんを持つ女性が働くことはまだまだ大変なことが多いので、こういった活動は素晴らしいです。
そのコミュニティでのタスク管理の話でした。
興味深かったのは、タスクや期限を[twitter:@pinkmac]さん等が割り振ると「やらされ感」で上手くいかなかったという点です。
タスクの一覧（タスクボード）があって、その中から自らがタスクを選択して行動していくようになると、プロジェクトは上手く回りだします。これは「自己組織化」された組織であるということです。そういった組織になれるようにするには何が必要か。そういった取り組みをしていきたいです。

どんな話が聞きたい？

株式会社アジャイルウェア代表取締役の[twitter:@agilekawabata]さんによる発表です。
どんな話が聞きたい？というテーマではなかったと思いますが、次回に向けてどんな話が聞きたい？というアンケートをとった感じの LT でした。
次回の RxTstudy に期待が高まります。

所感

なぜか今回は Excel 悪玉論が集中して盛り上がっていました。
Excel で管理することの問題点はいろいろと挙げられていました。ただ、それらは、「そもそもそれって Excel ですることなの？」なことも多く、Excel に原因を求めて溜飲を下げているだけであるようにも思えます。
それ（Excel）を使用をすることを選択した、もしくはそれを使い続けていることへの反省がないといけないのかなと感じました。

最後に、僕も壁（アナログ）が好きです。

父の日

今日は父の日です。
２週間ほど前に、娘に「父の日ってのがあるらしいよ？」って聞いてみました。
そのときは「ふ〜ん。」と、素っ気ない返事でした。
なので、今日は全く普通に過ごしていましたのですが、お昼過ぎに娘からプレゼントをもらいました。
細君と二人で選んでくれたようです。
こんなとき、娘の父親でよかったと思います。
プレゼントをもらえたからではありません。
こんな父親にでも感謝の気持ちを伝えようとする優しい心を持つ娘に育ってくれたことに、無上の喜びを感じます。


ありがとう。

TDDBC 大阪 2.0

6/3（日）に開催された TDDBC に参加しました。
会場の楽天カフェテリアはおしゃれな感じで、さすが楽天といった感じでした。
スクリーンもとても見やすく、勉強会として使用するのに理想的な会場でした。

当日のタイムテーブルは次の通りです。

  • 和田 卓人[twitter:@t_wada]さんの講演
  • 吉岡 弘隆[twitter:@hyoshiok]さんの講演
  • [twitter:@irof]さんと和田 卓人[twitter:@t_wada]さんによるデモペアプロ
  • 演習
  • 関 将俊[twitter:@m_seki]さんの講演
  • テーブルレビュー
  • 講師・TAによるトークセッション
  • ふりかえり
  • 和田 卓人[twitter:@t_wada]さんのまとめ

概要

テストを次のように分類したとき、TDD では Developer Testing を扱います。

  • Developer Testing
  • Customer Testing
  • QA Testing

Developer Testing とは、

テストのことです。
TDD の目標は、動作するきれいなコードです。
動作するきれいなコードを作成するために、

  • コードの健康
  • チームの健康

をテストで担保します。
テストを先に書くのは、ユーザ側にまわらないと分からない設計上の課題があるからです。
使いたいメソッドと作りたいメソッドとはきっと違います。
そういう意味で、TDD はテスト技法ではなく設計技法であると言えます。

演習では、同じ言語(C++)を使用する人とペアプログラミングしました。
テスティングフレームワークはCppUnitを選択しようかと思っていたのですが、C++の TA をしていただいた[twitter:@goyoki]さんに、

CppUnitはその作者も失敗作だと言っている

ということを教わり、急遽googletestを使用することに変更しました。
という訳で、まずはテスト環境を導入して環境を確認しました。
後は愚直に TDD のサイクルを繰り返して課題を進めていきました。

感想

やっぱりコードを書くのは楽しいです。
TDD のリズムを体感できたことはとてもいい経験になりました。
Red -> Green -> Refactoring のリズムは、やってみると、心地よかったです。
リズムを守ってコーディングするのは楽しくて、テストがあるので安心してコーディングを進めていけます。
これをやらない手はないと思いました。
また、人にコーディングを見られ続けるペアプロはなかなか刺激的な体験でした。
ただ、体力/精神を消耗するのは間違いないです。
適度に休憩を取る必要がありそうです。

あと、[twitter:@goyoki]さんに、

組み込みなら、Cpputestがいいですよ。

と薦められました。
今度試してみたいと思います。

それから、グリーンバンド買っちゃいました。

acts as professional

業務中、忘れずにつけています。

テスト駆動開発入門

テスト駆動開発入門

日本ファシリテーション協会関西支部の6月定例会に参加しました

日本ファシリテーション協会関西支部の6月定例会に参加しました。

6月のテーマ

6月のテーマには以下のものがありました。

  • 合意形成までの〈過程〉でもっとも大切なこと

〜南三陸漁業復興支援の現場から〜

  • ワークショップがぐっと良くなるプログラムデザインのツボ
  • 〜 サモアンサークルをやってみよう!? 〜

今回は「合意形成までの〈過程〉でもっとも大切なこと」に参加しました。
このテーマの概要は次のとおりです。

話しあいの場においては、最終的に参加者間の合意形成が必要となることが多々あります。限られた時間の中で、質の高い、そして皆が納得できる結論に到達できるよう、支援・促進する。そのような場をつくろうと思った時、もっとも大切にしな
ければならないものは何でしょうか？
本テーマでは、津波被害からの漁業復興に取り組むある地域の事例をベースに、【合意形成のための話しあいに至るまでの＜過程＞において大切にしたい働きかけ】を考えます。
なお、「話しあいの場におけるファシリテーション」でも、「話しあいの場のプログラム・デザイン」でもなく、「話しあいの場に至るまでのプロセス・デザイン」を中心に扱いますので、具体的なスキルやテクニックを身につけるというより、一人ひとりが自分自身の「大切にしたい姿勢」を見出すことをめざしたワークとなります。ご了承ください。

このテーマは次のように進んでいきました。

  • はじめに
  • 支援室紹介
  • ワーク1
  • ワーク2
  • わかちあい
  • ふりかえり
  • おわりに

ワークショップの概要

はじめに

徳田太郎さんによるアイスブレークがありました。
体を動かすことで参加者同士が打ち解け合うことができ、うまくワークショップに入ることができました。

支援室紹介

災害復興支援室の南三陸での活動内容についての説明がありました。
その中で、今回のワークショップで取り扱うある町（X地区）の様子が説明されました。

ワーク１およびワーク２

ワークショップでは、ある町でボランティアをしているAさんの友人という想定で行われました。
AさんはX地区のある漁業関係者から復興についての考えを聞きます。
そして、漁師さんたちで話し合う必要を感じたAさんは、ファシリテーションを学んでいる"わたし"に連絡をしてきました。
Aさんは8月16日（火）〜20日（土）の5日間、"わたし"は18日（木）〜20日（土）の3日間現地を訪問します。
また、漁師のコアメンバー全員が揃うことができるのは訪問最終日の20日の7時〜15時しかないことが分かりました。


そこで、今回の課題です。

  1. 8月20日の話しあいのゴールは？（どこまでを合意形成するイメージ？）
  2. 8月20日の話しあいのタイムテーブルは？（何を、どのような手順で話しあっていくイメージ？）
  3. 8月20日の話しあいの参加者は？（コアメンバー4名だけ？それとも他の人を呼ぶ？）
  4. 今日（仮に8月11日として）から訪問日（8月18日）までに、話しあいの準備として、あなたは何をする？
  5. 8月16日〜17日の2日間、話しあいの準備として、Aさんに何をお願いする？
  6. 8月18日〜19日の2日間、話しあいの準備として、あなたとAさんは何をする？


まず対象となる町の情報を収集した資料を精読しました。
結構なボリュームの資料で、個人で考える時間のほとんどの時間がこの資料を読む時間で使ってしまいました。
次はグループでのディスカッションです。


資料には、次の内容がありました。

  • X地区単独での復興は難しいこと
  • Y地区とは一部で協力して事業を始めていること
  • Z地区とは確執があり、共同での復興に障害となりそうなこと
  • X地区のコアメンバーの中でも意見が分かれていること


僕の考えた「8月20日の話しあいのゴール」は、次の通りです。

  • コアメンバーの復興のイメージ（ビジョン）をまとめる

グループ内では、3地区合同での復興への合意などの意見も出ました。
しかし、訪問時間も短い上にメンバー内でも復興へのイメージがばらばらであったため、そこまでを20日にもっていくのは不可能であると思いました。
グループ内で議論した結果、話しあいのゴールを次のようにしました。


次にタイムテーブルです。
僕は漠然と次のようにしか考えることが出来ませんでした。

  • 前半: みんなの意見を発散する
  • 後半: 共通イメージにまとめていく

グループ内では、午前中にゴールを決めて、午後からは食事＋お酒で親睦会ということになりました。


「話しあいの参加者」については、話しあいのゴールが「コアメンバーの復興の目的/目標」を明確にすることにあるため、コアメンバー＋地区の有力者としました。


Aさんにお願いすることとしては、コアメンバーおよび地区の有力者からお酒を飲みながら本音を聞き出すということになりました。
グループには農協関係者がいて、「みんななかなか本音のことを言ってくれないから飲みニケーションが必要」ということをおっしゃっていました。
個人的には、飲む/飲まないはどうでもよかったのですが、情報収集をすることは必要だと思いました。


"わたし"のする「話しあいの準備」はどのようにまとまったのかはよく分かりませんでした。
僕の考えた準備は、コアメンバーが復興のビジョンを決めるために必要なデータを収集することでした。


"わたし"とAさんのする「話しあいの準備」は、Aさんが事前に収集した情報をもとに、20日の話しあいのデザインをすることとしました。

ふりかえり

話しあいで合意形成をめざす際に大切にすることについて、個人でとグループでふりかえりました。
個人的には、以下の点を挙げました。

  • 話しあいの参加者にとっての価値
  • 当事者で議論すること

グループでは、他にも以下の項目が挙がりました。

  • 安全な場
  • 納得感
  • 本音を引き出すこと
  • 場の力にこだわりぬく

参加してみて

「合意形成までの〈過程〉でもっとも大切なこと」は、合意形成の場に臨むまでの準備をどこまでやるかだと感じました。
グループでのふりかえりで挙げられた「こだわりぬく」という言葉がしっくりときます。
真摯に誠実に「こだわりぬく」ことにより、当事者たちが納得する合意を得ることができるのだと思います。
また、テーマとは関係がないですが、議論の構成メンバーを考えることもとても重要であると実感しました。
正直、準備の段階から話しあいの当日まで「お酒」から離れられなかったのは残念でした。
その他には、ファシリテーターとは何かということについて考えてみました。
話しあいのゴールに具体的な復興案（三地区共同の復興）への合意といったものもありました。
これが果たしてこのX地区のコアメンバーの話しあいのゴールになり得るかというと、必ずしもそうでないと思います。
あらかじめ決まっている結論に導くということがゴールになることもあると思いますが、今回の場合はファシリテーターが結論を用意すべきではないと思います。
話しあいを行うメンバーたち自身が議論して納得して結論を出さなければ、やらされ感だけが残ります。
最後に、これは個人的な反省ですが、相変わらず場の空気を読んでしまってなかなか反対意見を言い出せませんでした。
このあたりは直していきたいです。

AgileNight2012夏 〜岸良さんが何でも答えます！TOC90分一本勝負！〜に参加しました。

5月25日に開催されたAgileNight2012夏 〜岸良さんが何でも答えます！TOC90分一本勝負！〜に参加しました。
Agile Japan 2012の基調講演では充分な質疑応答が出来なかったということで、講演者である岸良裕司さんに時間の許す限り質問するという趣旨のイベントです。

Agile Japan および Agile についての説明

はじめに Agile Japan の実行委員長である西河さんによる Agile Japan および Agile についての説明がありました。
今回参加されているのは IT に携わる人だけではありませんでした。
TOC や CCPM についての話題ということもあり（？！）建設関係の方が目立っていました。

見積もりと期間について

システム開発では見積もりの難しさについての議論が必ずといっていいほどつきまといます。
それを解決するためのアプローチについての質問がありました。
まず、岸良さんから次のような問いかけがありました。

ユーザーは見積もり通りに契約してくれますか？

たいていは安く押さえられるし期間も短く厳しく設定されてしまいます。
ましてやそこに他社との競合も加わります。
このことを受けて岸良さんは次のように結論づけます。

見積もりがどうのこうのではなく、その予算と期間でやらざるを得ないんです。

ではどうすればよいのでしょうか。
それには、

工期を短縮する必要があります。

と岸良さんは言います。
そもそも、ユーザーは個人に対して発注するのではなく、企業/チームに対して発注します。
個人ではなく組織やチームで解決していく方法こそCCPM(Critical Chain Project Management)であるということです。

投資を回収するという視点について

CCPMの基になるTOCを提唱したゴールドラット博士の言葉によると、「価格が重要」ということです。
もう少し突っ込んだ言い方をすると、「投資を回収する」という視点が重要であるとのことです。
納期が遅れると、ユーザーはそれだけ投資を回収し始める時期が延びます。
このことはユーザーからすると（とても大きな）損失です。
「顧客に価値を提供する」、そのことをどこまで真剣に考えているのかと問いかけています。
これは Agile にも通じます。
（参考）アジャイルソフトウェア開発宣言

とりあえず病

岸良さんは次のように問いかけます。

プロジェクトを開始する際に、「とりあえず」あるいは「なんとなく」始めていませんか？

その結果、「しまった！！」とか「やべー」といった状況に出くわすことを「とりあえず病」と名付けたそうです。
今の日本ではこの「とりあえず病」が蔓延しているように、岸良さんは感じているそうです。

よい遅れと悪い遅れについて

プロジェクトとは「不確実なもの」であるので、スケジュールの遅れは避けて通れないことです。
ではすべての遅れが悪いかというとそうでもないよというお話です。
起こるべくして起きた遅れ、すなわち計画時にリスクを考慮してあらかじめ想定している遅れというものは、この文脈では「よい遅れ」です。
それに対して、「とりあえず病」で始めることによる、準備不足で遅れる稚拙な遅れが「悪い遅れ」と岸良さんは言います。

どこまで品質を作り込むのかについて

いいものを作りたいとして取り組むと、どうしても遅れが出てしまいます。
また、品質はどこまで作り込めばいいのかという質問がありました。
これについて、岸良さんは次のように問いかけます。

時間をかければ本当に品質は上がりますか？

CCPMでは待ち時間を短縮することにより、品質にかかる時間を充分に割り当てることが出来るようになります。

回収（リターン）を測る指標について

金額で測ることが出来ないような場合、例えば国道を作るような場合はどのように判断するのかという質問がありました。
これに対して岸良さんは問いかけます。

回収は金額でしか測ることができませんか？

例えば、

早く仕上げるということもリターンではないですか？

と岸良さんは問いかけます。
国道でいえば、

  • その国道が出来ることにより地価が上がりませんか。
  • 便利になり企業などが移転してくると税収が上がりませんか。
  • 税収が上がると住民サービスが向上しませんか。

また、期間という視点を持つことの重要性を繰り返し述べられていました。

三方良しの公共事業改革

三方良しの公共事業改革とは、

  • 住民よし
  • 企業よし
  • 行政よし

の公共事業での取り組みのことです。

三方良しの公共事業改革

三方良しの公共事業改革

施工業者のみならず、発注者および住民と「目標を共有する」ということが大切だと岸良さんは言います。
これにより、施工業者の作業員は住民から「ありがとう」と声をかけられるようになったと岸良さんは力説します。
ここでも、目標を共有することとともに期間という視点を強調しました。
時間が延びるとそれだけコストアップになります。逆に時間が短縮されるとそれだけコストダウンになります。
時間の無駄を省くことの重要性を繰り返し述べられていました。

うつになる職場について

どうしてうつになるのでしょうか

  • 楽しくない仕事
  • プレッシャー
  • etc.

これらは解決したい課題を上手く解決できないジレンマが原因です。
これを解決するには、現場任せではなくマネジメントが必要です。

CCPM（やAgile）を導入するにはどうすればいいかについて

ケースとロジックが必要と岸良さんは言います。
ケース（事例）だけでもロジック（理論）だけでもだめで、両方揃わないと上手くいかないということです。

所感

TOC/CCPM でも Agile でも重要になる考え方は重複していることが興味深いです。

  • 「顧客に価値を提供すること」と「投資を回収すること」
  • 目標を共有すること
  • 共感すること

出自の全く異なる Agile と TOC/CCPM ですが共通点の多さに驚きます。
また、現在の高度化されたプロジェクトの中では、個人だけで解決するには限界がきている点にも納得ができます。
改めて、Agile Japan 2012での岸良さんのキーノートセッションのサブタイトルが胸に響きます。

〜 変えるのは現場ではない、マネジメントである 〜