氷山モデルとは？

氷山モデルとは、表面的に起きた出来事は氷山の一角とし、その水面下にある要素も含めて全体像を把握しようと言う考え方です。

心理学でも自閉症などの支援をするためにも使用されいて、
課題解決において汎用性が高いフレームワークとして利用できます。

氷山モデルの説明は、下記の記事が非常にわかりやすかったです。
https://www.change-agent.jp/systemsthinking/approach/the_iceberg_model.html

上記記事の内容をざっくりまとめると、

発生した問題を下記のレイヤーで捉えます。
① 出来事
② パターン
③ 構造
④ 意識・無意識の前提

下に行くほど、深いレイヤーになります。

そして大抵の場合、
①に対して表面的な対処をするだけで問題に対応したように扱われがちです。
ただ、この出来事は氷山の一角でしかなく、
その水面下にある②〜④まで深掘りした上で対策しなければ、根本解決にならないよという内容です。

例えば

前職でSESとして複数の現場を経験する中で、
何度か目にした問題をもとに使い方をまとめてみます。

技術的に詳しくない分野の対応を若手が任される状況で、
調べてもわからない部分があった時、
バカだと思われたくなくて質問をせず、後で手戻りが発生してしまうケースです。

新卒時代の私もよくやっちゃってました。

表面だけ見ると「知識・経験不足でした」で片付いてしまいます。
しかし、ここで「今回でこの知識を理解したからもう次は大丈夫」と考えた場合、
また詳しくない箇所の修正等を任された時に同じ失敗を繰り返してしまいます。

少なくとも「怒られるのが怖いから聞かない」が治らない限りは、
次また詳しくない作業を任されたときに不明点を残したまま進めてしまうためです。

氷山モデルをもとに考えると、さらに下記のように考えられそうです。

①出来事
→ 知識・経験不足でバグが発生。
②パターン
→ これまでも本人は不明点があることに気づいても、怖くて質問できていない。
③構造
→ 質問をしやすいタイミングや日頃から関係性を気づくための仕組みが作られていない。
④意識・無意識の前提
→ 責任を押し付け合う習慣がチームにあり、質問をするハードルが高かった。

状況等によっても変わると思うのであくまで一例ですが、
このように考えていくと、根本的に解決しないといけないのはチーム内の他責思考なのかもしれません。
個々人に「質問して！」と注意するだけでは、人が入れ替わるたびに同じことが繰り返しかねないです。

もちろん、質問できなかった本人が「チーム内の他責が問題だ！」と言ってると一生成長できないです。
自分なりに恐怖に立ち向かうか、「後で問題発生する方が信頼を失う」と考え方を変える等の努力は必要だと思います。
あくまで組織の成長を考えるときに④まで深ぼるのが良いのでしょう。

最後に

同じ問題が人が入れ替わっても発生するなどあれば、氷山モデルの出番です。

一定のパターンがないかをチェックすることで、個人の課題が明確になりますし、
さらに構造や意識・無意識の前提まで深掘りすれば、組織としての課題発見に繋げられるかもしれません。

最下層が「意識・無意識の前提」と書いてあるくらいなので、結局問題は人ということになります。

エンジニアをやっていると、技術にばかり目が行きがちですが、
実際に作業をしているのは人間なので、人間についての理解を深めることも大事だと思います。

私ももっと人として成長していけたらとしみじみ思います！
来年に向けて気合い入れ直しましょう！