無料ブログはココログ

« [#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて | トップページ | 簡単すぎるネットワークカメラQwatch - TS-WLCAM - »

[#TOC] 答えをみつける機会 - 「考えろ!」だけでは考えられない -

先日、TOCfE関西TOC/TOCfE関西分科会~ごちゃごちゃすっきり!ブランチ講座~に参加してきました。

TOCとは

最近、トヨタ生産方式の流れを汲むTOC/TOCfEがじわじわと広がっています。TOC/TOCfEは知らなくても「ザ・ゴール」という全米で250万部売れたベストセラー小説ならご存じの方がおられるかもしれません。

TOCというのは著者のゴールドラット博士がまとめた制約理論を基礎とするものです。中でも、個々の作業ごとに持ってしまいがちな作業のバッファをプロジェクトでまとめて管理することで高い生産性を実現するCCPMが有名です。

TOCfEとブランチ

そしてその2作目の「ザ・ゴール2」で書かれたのが、TOCをベースにした思考法であるTOCfEです。TOCfEには3つの有名なツールがあります。

  • ブランチ:なにを変えるのか
  • クラウド:なにに変えるのか
  • アンビシャスターゲット・ツリー:どうやって変えるのか

今回はブランチです。

ブランチでは、次に用に考えます。

1)隠れた思考の要素を導きだす。
2)「なぜならば」にあたる隠れた推論を導きだす(下から出る場合もれば、下から出る場合もあります)。
3)ブランチは正しいのか、内容を明確にし、存在有無、因果関係、十分な条件、から?因果関係を確認する。

気になった言葉

分科会ではいつものように、TOC/TOCfEの説明、ブランチの説明、演習、とあって、演習では付箋を色分けしているチームもあって、勉強になりました。

いつものTOC/TOCfEの説明でしたが、今回はゴールドラット博士の言葉が気になりました。

「学ぶことの最大の障害は答えを教える事ではないか?それは、自分で答えをみつける機会を永久に奪ってしまうからである。」

この「答えをみつける」とは、一体、どういう意味なのでしょう。ゴールドラット博士は、TOCfEの思考のツールを与えて、答えをみつけることの重要性を語られています。つまり、ツールを使ってもっと大切なことを考えさせようとしているのだと思います。

「考えろ!」だけでは考えられない

プロジェクトにトラブルがあったとき、「考えろ!」と言ったり、「考えさせろ」(あるいは「ちゃんとやれ!」)という指示をされていませんか?それは答えをみつける機会を与えているでしょうか?

指示する側から見ると、こうすれば良い、それぐらいわかるだろう、そんな思いがあるでしょう。でも、なぜそう思えるのでしょうか。どんなやり方があり、それぞれの特性を知っているから、適切な方法を思い浮かぶのだと思います。

もし、やり方を色々知っていて、考えないでいつも通りやっているなら、「考えろ!」は的確だと思います。でも「考えろ!」と言う人に限って、どのような方法があるかを教えずに、考えさせようとしていないでしょうか?

「考えろ!」という人も、多くの場合は過去の経験やどこかで知ったことを状況に合わせて適用しているだけなのですが、それを自分で考えたと思っていないでしょうか。

車輪の再発明をさせてはいけない

「答えをみつける」ということは、先人の知恵をどのように活かすかを考えることです。何もない所から、車輪の再発明させることではないと思います。

もちろん、工夫をしていたら同じようなことをしていたということもあるでしょう。でもそれは、知っていれば苦労せずに長所短所を知ることができて、さらに高度に発展させられたかもしれないのに、汎用化されていない似た様な事しかできていないのです。

いまだに、NIH症候群は根強いのでしょうか。

魚を与えるのではなく、魚の釣り方を教える

ゴールドラット博士の言葉は「考えろ!」というのではなく、「教えろ」と言われているのではないでしょうか?

たしかに「俺の若い時は」と思うことも多々あると思いますが、昔と今は違います。かつては、言語の本かマニュアルを1冊読んで、一通りのアルゴリズムを知っていれば良い時代でした。しかし、いまや言語はもちろんのこと、フレームワーク、アーキテクチャ、レビューやテスト技法、開発標準、法律、などなど、しかも、業務によってニーズは大きく異なります。

答えをみつける機会を与えるには、先ずその方法を教えることが必要だと思います。ポイントは「教える内容」であって、「教えないこと」ではないと思います。方法やツールを与えて解決策を考えさせる。TOCfE分科会で行われているような教え方が必要だと思います。


« [#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて | トップページ | 簡単すぎるネットワークカメラQwatch - TS-WLCAM - »

ソフトウェア」カテゴリの記事

TOC/TOCfE」カテゴリの記事

コメント

私は教えることだとは必ずしも思いません。
「答え」や「解法」「方法論」ではなく、答えに至るまでの道筋を大切にするべきだという立場です。
いまのソフトウェアの現場の人たちはある意味、かわいそうだなあ、と思います。世の中にはいろいろな情報があふれてしまっている。なんとかBOKもたくさんあります。
ところが、そういう状況にならされてしまっていて、どこかになんとかBOKやなんとか技法があると思い込んでしまっているように見えます。
ある意味、昔の人たちはそういうのが未整備で、かなり乱暴なことをやっていましたが、その中でTOCのような問題構造を解析し、そこから対策を考えるような思考方法が使われてきました。なんとかBOKに書かれているものも、そのとき、そのときで問題とその解決のために考えられたものに違いないでしょう。
なので、問題構造を考えることをきちんと身に付けることが大切だと思います。そうすれば、新しい条件が加わったとしても、対応できるようになると考えるからです。

コメントありがとうございます。

おっしゃるように「問題構造を考えることをきちんと身に付ける」は、とても大切です。たた、それは「考えろ!」と言うだけでは身に付きませんよね。

それに関する知識がある状態で、体験することで、ようやく身に付く物だと思います。我々は情報の少ない時代の「必然として」数少ない文献をつなぎ合わせる中で、その考え方を知った様に思います。

機械語を学んだ際に、桁あふれやボロービットなどを知りました。そのことはテストの境界値を考える際に役立ちます。しかし、若い人に同じことを教える必要は「必ずしも」なく、対象業務によっては「変数の有効範囲を確認する」と知識を与えることで十分かもしれません。

情報があふれている現代で、我々の学び方が若い人に「必ずしも」当てはまるとは思いません。

はじめまして。長文で失礼します。

私も、考えろと言われても、身につくものと思えませんし
人間のこれまでの知識の継承なんか必要にも思えなくなります。

アイデアは既存の要素の新しい組み合わせ以外何ものでもない。 ~ジェームズ W ヤング

という言葉もあります。

私は、博士は、「考え方を教えろ」「考えて・考えて・考え続けなさい」と言っていると思っています。
教える事においても、探求されていたと思います。

博士の著作を読む時は次のように意識しています。
「私はこの問題にこのように考えて取り組んだことを披露したよ。ツールはその成果物でしかない。
さあ、次は君の番だ」

なぜかと言うと、TOCの4つの概念(価値?)の一つに、「巨人の肩の上に乗って」があります。
これはまさに、先人の知識や経験を駆使して、もっと上へいきなさいという事です。
#いけるのか、行き先あるかはしりませんが( ̄Д ̄;;


さて話は変わりますが
さかばさんとあきぴーさんが、チケット駆動開発を考案したのは、興味があります。


何を問題をとらえて何を実現するために、チケット駆動開発にたどり着いたのか?


何回かコミュニティや勉強会でおみかけしますが、びびりのためお話したことがありません。
次回お会いした時に、是非お話させてもらえればと思います。

fukanoさん
コメントありがとうございます。

巨人の方に乗る事は重要ですね。実はチケット駆動開発は小川さんと私の考案ではありません。すでに公開されていたチケット駆動開発を、小川さんはアジャイルの実現方法として、私は従来型の開発の改善として利用させていただきました。

当時、少しずつ広がりつつあったチケット駆動開発に感銘し、それぞれの経験をまとめただけです。それはすでにあったから皆で議論し、活用できたのだと思います。

それが「考え方を教えろ」「考えて・考えて・考え続けなさい」だったのかも知れませんね。

どこかでお会いしましたら、ぜひ声をかけてください。

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて | トップページ | 簡単すぎるネットワークカメラQwatch - TS-WLCAM - »