最初のお題の完結編ですが、その前にひとつお知らせがあります。1月27日の超高速開発コミュニティ Wagby分科会にて登壇発表します。

http://wagby.com/users/index.html

タイトルは、、「超高速開発で全部できると本気で思ってますか? ～ ポストSI時代のエンタープライズ開発の現実解を見定める」です。特にユーザ企業の方で次の開発をどうするか考える立場の方は聴講いただけるとよいと思います。

初心者向けです

お題の解説に入る前に、もうひとつ。大切なことを書き忘れていました。

この連載は、文章を書くのが不得意な人を対象にしています。具体的には、報告や提案が書いても書いても上司に真っ赤にされてしまう技術者の皆さん、あるいは、そういう部下にどう指摘すればよいのかで頭を抱えている上司の皆さんです。    

文章を書くのが得意な人にとっては、びっくりするような変な例が題材になっていますが、それはそのためです。ただ、実際に社会人になって5年以上経験のあるの技術系の人達の書いたものがベースになっています。

あまり直しすぎない

さて、お題の文章を私ならどう書き直すかですが、私の基本的なスタンスは、もともとの文章の流れをできるだけ変えず、意味が通るような最小限の修正にとどめることにしています。あまりに差が激しいと、どこが悪いのかが、赤入れされる側がピンとこなくなってしまうからです。

難しい単語は使わない方に倒す

まず、大原則として、抽象的な単語は使わないほうに倒すことが大切です。それを意識するだけで、ずっと読みやすいものになります。

• 「文化」と単語はそもそも不要です。処理が紙の帳票で行われているという事実が伝わればそれで十分です。
• 「特性上」という言い回しは、事実間の関係を曖昧にしてしまいます。原因や理由を表しているので、「～によって」、「～のために」などより簡単な文のつなぎ方に変更します。

意味のブレる単語も使わない

抽象的な単語以外にも意味がぶれたり違ったり、自分で勝手な意味付けをした単語も使わないようにします。

• 「機械的」というのは、単語の使い方が間違っています。機械的なチェックとは、決まった手順のチェックのことなので、人間によって行うこともできます。ここでは文脈からシステムによる自動処理によるチェックの話をしていると考えられます。

このような勘違いが含まれている場合は、書いた当人に意図を確認をしない限り、本当にそうなのかどうかわかりません。この例では、実際に確認しています。

• 紙の帳票が使われているからといって、必ずデータが処理できないというわけではありません。そこでシステムで処理できる形式になっていないという説明を加えることにします。

理由付けが十分かどうかは、実際に読む人の感覚で変わるので妥当性は想定によります。ここは十分ではないという想定で加筆することにします。

こうした観点で修正したものが次になります。難しい単語を使わずに丁寧に書いているので長くなっています。

難しい単語を使ってもカッコよくはない

学生のころを振り返ると、難しい単語を使ったほうが、知的で教養があるように感じていたような記憶があります。

ときどき私の文章は格調がなく饒舌と言われることがあります。ですが、使い慣れない難しい単語を使ったところで、元々ない教養をカバーできるわけもなく、気にしないことにしています。

別に難しい単語を使っても誰も褒めてはくれません。まずは誰にも伝わる普通の単語で分かりやすく書くことを心がけましょう。

Facebookでもコメントしましたが、若干加筆してコラムにも公開します。他にも同種の議論をしているIT関係者は結構いる気もしますが、私のIT教育観に関わるのであえて書いておきます。

皆さんは、ネットで話題の次の問題についてどう思われますか?

「6÷2（1+2）＝？」

出題者によれば「この問題を大勢の人が「1」と答えているが、それは不正解で「9」が正解である」というのです。これを受けて、一部のコミュニティでは答えは「1」か「9」かという議論で盛り上がっているようです。

http://getnews.jp/archives/114382
http://grapee.jp/7355

要件定義の認識ズレですよね

要するに乗算記号を省略したときの計算の優先順位の決め方で、二通りの計算結果が出るのですね。それはそれで面白いのですが、この問題からするべき議論は他にもあると思っています。

この例は、一言でいえば、数式の表現の定義が曖昧なために解釈が複数出てしまうという話です。要件定義時によくある認識ズレの一例ですね。自分が正しいと教えてもらったことが、誰にとっても正しいと無邪気に信じてはだめだという教訓でもあります。

人によって当たり前が違うということ。それぞれが持っているコンテキストで、正しいか間違いかが変わること。このことは要件を満たすプログラムを作ることを通じて、IT技術者はごく初期の段階で学びます。「技術者以外の多くの人も学んでいれば、要件定義でのトラブルは相当減るだろうに」と思っています。

シンタックス・エラーにすべきでは？

この例について、私の意見は、「シンタックス・エラーではじくべきじゃないの？」です。そう考える理由は、意図して省略したのか、演算記号を書き忘れたのか区別がつかないからです。多くの人にとって想定外の計算を進めるので、結果が当てにならなくなります。こんな計算式で、高層ビルの構造計算とかされた日には恐ろしくて寝られなくなってしまいます。

そこで、値を計算するというセマンティクス（意味)レベルの処理の前に、シンタックス（文法)レベルで確認しておくというのが、IT分野を切り拓いた先人の知恵なわけです。古くはFORTRANの暗黙型宣言、比較的最近だとHTMLの終了タグの省略、など言語処理系で勝手に省略した部分を埋めてしまうと、見つけにくいバグを作りがちだよという議論にも通じます。

IT技術者が受け継いでいるもの

大げさな言い方をすれば、シンタックスとセマンティクスの概念をはじめ、コンピュータ技術の探求・深耕を通じて人類にもたらされた有益な知見は多数あります。モデルとビューなんかもそうです。数学的な厳密さを、普通の人が行う日常の仕事に持ち込む局面は、ソフトウェア開発以外にはそう多くありません。

ITの教育について、工学技術として教えるだけでなく、物事の捉え方のリテラシーを高めるという観点から議論してもよいと思うのですが、いかがでしょうか。

ということで、あっという間に時間切れになりましたので、次回こそ最初のお題を終わらせます。

昨日更新したかったのですが、その前に参考書籍を調べていたらつい読み込んでしまい、気づいたら時間がとれなくなっていた次第です。引き続き試行錯誤しながら、ゆるゆる続けていきますので、大目に見ていただけたら幸いです。

さて、今回のお題についての私の考えを示す前に、基本的な考え方を説明しておきます。

公式集でなく基本定理へ

良い文章の書き方の本は世の中にたくさんあります。その中で良い本もたくさんあります。ただ、多くは良い文章を書くためのTIPs集になっています。

TIPs集について、私は高校の数学などの公式集みたいなものだと思っています。数100もあるので、暗記できないという話になるのですが、これらはいくつかの基本の定理を覚えていれば、必要に応じて自分で組み立てることができます。

同じように、文の書き方も大きな原則を幾つか持っていれば、細かい規則は必要に応じて組み立てて使うので十分ではないかと考えています。

ワンパスで読めること

私は仕事で使うような文章は「確実に伝わる」ことが最も重要だと思っています。このための原則を一言でいえば「ワンパスで読めること」です。「ワンパスとは何？」とか、書き始めると終わらなくなるので、今回はここまでにして、簡単にまとめると次のようになります。

• 美しい日本語であるとか、流暢な文とか、格調の高い文とかは、重視しません。
• 重視するのは、読む人が苦労することなく、正しく理解できることです。
• 書く人の視点では、誤解されたり、問い合わせの来たりするリスクが少ないことです。

こうした前提を踏まえた上で、今回のお題を見てみます。

抽象語・難解語を気軽に使わない

この文で気になるのは、抽象的な言葉が多く使われていることです。

• 「文化」って何？
• 「特性」って何？
• 「機械的」って何？
• 「不整合」って何？

こういう難しい単語は人それぞれ持っている意味の理解が異なっています。最初に出てくる、「文化」と言われて、皆さんは何を連想するでしょうか？

私だと、元禄文化、室町文化、縄文文化、文化人、文化人類学、文化祭、文化大革命、・・・といった感じです。現時点のWikipediaによれば、「人間が社会の成員として獲得する振る舞いの複合された総体」だそうで、えらくまた難しい単語をもってきたなあと思います。

こうした難しい単語は、数が増えるつれて書き手と読み手の理解の差が大きくなって、伝えたいことが伝わらなくなるリスクが上がります。日頃から使い慣れていない言葉は、気軽に使わないことですね。

他の単語についてもひとくさり書いた上で修正までするつもりでしたが、またしても時間切れです。この続きは、次回(多分水曜日)にします。

エンジニアの皆さんにとって、そして私にとっても、2015年が良い年になりますよう、心よりお祈りいたします。

さて、年末に予告しましたように、今月からコラムを再開し、色々な小ネタを出して、コラム中であーだこーだ検討するのを続けていきたいと思います。

ただ、これまでも、何度も再開しては途中で終わってしまいました。これはある程度の説得力を出そうとして書き込みすぎて、長くなったのが敗因ではなかったかと思っています。

長くなると構成が気になるし、チェックも大変になるため1日作業になってしまい、忙しくなると更新できなくなるのですね。
そこで、今回は短めにさくっと書いて、さくっと読めるものを目指そうと思っています。

具体的には次の方針で書いていきます。

• 説得力はあまり気にせず、1時間程度でできる範囲で書きます。
  きっと突っ込みどころ満載です。炎上しないことを祈るばかりです。
• あまり日本語としてちゃんとしていないかもしれません。
  誤字脱字くらいは気にしますが、校正はほどほどにします。
• 1～2ヶ月したら選択的に(ネタとその解説)記事を削除します。
  以前の投稿との整合性を考え出すと大変だからです。
• テキストの議論を始めると本業の仕事が何もできなくなるので、
  質問や異論反論への対応は当面しないつもりです。

では、早速、新年最初のお題から。

上の文は、ある会社の現状業務の特徴を説明した文章の一部を抜き出したものです。
皆さんなら、これを読んでどう思いますか？これでOKとしますか？ 書き換えるとしたらどうしますか？ どのように書き直しを指示しますか？

あまり良い文ではないのですが、理解できないわけでもなく、修正を指示しようかどうしようか悩むあたりのところです。

さて、筆者の考えですが、そろそろ時間が来ましたので、次回(たぶん明日)にて説明します。

ではまた。

私自身が「ロジカル・シンキング」という単語をタイトルに含む本を書いておいて、言うのもなんですが、ロジカル・シンキングは民間療法のようなものだなあ、と最近はつくづく思っています。ITエンジニアも、仕事のランクが少しずつ上がるに従って、どうしても議論をまとめたり交渉したりする場面が出てきます。そのために、できるだけ早くから論理を扱える力（リテラシー）を高めるのがよいのですが、なかなか身に付けにくい状況にあります。この状況をまとめた上で、正しく論理リテラシーをつけていくために有用な本を紹介したいと思います。

ロジカル・シンキングが民間療法だとなぜ悪いのか

ここで、ロジカル･シンキングと呼んでいるのは、MECE、ピラミッド・ツリー、ロジック･ツリーなどの外資系のコンサルティング会社由来の議論の構造化テクニックのことです。そして、民間療法に似ていると言っているのは、これらは次の2つの特徴を持つからです。ひとつは基盤となる理論が確固としていないこと、もうひとつは、属人的な要素が大きく、流儀が少しずつ違うテクニックがたくさんあるということです。この2つの特徴にはもちろん関係があります。しっかりした基盤となる理論があれば、そこを中心に流儀も統一できるからです。

あらかじめ断っておきたいことは、私は民間療法を決して低く見たり、ばかにしているわけではないということです。私自身、整形外科では治らなかった椎間板ヘルニア系の腰痛が、保険の効かない整体療法一発で治ったということを経験しています。西洋医学では説明のつかない、本当に使える療法があるのは間違いありません。ただその基礎となる理論が、科学的な臨床データを積み重ねて検証したものではないため、西洋医学と同列に見られないという人が少なくありません。また、個人のスキルの差が大きくいろいろな流派もあるようです。

ロジカル・シンキングもこれと同様の様相を示しています。ロジカル・シンキングは、コンサルタントが使って有用性があったテクニックの集合体です。役に立たないはずがありません。ただ、そこに付けられる理論が、現代的な論理学の緻密な積み重ねとは全く関係がなく、正規の学問の体系に組み入れることができません。そして、論者ごとの力量に負うところが大きく、使うツールも論者ごとにいろいろと違っています。基盤が確固としておらず、種類が多くなると何がいけないかというと、学習効率が悪くなるのです。何か正しいのか判断に迷うため、身に付けるのが大変になります。

私もロジカル・シンキングのの一論者ではあるのですが、できるだけ正規の学問体系である論理学に近づけ、また、属人化してしまう要素を小さくしていきたいと思っています。そのほうが学習効率をずっと高くできるからです。その現時点での成果がMALTというロジカル・シンキングの新しい体系になります。詳しくは私の本「ITエンジニアのロジカル・シンキング・テクニック〔新装版〕 」をご覧ください。

ロジカル・シンキングと論理学は無関係

今から思うとロジカル・シンキングと呼ぶのは誤解を招きやすいので、適切なネーミングではなかったのではないかと思っています。少なくとも、ロジカル・シンキングと論理学には関係がありません。ロジカル・シンキングからの流れで、論理学に興味をもって本屋に行って論理学の教科書を手にとって開くととても悲しい思いをします。

論理式がいっぱい並んでいて、まあ、普通の人はめまいがします（私だってそうです）。 数学によほど慣れている人でもなければ、はっきり言って、この時点で引きます。それでも気をとりなおして、時間をかけて追いかけていっても、やっぱりこりゃわからん、俺の頭じゃわからん、と思って投げ出すタイミングが来ます (私はしつこいので何度もトライしていますが、途中で投げ出すのもこれまた何度も経験しています) 。

ここで正当化の誘惑にかられることがあります。こんな分かりにくいのは説明が下手だからであって、自分の頭が悪いせいではない。よって、こんな理論はないものとして、誰にでもわかる範囲から説明を組立てるべきだ。この気持ちは本当に良くわかります。でも、正規の学問からはすでに忘れ去られているような古典論理学から、三段論法、演繹、帰納などの道具を持ち出してきて、それが基礎になっていると主張するのはあまりよいアプローチとは思えません。扱いきれないのなら「ロジカル」とか「論理」とか言わないほうがよいのに、と思います。

論理リテラシーを高めるために

一方で、論理学の方ももっと分かりやすい説明をしてくれてもよさそうなものです。私は心からそう思っているのですが、これについては、野矢茂樹先生がいくつか非常に良い本を書いて下さっています。ITエンジニアの論理リテラシーを高めて、民間療法のようなロジカル・シンキングの指針に振り回されないためにも、これらの本は非常に貴重なので、紹介しておきたいと思います。

■はじめて考えるときのように―「わかる」ための哲学的道案内 (PHP文庫)

薄くてとても読みやすい本です。考えるということや論理ということについて、実はあまりよく分かっていなかったということに気付かされ、自分から考えていくためのヒントのようなものを得ることができると思います。なにより良いのは、論理式が出てきませんから、誰にでも軽く読み進められるということです。

■新版 論理トレーニング (哲学教科書シリーズ)

この本はタイトルが「論理」で始まっていますが、基本的には文章の書き方の本です。この本における論理のとらえ方は広く、有機的なつながりをもった文章そのものまで含んでいるためです。良いドキュメントを作成するスキルの向上に直結します。こちらも論理式は出てきません。論証図と呼ぶ議論の構造を表す図は出てきますが理解するのは難しくありません。

■論理学

論理学について基礎的なところだけでも理解しておきたいという方におすすめです。野矢先生と数百年前の二人の禅僧の仮想的な対話を通じて展開していくので、楽しく読めます。論理式も出てきますし、徐々に難しくなっていきますが、最初のほうはそれほど難解ではないので、わかるところまで読むだけでも論理リテラシーは上がると思います。

これからますますグローバル化が進むにつれて、日本だけでなく海外でも通用する論理的なコミュニケーションスキルが重要になります。ぜひ、将来をになっていくITエンジニアの皆さんには、正しい論理リテラシーを身につけて欲しいと願っています。

前回紹介した「おれは間違ったことを言っているのか？」と同様、私の心に残る台詞（悪い意味でですが…）がいくつかあります。そのひとつが、「おれの言いたいことが何かわかるか？言ってみろ」というパターンです。私もかつての上司から何度もやられましたが、この台詞が出てくるのは、大抵は何かミスをしたときの説教モードのときです。

何が気になるかというと、正しく答えられる見込みがほとんどないところです。私は現在、教育やトレーニングで講師をする機会が多いのですが、そのときに説明した内容の理解を確認するために質問をすることがよくあります。そのときの経験から言うと、自分の思ったとおりの答えをしてもらえることはまずありません。よほど簡単な質問で、よほどうまいタイミングで、よほどうまい聞き方をしたときに限るということです。

圧迫状況下で「おれの言いたいことが何かわかるか？」なんて聞き方をされて、正しく答えられるわけがありません。答えられないと怒りが増すことが予想できるのも厄介です。人によっては、繰り返すこともあります。アルゴリズムで書けば次のようになります。

"おれの言いたいことが何かわかるか？言ってみろ。"と言う;
こたえを聞く;
"ちがう"と言う;
while (まだ気が済まない) ｛
    "もう一度よく考えて言ってみろ"と言う;
    こたえを聞く;
    "ちがう"と言う;
}

そもそもミスをしてへこんでいるところに、これをされると本当につらくなります。加えて指摘すると、基本的に質問者主導の後出しになっているので、答えが正しくても、あるいは、質問者があらかじめ答えをもってなくても、「ちがう」と言えるということも覚えておきましょう。要するに誰にでもお手軽にできる「プチ・パワハラ」なわけです。

書いていると、なんとなく、パワハラの指南をしているようにも見えかねませんが、私の意図は、あくまで被害者にならないための心理的自衛策の提供にあります。この状況に追い込まれたら耐えるしかありませんが、上のアルゴリズムを思い出して、何回目のwhileループになるかカウントするくらいの心理的余裕を持って臨みましょう。

P.S. ちなみに、気付かれた方はいるかもしれませんが、今回は前回と違って、「です・ます」調になっています。レクチャーモードは「です・ます」調、雑感モードでは「である」調が良いかと思って、前回はやってみたのですが、書いていてあまりしっくりこなかったので、今回は方針を変更しています。

それまでの間、このサイトと「MALT100％」のほうで、毎週、目標的には月曜更新で、補足的な雑感を書いていきたいと考えている。

さて、前々回で紹介した肉食系マネージャとの対話だが、まあ、あそこまでいくと、ほとんどパワハラの一種だろう。特に、気に入らないのが「私は間違ったことを言っているか？」という台詞だ。

私も何度となく、かつての上司からやられたことがあるが、とてもフラストレーションがたまる。その理由は、この台詞の文字通りの意味の裏側にあるメッセージのためだ。言うまでもなくお気づきと思うが、この裏側には「まさか、間違っているなんていわないだろうな。」というメッセージがある。さらに場合によっては、「まさか、おれに逆らうつもりはないだろうな。」という脅しが隠れている。結局、脅されて同意をさせられるのと変わらない。

「間違っています。」と答えて反論を試みたことも何度かあるが、上司の側も反論できないはずということに相当の確信度を持っているので、冷静な議論にはならないことが多い。感情論になりそうなら、やり過ごすしかないが、それでも自分の考えをしっかり堅持し続けることは大切だと思う。

私が何より気になるのは、どうしてそうまでして、無理な説得をして、同意を押しつけないといられなくなるのかというところだ。結局のところ「心から同意して従ってもらう」ということを求めなければならない、という強迫観念があるからではないのか、というのが私の考えだ。

「心からの同意」は確かにできればベストだが、人それぞれ考えは違うので、そもそも無理がある話である。チームとして動くときに不協和音を出してもらっても困るが、「心から」というところまで求めなくとも、支障なくひとつのゴールに向かって進むことはできるのではないかと私は思うのだが、どうだろうか。

今回紹介する「ちゃぶ台返し」のテクニックは、「ロスト・スキーヤー現象とその悪用（1）」で紹介したタイプのものになります。ここで改めて事例を確認しておきます。

情シス部門からコンサルタントに対して、最初の依頼として「全社規模でのシステムの見直しをしたい」という依頼がされました。ところが、コンサルティングを受けた結果出てきた結論は、なんと最初の課題とまったく異なる「商品戦略を見直す」というものになっていた、というものです。ここまでこの連載につきあって下さった方なら、この理由はおわかりだと思います。そうです。一度、目的のレベルをずっと高く持ち上げて、下ろしてきたからです。この元々示された課題を「そんなことはどうでもいい」と言わんばかりに、別の課題にシフトしてしまうのが「ちゃぶ台返し」です。

◆コンサルタントの提言が「ちゃぶ台返し」になる原理

「悪用」と書いていますが、実際には悪意があってやっているつもりではなく、たいていの場合は、ただコンサルタントの職務に忠実に仕事をすると自然にそうなるだけのことです。まず、コンサルタントたるもの、顧客の持っている問題意識をそのまま鵜呑みにしてはなりません。「全社規模でのシステムの見直しをしたい」という依頼を受けると、「それが真の課題かどうか」は至極当然の、むしろ持たなければならない疑問です。したがって、次のように指摘するのはコンサルタントとして義務に近いものです。「今お話しされたシステムの問題よりも本質的な課題があるかもしれません。」そして、これは定義次第で100%正しくなる指摘です。これまでの説明からおわかりのように、より上位の目的のことを「本質的な課題」として示せばよいからです。

「システムの見直しをする」ことは、会社全体の業績向上といった目的から、ゴールツリーをかなり下のほうまで展開された施策であることはまず間違いありません。「システムの見直し」の目的はよりビジネスに直結する目的の解決をしていくための支援手段と位置づけられます。例えば、顧客管理のためのシステムでも、在庫管理システムでも、結局は商品を購入した顧客の満足度を高めるための手段です。また、営業支援のシステムは商品販売の拡大を、BIシステムであれば商品の企画のための手段となります。つまり、どんなシステムであっても、ビジネスの基本である商品を開発し、販売し、提供して利益を得るというプロセスのどこかを支援しているので、「システムを前提とせずその課題こそ解決すべきです」という提言はいつも可能なのです。

さらに言えば、システム課題をより上位に目的にシフトして別の課題を設定する場合、しばしばそのコンサルタントが得意とする分野の課題になります。これもそのコンサルタントが意図してもしなくても、自然にそうなります。なぜなら、課題を検討する際に、自分がもっとも多く経験して、よく知っている領域についての欠点が目につくに決まっているからです。

◆「ちゃぶ台返し」は良いのか悪いのか

ただし、この「ちゃぶ台返し」つまりシステム課題を上位課題にシフトする提言が説得力を持つには条件があります。それは提言を受ける相手が、元の依頼相手より経営層に近いことです。より上位レベルの目的にコミットしている層に提言するから、より上位への目的展開に意味が出るのです。もし、相手が最初に課題解決を依頼してきた情シス部門の人であれば、「余計なことはいいからシステムの範囲で仕事してください」と言われるだけです。これは社内で社員が提言をした場合も同じことです。自身が直面している問題には必ず上位の経営課題がありますが、一般の社員には、自分の抱える問題を棚に上げて、より上位の経営層に課題解決を求めるようなことはできません。経営層までリーチできるコンサルタントだから、個別の現場的な前提をひっくり返してしまうことができるのです。

図 関係者ごとの課題の責任範囲の違い

この「ちゃぶ台返し」がはたして悪いことなのかというと、その判断は微妙です。より上位の目的である「商品戦略の見直し」のコンサルティング結果が効果を発揮して業績向上できたとすれば、経営層の視点からすれば、施策の設定を変えたことによって良い結果が出たと言えるでしょう。ただ、通常、コンサルタントは指針まで作りますが、実行するのは依頼会社自身です。コンサルタントによって作成された計画や指針を、実際に実行する現場を巻き込んで進めて成果がでるまでに至るには、延々と努力を積み重ねていく必要があります。いくら経営的な視点から良い計画であっても現場の協力が得られずに、結果が出るまでに至らないことはよくあります。そうなると、結果は「良くなかった」ということになるでしょう。

ここで最初の依頼部門である情シス部門の立場に戻って考えてみましょう。システムの見直しという当初の目的は果たせないので、部門にとって責任範囲である問題は残されたままです。せっかく経営層に掛け合ってつけたコンサルティング費用が自部門とは無関係なところに消費され、しかも結果も出なかったとすれば、迷惑極まりない話です。

◆ロスト・スキーヤー現象に翻弄されないために

以上、ロスト・スキーヤー現象と呼んでいるマネジメントの混乱パターンを紹介しました。このパターンは目的のレベルを上下させる過程で当初予定していたのとは異なる施策を実施してしまうもので、意図しなくても生じますが、混乱を意図的に起こすこともできます。悪用例として「言い訳」「無茶振り」「居直り」「ちゃぶ台返し」を紹介しました。いずれも上位レベルに目的を移すほど抽象的なものになり誰もが合意できるものになること、そして上位目的に責任を持つのが会社の組織上のより上位で権限の大きな人であることが混乱をもたらします。

これらはいずれもテクニックと考えるとあまりお奨めできない種類のものですが、知らないうちに被害者にならない意味では、知識を持っていくことは重要です。ロスト・スキーヤー現象による混乱を防ぐには、ゴール・ツリーをしっかり把握しておくことが大切です。自分が進めようとしている施策の目的を上位レベルまで理解しておくことと、そこから導き出せる施策の代替案について検討しておくことが重要になるのです。

なお、このゴール・ツリーの活用やロスト・スキーヤー現象というテクニックは、かならずしもビジネス上の課題解決のためだけに有用なものではありません。あまり具体的にすると、生々しくなるので詳しい説明はしませんが、例えば、転職を考えるような場合でも、「それは何のため」という上位目的をしっかりさせることで、他の可能性を網羅的に検討することができます。このような人生の重要な意志決定でもゴール・ツリーによる分析は有効ですので、ぜひ使ってみて下さい。

次回は、また少しネタをTwitterで作ってからにしようと思います。こちらの経緯は、別のコラムで書いた記事『「言い訳しやすさ」で人はより能動的になる』をご覧下さい。また、Twitterのタグなどについては、最初に紹介した「MALT100%」のほうを参照下さい。

　この度の震災によって亡くなられた方のご冥福をお祈りすると共に、被害に遭われたすべての皆様に、この場を借りてお見舞い申し上げます。

　さて、前回はロスト・スキーヤー現象を使って、熱血型のマネージャが無茶振りをするパターンについて紹介しました。「ロスト・スキーヤー現象」というのは、筆者が名付けた典型的な論理の混乱パターンのひとつで、いつの間にか課題解決のために当初想定していたのとは違う行動を選択してしまうというものです。今回は、肉食系マネージャによる無茶振りのパターンを紹介します。併せてこの変形例である「居直り」のテクニックも紹介します。

◆無茶振りパターン≪肉食型≫

　では、肉食系マネージャにご登場願います。状況は前回の熱量型のときと同じです。

• マネージャ 「私が見ているコールセンター部門のシステム検討のリーダーをお願いしたいのだが」

• 担当 「ちょっと無理です。今取り組んでいる商品配送部門の作業ミスを減らすためのシステム連携の活動に集中したいのです」

• マネージャ 「おいおい。君のような責任者レベルがその次元の認識では困るな。配送業務のシステム連携は何の目的でするんだ？」

• 担当 「作業ミスをなくして効率化するためです」

• マネージャ 「そんな答えじゃあだめだ。その目的を考えろと言っているんだ」

　肉食系の本領発揮で圧迫です。

• 担当 「それはお客様に対して商品を間違いなく素早く届けるためです」

• マネージャ 「まだ、理解が十分じゃないな。その目的は何だ？」

• 担当 「抽象的ですが、当社の製品を購入したお客様の満足度を高めるためではないでしょうか」

　こうなってしまうともう後戻りはできません。

• マネージャ 「そう。君の活動の本質はサービスの満足度は製品だけでなく配送からサポートまでトータルで最大化することだ。違うか？」

• 担当 「そうも言えますが……」。

• マネージャ 「そのためにコールセンター部門の活動強化は重要だろう？」

• 担当 「それは確かにそうですが……」

• マネージャ 「我々の目指すところは結局同じと言うことだな。私は間違ったことを言っているか？」

• 担当 「いえ、間違ってはいません。」

• マネージャ 「じゃあ私の活動に協力してもらえるね？」

• 担当 「……できればそうしたいですが、今の仕事があるので……」

この答えではOKしたも同然です。

• マネージャ 「わかった。君の上司には私が話をしておく」

となります。

　自席に帰る頃には上司に次のような話が通っていることでしょう。
「彼に私の部門の状況を話したところ、目指すところは同じだという話になって、できることなら協力したいといってくれているんだ。少しこちらの作業に手伝ってもらっていいだろうか？」

　微妙なニュアンスの違いを除けば、この肉食マネージャが上司に言っている内容はすべて事実です。担当者が自発的に進んで言ったのでないというところだけがどこかに行ってしまっていますが、気の毒ですが、本人以外それを重視する人はあまりいません。しかも、頭の痛いことに、肉食系マネージャの頭の中ではまことに好都合にも、担当者が自発的に進んでそうしたと脳内変換されていることも珍しくありません。

　上司が熱血型のケースと肉食系のケースを見てきましたが、2つには共通点があります。目的を上位レベルに持って行ってから、「君と私は目指すところが同じだ」というところに持ち込んでいます。その上で、担当者の想定とは違う実現施策への協力を求めています。

　このテクニックのポイントは、目的を上位に持っていけば必ず、合意できるところがあるということです。上位目的になるほど、抽象的で拒否できないものになります。そこから熱意や権威を使うことで、担当者が元々提案しているとは違う施策にシフトしていくのです。

◆無茶振りによる組織統制

　以上、いったん上位目的に持ち上げて施策をすり替えることを「無茶振り」と名付けて悪用テクニックのひとつとして紹介しました。

　しかし、別に筆者はこの「悪用」は絶対にしてはいけない手口として非難、糾弾するつもりはありません。日本の職場において、現場の合意形成は非常に重要です。むしろ、このくらいの熱意と強引さで周りを巻き込んでいくくらいでなければ、なかなか会社を変革したり、新しいことを進められないという面もあります。ただ、無茶振りされる側として、知らない間に作業がすり替わっていたということがないように気をつけたいものです。

　無茶振りのテクニックは、基本的に上司が部下に使います。論理的で問題意識の高い部下ほど押し込まれやすいと言えます。上位目的は否定しにくいですし、「おれが何か間違っていることを言っているか？」と凄まれて「はい。間違っています。」とはなかなか言えません。

　今時の会社では権威だけを使って、「つべこべ言わずに自分の言うことを聞け」ではなかなか組織の意志統一には至りません。権威に加えてロスト・スキーヤー現象を使った「無茶ぷり」を併用することで、強力な統制を実現している例をしばしば見かけます。

◆居直りパターン

　「無茶振り」の変形テクニックに「居直り」があります。これは、以前に出した指示と別の指示を出すときに使われます。前言った指示と新しい指示は、結局は同じことなのだと主張するわけです。

　「今の指示は前回受けた指示とは違っていると思います。」などと言ってみたところで、やさしめな上司であれば「ひょっとすると、前回の指示でちゃんと目的が伝わっていなかったようで、申し訳ないが、私は別のことを指示しているわけではないんだ」となるでしょうし、肉食系上司であれば「もし、前回の指示と違うように聞こえるのだとすると、それは君が目的をちゃんと理解していないからだ。やるべきことは何ら変わっていないぞ」などと言われます。

　いずれにしても目的レベルの設定を自在に変える上司を持つと部下は大変です。無茶振りや居直りのテクニックで、振り回されるのを避けるにはあらかじめ上位目的を想定し、自分の進めている施策に代替施策がないかを把握することが必要です。そして進めている施策が他のよりもよい施策であることを納得させられる説明を持っておくことが大切です。

　次回、「ちゃぶ台返し」の解説で、「ロスト・スキーヤー現象とその悪用」編を完結します。

　事業企画や業務効率化を行うコンサルタントは、その領域でよく使う定番の枠組みを知っていて、それを活用することで効率よく提言をまとめています。こうした枠組みはフレームワークと呼ばれています。なお、システム開発で使うソフトウェアフレームワークとはまったく関係ありません。

　コンサルタントがフレームワークには様々なものがあります。企業のビジネス戦略を立てるための基本となるフレームワークとして、3CやSWOTなどのフレームワークがよく基本として紹介されることがあります。こうした有用なフレームワークの中でも、とりわけ応用範囲が広く、ITエンジニアの日々の仕事にも活用することができるお勧めのものがいくつかあります。

　その1つが、今回お話しするPDCAサイクルです。もう1つは、わたしが「課題解決フレームワーク」と呼んでいるものですが、こちらはわたしの本の中で詳しく書いていますので、また別の機会に触れたいと思います。

　さて、ここでお約束の宣伝をひとつ。

　2月27日にITエンジニア向けのロジカル・シンキングセミナーを開催します。講師はわたしです。

• 「超」ロジカル・シンキング体系 MALT(モルト)講座（導入編）
  ～顧客・上司の心を動かす「説明力」を身につける～
  

　プログラムは、キャリアの幅を拡げていきたいITエンジニアの皆さん向けに構成してありますので、ぜひ参加をご検討下さい。

では、本題に戻ります。

◆まずは、まじめにPDCAとは何か

　PDCAサイクルはとても有名な考え方なので、このコラムの読者であれば大半の人がご存じかもしれませんが、まずは、まじめにPDCAとは何かを説明しておきます。

　PDCAというのは、生産管理や品質管理を行うための基本となる考え方です。Plan（計画）、Do（実行）、Check（評価）、Act（改善） のステップを繰り返し行うことによって、目的に近づいていくというものです。何度も繰り返すことから、PDCAサイクルという呼び方がされます。簡単に言ってしまえば、まずは、どうするのかよく考えて（Plan）から、実行（Do）し、その結果を検討して（Check）、修正をする（Act）という考え方です。これを繰り返せば、目的に近づいていくことができるという話です。下のような図がよく使われます。

図1：PDCAサイクル

　「なんだそりゃ。あったり前じゃん。」と思ったあなた、これがなかなかできないんです。

　何でも構わないのですが、例えば、プログラムの品質を高めるための標準を定めたとしましょう。最初のうちは皆が従っていたその標準も、時間が経つにつれて開発環境の変化などで実態に合わなくなったりすることもあるでしょう。あるいは、やってみたけれど例外が多いので守り切れなかった、また、思ったほどの効果はなかったということもあるでしょう。そういうことが繰り返されると、時間とともに少しずつその標準は使われなくなっていきます。1年も経つころには、もともと目的としていた品質向上ができなくなった、そんな経験はないでしょうか。

　この場合、最初に標準を定めたのがPlan（計画）で、それを実際に適用しているところまでがDo（実行）です。その後、実行結果をちゃんと評価（Chek）して、もし不都合があれば改善（Act）を行うことを行ってはじめて、標準は常に最適な状態に保たれ、目標とした品質に到達することができるということになるのです。特に後半のCheckとActは軽視されがちなのですが、継続するのは意外に大変で、しっかりできていないケースはよく目にします。

　PDCAサイクルの由来を聞けば有り難みが増すかもしれません。この考え方は、第二次世界大戦後の日本企業に品質管理を指導したアメリカの統計学者、デミング博士によって、品質管理（QC）の考え方ともに導入されたものです。その後、日本の製造業が品質を急速に向上させ20世紀末の数十年の間、世界一の工業大国として君臨できたのはこのPDCAサイクルのおかげなのです。

　わたしは製造業の会社が出身なので、入社したとたんに、この考え方についてしっかりと指導を受けました。「なんだそりゃ。あったり前じゃん。」と思ったものです。

◆万能フレームワークPDCA

　このPDCAサイクルの考え方は、非常に広い範囲で使うことができます。皆さんの日々の活動でも何か達成したいことがあれば、このPDCAの枠組みをうまく使うことで確実に進めていくことができます。PDCAサイクルの見方ができるようになると、本当にいろいろなところにPDCAサイクルを見つけることができます。

　例えば、車の運転。右カーブを曲がろう（Plan）としてハンドルを右に切ります（Do）。その結果、少し切りすぎたと思う（Check）と、少しハンドルを左に戻します（Act）。この繰り返しによって安全にカーブを曲がり切ることができます。

　例えば、料理の塩加減。最後に味を整える（Plan）ために、塩を入れます（Do）。その結果、少し水くさいと思う（Check）と、塩を追加します。この繰り返しによって、料理はおいしく仕上がります。

　少し考えるといたるところに応用がききそうだというのはおわかりいただけるかと思います。こう書くとさすがは、コンサルタントのフレームワークと思ったりもしますが、他にもベースとなる考え方があるんですね。やはり第二次世界大戦の頃からの歴史を持つフィードバック制御技術です。下の図を見てください。

図2：フィードバック制御
「制御工学の考え方―産業革命は「制御」からはじまった」木村英紀著 （ブルーバックス）の図に加筆

　フィードバック制御というのは、制御対象のものを動かしてみて、その結果をセンサーで感知して、微調整することで正確な動きをさせるものです。元々は生体の動きを模したもので、機械を制御するのに必須の基本中の基本のモデルです。わたしも大学の学部生のときの講義で、それも教科書の最初の方に載っていたことを今でも覚えています。日常的にも「今回のインタビューの結果をフィードバックしておきます。」等と使いますが、これのことです。

　見てお分かりのように、PDCAサイクルと変わりません。実際にどちらのアイデアが先かとか、影響を与えているとかはわたしにはわかりませんが、フィードバック制御系をマネジメントに応用したものだと考えることはできそうです。オブジェクト指向風に言ってしまえば、このフィードバック制御がモデルで、それを経営から見たビューがPDCAとなります。

　このように工学技術の中にあるモデルが、ビジネスの分野でも有効に活用できるという例はめずらしくありません。これは、ソフトウェアについても同様です。システム開発に関連して生まれた様々なアイデアは、ビジネスへの適用が可能なものが少なくありません。これ以上は、話がそれるのでここまでにします。

◆とりあえず「PDCAが回っていない」と言ってみる

　さて、上でPDCAサイクルとフィードバック制御のモデルの類似性の話をしましたが、上流エリアで活動する上で大切になるのはもちろんPDCAのほうです。フィードバック制御のモデルは、大学で工学を専攻しないかぎり知りませんが、PDCAのほうなら経営層の方であればかなり認知度が高いものです。PDCAはコンサルタントであれば誰でも知っており、誰も否定する人のいない強力な説得力を持つフレームワークなのです。

　もし、あなたが働いている会社の社長から、「うちの会社の問題が何か言ってみろ」と聞かれたら、即座に次のように答えて構いません。

　「それはPDCAサイクルが回っていないことです」

　まず間違いなく、回っていませんから、ここまでなら言い切っても大丈夫です。

　わたしはいろいろな会社、いろいろな部門で働いたり、コンサルティングをした経験がありますが、まったく何の問題もないようなところなど1つもありませんでした。おそらくどこでもこれは同じではないかと思っています（ちなみに、これは正しい帰納法です)。

　解決されていない問題があるのであれば、解決のための計画（Plan）が立てられていないか、その実行（Do）がされていないか、実行されたとしてもその結果を確認（Check）していないか、結果を確認した上で計画を修正する（Act）取り組みをしていないか、いずれかであるといってまず間違いありません。

　特に後半にあたるCheckとActについては、よほどしっかりした経営スタイルが末端まで浸透していない限りはできていないことが多いようです。これらができていないために、いろいろな対策を打っても、結局、一時しのぎの解決にしかならず、すぐに再発してしまうことが繰り返されるのです。

　なお、上のように社長に答えた後ですが、問題がPDCAサイクルが回っていないことであったとして、そのP、D、C、Aのそれぞれが、いったい何のことを指しているのかが具体的に説明できなければ、怒られることになるので注意してください。経験の浅いコンサルタンの場合も、相手の状況をよく把握しないまま、PDCAサイクルの図を描いて問題を指摘してくることがあります。顧客から「回ってないのは理由があるんだよ！」と一喝されかねないので、注意しましょう。

◆PDCAな人々

　PDCAって、ほんとどこでも使えるものだなあ、と常々考えていたのですが、最近になって、会社における社員の行動様式の分類にも使えるということに気づきました。なんと、社長や役員も含めすべての社員は、以下の4つの類型に分けることができます。

• P型社員： 構想やアイデアを打ち出すが実行が伴わない人
• D型社員： 力わざで実行してしまうがやりっ放しになる人
• C型社員： 文句や批判がやけに多いが自分から動かない人
• A型社員： 身近な問題を地味に解決するが大きな構想に関心のない人

　もちろん、このうちの複数ができるようになることが当然望ましいのですが、すべてができているひとというのはなかなかいないものです。お互いに文句を言い合っていたりもします。

• P→C： 文句ばっかり言っていないで対案を出せよ
• D→P： 口ばっかりで結局自分ではできないじゃないか
• P→A： 近視眼的でなく大きな視点で動いてもらいたいな

　これを書いているうちに、また新しいことに気づきました。システムに関わる職業や役割の分類にも使えますね。

• P型職業： システム化計画までを行って去っていく役割
• D型職業： 指示されたプログラムを指示されたとおりに作る役割
• C型職業： できてきた仕様やプログラムに注文をたくさん出す役割
• A型職業： 元の仕様とできてきたシステムとの違いを調整する役割

　どういう職業がどの分類にあたるのかは、ノーコメントとさせていただきます。