受託開発のゲージに押し込まれコードを産み続けるエンジニアにはプロダクトマネジメントはできない

プロダクトマネジメント、特にプロダクトオーナとして完成イメージを持ってプロダクトを作ると言う点において、全てのエンジニアが共通して持つことが必要なスキルだと思うのです。

もう、必要とされているのはプロジェクトマネジメントができるのは当たり前で、プロダクトマネジメントをできるエンジニアが必要とされているのです。

もし、エンジニアとして生き残りたければ。ワーカーとしてではなく。

エンジニアが一番理解できるポジションにいると言う意味

エンジニアは顧客が業務課題をITで解決するための策をシステムとして提供します。見方を変えると、要件をどう実現するか一番理解しているのはエンジニア自身であると言うことです。

これ、すごく大事なことなのですよ。

なぜかですって。

顧客の業務課題の解釈力が求められるし、それを様々な制約に縛られながらも実装し、顧客が手に入れたいタイミングでリリースしなければなりません。その完成イメージと工程を描けるのがエンジニアだからです。

え、今までのシステム開発と同じじゃないかですって。同じですけれど違います。言われたまま作るのではなく、専門家としてプロダクトを適正な状態で実現するからです。

理解も発想もできないし、しようともしない

これは今までの受託開発に携わるエンジニアには発想できません。指示待ちエンジニアにもプロダクトマネジメントは理解できません。

なぜなら、自分自身でシステムの完成イメージを持つことをしないから。

ゲージの中に押し込まれ、出て来た仕様書を啄んでプログラムを産むだけの存在になっている、ちょっと表現はアレですが、でも、あながち外してもいないでしょう。

じゃあ、リーダクラスはどうかと言えば、ゲージに押し込んだエンジニアに仕様書を配って、そのあとのコードを集めている業者そのものです。

エンジニア自身が自発的にシステム全体の完成イメージを持とうとし、自分の理解のために全体構成図を描こうとする人はどのくらいいるでしょうか。

プロジェクトがあったとしてそれを書くのはアーキテクトかプロジェクトマネージャだけです。なぜなら、プロジェクトマネージャは完成責任があるし、それをデザインするのはアーキテクトだからです。

他のエンジニアは分業が当たり前、自分の目の前の仕事だけをこなすことが当然と思っているのですから。

受諾でプロダクトマネジメントは存在しなかったか

そんなことはない、と思うのです。少なくとも純粋なプロダクトマネジメントとは遠いかもしれませんが、プロジェクトマネージャやアーキテクトは受託開発のエンジニアの中では一番プロダクトマネジメントに近い存在です。

ソリューション開発と言うジャンルもあります。これはパッケージをカスタマイズしてソリューションとして提供する形態のビジネスです。

これもパッケージを最適に使うため＝フィット率をあげる＝アドオンを極力せずにカストと業務を変える方向に持っていこうとするならば、やはり完成イメージをもち、適切なシステムを構成しようとするのは、受託よりはよりプロダクト（もともとのパッケージがプロダクトなので）の概念を持っていなければソリューションビジネスが成り立たないので。

ただ、ソリューションビジネスもパッケージソフトウェアを利用するビジネスなので、大元のパッケージを作り上げ、売ると言うところはすっぽりと抜けているけれど。

どうしたらできるようになるの

コストと手軽さからエンジニアが自分自身をプロダクトとしてマネジメントするのがいいのではないでしょうか。

プロダクトの出来が悪くても自分のことですし。市場で評価を受けないとかがあっても自分のプロダクトマネジメントの方向性の失敗ですし。

ただ、自分自身をプロダクトとしてまうとコストの概念が希薄になってしまうんですよ。

これがどうしてかがわからないエンジニアは受託開発のゲージの中でコードを産み続ける他ないですねぇ。

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

リーン・スタートアップ

図解リーン・スタートアップ成長戦略

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

これが必要なエンジニアにはこれが届かない

仕事って、ここまではやっておかないと、という矜持というかismを持っていないとせっかく仕事をしていても「やっつけ仕事」にしか見えないんですよ。

そういうやり方をしている人の仕事は、作業の途中で必ず文句を言う割には自分の考えを周りに押し付ける一方で周りを全く見ていないんですよねぇ。

人は、エンジニアは特にオペレーションではなく、その人が持っている経験と知識に基づいて創作的な物作りをしなければならない作業が含まれています。そうした仕事は、1人では完結しないので必ず周囲を巻き込まないと仕事にならないんです。

こうした仕事のやり方をしている人がいると誰が困るかと言えば、巻き込まれた周囲です。もちろん、そんな仕事をしてれば、それを見ているマネージャはそう言う人は評価しないものです。

もし、次のような症状が現れていたら、困ったエンジニアなのかもしれません。

忙しい、時間がないと言う

 このフレーズを使うエンジニアは全体を考えて進められないエンジニアです。こうしたエンジニアのアウトプットは考えられてないので成果物の出来が甘いです。

目の前にあるタスクを処理するだけのオペレータなのです。情報を寄越せと言って、情報をステープラで綴じているだけ。

全体の枠組みを考え、巻き込む周囲の負担を最小限にして且つ自分が必要とする情報を必要とするタイミングで手に入れる。

そうした考え方ができないので、納期とやらないといけないことだけを気にして納期に合わせて仕事をするから、巻き込まれた方は堪らないのです。そんなことをされれば巻き込まれた周囲は文句を言うのは当然です。

でも、当のエンジニアはそれに気づかない。

周りの意見をやらない壁を作って耳を貸さない

仕事ですから、巻き込まれた周囲は協力しようと思っても、何せ全体の枠組みや作業の目的など肝心なところを示されないので、作業で何をすればいいのかさっぱり理解できません。

当然、こうした方がいいよとか、もう少し説明して欲しいと要求します。当たり前ですね。特に、巻き込まれる方が所属する組織が違うと、その人の後ろに何人もいることになります。その中には巻き込まれているマネージャも含まれます。仕事で巻き込まれている以上、マネージャに報告すれば、リソースの権限を持っているマネージャは、本業の方の作業をして欲しいですから、どうしてその作業が必要か理解しておきたくなるものです。

さて、巻き込まれた方は説明できるでしょうか。

無理なんですよ。全体の枠組みや目的を理解できるように説明もされないし、資料も行間が多い不十分な出来なのですから。

そういった事態になるとどうなるかと言うと、巻き込まれた方のマネージャが巻き込まれた人に情報を聞いてこいというわけです。そうしないと判断つかないから協力していいとは言えない、と。

だから、情報を提供して欲しいとか、進め方のアドバイスをしたりとか、それに業をにやすと文句を言うことになるんです。

ここまで自体が進展してしまうと、所謂拗れた事態になっているわけですが、じゃあ、拗らせた一番最初の原因を作っているエンジニアはどうかと言えば、

• 協力を依頼しても文句を言われる
• あれこれ資料を提示しろと要求される
• 会議の場で説明したのだからやるのは当然

など、この状態になっているのはさも他責であると言うわけです。

でも、この状態になった当事者であるエンジニアは、周囲の言葉の真意を読み解くことができているのでしょうか。

もし心当たりがあるなら

もし、自分の行動に重なるところがあるとしたら、次のことを自分に向けて問いかけて見てはどうでしょうか。

• 巻き込んでいる周囲の振る舞いは、自分の行為の鏡かもしれない
• 文句に聞こえるのは、自分自身の不作為を突かれているからかもしれない
• 今の成果は専門家としてのismになっていないかもしれない

今、思うように仕事が進んでいないのに、同じ進め方を続けて上手くでしょうか。何かを変える時期なのではないでしょうか。

でもこれが必要なエンジニアにはこれが届かない。

自分の小さな「箱」から脱出する方法

作業プロセスを設計できないエンジニアのカップ麺は美味しくない

ここのところ、プロジェクトマネジメントの話題を振ると返ってくるのがプロジェクトでのプロセス設計ができないという愚痴なのです。現場のエンジニア、リーダになるようなエンジニアやなって欲しいエンジニアが悉く作業プロセスを設計できないのだそうです。

こうした愚痴もサンプル数１とか特定業種ばかりではなくて、製造業でもそうなんだそうです。超大手でも。

ちょっと昔を思い出して

よく思うことは、今できるエンジニアが少ないというのは、じゃあ、昔は多かったのかといえば、できる人たちはできていただろうと思い込んでいるだけじゃないかと思うのですよ。

昔といっても20年くらい前のことを思い出しているのですが、口を開けて待っているエンジニアがいれば、何をいっても文句が先に出てくるエンジニアもいたし、技術ネタばかり話しているエンジニアもいれば、エンジニアの仕事が好きなのかどうか怪しい人だってそこそこいたし。

記憶は美化するというけれど、あまり人の習性というか特性は変わらないのではないかと。

実体験からもそう思うので、昔はーというのは何いっているんだか、と。

どうしてプロセス設計ができるようになって欲しいのか

まあ、これに尽きます。じゃあ、どうなったらできる方のおじさんエンジニアたちは満足するのか、と。別に満足してもらわなくてもいいのですけれど。言われるエンジニアの立場になれば。

とは言え、何かができるようになるのはいいことです。武器を増やすことになるし、エンジニア的にはプロセス設計ができるようになって、実践できるということはリーダのロールが担える可能性が出てくるのですから。

プロセス設計で何ができるようになって欲しいのか

 じゃあ何ができるようになるといいのかと。

例えで話をすると、カップラーメンを作る手順、そう、カップ入りのラーメンならカップの側面に書いてある手順をシステム開発の工程単位で作れるようになって欲しいのです。

どんなプロセス設計ができるようになって欲しいのか

例えのカップ麺を作る手順の話で進めます。カップ麺を作るのは要求があってその解決策、ソリューションとしてカップ麺を提供することを提案するわけです。受け入れられれば、商談成立です。

商談が成立したので履行しなければなりません。そこでカップ麺を実現する手順を確立しなければなりません。

既知の、経験知があれば、それに基づいて手順を構成すればいいのです。まとめるとこんな感じですね。

要求　：お腹すいた

解決策：カップ麺でいかがでしょうか

手順　：材料を用意する→お湯を沸かす→注ぐ→3分待つ→提供する 

でも、こうした手順をスラスラと書き出す＝具体化できるのは経験があるからで、完成イメージを持っているからです。

カップ麺はお腹をいっぱいできる＝要求を満たすことができることを知っている

逆に言えば、知らないことは具現化できないのです。

まあ、そうはいっても、上記の手順をシステム開発の工程内の作業プロセスとして表現できれば、それはそれで、ベースのプロセスとしてはいいのです。及第点はあげられるかと。

実現したい完成イメージを持てる＝手順を知っている

ただ、カップ麺は割と手順が標準化されているので－－割とと書いたのは、かやくやスープの素を入れるタイミングがまちまちであることや待つ時間が3−5分といくつかの種類があるので、3分だと思い込んでいると固い麺で出来上がることになってそれを検査もしないで給仕すると要求を出した人からクレームになるわけです。

手順を知っている＝材料や要求の性質から調整できる

つまり、標準的だと思っている作業プロセスは、プロジェクトのソリューションでテラーリングが必要ですよ、ということです。

それはさておき、まずはカップ麺の作り方と同じレベルで作業プロセスを作れるエンジニアになって欲しいのです。

一平ちゃん/マルちゃん/サッポロ一番の人気カップ麺12種類×各2個　合計24個

ニュータッチ　凄麺　12種セット

日清　カップヌードル　5種　各4個セット（計20個）

日清食品 どん兵衛 日清どん兵衛 シリーズ 6種類×2個(12食) Bセット

プロジェクトマネジメントFAQ

1日何時間で作業を見積もればいいですか

就業時間で見積もります。ただし、次の事項を考慮してください。

組織内の間接業務

• 年休
• 病欠
• 研修
• 組織内の会議
• 事務作業（申請など）

フルフルな就業時間で見積もると残業することが前提となってしまうので実務に使える時間は目減りすることを忘れてはいけません。

さらに、プロジェクト内の作業においても仕様書を書く、コーディングするという正味の生産的な作業の他に生産的な作業ではないけれど欠かすことができない作業もあるので実質な作業時間は1日の半分くらいだと思っていた方が良いです。

• 朝会
• 仕様検討
• 課題検討
• IT機器の環境設定
• メンバの入退場による権限管理
• 開発環境の設定・維持
• レビュー

メンバのスキルレベルがバラバラですが見積もりはどうしたらいいですか

見積もりはできる人が見積もりをしがちです。プロマネができるエンジニアに振るからですけど。

見積もりをする際には、誰のレベルで見積もりをしたか、例えば、できるエンジニアなのか、中堅のAさんレベルなのか、新人のBさんレベルなのか、を確認する必要があります。

さらに、見積もった後はチームでその見積もりが妥当かどうか、ウォークスルーをして見積もり時の前提や範囲を可視化しましょう。

システム開発手法はどう決めればいいですか

プロジェクトの特性で選択してください。いつもウォーターフォールだからとか、顧客がアジャイルをやりたいからとかで選択してはいけません。

納期、品質、リリースサイクルなど、プロジェクトの特性に適合する手法を選択しましょう。

もし、未経験のシステム開発手法を選択する必要がある場合には、炎上して多大な火消すコストを投下するくらいなら、最初から専門家をアドバイザリーとしてアサインしましょう。

ただ、アドバイザリー役に実務をやらせてはいけません。 実務は全てチームでやらないとコストを持ち出してアドバイザリーを雇っている意味がありません。

何人でやるのがベストですか

プロジェクトの規模によります。ただ、機能しないエンジニアを入れても成果が出ないばかりか、成果のでる複数のエンジニアの足を引っ張るのでそんなエンジニアは入れない方がましです。

大規模開発や小規模開発のどっちが向いているの

プロジェクトマネジメントは、プロジェクトの規模には影響を受けません。大なり小なりどちらでも、プロジェクトをマネジメントするために行うので。

どの業種でも使えるの

 プロジェクトマネジメントのデファクトのPMBOKはどの業種でも使えるように多数の業種のプラクティスを汎化したプラクティスのエッセンスです。

 それゆえ、フレームワークになっているので業種特有やプロジェクト固有の特性はプロジェクトマネージャがインプリしなければなりません。

それをしないでPMBOK使えねーというのは、お前が使えねーです。

最近あまりプロジェクトマネジメントがー、とか聞きませんね

 日常になってしまっているからじゃないかな。

プロジェクトマネジメントってデイスコンでは

プロジェクトマネジメントがない世界でプロジェクトをやるなんて考えられません。旧石器時代に戻れっていうことですか。

プロジェクトは組織に影響を及ぼしますか

 プロジェクトの規模や契約条件により、組織がパーになることだってあります。しないように履行するのが日本の組織の選択ですが。

プロジェクトが組織にというよりは、組織の文化がプロジェクトに振る舞いを制約します。

ただ、一方的ではなくて、プロジェクトの特異な点が組織に逆流することもないわけではありません。

見積もりの基準は

 過去の類似実績から類推するのがいいです。ただ、同じものはありえないので。

それよりは、チームの中で中堅クラスのエンジニアに先行作業として1つやらせてみて、それを標準値にする方が精度が高いです。

要件はどこで決めますか

 要件定義局面で実施します。もし、基本設計＝外部設計からの受託であれば、基本設計局面の前か中の頭に、要件確認タスクをしっかり入れてください。

入れないと死にますよ。

 今日はここまで。

システムを「外注」するときに読む本

システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意

はじめよう! 要件定義 ~ビギナーからベテランまで

なぜ、システム開発は必ずモメるのか?

プロジェクトマネジメントFAQ

プロジェクトマネジメントは1人で出来ますか

有期限性の業務活動で、その業務をマネジメントつまりコントロールしたいのであれば出来ます。

プロジェクトマネジメントの知識エリアの全てをやるのではなく、一部だけをやってもいいかもしれません。

遠隔でのプロジェクトマネジメントはデジタルツールを使用すれば可能ですか

アジャイル開発と一緒で、同じ場所でプロジェクトを実施するほうが望ましいです。特に、プロジェクト立ち上げ時は。

n次開発のようなケースや、開発ごとにテーマを変えるのであれば2回目以降は遠隔でもいけるかもしれません。

チームの相乗効果をあげるにはどうしたら良いですか

 プロジェクトマネージャの数だけプロジェクトマネジメントのやり方があります。

プロジェクトチームの文化は、プロジェクトマネージャの意向が強くチームにインストールされます。

プロジェクトチームの体制が3階層以上になると2階層以降の各リーダのバイアスが掛かるのでプロジェクトマネージャの意向が減衰し、劣化していきます。

プロジェクトチームがステークホルダに直接アクセスすることはNGですか

PMBOKの1つの知識エリアにもなっているようにステークホルダーはプロジェクトに多大な影響を与えます。

プロジェクトチームの代表として会うのであれば良いケースもありますが、プロジェクトの意思決定を誰がしているのかは明確にしておく必要があります。

あくまでも、プロジェクトの代表としての意見はプロジェクトマネージャの発言だけです。 

プロジェクトマネージャはSEリーダと兼務をしてもいいですか

小さなプロジェクトチームの場合、専任のプロジェクトマネージャをおくことが様々な理由から実現出来ないと思われています。

プロジェクトマネージャは専門性のある職業ですから、本来は専任でつき、プロジェクトを運営すべきです。

兼務の場合は、他のプロジェクトを兼務するほうがエンジニアを兼務するよりは少しだけマシです。

プロジェクトマネージャがエンジニアを兼務する、所謂、プレイングマネージャは、得てしてエンジニアの比率が高くなり、プロジェクトマネジメントがなおざりでプロジェクトマネージャ自身がリスクを作ってしまうこと請け合いです。

プロジェクトマネジメントのどこがすごいかわかりません

 プロジェクトマネジメントが健全に運営されている場合、プロジェクト完了時の見通しができることです。

プロジェクトマネジメントとはなんですか

 有期限性の業務活動をマネジメント＝コントロールするための管理手法です。

経営者がエンジニア任せだと経営にインパクトが出るようなプロジェクト運営をするために、経営者にレポーティングするために作られた、と視点を変えるとそう捉えることもできます。

プロジェクトマネジメントの他にはどのようなものがありますか

プロダクトマネジメント、がそれに当たると思っています。

アジャイル開発はシステム開発手法の一つで、ウォーターフォール開発と同列です。

プロジェクトマネジメントがちゃんと回っていると判断するにはどこを見ればいいですか

PMBOKの知識エリアに該当するマネジメント領域のレポートが綺麗に出来上がっていても失敗するプロジェクトは失敗します。

計画、実行、予実の較差を様々なマネジメント領域でマネジメント＝コントロールされている状態と判断できるかどうか、です。

 WBSの分解粒度はどうしたらいいですか

プロジェクトの特性によります。

スクラムで開発するようなスピードを優先するプロジェクトであれば、時間単位です。

一般的なプロジェクトでは、5営業日以内、です。

プロジェクトマネジメントができているとマネージャは暇になりますか

 常にプロジェクトの進捗の障害となる兆しをモニタリングしているので暇になることはありません。

暇そうにしていたら、プロジェクトが奇跡的に運営されているかサボっているかのどちらかです。

エンジニアはその辺にいるjavaエンジニアでいいですか

プロジェクトチームとして必要なチームのスキルセットを一部を満たすのがその辺にいるjavaエンジニアならそれでもいいです。

マルチスキルや一気通貫した工程を担えるエンジニアの方が勝手が良いのは当然です。

プロジェクトマネジメントはどこで覚えられますか

 プロジェクトマネジメントのフレームワークであれば、PMBOKで十分です。

実際に使用するプロジェクトマネジメントのツールは記載がないので実務で使う道具は経験してストックしていく必要があります。

エンジニア以外の人にプロジェクトマネジメントはどれだけ知識が必要ですか

 プロジェクトからのレポートがエンジニア以外の人に伝えられることになります。

インタフェースになるのでレポートで使われる言葉、やり方が理解できないと意思疎通が成り立ちません。

プロジェクトマネージャに向いている人はどんな人ですか

 自分でプロジェクトのシナリオを書けて、チームやステークホルダと合意形成しながら実現できる人です。

アサインするマネージャの眼力が問われます。

今日はここまで。続くか。

プロジェクトマネジメントの基本

PMBOK問題集 第5版対応 (PMP試験対策)

図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ (Panda Publishing)

プロジェクトマネジメント現場マニュアル[改訂版] （日経BP Next ICT選書）

プロジェクトマネジメントの基本 (この１冊ですべてわかる)

先制型プロジェクト・マネジメント―なぜ、あなたのプロジェクトは失敗するのか

「プロジェクトマネジメント」実践講座

PMBOK対応 童話でわかるプロジェクトマネジメント

プロジェクトマネジメント標準 PMBOK入門 PMBOK第5版対応版

マンガでわかるプロジェクトマネジメント

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう！?

やることだけを見える化しているとトラブルの原因を可視化し忘れる

プロジェクトを回していて、思うように進捗できていないと相談を受けて話をよくよく聞くと、一方向でしか作業を見ていないということに気づかされることが多いいのです。

まあ、第三者の視点で見られるので、この点はどうなのとかそっちから見たらどうなのというように他人事で巻き込まれていないからこそ、頭の中にある経験知を引っ張り出す余裕が持っているから、なのですけれど。

何事も余裕がないと打つ手にはろくなことがなくなってしまうのは世の常、なのですが。

例えばどのようなことが起きるか。

作業をする前には、次のような工程があります。

1. どのようなものを作りたいかを決める
2. 作業工程を具体化する
3. 作業の見積もりをする
4. 必要なリソースを引き当てる
5. 作業を実施する
6. 品質を検査する
7. 完了する

普通ですよね。標準的というか。ここまでガイドされたらうまくいかない理由がわかりません。

でも、現実には上記のように作業項目を列挙して、その通りにやったとしてもうまくいかない方が多いのです。

1. どのようなものを作りたいかを決める　←仕様が曖昧
2. 作業工程を具体化する　←認識していない作業がある
3. 作業の見積もりをする　←見積もり根拠がない
4. 必要なリソースを引き当てる　←必要なリソースが手に入れられない
5. 作業を実施する　←作業品質が実装されない
6. 品質を検査する　←検査基準が曖昧
7. 完了する　←完了の基準が曖昧

 それぞれの作業項目ごとに幾らでも上手くいかない原因は潜在しています。更に言えば、これらの潜在している上手くいかない原因の他にも、これだけ上手くいかない原因を可視化したはずなのに、まだ見えていないことがあるのです。

さて、何が見えていないか挙げられますか。

仮に、上記で列挙した作業項目とそれが上手くいかなくなる原因まで対処できたとしても、思うように終わらせることができない原因がまだあります。

逆の見方をしてみましょう。仕様は揃った。作業も具体化できた。必要なリソースも確保できた。とすると、あとは進捗をモニタリングしていれば、問題なさそうです。

でも、それでも上手くいかなくなるかもしれない。

どうしてそのようなことが起きるのか。

それは、前述した作業の列挙では可視化されていない別の指標があるからです。それは、負荷です。

ええっと思ったかもしれないですが、これって無意識に頑張るとかやり切るとか言ってしまう、精神論的な行動を取りやすい指標なのです。この負荷も何が原因で負荷がある状態になるかは想像がつくと思います。

原因は、見積もりとリソースでの較差と必要とするスキルと充足されたスキルのギャップなど、上述した作業項目が絡み合って一旦、負荷という状態に変遷し、更に進捗が遅れる、などの事象に変化するのです。

こうした事象の変遷を解きほぐしもせずに見えている事象だけを短絡的に解決しようとすると、実は一つも二つも先に本当の原因があった、ということに気づくことができないのです。

これを不十分な可視化、見える化と呼ぶのです。

仕事の成功はダンドリで決まる！カレーで学ぶプロジェクトマネジメント

ビジネスで使う機械学習

エンジニアの認知、観察力から、解釈の特性をモニタリングしないと進捗でトラブるかもしれない

ワタシは視界に入ってくる、そのとき起きている事柄からしか、情報を得ることができません。これはワタシだけではなく、どの人も同じです。

視界に入ってくるということは、視界に入って起きる事柄には少なからず関心を抱いているか、無意識にその起きている事象に関連していることに気づかずに結びつけているだけなのです。

とするとき、認知するためには背景に多くの知識や経験が必要で、そのためには、主体的にバックグラウンドとなる形式知の蓄積と経験知の言語化の繰り返しが必要となるのです。

あるとき、メンバのエンジニアが出席していない会議の議事をチームで共有しているときに、その出席していなかったエンジニアが議事内容を取り違えて急に前のめりで噛み付いてたんですね。

その議事内容はおかしい、これまでの経緯と違うのではないか、訂正が必要だ、と。

まー、何言っているんだ、コイツは、と思ったわけです。普段から早合点するたちではありましたが。

ふと、思ったんですね。これは見えている、視界に入っている目の前の出来事で得ている情報が少ないのではないか、と。言い方を変えれば、情報共有が十分出来ていないということもできますし、コミュニケーションが不足しているということもできます。

でも、視界自体が狭かったり、広かったとしても関心事項ではないのだとしたら、それは幾ら情報共有していても結果は期待する情報共有はできないし、コミュニケーションだって同じ事象としてしか表面には出てこないのです。

視界自体が狭い、つまり、認知する窓が狭いということは、目の前で起きている事柄に対しての観察する力が何かしら不足していることを疑わざるを得ません。認知しようとしていているのにも関わらず、その前で起きている事象を観察対象とできないのですから。

認知の窓が狭く、目の前に起きている事柄についての観察する力量も弱いとするならば、そこからもたらされる事柄に対する解釈は、限定された情報の中で観察できた方法量だけが解釈されるので、認知の窓が広く、観察する力量も十分備わっている場合に得られる解釈から導き出される結果や行動は全く違うものであっても不思議ではありません。

チームの活動においては、普段の行動や判断基準から、メンバの認知、観察する力、及び、解釈から導い出される結果をアウトプットをモニタリングして、メンバごとの特性として把握して置く必要があります。

こうした行動の結果に結びつく、内面的にもかかわず外的な活動の結果として現れるパフォーマンスはプロジェクト立ち上げの早期に把握する機会を作り、基礎データとして持っておかなければ、あとあとトラップになりかねません。

マンガでやさしくわかる認知行動療法

コミケ童話全集