読者です 読者をやめる 読者になる 読者になる

かとじゅんの技術日誌

技術の話をするところ

プロフェッショナルなら政策メッセージを使え

etc

あけましておめでとうございます。今年もよろしくお願いします。

引き続き、ロジカルシンキングの話。前々回、前回と論理の基礎をざっくりと述べた。

同僚や上司、顧客から、納得を得るために必要なこと 〜演繹法〜

同僚や上司、顧客から、納得を得るために必要なこと 〜帰納法〜

これ以上深い論理学の観点には触れずに、、、今回は論理的な表現としての「メッセージ」(命題ともいう)について触れたい。*1

メッセージのタイプは4つあります。

  • 事実メッセージ
  • 評価メッセージ
  • 政策メッセージ
  • 希望メッセージ

簡単に説明すると、
事実メッセージは、単なる事実を述べる命題。
評価メッセージは、ある事柄に対する自分の評価を述べる命題。
政策メッセージは、政策を提言したり、何かアドバイスする命題。
希望メッセージは、依頼や希望を述べる命題。
となる。
この4つのメッセージを理解すると、コミュニケーションや意志決定が円滑にできるようになる。
今回は仕事でよく使う「事実メッセージ」「評価メッセージ」「政策メッセージ」について説明したいと思う。

事実メッセージ

単なる事実なので、たとえば以下のようなものだ。

部下の岩間さんは、多くの仕事を予定より早く仕上げた。

これも主張と根拠のピラミッドストラクチャを構築する。
下記の例では、帰納法で論理構造を作っている。

主張:部下の岩間さんは、多くの仕事を予定より早く仕上げた。
根拠:明日のデモ版のビルド作業を本日に完了させた。
根拠:今週末の製品リリース版のビルド作業を本日に完成させた。
根拠:来週初めに必要なビルド環境を本日 完成させた。

多くの仕事を予定より早く仕上げた根拠が提示されている。
もちろん、演繹法を織り交ぜてもよい。このあたりは演繹法と帰納法はわかっていれば、それほど難はない。

評価メッセージ

Mさんは、優秀なJavaプログラマだ。

このようなメッセージが評価メッセージだ。事実メッセージとは違って、ある基準に対してどうかという評価を表現している。
たとえば、以下の例。

主張:Mさんは、優秀なJavaプログラマだ。
基準:弊社では、以下の条件を満たすものJavaプログラマとしている
      - 自らプログラミングを実践しているか。
      - プログラミングの理論を学習しているか。
      - 他のプログラマに得た知識やスキルを共有しているか。
      - 課題解決の方法(ソリューション)を提案しているか。
      - 外部からの評価を得ているか。
根拠:
      - 社内の研究開発プロダクトで開発を担当している。
      - 社内でOSSに関する技術的な調査を担当している。
      - 自身が創設したOSSプロジェクトでチーフコミッタを担当している。
根拠:
      - ブログで日々の研鑽状況を確認できる。
      - 厳選して質のよい書籍を多く読んでいる。
      - よくわからないことは、グルといえる人物から教えを乞うている。
根拠:
      - 教育資料を作成し、社内の勉強会で得た知識を共有している。
      - 外部で自身が創設したOSSに関するセッションを実施している。
      - Skypeチャットなど、要求があればどこでも議論に参加している。
根拠:
      - 自身が創設したOSSでは、新しい開発プロセスと関連ツールを提案している。
      - プログラミング・ノウハウに関する提案は、日々のブログで公開している。
根拠:
      - SJC-Pの資格を保持している。
      - 自身が創設したOSSプロジェクトでは、プロダクトとして理想像と
        彼の人柄で、コミッタ集まっているといってよい。
      - Javaのカテゴリで現在100位以内。
      - 記事を執筆したことがある。
      - 彼は、カラオケにいくと朝5時まで全開で歌う。
        ラストはE缶がなんちゃらという歌でみんなが一体化する。

断っておくがこの物語はフィクションだw
まず、「優秀」とは何を指すのかという点を判断基準という形で表す必要がある。今回は、社内規定でこういう判断基準があったとする。そして、その判断基準に対して事実はどうなのか、「事実メッセージ」の形式で表す。つまり、「判断基準」+「事実」となる。
演繹法としてみると、結論に対して判断基準が大前提、根拠が小前提となる。また、帰納法としてみると、各判断基準に対して根拠が対応付くようになっている。
「評価メッセージ」は自分の主張を相手に表現するときに有用だ。相手から説得を得るには、「論理力」以外にこの「判断基準」が重要になってくる。当然、客観性の欠ける基準では納得は得られないという点は、十分に注意が必要である。
 

政策メッセージ

さて、本題の「政策メッセージ」だ。これ非常に重要だ。

Javaプログラマなら開発マシンにMacを選ぶべきだ

政策メッセージは、「このようにすべき」という提案やアドバイスのためのメッセージだ。
例としては以下。

主張:Javaプログラマなら開発マシンにMacを選ぶべきだ
必然性:
 - UNIXの開発・テスト環境を利用することが多い。UNIXコマンドが使えないと不便。
   Windowsではcygwin環境などをインストールする手間がかかる。
 - Windowsのcygwin環境は、パッケージをインストールする場合は、
   setup.exeを使わなければならず、コマンドラインから簡単にインストールできない。
 - Windows XP 32bitは、メモリの制限がある。上限3GB?
 - Macを除くUNIX OSでは、Officeのドキュメントファイルが扱えない。
   OpenOfficeもあるが互換性に難がある。
 - Macを除くUNIX OSでは、IEなどのWindowsアプリが利用できない。
 - できれば検証目的でいろいろなOSを稼働できる方がよい。
   業務ではやっぱりOracle環境が必要。
 - 慣れないうちはなれたOSが選択できるとよい。
 - コストが比較的に安いほうがよい。
効用:
 - Macは、正式なUNIX OSである。ターミナルを開けばls -alなどのUNIXコマンドがそのま
   ま扱える。
 - Macは、MacPortsを利用すれば、ほとんどのUNIX系アプリや開発言語がコマンド一発で
   インストール、アンインストールできる。
 - Macは、最初からJavaがインストールされている。インストールの手間がない。;
 - MacBookは、4GB、Proは8GBまで増設可能。
 - Macは、MS純正のOfficeがサポートされている。Windowsとの互換性も問題がない。
 - Macは、Intel CPUを採用しているのでVMware Fusion上でWindowsやLinuxやUNIXな
   どのx86系OSが同時に利用可能。IEでの動作確認やSolaris上でOracleのインスタ
   ンスを起動させたりできる。
 - Macは、不慣れなうちはBoot CampでWindowsマシンとして使うことも可能。
 - MacBook 13インチは、10万円を切っていてコストパフォーマンスがよい。
実現可能性:
 - AppleStoreでも、量販店でもすぐに購入できる。ビックカメラやLABIなどの
   量販店は10万切るしポイントもつく!
 - 購入時にOneToOneを購入すれば、AppleStoreで実践的にレクチャーを受けれる。
 - 環境構築方法は、インターネットから得ることが簡単。
 - 周囲にいるMacを持っているプログラマからレクチャーを受ける。

「必然性」は、なぜそうしなければならないのか、提案を受け入れないとどうなるのかという意味で、「効用」はその提案の効果やメリット、「実現可能性」は実際どのようにすればその提案を実現できるかというものを表したものとなる。

プロならどのメッセージを使うべきか

駆け出しのうちは「事実メッセージ」と「評価メッセージ」で十分。でも、最終的には「政策メッセージ」が扱えなければプロとはいえないと思う。
現場ではトラブルや懸念事項があがるのはつきものだ。その際に、問題を事実メッセージや評価メッセージで表現することは可能だ。だが、肝心のどうすればよいかというのが決まらないのだ。事実だけを述べる。いい悪いだけの評価を述べるだけでは、何も改善できない。リーダをはっている人や現場作業でも顧客とよく接する人は「政策メッセージ」で提案できなければいけないと思う。
こう思う人もいるかもしれない。「提案しても提案どおりにならない」。そういう不満を言ってはいけない。言える立場ではない。提案しないことと、提案が採用されないことは、技術者としては雲泥の差なのだ。提案が採用されなくても、提案するのがプロの仕事だ。
顧客からいわれたことだけをやっているのが物作りではない。時には顧客の設定したゴールに、顧客自身が間違うこともある。そういう時は、声を大にして「政策メッセージ」で論理的に「こうするべきだ。あなた方のために」と主張するのがこれから生き残っていく技術者であり、SIerだと思う。もちろん、これは社内でも使える。上司に何か要求がある場合は政策メッセージで依頼するといい。建設的な議論ができると思う。
私もDIやAOPに代表される技術を駆使して仕事をしているが、これは戦術論だ。「政策メッセージ」は戦略の観点で考える作業だ。戦術は戦略に基づいて実行される。たとば、戦略によってはDI/AOPを選択しない場合があるのだ。戦略を知っていれば、自ずと適切な戦術が見えてくる。これから先に自分がどういう技術を学ぶべきかがわかってくる。

今年もさらに景気は厳しい状況が続くと思うが、自分が顧客なら「政策メッセージ」で提案しない技術者やSIerは、自分たちのビジネスのためにならないので契約を切ってしまうと思う。Googleの力を借りながら内製化することを考えるかもしれない。(内製化自体は悪ではないので、内製化のためにSIerができることもあるでしょう)
いずれにしても、SIerが顧客と共生するには、技術者自身が戦略と戦術の観点から考え行動することが重要ではないかと思う元日でした。

あわせて読みたい


上記の4つのメッセージに触れている書籍です。興味のある方は、詳しくはこの書籍を参考にしてください。

http://d.hatena.ne.jp/gothedistance/20081030/1225367985
http://jibun.atmarkit.co.jp/ljibun01/cs/200912/05/01.html

*1:実はこの二つのエントリは今回のために書いた