「問題」を「前提」にしてしまえ!

このエントリーは、TOCfE Advent Calendar 2015の10日目の記事です。
昨日のエントリーは、土井柾輝さんの”大学生のTOCfE”でした。

中1日で再登板のたのっちです。ホントは5日、10日で書く予定でした。
実はウラでいろいろ調整をしまして。そうしたら、中1日となりました。
ところで、中◯◯と書くと、某メイドの人が浮かんでくるのはどうしてなんでしょうね。(すごくどうでもいい)

「クラウド」とはなんぞや

今日は「クラウド」について書いてみたいと思います。
「クラウド」とは、別名「対立解消図」や「Evaporating Cloud(雲の消滅)」とも呼ばれます。
対立が無くなると、雲が晴れてすっきりする。そんな感じですね。

「なぜ決断をできないのか」

さて、今日は私が昔実際に苦しんだ問題を改めてふりかえってみようと思います。
かつて、私が関わっていた某システム開発プロジェクト。
やっていたのは、人事に関わるシステムの開発でした。

この手の話は、シフトの組み方から給与体系まで、業務の仕組みとして多くのことを決めなければなりません。
大枠は人事コンサルタントなる方が考えて提案をします。
が、実業務の細かいところまでは行き届かない。ということもままあるかと思います。
良くも悪くも、フレームに当てはめて「こうしてみるのはどうでしょう」と提案するのが彼らのお仕事です。ものすごく細かい運用の部分は、やはり現場が決めなければなりません。

こうしたなかで、システムを作っていく中で「ここはどういう形で運用すればよいのだろう」と迷う場面が山ほどでてきます。自分で考えてもわからないので、お客様に問い合わせる。しかし、お客様が答えてくれない。お客様が答えてくれなければ、仕事が進まない。上司からは納期をせっつかれる。それで、えいやで決めて作ると「それは違う!」と差し戻しをうける。

こうしたことが繰り返されると、お互いの関係が悪くなるわけです。ぶっちゃけつらかった。

では、本当はどうすればよかったのだろう。というところを、改めてクラウドで考えなおしてみようと思います。
「仕様を決められない」vs「仕様を決めたい」のクラウド
Android版TOCクラウドアプリを使って書きました。)

意思決定できないヒトではなく、意思決定できない仕組みが問題

もともと、通常業務を回すので手一杯になるような人員配置とスケジュールで動いているなかで、新システム開発の仕様で意思決定をしなければならない。意思決定をするためには、そもそも業務のあるべき姿から考えていかないといけない。
となると、意思決定をするための検討の時間も取れない。

結局のところ、意思決定できないお客様ではなく、意思決定するための検討をする時間を確保することができる体制ではないことが問題だったのだなぁ。と振り返って感じました。
「バグを憎んで人を憎まず」ですね。状況変化から仕組み上のバグ。ホント、人を憎むとロクなことにならない。

問題を解消できないならば、その問題を前提条件にしてしまう

TOCfE流のクラウドでは、お互いの対立を見ずに、真ん中のお互いの要望を両立できる方法を考えます。
一方で、TOC思考プロセス流(のなかでも、特に「全体最適の問題解決入門」で説かれる岸良裕司さん流の)クラウドでは

  • 「相手の行動と自分の要望」
  • 「自分の行動と相手の要望」
  • 「お互いの行動が対立しない条件」
  • 「両者の要望を両立する術」

の4つで考察する「相自時妙」という方法も存在します。

実は、最近自分の思考方法が、後者の考え方。そのなかでも「相手の要望を叶えつつ、自分のやりたいことをしたい」という方向で解決策を考えているなぁということに気が付きました。

この例ですと「そもそもの新システムで実現したい業務のあり方を踏まえると、この◯◯業務では☓☓という形で業務を回すほうがいいと思っています。そのための手段としてA, B, Cの手段があります。どれも一長一短ですが、この判断基準のもとであれば、Aが一番よいと思うのですがどうでしょうか。」
といった具合で、YES/NOのクローズドクエスチョンに持ち込んでしまう。

もし、お客様が意思決定をするための検討の時間がとれないのであれば、こちらで肩代わりをして検討をする。それで合っていればOK。間違っていたら、改めてどうありたいのかを聞く。

といった具合で、自分を制約に合わせたほうが楽だと考えるようになりました。

「問題」を「前提」にすると、可能性が広がる。

こうやって「問題」を「前提」にすることで「あれもできるんじゃないか」「これもできるんじゃないか」という具合で、問題に立ち向かう方法がいろいろ思いつくようにもなりました。

「人が集まらない」なら集まらないでいいじゃない。「発表資料作るのが当日になる」なら、むしろ作らなくてもいいじゃない。それでも成り立つ方法を考えようぜ。

そんな思考から、新しい世界ができるんじゃないかなぁと思っています。

いつもの告知

毎日告知をしている
【東京開催】日常系非日常TOCfE ~日常の中でちょこっとやってみたこと言う会~
も、こんな発想から生まれました。別に大仰なカンファレンスでなくていいじゃない。普段やってることを話そうよ。それでいいじゃん。そんなノリです。

こうしたことを考える人たちの集まりなので、だいぶ振り切った場になると思います。現在、発表順などをうまく活用して、さらに振りきれるように持っていけないか妄想を膨らませております。
(この、振り切り度合いを高める計画を立てるのが楽しかったりします。)

果たしてどんな世界が生まれるか。気になってしまった方は、12月19日(土)秋葉原の会場に遊びにきてくださいませ。

さーて、明日のTOCfE Advent Calendarは?

Akihiro Itoさんが「幼児向けTOCfE教材Chest of Secretsの紹介」をしてくれるそうです。
いったいどんな教材を作られたのでしょうか。なんだか気になります。

広告

「問題」を「前提」にしてしまえ!」への1件のフィードバック

  1. 要求分析はたいていお客様がボトルネックになります。
    そこで、答えが返ってこないから…と言ってるよりは、なるべく相手の負担を減らしまわる方法を探る方が建設的ですね。
    関係が悪化すればするほど、それは難しくなるので、早めに考えてほうが良いですね!

    いいね

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中