仲の良いチームじゃないと成り立たない技術がある

タイトルに迷いました。
技術？技術課題？問題解決？技術方式？少し広い意味に捉えてください。

jfluteの10年以上の、様々な現場での経験を元にしています。昔も今も全部振り返ってみました。

かぶストーリー

かぶを収穫します！

resort「かぶを収穫しますよー」

sea「はーい」
land「はーい」
piari「はーい」

resort「seaさんはこのエリア、landさんはこのエリア...」

sea「はーい」
land「はーい」
piari「はーい」

resort
(seaさん、landさん、piariさん、みんな仲悪いんだよねぇ。。。)

sea「収穫できましたー」
land「収穫できましたー」
piari「収穫できましたー」

resort「よっし！」

収穫量が増えてきました

resort「かぶを収穫しますよー」

sea「はーい」
land「はーい」
piari「はーい」

resort「かぶの量が増えてきました」
resort「この道具を使えば、効率よく収穫できます」

sea「収穫できましたー」
land「収穫できましたー」
piari「収穫できませんでしたー」

resort「あれっ、piariさんどうしたの？」
piari「道具の使い方がよくわからなくて...」
resort「いや、ここを引っ張って...そして...」
piari「収穫できましたー」

resort
(ってか、この数日間、何やってたのー!? seaさんやlandさんも気づいてたと思うんだけど...でもまあ、作業エリアも明確に分けてるし、この人数なら自分がフォローすれば良いので、別に仲悪くても関係ない、めでたしめでたし)

大きな農場になってきましたー

resort「かぶを収穫しますよー」

sea「はーい」
land「はーい」
piari「はーい」
bonvo「はーい」
dstore「はーい」
amba「はーい」
miraco「はーい」
dohotel「はーい」

resort「多っ！」

sea「収穫できましたー」
land「収穫できましたー」
piari「収穫できませんでしたー」
bonvo「収穫できませんでしたー」
dstore「収穫できましたー」
amba「収穫できませんでしたー」
miraco「収穫できませんでしたー」
dohotel「収穫できましたー」

resort「んん!? 誰ができなかった？」

(ひとりひとりresortさんが対応...いやー、この人数はもう無理無理)

resort
(でも、seaさんやlandさんとか、他の人ができずに止まってたの知らなかったのかな...いやぁ、そんなことはないと思うけど)

resort「seaさん、landさん、フォロー手伝ってくれる？」
resort「seaさんはあの人とあの人、landさんはあの人」
seaさん「俺の方が人数多くないっすか？」
resort「ああ、じゃあ、一人自分が巻き取ろう」
landさん「...」

(そして...)

resort「あれぇ、ambaさん、landさんから聞いてないの？」
amba「まあ...なんかここ押せって」
amba「でも動かないのでずっと立ち止まってました」
resort「ええぇ、その後landさんには聞かなかったの？」
amba「いやぁ...なんか話しかける感じじゃなくて」

resort
(人数多くなると、縦関係のフォローだけじゃつらい。横同士のフォローが欲しいけど、仲悪いと成り立たないな...)

おおきなかぶ

resort「おおきなかぶを収穫しますよー」

みんな「おおっ」
resort「では、みんなで引っ張りましょう」

みんな「うんとこしょ、どっこいしょ」

(まだまだ、かぶはぁ抜けません)

resort「抜けないね、この道具を使おう、三人一組で」
resort「使い方の説明あれこれー」

みんな「うんとこしょ、どっこいしょ」

(ぜんぜん、かぶはぁ抜けません)

resort (さっきより力が弱い気がする...)
resort「seaさん、landさん、ambaさん、手つないでる？」
sea「手をつながないとだめなんですか」
resort「まあ、その方が力出るよね、ってさっき説明したけど!?」
sea「いや、急激にお腹痛くなってトイレ行ってたんで」
resort「...そ...そか」
resort「landさん、ambaさん、
そういうときは、ちょとフォローしてくれると嬉しい」
land「...」
amba「はい！そういうときはフォローするもんなんですね」

resort「では、みんなで引っ張りましょう」

みんな「うんとこしょ、どっこいしょ」

(これっぽっちも、かぶはぁ抜けません)

resort「この道具でもダメなくらい大きいか...」

resort「したら今度はこの道具だ、呪文だ！」
resort「みんなの意識が同じになったとき、すごい力を発揮する」
resort「念じよ！」

みんな「うんとこしょ、どっこいしょ」
resort「ドルペンパ！」

(しかし、じゅもんはきかなかった)

(おおきなかぶははげしいほのおをはいた！)
(どがっ)
(どがっ)
(どがっ)
(どがっ)
(...)

単純なシステム構成だった時代であれば...

あまり大げさなアーキテクチャもなく共通化もされず、プログラマーの仕事がそれぞれ独立して進み、そこで必要な技術力がそこまで高度ではなく、一人一人の作業量が重要なシステム開発であれば、仲が良いとか悪いとかあまり関係ありません。

要件定義する人がいて要件定義書を作って、仕様策定する人がいて仕様書を作って、プログラマーに渡して実装してもらって、専任のテスターがテストしてリリースして...

採用する側もマネジメントする側も、仲の良さなんて個人的な話だから踏み込みません。プログラミングの経験年数だけで人を選ぶ...なんてこともあったかも!?

あくまで「比較的」というところですが、昔はそれで済むプロジェクトが多かったと感じます。

効率を上げるために敷居は上がる

しかし、ビジネス要求のスピードが上がってきて、効率性が求められるようになってくると、スピードを出すためにさらに高度な道具が必要になってきます。

プログラマーに求められるスキルは上がります。みながすんなり使いこなせるわけではありません。教育が必要でしょうが、教育も人員とお金がかかります。

少ない人数であれば、誰か詳しい人ひとりだけで、全体のフォローすることはできるかもしれませんが、少しでも人数が増えてきたら破綻します。

破綻したら、終わる人と終わらない人の差が激しくなってきます。もしかしたら、全体の効率性としては、以前とあまり変わっていないかもしれません。

要求自体が難しくなってきたら

そして、ビジネスの規模が拡大してきて、ビジネス要求の難度が高くなってくると、より複雑な問題を解決するための高度な道具が必要になってきます。

プログラマーに求められるスキルは上がります。ただ、ここまで来ると、もはやひとりの力では解決しない問題が多数になります。ひとりひとりのスキルがコラボして、ぜんたいのスキルに化けて問題を解決する、そのためのスキルが必要になってきます。

成果の考え方も少し変わります。プログラマーひとりひとりの独立した成果量ではなく、プログラマーぜんいんで作り上げる成果が求められるようになります。

「おおきなかぶ」です。

1000個のかぶのうち、700個を収穫するのではなく...

「1個のおおきなかぶをぜんいんで抜けるかどうか？」

共通化や抽象化のためのアーキテクチャも必要になり、互いに独立した作業というわけにはいかなくなります。普段から横同士で連携しないと成り立たない作業が増えてきます。ちなみに、技術的負債の返済なんかは、まさしく "おおきなかぶ" の代表格でしょう。
　=> 技術的負債の返済プロジェクトが失敗する 11 のワケ

それぞれのレイヤがそれぞれ難易度が高く、ひとりの人がすべてを把握するのも難しくなってきます。でも、全体を把握していないと判断を誤ります。

全体を把握するためにはどうすればよいのか？互いに情報交換し、把握し合うしかありません。

「仲が良い」は、れっきとした手段

もちろん、そういった状況でも、人間をほぼ「もの」と捉えて、システマティックに開発を運用していく、っていう手法もあるかもしれません。

ただ、そのシステマティックな仕組みの構築自体に、人員も時間もお金もスキルも必要です。まず、成長途中のベンチャー企業では無理でしょう。成長と問題発生のスピードに仕組みが追いつかないでしょう。

ということを前提にすると、属人的で個人的に思われる「チームの仲が良さ」というのは、そう簡単にマネジメントの視野から外して良いものではない、という風に思えます。

「仲が良い」が目的ではありませんが...
「仲が良い」が手段の一つになるからです。

仲が良ければ、仕組みがなくても成り立つことがあります。仲が良ければ、未然に防がれる問題もあります。仲が良くないと成り立たないアーキテクチャがあります。

仲の良いチームだと？

jfluteの経験から言うと...

とにかく自己解決力が違いすぎる

の一言に尽きます。

...

仲の良いチームは、自主的に問題を議論して考えて、自ら解決案を出して行動に移すことが多いなと。そのための道具も互いにフォローし合ったり、うまく連携してある一定上しっかり使いこなします。

仲の良いチームが自主的に考えた解決が適切かどうかはまた別の問題ですが、マネジメントコストが非常に少ないの事実です。プラスアルファの会話が自然と生まれる、ってのが大きなポイントです。

仲が良いチームのメンバーは、会社への愛着も湧きやすく、縁の下の力持ち的な地味な仕事もやってくれやすいです。

...

印象的な事例が一つ、過去に技術的負債が溜まってしまったプロジェクト、新たにそれを引き継いだチーム、平日の業務時間での返済はちょっと厳しい...。

「でもこのまま抱えたまま開発していくのヤダね」
「月イチで土曜日に集まって継続的に返済会やろう！」
(サービス残業じゃなく、ちゃんとお金になる残業で)

ってな話になって、実際に半年くらいやってましたかね。本来そうならないようにすべきではありますが、やり切った後はずいぶんとスッキリ笑顔でしたよ。仲良くできないと絶対にできないことだなって。

仲が良いと「そのサービスは自分たちのモノ感」が出やすいんじゃないかと。と事業会社では大切なことですね。

マズローの欲求５段階説で言うと、「社会的欲求（帰属欲求）」に当たるかなぁと勝手に思っています。

その欲求が満たされて初めて、「自分たちのビジネスを成功させよう！」という高次の欲求がようやく発生すると。

仲の悪いチームだと？

仲の悪いチームは、なんの施策も打てず、ずっとそのまま問題を抱えていることが多いです。

そういうとき、それぞれ個人個人に話を聞くと、しっかり問題意識は持っていて、アイディアも持っていたりするものですが、「こうすればいいと思うんですけどねぇ...」とだけ言って何もしない。みながその状態。互いにそんなことを話したことはない。ひとりでも場を乱す人がいると全体が乱れます。悪い方向におけるひとりの影響力は強いものです。

たいてい議論すら発生していない模様で。ツールを導入しても、何かうまくまわらない(ツールがかわいそうに思えてきたり...)。なので実装に、「このチームだとこの機能はオススメできないなぁ」とか、技術面でのアドバイスとかに影響もします。

...

ちなみに、仲が悪いって、必ずしも「険悪というわけではない」です。超最低限の会話は社会人だからちゃんと発生します。ただ、プラスアルファな会話がなかなか発生しない。互いに何も思っていないとか、何かしらの気持ち的な壁があるとか、何にせよ、発生している問題に対してチームとして、自主的にアプローチができないのであれば同じです。険悪というわけではない仲の悪いチームの方が、負の側面が見えづらく、対処しづらいかもしれません。

仮に、自己解決的に何かアプローチしようとしていても、「できるだけコミュニケーションしなくていいようにする」という方向性の解決を推進しようとする傾向があります。一見、効率性重視で悪くはなさそうに聞こえますが、そういった仕組みの構築にはコストが付きものですし、仲の悪いチームから発せられた解決策だと、目的が効率化というよりも「周りを気にしたくない」という気持ちの面に引きづられやすいので、非常に「いびつな解決」になっていることが多いです。

「そのときにひとこと周りに質問すれば、もしくは、周りが教えてあげれば、その機能(施策)要らなくない？」とか。

例えば、事業会社などでは、本来そういった仕組みの構築コストを省略して、人間性でスピードを出そうという組織デザインが多いので、それとは真逆の方向性に進んでしまう可能性があります。仲の悪いチームはコストが高いのです。

あと、当然のことながら...
「離職率は高い」という強い印象です。

...

もちろん、たんなる仲良し小好しじゃダメですが、どんだけスキルの高い人が集まったとしても、仲が悪いと、一定以上の難度の壁を、チームとして超えることができないなと。

重要な施策の一つ

特にサービス開発をしている成長途中のベンチャーでは、周りとコミュニケーションを取らなくてもいいようなシステマティックな仕組みを構築する余裕がないでしょう。(組織変化のスピードに仕組みが付いていかないでしょう)

それが前提になる以上...

仲の良さを活用したチームエンハンス

が、複雑なビジネスを成り立たせるための重要な施策の一つになるのではないかと考えるのです。

...

誕生日をおおげさに祝ったり、週末にイベントをやったりなど、普段からの挨拶などしっかりさせたり、Web企業でよく見かけるのは、こう考えると納得できることだなぁとも思います。(最初けっこうビックリしたけど...)

いわゆるオシャレなオフィス、なんかも、「コミュニケーションが生まれやすいように」って、いまはしみじみ思います。コミュニケーションには空間が必要ですから。「仲良くしろー」って言ってするものじゃないから、仲良くするための間接的な施策が必要なんですね。

でもいま思えば...jfluteがSIerでプロジェクトリーダーやってたときも、「近い仕事をやっている同士が近くに座るように」って、席替えを機能単位でしょっちゅうやってたなぁとか。で、Aさんと議論してるときに、しれーとBさんにも振って、AさんとBさんで議論し始めたらjfluteはスッと消えるとか...他にも細かいことたくさんやってましたよ。このブログのような分析や意識は持ってませんですが、チーム内のことはわりとスムーズに事が運んでたなと。(みんな楽しくやってくれていたように勝手に思ってます^^)