暑かったり台風で気温が下がったり、湿度が上がったり振り幅がある9月、いかがおすごしでしょうか？今後健康管理についての記事も記載しますが、それまで体調を崩さずに！
前テーマの話す聞くに続き、今回は組織内コミュニケーション編です。
これまではあなた自身、もしくは1対1のコミュニケーションを中心に解説してきましたが、今回は社内、組織内、対複数のコミュニケーションについてお話しします。
相手は変えられない。自分のフレームを振り返る
これまでのあなた自身のコミュニケーションと今回の組織内コミュニケーションの大きな違いは、”相手は変えられない”という前提に立ってスタートしなければならないということです。
- 上司がうっとうしい
- 先輩が神経質だ
- 後輩が思ったように動かない
すべて当然です。そして変わらないのであればどうするのか？という点から着目していきます。
人はみなフレームを持っています。どういうことかというと、例えば今、あなたの目の前に水が半分入っているコップがあるとします。
- 水が半分「も」ある
- 水が半分「しか」ない
あなたはどちらの感想を持ちましたか？このように、コップに水が半分であるという事実は変わらないのですが、自分が持っているフレームによって、解釈が変わります。おそらく社会人なりたての頃に言われた方もいらっしゃるかもしれませんが、”事実と解釈は違う（ので分けて考えましょう）”ということです。
では最初に取り上げた、うっとうしいとか神経質とか動かないと思った事実はなんでしょうか？
たとえば、
- 提出した資料やソースコードに対する指摘が細かった（事実）
- （だから）彼/彼女は神経質だ
と論理構造的につながるのであれば問題ありませんが、事実と解釈の間に飛躍があるとしたらそれはあなたの歪んだフレームであるかもしれません。例えば「上司はコードレビューが細かい。きっと自分のことが嫌いなのだ」といったように。
ですので、組織内の集団コミュニケーション以前に、自身が持っているフレームを振り返ってみることからスタートしてみませんか？指摘が細かいのは、あなたに対して成長を期待しているからかもしれませんよ！
事実と解釈を切り分けるには
では、組織内コミュニケーションになった時に気をつけることを考えていきましょう。先程のソースコードのレビューの例えを引き続き使います。上司のAさんは、
- あなたに対しては非常に厳しく細かく指摘をする
- 同僚のXさんに対しては細かく指摘をせず、一発でレビューが通ることもある
だったとします。
人によって態度変えてるんじゃねーよ！えこひいきか！と思う気持ちをぐっとこらえてください。人は他人に対して、完全に平等に接するなんてことはありません。（というと怒る方が世の中には多いように思われます。もちろん平等に接した方がいいと思いますが、そうではないのもまた事実ですよね）
一方、えこひいきか！とあなたが思うのもまた解釈にすぎません。引き続き事実にフォーカスしていきましょう。
組織内（集団）ですので、発言や指摘が変わる原因はあなたとの関係性に注目する必要があるでしょう。MECEではないですが、ありそうな状況を列挙してみます。
- あなたが１年目の新人である
- あなたのバグが原因で先週、障害を起こしてしまった
- あなたがこのプロジェクトに入って一ヶ月である
- あなたのコードはおおよそ質が高いが、他の連携モジュールでバグが多いので結果として厳しくなった
- Xさんは熟練である
- XさんはAさんより現場経験が長い
- Xさんは若手だが、きちんとしたコードを書くと周囲からも既に評判を得ている
- プロジェクトの品質がまだ上がりきっておらず、全体的にレビューが厳しい（たまたまXさんはコード量が少なくて指摘がなかった）
などなど
この記事を読みながら、他にも思いついたものがあればよりGoodです。
こうやって考えることは非常に大事です。しかし、毎日仕事に追われ忙しく過ごし作業に追われていたら、いちいち考えていられませんよね。なので人はフレームを用いて”こうに違いない”と思い込むのです。
フレーム自体は悪いことではありません。一日起きていることを全部疑ったり、意思判断決定を密にしていたら、MP（ここでは精神的体力の意味）がいくらあっても足りません。ですので、人は無意識のうちにフレームを用いて意思判断決定の労力を減らしています。ただ、この例のように自分がネガティブな解釈を持っていたり、それがコミュニケーションにおけるストレスとなっているならば、ふとした瞬間に時間を少しとってフレームそのものを疑ってみる機会を設けることは有効でしょう。
エンジニアと非エンジニアでは、会話のロジックが異なる
エンジニア同士の場合は、非常に楽かもしれません。たとえばSlackなどのチャットツールでやり取りして、「この実装どう思う？」に対して「OK」や、「こういう値が来たら、この例外処理がコケそうだから、そこだけ修正してテストしたら？」などスムーズなコミュニケーションができそうです。
なぜなら、（プログラマ同士でもエンジニア同士でもデザイナー同士でも）スキルの差こそあれ、コミュニケーションを取るには十分な知識を共通して有しており、最小限のキーワードでやり取りができるからです。また同じロジックを持っているので焦点がボケにくいですよね。（以前の連載でチャットツールでのコミュニケーションは除くと書きましたが、そこでも書いたように決して悪いことではないですし、この場合ツールを使った方がおそらく対面で話すより早く、スムーズです）
ではあなたがエンジニアで、相手が非エンジニアの場合はどうでしょう。一度はイラッとしたことがあるかもしれませんね（笑）。タモさんの「これ貼っといて」（例が古くてすみません笑）ばりに、「仕様が変わったので既存のやつにこの機能ちょっと足してほしいんだけど」と非エンジニアの方に言われたとしましょう。
いやいやいや”ちょっと”って！そんな簡単に足せません！！とあなたは思うはずです。イチからテストしたり、そもそも他のコードへの影響度を鑑みてないだろうと言いたいですよね。非エンジニアの方はエンジニアと同じ知識を持っていないので、表面の機能だけを見て「ちょっと」という表現をしてしまいますし、「ちょっと」ではない、ということを説明しようとすると、結果として会話の焦点がどんどん逸れていってしまうのです。
ですので、それに対してイラッとするなとは言いませんがこの「同じ知識・ロジックを持っていない」という前提からスタートします。相手のタイプにもよりますが、端的にできる/できない、できるならどれくらい掛かるのか難易度の高低、できないならなぜできないのかを”非エンジニアの相手にわかる形で説明する”必要があります。私もこれを書いていて過去の難しい経験を思い出してゾッとしました（笑）。これ、難しいですよね。ですが、このコミュニケーションコストが高いのもまた変えられない事実ですので、ご自身で工夫するしかありません。
プロジェクト別の解説、ウォーターフォールの場合
金融系を始めとする、中規模かつ大規模のプロジェクトの場合はウォーターフォールモデルが採用されていることが多いでしょう。改めて説明するまでもありませんが、ウォーターフォールモデルは開発手法のひとつで、開発を複数の工程に分け、上流工程から下流工程まで文字通り「滝のように流れる」ように開発が行われることが特徴です。
このウォーターフォール開発を行うプロジェクトかついわゆる下流工程にいる時は、上流工程の担当者、または上司や先輩から仕様や依頼内容が一方的に振ってくるのがほとんどです。
もちろんそれはこなさないといけないのですが、実践して頂きたいことはその仕様を実装した時の他への影響や、考慮漏れを指摘することです。依頼から出来るだけ間をおかずにこれを行うと、喜ばれたりあなたの評価が上がったり、ひいてはコミュニケーションがスムーズになりやすいでしょう。なぜならウォーターフォールは手戻り厳禁という前提があり、それを避けるためのコミュニケーションは是だからです。
一方上流工程（エンドユーザー、クライアント、PMといった立場）の場合はどうでしょうか。これは私が彼ら（非エンジニア/上位職）向けのIT研修をやっているというポジショントークもありますが、一言で言うと技術についてもっと勉強しなさい！ということです。非エンジニア向けのITやプログラミング研修やセミナーは山程あります。また各社オンラインプログラミング学習サービスがあります。相当障壁は低いはずです。なのにそこの知識がおざなりなのは考えられません。
そもそもなぜ上流工程の人が技術について勉強しなければならないのか？会話のロジックのところで書いたように、実際に開発を担当してくれる方々が話す内容をちゃんと理解しないとお互いにストレスになるし、もちろんプロジェクトが上手く進まなかったり手戻りが発生します。上流工程の方が勉強して、その差を埋めるのは、私は自然なことだと思うのです。
下流の方（言い方は語弊あるかもしれませんが）は、技術に関するスペシャリストでそれを求められてきているので、技術＞コミュニケーションです。一方上位者はコミュニケーション＆技術知識（実際にバリバリ書ける必要はない）であるべきですが、これが両立していないことが、プロジェクトでのボトルネックになっている事例をたくさん見てきました。
プロジェクト別の解説、アジャイルの場合
アジャイルのそもそもの定義（アジャイルソフトウェア開発宣言にあります）を見てみましょう。
参考）http://agilemanifesto.org/iso/ja/manifesto.html
プロセスやツールよりも個人と対話を、
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
（一部引用）
私が考えるアジャイルにおけるコミュニケーションの肝とは、シンプルさを追求しつつ「それって必要？不必要？優先度が高い？低い？」という思考プロセスがベースになっているかどうかです。ですのでコミュニケーションにおいても、この機能（実装）における核は何か？ということに焦点を合わせて、シンプルな説明になるのが自然なのです。
逆説的ですが、シンプルな説明にならない複雑な機能や実装はそもそもアジャイルに適していないとも言えます。依頼を受けた時、出す時に、この原則に則っているかどうか、常に注意を払うとコミュニケーションコストとストレスが低くなると考えています。簡単な例としては、（判断基準として）2週間のイテレーションではここまでできる/できないとYes/Noのクローズドクエスチョンになるやり取りの割合を増やしてみてはいかがでしょうか？
また対話が必要であり時間がかかるのは、与えられた仕様や要件を対話を通じてシンプルにすることです。シンプルにするためのコミュニケーションは積極的に推奨されるべきであり、またコストを惜しまない方がよいのです。
ウォーターフォールのところで挙げた、上流と下流視点からも見てみましょう。
上流のエンドユーザー、クライアント、PMに関しては、ウォーターフォールと共通して、きちんと技術的な勉強をした上で、実装コストの面からいかにシンプルな仕様、機能になるかを指示内容とすべきです。少なくともその指示が2週間でできるのかの判別と、優先度/重要度/難易度の切り分けができるくらいの知識が必要最低限です。
（下流の）SEやプログラマに関しては、シンプルな実装を行うということです。シンプルな実装を行えない仕様や依頼の場合、その時点で「それが厳しい」ということを（エンジニアであったとしても）きちんと返すだけのコミュニケーションとその能力が必要です。あとプログラマにありがちなこれも実装したい、あれもやってみたいという技術的チャレンジに偏りすぎないことです。（これはもっと前のフェーズや検討課題として扱うべきでしょう）
まとめ
今回は組織内コミュニケーションについて、
- 自身のフレームを振り返る
- 自身にネガティブな影響を与えているフレームがあればそれを見直す
- ポジションが違う時にコミュニケーションコストが上がる
- プロジェクトのタイプ別における、コミュニケーション例
を学びました。
次回は「ファッション」をお届けいたします！
ではまた!
(記事:金子 雄太郎)
フルスタック・ジェネラリスト。教育コンサルとして企業向け研修を行い、内容はヒューマンスキルやITスキル向上のカリキュラムなどオールジャンルの講師を実践。コンテンツも自身で作成する。 元々は、IT業界でSEを６年半経験した後、2012年2月独立。編集業や企画も扱う。 ライティング・編集もジャンルにこだわらず。ビジネス、サイエンス、エンタメ、法曹、Webメディアとオールラウンドにこなす。 関わった人々全員を幸せにするのが、密かな野望である。