死なないためにチームのカルチャーを先に掲げる

エンジニアも人の子、一人ひとり別々の灰色の脳細胞を持っていて、特徴のある身体を持っているから、誰1人として同じことを考えたり、意思決定したり、行動することはない。

エンジニアに限って言えば、エンジニアになるまでの教育(専攻)も違うし、エンジニアになってからのキャリアパスが誰1人同じケースがないことは、これまでのエントリで散々述べてきたことである。

だから、プロジェクトで1からチームを立ち上げる場合、最初にしなければならないイニシエーションは、チームビルディングであるし、プロジェクトの中でメンバが同じ意思決定するために必要な価値観の共有である。

ベンチャーやスタートアップでは、その組織の価値、バリュー、ミッションを明文化しているところが多い。なぜかと言えば、事業成長する上で事業そのものが当たることは必然であるが、それを支える優秀なエンジニアと同じ方向を向いて仕事をしなければならないし、新規採用でも同じ価値観を持つエンジニアを採用したいからだ。

果たして、これがベンチャーやスタートアップの専売特許かと言えば、そんなことはない。

伝統的なウォーターフォールでさえ、プロジェクトチャーターを作成し、それをプロジェクトの神様として祀り、プロジェクトの価値観としてプロジェクトが完了するまで鎮座する。

それでも、ウォーターフォールのプロジェクトが上手くいかないのは、そのプロジェクトチャーターが機能していないからである。

アジャイル開発の手法なら上手くいくのか。残念ながら、そうは問屋が卸さない。価値観ババ抜きというゲームがあるのはどうしてか、を考えればその理由は理解できるだろう。

現実の世界では、そのくらいやっても日々の思い違いやボタンの掛け違い、期待違いを起こすのである。

もし、プロジェクトチャーターやバリューやミッションが必要ないチームだとしたら、それはすでにそのチームの文化、カルチャーとして定着しているからである。

カルチャーは、その人格の意思決定を振る舞いとして表現されるものである。バリュー、何を大切にするかという考え方は、それを基準に意思決定する行動様式として現れる。意思決定が組織化すれば、承認プロセスとして表現される。承認プロセスは、その組織にjoinする採用者の採否に現れる。

それでも、チームという組織の縮図に落とされると個人の価値観と組織のカルチャーの捉え方、受け止め方が違うのである。

それをバリューやミッションという形でカルチャーを言語化することで、最低限のフィルタリングを行うのである。

そうしなければ、体力のないベンチャーやスタートアップは死んでしまうからであるが。そう考えると、SIerはそれをしないでプロジェクトを始めてしまうのだからそら恐ろしいし、上手くいくのは奇跡でしかない。

ああ、自分が過去にプロジェクトを失敗してこなかったのは、最初にグランドルール、チームの意思決定の基準、プロジェクトマネージャとしての大切にすることを話して、定着するまで繰り返し言ってきたからかもしれない。