見出し画像

コミュニケーションコストを下げて開発スピードを上げよう委員会

こんにちは、株式会社 Zaim の開発部でマネージャーをしている高山です。年末の超忙しい時期、皆さまいかがお過ごしでしょうか。

Zaim は、この 1 年を振り返ると社員が増えた一方、コロナ禍をきっかけにフルリモートでの勤務となったのが大きな変化でした。この写真は今年 3 月に移転したものの、ほとんど使われていないオフィスです。悲しい……。

画像3

こうした環境下において、エンジニアを率いる身として特に意識しているのは「コミュニケーションコストを下げる」ことと「開発スピードを上げる」ことです。最近「これらを両立するために、コミュニケーションのやり方をもっと改善できるんじゃないか」と思うことがあり、今回、この note を書くことにしました。

なお Zaim は自社サービスを開発する会社なので、それを前提とした内容となっています。

説明のための登場人物です。X さんはディレクター的な人、A さん・B さん・C さんはソフトウェアエンジニアのような実作業をする人と想像してみてください。

パターン1:A さんの場合

X 「こんな感じで作業お願いしますー」
A 「了解」
A(開発開発開発開発)
A 「指示のない別の画面も基本的な UI は一緒ですけど、どうします?
X 「えーっと、同じでお願いします!」

こういうやり取りを、見かけたことはないでしょうか。何だかまどろっこしいですよね。

パターン2:B さんの場合

X 「こんな感じでお願いしますー」
B 「了解」
B(開発開発開発開発)
B 「指示のない別の画面も基本的な UI は一緒ですけど、 同じにします?
X 「はい、お願いします!」

こういうのも見かけますね。悪くはない気がします。でも、もうちょっと改善できそうです。

パターン3:C さんの場合

X「こんな感じでお願いしますー」
C「了解」
C(開発開発開発開発)
C「指示のない別の画面も基本的な UI は一緒なんですけど、こっちも同じようにしておきましたので問題あったら言ってください
X「ありがとう!」

さて、どれが最もスピーディでしょうか?最後のパターンでしょうか。

え、ちゃんと X さんに確認を取っておかないと、後で差し戻しがあるかもしれない?

ですです、そうですね、そうなったら作業が無駄になりますもんね。A さんや B さんのように、会話を細かくしたほうが安心するのも分かります。

でも自社サービスで、そういうやり直しって頻繁にあるでしょうか。後々「問題があるので、やり直して」って言われないよう、今よりもっと自分で考えて決断できるようになることが、作り手には求められているんじゃないかと思っています。

確認回数の増加によるスピード感の喪失

そして C さんには、他の二人に比べ、仕事でスピードを出すための大きな違いがあります。

A さん B さんは表現は違うものの、作業の可否を X さんに委ねています。X さんからの返答があるまでは進められません。一方、C さんは X さんが確認しようがしまいが作業を進められます。

今回の例では確認の工程が 1 回でした。開発を進めていく中で、確認したいことが二つ・三つと増えると、どうでしょうか。A さんや B さんは返答を待つ間、他の作業を進めていそうですね。でも、コンテキストスイッチはどんどん増えていくことになります。

さっきの続きやろ…あれ、どこまでやったっけ?

って経験は、誰しも覚えがあると思います。

スクリーンショット 2020-12-21 22.13.18

作業を待っている間は、頭の中にも「確認オッケーだったら作業を再開しよう」というマインドシェアが取られます。こういうのって、すごく無駄じゃないでしょうか。

「はやく答えないと!」 vs 「あとで確認すればいいか」

今度は逆に X さんの視点から考えてみましょう。先ほどのパターンを簡略化すると、以下のような質問を受けたと想定できます。

A さん:どうしますか?
B さん:同じようにやっておきますか?
C さん:やっとくんで、問題あったら言ってください

この時の X さんの気持ち(想像)。

A さんの時:早くどうするか決めないと、作業が停滞してしまう!
B さんの時:早く回答しないと、作業が停滞してしまう!
C さんの時:めっちゃ気が利くやん〜〜〜!あとで暇な時に見ておこ

……わりと脚色してる感は否めませんが、X さんと同じ立場の人は「うんうん、そうそう」って思ってるんじゃないかと期待しています。

まあ正直、コレは理想の状態なので

「気が利くとかいうけどサ、それはアウトプットが適正な場合でしょ?」

というお叱りを受けそうです。

いやはや、まったくその通り。正論ですね。つまりその差分を埋める必要があるわけです。目指すべきは

X さんが期待しているアウトプット精度を、自分も出せるようになる

ということです。もちろん完璧に同じになれる必要はありませんが、できるだけ近づく・近づくための努力をする必要があるかなと思っています。

極端な話、これができないと「指示がないと判断できない人」という評価を受けてしまいます。

今 A さんようなコミュニケーションをしている人が、いきなり C さんにジャンプアップするのは難しそうです。「自分は A さんみたいな振る舞いをしているな」と思い当たる人は、まずは B さんを目指すところから始めるといいのではないでしょうか。

事前の仕様確認の精度を上げればいいのか?

もう一つ、別の観点からのツッコミとして「事前に網羅的に仕様を作っていれば、このようなコミュニケーションコストの問題は回避できますね」というのがありそうです。

しかし、待ってください。それは準備のコストがとっても高まりませんか?

網羅的な仕様を作るためには、あらゆる状況を想定した仕様を作る必要があります。その時、発生するのが

この状態だったらどうしますか?
こっちの画面はどうしますか?

という「どうしますか?」の連続です。

開発の現場において、あらゆる事象を事前に想定するのは大変な労力を要します。ある程度は途中で妥協せざるを得ません。問題は「どこに妥協ポイントを置くか」です。

例えばコミュニケーション量と仕様の厳密さをそれっぽい図にすると、こんな感じでしょうか。こんなもんですよね。今、Zaim はかなり右上の位置で開発していますが、もうちょっと左下に寄せたいなと思っています。

スクリーンショット 2020-12-21 22.19.31

もちろん、左下を目指すのは困難な道です。なぜなら、後ろの工程で想定外が発生することが多くなるからです。でもそんな時に「あ、ここは私のほうでやっておきます」というコミュニケーションと正確なアウトプットが備わっていたらどうでしょう。最高じゃないですか。

ユーザーのことを考えると道は開ける(と思う)

開発スピードを上げるためには、コミュニケーションコストを下げることが大事、という話をしてきました。実際には、何をどうすれば良いのでしょうか。個人的には、

本来、必要のない相互確認を減らすこと

が必要だと考えています。

もっと掘り下げると、どうすれば「本来、必要のない確認」を減らせるのか。それは、

曖昧な状況であっても、正しい選択ができることを増やす

ことだと考えています。

どうすれば正解が示されていない中で、正しい選択ができるのでしょうか。

……ユーザーです。常にユーザーの考えていることを想像するのです。

画像4

ユーザーが違和感を感じないか・間違わないか・喜んでくれるのか、常にユーザーが操作している時のことを想像するのです。自分だったらどう感じるか・自分の身近な人だったら?この人だったらどう思うだろう?常に「他の人が、どう感じるのか」ということを考えて考えて考え続けるのです。

どんな人でも「どうしますか?」ではなく「こうしますね」と言えてることはあるはずです。その、できていることの量・範囲を増やしていけば、素晴らしい活躍ができるようになるんじゃないでしょうか。

まとめ

「すべて自己判断でやる」ことを推奨しているわけではありません。「自身で判断できることを増やす努力をしよう」というのが、本質的な趣旨です。

「どうしますか?」ではなく「これでいいですか?」や「これでやっておきますね」というコミュニケーションを増やそう
 ユーザーのことを考えて・想像して意思決定できるようになろう

良いお年をお迎えください。

※記事中の画像は、スタジオジブリのサイトで配布されているものを利用させてもらいました。



結構いろいろ募集してます…



この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
うれしい!!
22
気ままに書いてます

こちらでもピックアップされています

Zaim スタッフの頭の中
Zaim スタッフの頭の中
  • 96本

「毎日のお金も、一生のお金も、あなたらしく改善。」をコンセプトに家計簿サービスを運営する株式会社 Zaimです。中のスタッフたちが、どんな風にサービスに向き合い働いているかを綴る note です。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。