心理的安全性の高い環境は本質を求めた先に見つかりました

こんにちは！クラウドサーカス開発部で、チャットボットツール『IZANAI』の開発を担当している苑田です。

2023年1月まで弊社（以下、CC）の技術顧問に就任されていたまつもとゆきひろ（以下、Matz）さんとの社内勉強会で学んだことや、それを通じて変化したIZANAIチームの開発体制について発表します。前回は、ソフトウェアエンジニアとしての本質について書かせていただきました。今回は、本質的な開発体制に変わったことで心理的安全性の高い環境にも変容してきたことについてお伝えします。

本質を求めた結果、心理的安全性の高い環境になった

前回、実際に書いたコードでレビューをすることによってコミュニケーションが増えたとお伝えしました。ただ仲良しこよしでレビューしているのではなく、お互いに言い合える環境が構築されています。

IZANAIチームメンバーが年齢的に近いこともあり、意見を自由に言い合える環境なので、議論の際、メンバーがソフトウェアエンジニアとしてのプライドを持って意見をぶつけ合う、健全な空気感があると思います。

たまに嫌な空気になることもありますが、全員がIZANAIをいいプロダクトにしたいという思いから話し合いができているので、結果的に、心理的安全性の高い環境が構築されたと思います。

最終的に議論を収束させる際は、全員が自分の意見にどのようなメリットがあるかをとにかくアピールします。
タスクに対してメリット・デメリットを並べ、何が最適なのかを議論し合います。メンバーそれぞれが、一歩引いて重箱の隅つつくのではなく、一歩踏み込んで意見を言い合うので、お互いを高め合うことにもなっています。
気になったことや足りないことに関してはすぐ言うようにしていますし、設計や要件定義の段階でも同じです。詳細設計からコミュニケーションが増えたことで、その後も継続して言いやすい雰囲気になったのは大きなメリットでした。結果として、要件定義や開発MTGの場で発言数が増えています。

雑にしていいのはあくまで設計で、要件定義は雑にしてはだめ

ただ、まだまだ改善が必要な部分もあります。詳細設計をブレストレベルにしたことによって、仕様が雑にならないように意識しなければならなくなりました。設計においては、雑にしても問題ない場合がありますが、要件定義においては、雑にすることは許されません。コードを書くのは楽しいですが、仕様を曲げてはいけません。

これまでは詳細設計書の中で仕様に沿うように書いていましたが、現在のやり方は個人の自由やセンスに依存するようになっており、仕様が急に曲がることもあるため、注意が必要です。

実際に、「あれ？ここの処理って、この仕様だったはずなんですけど、スルーされていませんか？」ということが起きているため、改めて明確な線引きが必要です。

IZANAI開発チームはプログラマーではなく、エンジニアを育てていく

Matzさんからのアドバイスを受け、開発チームが良い方向に進んでいるため、今後はそれぞれが独り立ちできるようになることがベストだと考えています。つまり、エンジニアとして独り立ちすることです。

プログラマーは、詳細設計書を渡されてコードを書くことができますが、これは誰でもできます。私は個人的に、エンジニアには自主性を身につけることが必要だと思っています。自分で考えることは、自主性を習慣化することに繋がります。自主的に、ある要望を実現するための最適な処理方法を考えることや、負荷を減らして早く、安くエンドユーザーの画面に表示するために何をすべきかを考えることは、エンジニアとしての基礎力を底上げするために必要なことだと思います。

さらに、開発に携わらないビジネスチームとのミーティングでも、普段から自分で考えているからこそ、難しい要望に対して、現実的にデプロイできる落とし所を提案することができます。ソフトウェアエンジニアとして独り立ちすることは、業界だけでなく、組織内でも非常に重宝され、信頼を得やすいです。

私は、IZANAIチームでの業務が市場価値を高めることに繋がると信じています。
だからこそ、今後、エンジニアとしてプライドを持ち、主体的に良いものを作るために尽力できるような、エンジニアとして独り立ちできる組織作りをしていきたいと考えています。
IZANAI開発チームは、プログラマーではなく、エンジニアを育てていくチームにしていきます！