かんばんボード(タスクかんばん)導入の肝

タスク管理の手法というのはいくつかあると思うのですが、その中の一つに「かんばんボード」(あるいはタスクかんばん、タスクボードとも言うらしいですが)という見える化によるタスク管理手法があります。基本はアナログですが、タスクかんばんを実現するアプリも存在するようです。

かんばんボードの原理は簡単で、チームが持っているタスクを全て付箋に書き出してホワイトボードに貼り付けるのですが、ステータスによって貼り付ける位置を変えていくというものです。でも、これを本格的に取り組もうと思っても教科書的なものが見当たらない。ネットで調べると多少それらしきものは見つかるのですが、いざ取り組んでみようと思うとなかなか難しいのではないかと思います。

やってみると分かるのですが、実はかんばんボードを使いこなす肝はレーン(ステータス)の設計ではないかと思うのです。レーンというのはボードを縦に区切った言わば列のことで、通常はステータスを割り当てています。(但し、必ずしも列という形にこだわる必要はなく、自由にレイアウトを決めて良いと思います。)Redmineなどのタスク管理ツールでタスクを管理する時もステータスの設計が使い勝手に影響してきますよね。

例えば参考になるのが以下のサイト。
Web開発チームをタスクボードだけで見える化する 5つのコツ
http://engineer.blog.lancers.jp/2012/07/task_board_tips/

文献を見る限り一番オーソドックスなレイアウトはToDo、Doing、Doneという3つのレーンで区切る方法。ですが、杓子定規にこれを運用する必要はなく、現場の判断で変えて良いと思いますし、変えていくべきです。タスクのステータス設計にはどんな業務を対象とするかによっていくつものバリエーションがあり得ます。例えば開発現場でも設計工程と開発・テスト工程とでは管理すべきタスクが異なりますよね。

まずは導入しようと思う時に、この現場ではどのようにステータスを管理・運用しているかということを分析することになります。業務によっては併せてワークフローの設計もした方が良いケースもあります。具体的なステータス設計の例は追々ご紹介できたらと思います。


ITコーディネータへの挑戦

ちょっと前のことになりますが、私はこの9月から土日を利用してITコーディネータのケース研修(全6日間)を受けてきました。正式な認定は年明けになるのですが、とりあえず研修を修了して試験にも通過したことでITコーディネータに一歩近づいたと言えます。

そもそも私はITコーディネータにあまり興味を持っていませんでした。が、ある日ある方にITコーディネータ資格の取得を強く勧められ、取得を目指すことにしたのです。しかも、私の知らない間にITコーディネータの制度が変わっていて、ケース研修も以前は15日間もあったものが6日間と短縮され、その分資格取得までに必要な費用も抑えられており、以前よりは敷居が低くなった印象を受けました。とはいえ、全く見ず知らずの人と濃密な討議を強制されるというのは、さすがに不安も覚えます。

ケース研修ではどんなことをしたかというと、ITコーディネータには一種の教科書であるプロセスガイドラインというものがあるのですが、そこに定義されているプロセスを一通り疑似体験するというものです。架空の中小企業の設定資料があり、その資料を読み込んでその企業をコンサルティングする…というのではなく、架空のコンサルティングを通してプロセスガイドラインを学ぶというのが主な目的です。

そうは言っても、演習では本来の目的を忘れてつい議論になってしまうこともあり、最初のうちは演習の時間配分が難しく、成果物が最後まで仕上がらないことが多かったです。やはり方法論についての議論というのは楽しいもので、ついのめりこんでしまいますね。しかし、徐々に本来の目的を意識しながら演習を行うことが出来るようになり、枝葉末節の議論は割り切って先に進めるようになりました。ただ、ケース研修を終了したとはいえ、あくまでも疑似体験であるため、これでいきなりバリバリIT経営のコンサルティングができるというわけではないですが、何をすればよいかという全体像をつかんだという感じがしています。

試験の方は11月にケース研修を修了するので、本当は2月ごろに試験を受けようかと思っていたのですが、ケース研修受講生の半数は既に試験に合格していたという事実と、ケース研修の熱が冷めないうちの方が受かりやすいのではないかという考えから、急きょ11月中に試験を受けることにしました。ケース研修の修了から一週間後に試験を設定してしまったので、短期間という制約の中で出来る準備としてはあまりなく、わざわざ問題集を買っても最後までできないだろうと思い、ネットで公開されているサンプル問題や想定問題をひたすら解いてプロセスガイドラインのおさらいに努めました。

これで万事うまく行く、とは思っていませんが、この体験が間違いなく今後の糧になるだろうと思っています。


プリンタ複合機を買い換えました

先日プリンタが壊れました。正確に言うとプリンタと一体になっているスキャナが壊れたのですが、スキャナはすぐに必要だったため、壊れた翌日に買いに行きました。

実はこのプリンタ、個人事業主として独立した10年前に購入したものです。それまで持っていたプリンタはどんなんだったか忘れてしまいましたが、ほとんど使っていなかったのではないかと思います。しかもプリンタはパラレル接続の単品で、スキャナはこれまたSCSI接続の単品でした。そこに独立というイベントが発生し、今後は仕事で使うだろうということでプリンタ・FAX・スキャナ・コピー機能を有するいわゆる複合機を購入したのです。ある意味苦楽を共にした機材でもあり、やや心残りではあります。

独立すると印刷したりコピーを取ったり紙の資料を電子化したりといった局面が増え便利に使っていましたが、個人ユース向けとはいえ複合機ともなるとそれなりに筐体のサイズも大きく、引越しの度に難儀していました。また、数年前から、印刷の時に紙を複数枚同時に巻き込んでしまうことがあり(経年劣化によるローラーの摩耗が原因だそうですが)今度インクが無くなったら買い替えようと思っていたところでした。まさか先にスキャナに接続できなくなるとは…

それにしてもプリンタって安くなりましたね。現行機種と同等の機能を有するものでも充分に安いのですが、今だったらFAXは要らないし、ADFも無くて困るほど使ってはいないので、そういったものを排除するともっと安くなりました。それでも無線LAN経由で印刷が出来たり、両面印刷も標準で対応しているなど必要なところは押さえています。しかもコンパクト。デスク周りが非常にスッキリしました。


炎上プロジェクトの根本原因を探せ!

JSDG第14回全国大会の2日目は、会員限定のコンテンツとして分科会が行われ、私のものを含めて4コマの企画がエントリーされました。私は「炎上プロジェクトの根本原因を探せ!」というタイトルで、TOC思考プロセス(TOCfEのブランチ)を使ったトラブル原因分析の事例発表を行いました。実はこの事例は、毎月新宿で開催されているTOCfEオンデマンドで発表させていただいたものを分科会企画として練り上げたものです。

思考プロセスの研修はワークショップをやることが多いのですが、私は敢えて事例発表という形式を選びました。というのも、TOCfEの国際認定プログラムでは朝から晩までを計4日間の研修が行われ、しかもブランチについてはそのうち2日間を費やし、尚且つそれでも時間が足りないというものなのです。まして90分という限られた時間でワークショップをやったとしてもブランチを作成するプロセスを会得することは難しく、それが却ってブランチは使い物にならないという結論を招きかねません。ワークショップで扱う事例はシンプルなものばかりですからね。

それなら発想を変え、事例発表を通してブランチは使えるんだという認識を持ってもらい、かつ、どんな事象に対してブランチを使ってみたいかというイメージを思い描いてもらうことで、結果としてブランチを使えるようになりたいと思ってもらうことをこのセッションの目標に設定しました。

分科会後のセッションで北村JSDG会長からも、何も全て解ってスッキリというだけが研修会ではない、むしろ次につながるようにするのも一つの方法であるという趣旨の発言がありましたが、まさにそのような形で各自の学習につながっていけば良いと願っています。

さて、私が担当する分科会に参加してくださったのは11名でしたが、ほとんどの方が「ザ・ゴール」を読んでおられ、少なくとも制約理論についてはある程度の知識を持っておられました。前述した目標を達成するために、事例発表の後に軽くディスカッションをした後、アンケート形式で気付きを書き出してもらいました。最初の質問が「もし、ブランチを使いこなせるなら何に使いたいですか?」というもので、続いての質問が「自分でそれを実践するためにどんなサポートが必要ですか?」という風にしました。この気付きを全員が順番に発表し、このセッションをお開きにしたのですが、全体を通して予想よりも反響が大きかったと思っています。

例えば、私の説明の内容に対して大きくなるほどと頷いてくださったり、既に今実践しておられる方からは「これはすごくいいんだよ」と共感して下さったり、何よりもセッション終了後に「とても楽しかった」と言ってもらえたのがとても嬉しかったです。もっと他の事例も聞きたいという意見もありましたので、私自身ももっと積極的に事例を集めていきたいと思っています。


リーダーとして、明後日を見ているか

この週末10月5日と6日とでJSDG(日本システムアドミニストレータ連絡会)の全国大会が開催され、参加してきました。全国大会というのは毎年開催されているものなのですが、実行委員は持ち回りというか「手挙げ制」で、開催場所も毎年変わっています。今年は横浜。もっと言うとテレビ神奈川のイベントスペースを借り切って行われました。

この記事のタイトルにもつけた「明後日を見ているか」というのが今回の大会のテーマです。この変化の速い時代に明日を見ていては遅すぎて、さらにその先を見ていないとダメだよねというコンセプトです。

1日目、メインセッションの1つ目はJSDG会員の山中吉明さんによる講演で、他社に真似されにくいビジネスモデルをいかに築いていくかというテーマで実例を交えながらお話しくださいました。JUAS(日本情報システム・ユーザー協会)のアドバンスト研究会において、競争優位を確立するためのフレームワークを見つけるという研究をされており、どのようにイノベーションを起こせばよいかというヒントを頂きました。

メインセッションの2つ目はJSDG会員の関尚弘さんと、今回のゲストでケンブリッジ・テクノロジー・パートナーズからお招きした白川克さんによる講演で、「反常識の業務改革(プロセス・イノベーション)」というテーマでお話しくださいました。このお二人は「プロジェクトファシリテーション」という書籍の著者でもあり、特に今回は白川さんのお話を直接聴くことができるということでとても楽しみにしていました。

関さんは「プロジェクトファシリテーション」にも書かれている内容からお話しくださり、一方、白川さんは「業務改革の教科書」という本を出されているのですが、そこにも書かれている内容から一部をお話しくださいました。ポイントは、一部の方にはODSCと表現した方が早いのかもしれませんが、プロジェクトの「背景・目的・ポリシーを明確にする」ということ。これらの共有が重要であるということを再認識しました。

関さんのお話は実は何度も聴いているのですが、何度聞いても新鮮で毎回心を動かされる何かがあります。コンサルタントとそのクライアントとが、仲間意識を持って同じゴールに向かってプロジェクトをドライブしていく様を見せつけられると、私もそのような関係をお客様と築いて仕事をしていきたいと思わずにはいられません。

白川さんのお話も、ちょうど私自身が興味を持っている内容にマッチしていたため、何度も何度も大きく頷いてしまいました。プロジェクトの立ち上げのタイミングでいかに良いコンセプトを作るかということ。良いコンセプトを作れば関係者の考えに刺さり、結果としてそれがパラダイムシフトを生み出すということでした。

また、良いコンセプトを作るためには、すぐに答えが見つかるというものではなく、正解の無いドロドロとした話を根気よく語り合うのが秘訣だとか。「コンセプト」という言葉についても、これまでなんとなくしか意味をとらえていませんでしたが、「本質」と訳すと分かりやすいですね。白川さんの講演もとても刺激になりました。「業務改革の教科書」を早速購入しましたので、読んでみたいと思います。

ログレベルとメッセージコード体系の調和

久しぶりにアーキテクトっぽい話題としてログの話をします。その中でもログレベルとメッセージコードの設計にまつわる失敗談をお伝えしたいと思います。ログまたはロギングは情報システムにとって主要な機能でないにも拘らず、おざなりな設計をすれば後で痛い目に遭うという曲者です。

ログレベルというのはエラーレベルとも言いますが、ログに記録する事象の重要度(あるいは緊急度)を示しており、大別すると3種類で故障・警告・情報です。ただ、ログレベルの種類はそのレベルの定義も含めて運用設計に関わってくるので、一般化しようと思ってできるものではありません。ですので、ここではログレベルそのものの話題ではなく、メッセージコードの体系との兼ね合いについてお話しすることにしましょう。

メッセージ設計の観点

まず考えることとして、メッセージコードにログレベルを持たせるかどうかという点があります。それはつまりメッセージコードを見ただけで、ログのレベルを判断できるようにするかどうかということです。故障ならErrorの頭文字を取ってE001、警告ならWarningの頭文字を取ってW001などとするのはこの考え方です。

次に考えることとして、発生したメッセージのログレベルに応じた制御があります。例えばバッチプログラムではジョブストリームの制御、Webアプリなどのオンラインプログラムでは画面遷移の制御を切り替えるということ。それらに加えてログ監視によるエラー検知と警報(エラー通知)を行うことも最近ではごく一般的なことだと思います。

ログ出力の方式の失敗

さて、そのログ出力処理ですが、あるシステムでは、ログ出力処理にログレベルとメッセージコードの両方を渡していました。これは愚直な方法ですがシステム全体において両者の整合性を保つ必要があるため、正直しんどい方式です。

そこで、私がアーキテクチャを担当した別のシステムでは、メッセージコードだけを渡す方式を採用しました。ログ出力処理の中で渡されたメッセージコードからログレベルを判別して以降の制御を行うというものです。これはほとんどの場合においてうまく行きましたが、ログレベルの変更に弱いということが分かりました。ある事象についてのログレベルを変更したいという場合、ログ出力処理を呼び出している個所のメッセージコードも併せて変更する必要があるということです。

また、ログレベルと画面遷移が必ずしも対応してないケース、つまり、同じレベルのエラーでもエラー画面に遷移すれば良い時もあれば、前の画面に戻したい時もあり、そういったケースでは単純な共通コードでは実現できないため少々苦労しました。それに、ログレベルが変わっただけで画面遷移(あるいはジョブ制御)が変わってしまうと不都合もあるでしょうし、バグになりやすいのです。

ログレベルとメッセージの現実的なアイデア

そこで、現実的にはログレベルと制御を分離した上で、ログレベルの変更に強いログ出力方式を考案する必要があります。前提として、メッセージの文言は定義ファイルに設定されており、メッセージコードから一意に引当てることができるものとします。

いくつか考えられると思いますが、ログに記録するメッセージコードの体系は、既に運用設計の中で定められており自由に決められない場合があります。そういう場合でも対応できるようにログに記録するメッセージコードとは別に内部のメッセージコードを定義すると良いのではないかと考えています。

この方式では内部のメッセージコードにはログレベルを表す文字を含めず連番(とその他の記号)のみとし、ログレベルはメッセージ定義ファイルの中に文言と一緒に定義しておきます。ログを出力する時は内部メッセージコードをログ出力処理に渡します。するとメッセージ定義ファイルからログレベルと文言を引当ててログに記録します。

こうしておくと、ログレベルを変更するにはメッセージ定義のみを変更すればよく、ログ出力処理を呼び出しているコードの修正を行う必要がありません。ログレベルの変更で悩まされたという方は是非一度試してみてはいかがでしょうか。

創業10周年の感謝

おかげさまで昨日9月1日に創業して満10周年を迎え、11年目がスタートしました。また、法人としても第4期がスタートしました。ここまでやって来れたのも周りの皆様の温かいご支援があればこそであると感謝しています。

こういうスタイルで仕事をしていると、よく「独立のきっかけは何だったんですか?」という質問を受けます。私はつい、その質問の意図を確認もせずに答えてしまうのですが、きっかけは勤務していたソフトハウスの解散です。私は中途で入社したのですが、その頃に随分と大きな赤字を出していたようです。

同僚や先輩のほとんどは新たな勤務先を見つけて転職しました。一部の同僚が独立しましたが会社員に戻ったと聞いています。私は元々いつかは独立して仕事をしたいと願っていましたので、ちょっと早いなとは思ったけれども一旦会社に就職してしまうと独立し難いかもしれないと考え、その会社の役員方の後押しもあり、思い切って独立の道を選びました。

解散当時は私はあるソフトハウスにアウトソーサーとして常駐していましたが、その契約を法人間から個人との契約に切り替えるという形で最初の仕事を頂くことが出来ました。そこからは現場で知り合った方の紹介を受けたり、元上司に呼ばれたり、エージェントを利用したりとギリギリ仕事をつないできました。

本当にあの時は全く何も解っていなかったと思います。多少なりとも解っていたら独立していなかったでしょう。もちろん今だって解っていると言うつもりは全くありません。むしろ独立したからこそ可能になった経験や出会いがあったのは確かです。

例えば、資格もそうです。会社員時代には資格には全く興味がありませんでした。でも独立してやっていくには資格が必要だと認識し、中でも上級システムアドミニストレータを取得した際には合格者のコミュニティである通称JSDGにも参加しました。また、独立事業者が集まるインディペンデント・コントラクター協会(IC協会)にも加入しました。独立するといわゆる同僚とか先輩といった概念がありませんので、外に出て様々なコミュニティに顔を出すしか人脈を拡げる方法が無いんですよね。それらのコミュニティを通しての出会いは自分にとって財産だと思います。

ところで、独立当初はずっとフリーのエンジニアとして個人事業主を貫くつもりでいましたが、一方でこのままで良いのだろうかという漠然とした不安や焦りのような感覚を覚えるようになりました。ちょうどその頃、いつもお世話になっているIC協会のセミナー等で、活躍されている諸先輩方の話を聴く機会が何度かあり、徐々に自分も法人化しようかなと考えるようになりました。

法人設立当初は大丈夫かなと思う局面もありましたが、結果的に主体的に考えることも多くなったし、ビジネスという観点では動きやすくなったと思います。なにより個人の時と比べて信頼されやすくなったという実感もあります。私にとっては第二創業ともいうべき法人化がまだ軌道に乗ったとは言えないものの、以前より展望が開けてきました。

今後とも引き続きどうぞよろしくお願いいたします。

ブランチ事例を発表させていただきました・その3

昨日27日(火)に西新宿にてTOCfEの月例勉強会(通称オンデマンド)に参加いたしました。私は先々月、先月に引き続き、3回シリーズの最終回のブランチ発表をさせていただいたのですが、本当は15~20分程度を想定していたのに、様々なツッコミを頂いて気づいたら50分にもなっていました。他に発表準備をされていた皆さんごめんなさい。

それだけ深い議論が出来たのではないかと思いますが、いろいろと質問や指摘を受けていく中で私自身がまだモヤモヤしていた個所がクリアになってきて、なるほどと思うところが多数ありました。また、される質問によっては答えに窮する場面もあり、そこは私の中で良い考えが浮かばなかったりまとまらないという状況に陥ったためで、そういう時は開き直って逆に「何か良いアイデアありますか?」のように切り返すことが、会話をテンポよく続ける上で大切かなと思いました。

今回のブランチを共有する中で一番勉強になったのは、所属する組織の評価基準や体制(仕組み)が実態に即していない場合に何が起こるかということで、それは「評価基準や体制に合わせるか、もしくは実態に合わせるか」という内部対立が起こるというアドバイスを頂きました。そして、その内部対立を解消できなかったから、結果として主題に掲げたような問題が起きたという指摘も。

確かに特定の個所でスッキリしなかったのは相反するような複数の原因が1つの結果につながっていたからで、どのように対立を解消したのかというところの前提条件がもうひとつ加わればスッキリするんでしょう。そしてその前提条件を導き出すにはクラウドの出番ということになりますね。このテクニックは是非ともマスターしたいと思いました。

続いて、いつもお世話になってるY2研究所の吉田裕美子さんが今企画されているワークショップの検討会を行いました。「こういうストーリーを考えているんだけれども皆さんどう思いますか」という問いかけから始まり、様々な意見が出されました。集まっているメンバーは皆さん論理的に考える方々ですので、建設的な議論が出来て大変有意義でした。

弊社でも今は中断していますが、新人プロマネ向けのワークショップをTOCのツールを取り入れた形でバージョンアップして再開したいと思っていて、この検討会の中で私がまさにイメージしていたようなアイデアが出てたのでとても参考になりました。実現はもうちょっと先になりそうですが、是非ともチャレンジしたいと思います。


「集合知とは何か」西垣通 著

前回採り上げた「2045年問題」とはある意味対極を成す著作です。「2045年問題」はかなり著者の趣味であるSFの色が濃く、コンピュータが知能を持つという話題を提供していましたが、「集合知とは何か」ではその話題を真っ向から否定しています。こちらの著者の西垣氏は本当にコンピュータを専門に研究しておられる方なので、SF的な読み物よりも現実的かつ学問的な内容となっています。

突き詰めていくと「コンピュータとはそもそも何なのか」という起源に遡るのですが、それ自体は本書の論点ではありません。ただ、コンピュータがある情報を入力として、人間の代わりに正確に思考をしてくれる装置として作られたものであり、その一つの形がAI(人工知能)なのだそうです。その背景として「事物を記号であらわし、記号を形式的なルールにもとづいて論理操作することにより、事物についての正確な知がえられる」という論理主義的・形式主義的思想があります。

コンピュータが人間の代わりに問題解決を行う未来、例えば病院に行ったら医師が全く居らずコンピュータが全ての診察と処置を行うような世界、あるいは、裁判所に行ったら弁護士も裁判官も全てコンピュータで、そのコンピュータが即座に判決を下すような世界を想像してみてください。昔の人はコンピュータに専門知識を全て記憶させておけばそういったことが可能であると考えたようですが、実際はそうはなっていません。それはなぜでしょうか。

冒頭に記したように、西垣氏は人間とコンピュータは全く異なる存在であり、コンピュータが知能を持つことは有り得ないとしています。というのも人間が得意なのは「刻々と変化する環境の下で、常識と直観を働かせ、臨機応変に働くことだから」で、これはAIを含めコンピュータがあまり得意ではありません。なのでコンピュータに問題解決を丸投げするのではなく、あくまでも意思決定は人間が行う前提で、その材料となる情報を提供するというのが現在の潮流なのだそうです。

さて、主題に戻りますが、これらを踏まえ、私たちがこれから将来コンピュータやコンピュータを利用した情報社会に何を期待できるのか、あるいは何を期待すべきでないのかということが後半で述べられています。

私たちは兎角「フラットで透明な」社会や組織を望ましいもののように考えがちですが、あるモデルによるシミュレーションの結果によるとそれは却って不安定な社会を招くことになり、逆にある程度の閉鎖性や不透明性がある方が望ましいリーダが生まれ健全な社会が形成されるとしています。

すると望ましい集合知を作るためのカギはコミュニケーションの在り方にあるようです。つまり、何でもかんでもすぐに多数決を取るのではなく、泥臭い対話を重ねて合意形成する方がより良い解決に到達しやすいようです。ソーシャルと言われるネット上のインフラが発達し、そこで形成される意見が多数決で正しい意見のように思われがちですが、必ずしもそれがベストの解ではないということなのですね。


書名:集合知とは何か
副題:ネット時代の知のゆくえ
著者:西垣通
発行:中央公論新社/2013年2月25日
ISBN:978-4-12-102203-5

教育のためのTOC国際認定プログラム2013・最終日

いよいよこの研修も最終日です。最後のツールはアンビシャス・ターゲット・ツリー。私が毎月参加させていただいている勉強会でも事例の少ないツールです。「何でアンビシャス・ターゲット・ツリーの事例発表は少ないんでしょうね?」と半分冗談で質問したこともありましたが、「発表したら実行しなきゃいけなくなっちゃうからじゃない?」みたいな冗談が返ってきたこともありました。

私はこれまでにもアンビシャス・ターゲット・ツリーを教わったことがあったのですが、これまでは全ての中間目標に対応した行動(計画)は必ず書き出さなければいけないと思い込んでいました。ですが、今日の説明では中間目標が具体的にイメージできるレベルの行動として表現されているのであれば、わざわざ行動の欄を記述する必要はないということでした。行動を書き出さなければならないのは、中間目標が抽象的な表現であったり達成できそうかどうかわからないような場合なのだそうです。

ブランチやクラウドと比べると、アンビシャス・ターゲット・ツリーは演習の時間が短く、もうちょっとじっくり取り組みたかったなと思いました。その代わり、講師の方がこれまでより教科書に忠実に進めてくださいましたので、理解は確実にすることはできたのではないかと思います。とはいえ昨日までの三日間は疲れを感じなかったものの、さすがに今日は疲れを自覚しまして、なかなか講師のお話が耳に入ってこなかったのは否定できません。

最後には認定書の授与式があり、TOCfE Inc.会長のKathy女史から認定書が手渡されました。Kathy女史は日本語を話されないので(研修中にお話しされる場合はボランティアの方が通訳されていました)あまりおっしゃってることが聞き取れませんでしたが、感謝の気持ちを込めて私のたどたどしい英語で感謝と決意の言葉をお伝えしました。ちなみに、認定書が予想してたよりもかなりしっかりしたものだったので、それにはちょっと驚いてしまいました。

フィナーレとしてオフィシャルの懇親会が開かれましたが、そこである方に「4日間どうでしたか?」と問われて、とっさに「一言で言えません」としか答えられませんでした。とにかく様々なことを深く深く学びました。もちろん私は仕事の中にTOCの考え方を取り入れていきたいので、これからも練習を重ねて習熟できるように励みたいと思います。この研修に関わってくださった皆さん、お目にかかった皆さん、本当にありがとうございました。