Q. メンバーの共通言語、キャラクターを揃えるべきか？

別の項でも述べたようにスピードを重視する場合にコンテキストの揃った人間を集めることはとても効果的に働きます。ここではキャラクター＝カルチャーについて触れたいと思います。

そもそもカルチャーの対立というのはどのようなところで発生するでしょうか。

私が見てきた多くのケースのうち典型的なパターンのひとつが「厳密さの対立」です。

例えば委託業務を多くこなしてきたキャリアを持っている人たちは仕様書や契約書に対する厳密さが一般に高い水準に存在します。顧客と正式に結んだ仕様書をあとで覆すことは非常に手間がかかりますし、契約書に書いてあった例外的な事項にたまたま巡り当たってその結果裁判沙汰になるようなことも決して珍しい話ではありません。 しかし一方、自社製品をほぼ単発で繰り出すことばかりをやってきたキャリアの方は、仕様書や場合によっては設計データの保全に対してもあまり意識せずにここまで来てしまった、なんてことが往々にしてあります。 また事態をより複雑化させるのは、前者のキャリアの人が「今回は後者だ」と思ってその会社に来ているケースや、後者のキャリアの人が「今回は前者だ」と思って来ているケースもあります。 これらの意識合わせは放っておいてもなかなか自然には成立しません。

したがって明確なリーダーシップが求められます。方針を示し、体制を整え、また経験あるメンバーが模範を示す必要があります。厳密さをどう捉えるかは会社次第です。開発プロセスも、稟議も、顧客コミュニケーションも、いずれも一つの解があるわけではありません。しかしながら「うちはこう考えていくから」ときちんとした指針を示すことができれば、大きな問題に発展することは恐らく避けることができます。

次によく見るパターンが「情報の浸透度に関する対立」ではないかと思います。

少々まどろっこしい言い方になってしまいましたが、要するに幹部たちが話し合っていることや特殊なプロジェクトの進捗状況などをどこまでどのようにして社内に情報流通させる「べきか」という感覚の違いによって発生する対立のことです。

例えばアメリカ時代に私のボスだったことがあるJはメールに大量のCC入っていることが嫌いで、メールでJから返信が来るたびにCCに入っていた人が減らされていることがよくありました。一度Jに何故そうするのか尋ねたことがありますが「まず『必要がない』からだ。あと誰に送ってあって誰に送っていないかがわかりにくくなるからだ」という答えでした。ちなみにJは元Appleで、Macbookの開発プロジェクトを取り仕切っていたことがあるそうです。

一方、情報の流通が面倒な事態に発展する代表的なパターンのひとつは「誰かが退職した時」です。当然引き継ぎが必要になりますが、「退職し慣れている人」と「周囲が退職するのに慣れている人」が引き継ぎ対象である時にはスムーズに処理が進みますが、そうであっても大抵は多かれ少なかれの抜け漏れが発生します。元々従来の情報流通度合いが高い職場ではそのようなケースが発生するリスクを自然と低減できます。 また「プロジェクトの一部が危機的状況にある時」なども重症化を避けるためには早めに情報を社内で共有して知恵を集めることが有効です。情報伝達が遅れれば遅れるほど事態は悪くなっていきます。

この対立はほとんどが「個人の日々の行動」によって顕在化するため発見及び対処が難しいことがあります。また一個一個は些細な話なので大事に扱われないというのが実態です。 しかし、これら対立は徐々に小さな歪みを生み、いつかどこかで大きな落とし穴を形成することがあります。必ずそういうことが起こるというわけではありませんが、そのリスクをどの程度見積もって実際に採用アクションに落とし込むかというのは判断が必要です。

なお、アメリカでは意図的に自分の手元からの情報流出を遮断する人間がたまにいました。これはいわゆる自己防衛だと私は理解しています。つまり小規模なタコツボを自ら作ることで自らのポジションを守るわけです。 この手の人間は普段から情報をまとめておく習慣がないため、いざ退職となってからやれやれと情報のまとめを始めます。当然抜け落ち満載です。これは大きなリスクファクターとなり得るので採用の時には注意が必要です。

このポストの内容は以下の書籍の一部（原文）です。興味のある方はぜひ書籍をお求めください。

幸せなIoTスタートアップの輪郭