「エンジニアリング組織論への招待」を読んだ

以前のポストにも書いたんですが、組織やチームついて考えるキッカケを求めて、「エンジニアリング組織論への招待」を手に取ってみました。

僕らがいる業界は、なにが正しくて、なにが正しくないのか。答えがないなにか(不確実ななにか)に相対しているわけだが、この「不確実ななにか」に対して、エンジニアとしてどうアプローチしていくのか。みたいなことについて書いてあったように思います。

組織がどうとか、チームがどうとかみたいなこともありつつ、エンジニアとして働くつもりなら読んでおいて損はないなーと。

というわけで抜粋。

不確実性の正体

よく「我々は不確実性の高い時代を生きている」みたいなことを聞きますが、結局その不確実性ってわかるようでよくわからない。みたいな感覚ありませんでしたか?

不確実性というのは、「わからないなにか」であり、「わからない」というのは

1. 未来

2. 他人

の2つに分類されます。

不確実性の高い問題、わからない問題にぶつかったときに、人は「回避」するか「攻撃」するかを迫られる機能が本能的に埋め込まれています。

このような不確実性というものに対して、僕たちは相対しないといけません。

不確実性とは、「わからないこと」です。 私たちがわからないことには、未来と他人があります。 未来の不確実性は、ソフトウェアをどのように作るかという方法不確実性と何のためにソフトウェアを作るのかという目的不確実性に分かれます。 また、他人の不確実性は通信不確実性といい、コミュニケーションが不確実であるために情報の非対称性や限定合理性が生まれてしまいます。 そして、不確実性は、「不安」を生み出します。 わからないものは自分を脅かすかもしれないと本能で感じてしまうからです。 不安は、コミュニケーション不確実性に変わり、それは未来の不確実性を増大させます。

不確実性の高い問題とは?

この不確実性の高い問題、つまり解きにくい問題を正しく捉える必要があります。

ここで、問題というのは大きく2つに分類するとします。

• 仕事の問題→解きにくい

• 学力テストの問題→解きやすい

「問題が解けない」のであれば、それは「問題が正しく明晰に記述できていない」と考えると何をすべきがが見えてくるはずです。 ところが、「仕事の問題」を「学力テストの問題」に変換せずに問題を解こうとすると、非常に難しく、困難な問題が立ちはだかっているように感じてしまいます。

「イシューから始めよ」にもつながる話で、問いを正しく設定することの方が重要で、それを解決するのは意外と簡単だったりして。

「コントロールできる・できない」×「観測できる・できない」問題

問題を取り扱う上で、重要な点として、自分たちが観測でき、コントロール可能な問題に取り組まないといけません。

逆に観測できない問題、コントロールできないような問題に対しては、

• 観測できる・コントロールできるような問題に分割する。

• (視点を変えて)コントロールはできる問題として捉えなおす。

というアプローチを考えてみる必要があるかもしれません。

不確実性に対するプロフェッショナルとアマチュアの姿勢

不確実性の高い問題に対して、プロフェッショナルと呼ばれる人と、そうでない人がどのように取り掛かっているのでしょうか?

プロは短い時間で一定のクオリティまで上げて、残りの時間でクオリティを作り込んでいきますが、アマ

チュアは、残り時間が短くなってから、急速にできあがってくるといわれることがあるそうです。

• 不確実なものから仕上げる→全体像が早い段階で見えるようになる。

• 確実なものから仕上げる→全体像がなかなか見えず、最終工程でようやく完成形が見えるようになる。

プロフェッショナルであればあるほど、不確実性を最初期に下げていくことを心がけているのは、そういったためです。

役割と限定合理性によって発生する問題

いわゆるセクショナリズムを徹底によって発生するセクション間の摩擦は、心理的安全性を破壊する行為につながる可能性を懸念する必要があるかもしれません。

効率を考えて「役割」を分けました。 「役割」が分かれたことで、それぞれにとっての「限定合理性」が生まれたのです。 それが解消されないままに物事が進み、 意見の対立が起こりました。 相手の考えていることがわからないので「不安」になり、 ボブは「適当に決めてくれ」 と回避的にコミュニケーションしました。 これによって、エバは料理人として尊重されていないように感じ、攻撃的な思いをボブに抱きます。ボブが、要求を変えたときにエバは自分が尊重されていないという思いから、攻撃的に振る舞います。 それぞれが、それぞれのアイデンティティを知らないうちに軽んじ、それが本格的な怒りへとつながっていきます。

コミュニケーション能力とは?

コミュニケーション能力とは?

• コミュニケーションの不確実性を減少させる能力

• 組織内において連鎖的に発生する不確実性のループを止めることができる能力

これらによって、集団内で発生する「情報の非対称性」と「限定合理性」を極力低減させていくことが可能になります。

情報の透明性

「透明性」のある状態とは、継続したコミュニケーションと仕組みで、コミュニケーションによって発生する不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態です。

よく組織で話のある「情報の透明性」です。 情報の透明性というと、「できる限りの情報を公開すること」だと勘違いされがちですが、それは1つの手段です。 公開するだけでは、コミュニケーション不確実性のうち、伝達の不確実性をわずかに下げるにすぎません。 「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。

不確実性をマネジメントする

マネジメントとは?

• 対象となる○○の資源資産リスクを管理し、効果を最大化する手法

プロジェクトマネジメントとプロダクトマネジメント

プロジェクトは、「はじめ」と「おわり」があり、それが効果を上げて「終了すること」が目的です。 それに対して、プロダクトは「製品·サービス」ですので、そのプロダクトが継続的に収益を上 げて、損益分岐点を超えて発展することで、「終了しないこと」が目的です。

つまり、これらプロジェクトマネジメントとプロダクトマネジメントはそれぞれ、「スケジュールに対する不確実性」と「マーケットの対する不確実性」を対象としています。

プロジェクト型チームとプロダクト型チーム

マネジメントする目的がなにかをベースにすることで、組成されるチームは異なってきます。

プロジェクト型チームは、計画駆動型(ウォーターフォール型)で、レスポンスタイプを最適化する挙動をします。

ここでのレスポンスタイムとは、ある要求に答えるまで時間です。

このチームは、プロジェクトを如何に短い時間で終了させるか。ということに集中します。

プロダクト型チームは、アジャイル型で、スループットを最適化する挙動をします。

スループットとは、ある時間内で答える要求の数です。

このチームは、自分たちが挑むマーケットに対する不確実性を減らすため(わかっていることを増やすため)に検証スピードをあげることに集中します。

スケジュール不安の「見える化」

プロジェクトが「間に合うか、間に合わないか」を最初から予測するのは不可能です。

重要なのは、「間に合うか、間に合わないか」ではなく、「スケジュール予測が収束していくかどうか」を管理できる体制や仕組みの方がずっと重要です。

エンジニアリングの正体

エンジニアリングという言葉の指し示す対象を「方法不確実性の削減」だと狭く捉えてしまうと、「目的不確実性」ゃ「通信不確実性」が形を変えて、方法不確実性の増大を引き起こします。 エンジニアリング全体を「不確実性のシステム」の中で捉え、「不確実性削減のシステム」を追加することがエンジニアリング組織の役割だといえます。 このように、スコープを狭く捉えることで、「何を作るか考える人」と「どのように作るか考える人」の切断に伴う弊害が生まれます。 … 「何を作るか考える人」は、目的不確実性の削減に対してアプローチをしたいと考えていて、「どのように作るか考える人」 は方法不確実性の削減に対してアプローチしたいと考えています。

現実問題としてなにを作るか、どう作るかをそれぞれ考える人は違っています。

ここで、情報なの非対称性や認知の歪みが発生しないようにすることを考えないといけないはずです。

例えば、ドキュメントを正確に書くとか、コミュニケーションを密に取るとかを考えないといけないかもしれません。

責任と権限の不一致

あるあるな話かもしれないので、自戒として。

「うちは自由な社風だから」といって、従業員に十分な権限が委譲できていると錯覚してしまう経営者も多数います。 権限を明示することは、「縛ること」であって、明示しないからこそ自由であるとする発想をすると、多くの場合問題が生じます。 従業員にとって明示的でない権限は、最も不自由な状態とちがいがありません。 権限が明示的でないことが意味しているのは、上司の胸先三寸で権限について差配できるということです。 すべての権限が上司にある状態と変わらないのです。 あるときはよくて、あるときはよくないというように朝令暮改であったならば、従業員は最小限度の権利しか行使しないでしょう。 … 経営者、あるいは上司による「権限を与えているはずなのに、自由に提案をしてくれない、経営者マインドをもってくれない」という嘆きは、よく目にします。 多くの場合、十分に責任を自覚した上これは実質で必要な権限を受け取っているのであれば、このような問題は起きません。 このような認識に至るのは、部下に権限を与えていると明示的にコミュニケーションできていないか、 それに伴う責任を十分に理解させられていないということを意味しています。

権限移譲のレベル

責任と権限の不一致を避けるために、適切な権限移譲を考える必要があります。

今まで権限を渡すor渡さないの0か100か。みたいな思考をしていたので、自分と相手がどのレベルにいるかの認識を持つためのすり合わせの場を準備してもいいのかなと。

これらは、その組織で行う様々な業務で項目別に明らかにする必要があります。 たとえば、「その件は、自由にしていいよ」 と上司が言ったときに、 暖味な権限に関するコミュニケーションが生まれています。 それは、権限のレベルでいうと7のことなのか、6なのか、それとも5なのか。 そこがわからないと、認識の不一致があったときにトラブルが生まれます。 上司は、それぞれの業務を部下がより高いレベルで権限を委譲できるように育成する必要があります。 … 定期的にメンタリングを行い、 責任の認識レベルを上げていきます。 また部下は、自分の権限を拡大できるように、自分の問題認識のレベルのどこが足りないのかを真拳に向き合い、成長していく必要があります。

技術的負債に光を当てる

エンジニア誰しもが聞いたことがあるであろう”技術的負債”。

結局あれってなんだろ?と思ってたのですが、構造化してくれています。

そして、技術的負債に光を当てるためには、2つの情報非対称性、 つまり「エンジニアは知っていて、経営者が知らないこと」と「経営者は知っていて、エンジニアが知らないこと」を解消していく必要があります。