「心理的安全性」は
「なれ合い」とは別物である

　ソフトウエアの開発チームは、全員で一つの精密機械を作っているようなもの。一人がポカをして1カ所でも間違ったプログラムを書いてしまえば、それだけで全体が動かなくなる。従って、開発チームは常にお互いの仕事をチェックしながら慎重に作業を進めなければならない。

　その際に大事なのが、互いの情報共有と信頼関係だ。ミスをしでかした本人は、それを隠すことなくすぐに報告し、全員に共有することが求められる。報告を受けたり、共有された側は、本人を過剰に責めたり、感情的に接してはならない。責められた側が萎縮して、次にミスをしたときに隠すようになるかもしれないからだ。

　そうした、率直に物を言い合える風通しのいい状態を「心理的安全性がある」という。最近流行している言葉なので聞いたことがある人も多いと思うが、心理的安全性とは、皆が和気あいあいとして、なんでも許される風土のことではない。お互いが信頼し合い、萎縮せずにミスを報告できる状態のことなのだ。

　すなわち、ソフトウエア開発の効率化に当たっては、単に人を増やすことが最適解なのではない。心理的安全性を高めることによって「作業とチェック」のサイクルを素早く回し、「速く正確に作れるチーム」を構築するのが得策ということだ。発注者や経営者は、そのことを理解する必要があるだろう。

　ここまで述べてきた指摘は、主に「社外向けの開発案件」に当てはまるが、倉貫氏は「社内における『受発注の関係』をなくすべき」という提言もしている。

　というのも、システムやソフトウエアの開発を内製化している企業であっても、発注者に当たる上層部にITの知識や経験がないため、「社内の開発チームにお任せ（＝丸投げ）」してしまうケースがよくあるとのこと。

　だが本書によると、社内のシステム開発で目指すべき姿は「丸投げ」ではなく「協働」なのだという。依頼する側の上層部と開発チームが事業活動のミッションを共有し、達成に向けてともに努力する、といった関係性だ。

　依頼する上層部側は、システムの特性を知った上で、開発プロセスについて大まかでいいので理解する。開発チームのエンジニアは、ただ言われたものを作るのではなく、作っているシステムがどう使われるかに関心を持ち、知ろうとすることが重要になる。

　社外向けのビジネスにも当てはまるが、従来のシステム開発は「作って納品すれば、それで終わり」であることが多かったそうだ。しかし、今は納品後もメンテナンスやアップデートなどで関係が継続していくケースがほとんどだろう。だからこそ一方通行の関係性ではなく、相互理解が重要になってくるのだ。