強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016

業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。

では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。

いまお読みの記事は前編です。

プロジェクトの多くは技術ではなく人間系で失敗している

吉羽 龍太郎氏（Ryuzee.com）。

吉羽と申します。いままで野村総合研究所とか、Amazon Web Servicesで働いておりまして、今年からフリーランスになりました。過去、僕が働いてきた環境でマネジメントや採用などをしてきて、そこで得てきた知見などをシェアしたいと思います。

これは「ピープルウェア」というトム・デマルコの本からの引用ですが、「実際のところソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と書いてあるんですね。

開発プロジェクトは技術じゃないところで失敗しているところの方が多い、ということなんです。

技術の問題は、勉強したり詳しい人を連れてくればクリアできるのですが、人間系の問題がクリアできていないと結局最後まで開発プロジェクトがうまくいかないことが多い、というのが僕の経験ですね。

ですので、エンジニアは技術だけじゃなくて人間系、社会学系のところも注目しなければいけない、というのが今日の問題提起です。

チームの課題とカイゼン

1つ目のテーマは「チームの課題と改善」です。

まず、よくあるチームの課題を見ていきたいと思います。

例えば「仕事が多すぎて新しい技術やプロセスを試す時間がない」。会場の皆さん、どうですか？ けっこう手があがりましたね。

「必要なスキルを持った人が足りない」。どうですかね？ がんがん手があがりますね。

「状況を改善しようにもアイデアが出てこない」。これは少なめですね。

「すぐに人が入れ替わるので、仕事のやり方に慣れない」。これはけっこう手があがりましたね。

「メンバーのやる気がない」。これもあがりましたね。

じゃあ、いまのチームに課題がある、と思う方、手をあげてください。だいたい80％、90％くらい手が上がりましたね。

ないと答えた人、そんなはずないですよね。

課題があると答えた人、カイゼンはしてますか？ 課題を認識してもカイゼンしていないのは見て見ぬふりです。できるところからカイゼンしてください。

技術だけでなく、組織についてもカイゼンしていかなければならないと僕は考えています。

カイゼンの進め方

カイゼンの進め方ですが、一般的にはバリューストリーム、流れに注目します。例えば、新しい機能を作るには、要望が来て、それを実装して、使ってもらう、といったこの流れの全体ですね。

全体を見ないと何が起こるかというと、自分の目が見えるところだけの部分最適化になって、全体としてはカイゼンされていなかった、と言うことが起きます。

それから「知恵を使う」。例えばDevOpsの文脈では自動化とかツールの話に行きがちですが、もっと人間系のことを考えるとか。

「今が最高だと思わないで変わり続ける」。カイゼンに終わりなしです。

「目標を立てる」。目標を数字で把握して計れるようにするのは結構大事です。計れない、見えないものはカイゼンできないんですね。

「チームで取り組む」。自分だけでカイゼンをやろうとしても心が折れちゃうので、チームみんなで、組織みんなで取り組む。トップダウンで、というのはあまりうまく行かないんです。

リーンスタートアップなどが注目されて、良い製品を作るために、ビルド（開発）、メジャー（計測）、ラーン（学習）といったフィードバックサイクルを早く回すことが大事と言われるようになりましたが、これは組織運営も同じです。

組織運営も、カイゼンをやってみて、効果を測定して、そこから学んで次のアクションをとる。ビルド、メジャー、ラーンを早く回すことが大事だと考えます。

だから一年に一回大規模な組織改正をするのではなくて、もっと小さいサイクルで試して、ダメならやめる、うまくいったらどんどん広げる、みたいなやり方を進めていくのがいいのかなと思います。

なぜチームが必要か？

チームが必要な理由は、一人ではできない規模の仕事をやるためです。ただ、人が集まっただけではまだチームではありません。

ゴールを共有して、いろんな人が持っているスキルを組み合わせて全体の能力を補完し、レバレッジし、それを仕事に活かしていくのがチームです。

強いチームの特長は「続けられる」というのがキーワードだと僕は思っています。何を続けられるのか。

「ビジネス上の結果を出す」。短期的に結果を出すのはデスマーチでできるかもしれませんが、続けるのは大変です。

「変化に対応する」。ワンショットの変化ならなんとかなるかもしれませんが、どんどん変わるビジネス環境に対応し続ける。

そして「成長を維持する」ということを続けられるのが、強いチームだと思います。

強いチームの形成

強いチームの形成とか構造について話していきたいのですが、みなさんの仕事は単純ですか？ 単純ではないですか？

ソフトウェアに関する仕事はビジネスにひも付いているので、基本的に複雑な仕事です。 そういう仕事であるときにチームにどんなものが必要かを考えると、多様性は絶対に必要です。

多様性とは性別とか国籍とか年齢、育った環境や好み、考え方などがばらばらとしている方がいい。ばらばらで同じゴールを向けないのは困りますが、バックグラウンドとしてばらばらなことが必要。

複雑な問題やいままでなかった問題を解くために、多様性をもっていろんな視点で問題の解決に迫る必要があります。そして多様性があればいろんな意見が出てくるので、フィードバックによる軌道修正をしていこうと。

多様性がないと、従来のやり方にフィードバックしにくくなって、いままでのやり方でいいんじゃないか、とか。文句が外に向けられて「うちのやり方が気に入らなくてさ」と飲みながら終わっちゃうとか。

上手くいってないことを他人やツールのせいにする。で、考えても無駄だから目の前のことをやればいいよとなって、モチベーションが下がって、会社をやめる。

多様性がないと、こういう傾向が出やすい。

チームには形成ステージがある

チームには形成のステージがあります。これを説明しているのが「タックマンモデル」です。

最初が「形成期」。人が集められて、まだコミュニケーションがあまりない。

会話をしたり意見の反発があったりと、そのあとの「混乱期」がある。お互いに意見を言うようになるんだけど、自分と違う意見を言われるとイヤじゃないですか。このあたりは仕事を進めなくちゃと思って、各自が自分の思うところだけをやったりします。

そのあと「統一期」が来て、一緒に活動して人の意見を受け入れて、目的や期待値がだいたい一致して動き始めます。このあたりで機能するチームになる。

「機能期」になるとよく機能するチームになる。一体感があって自律性が高いということで、最大の成果が出せる。

このモデルは当初4つでしたが、最後の「解散期」があとからつけられたんですね。SIerとかだとプロジェクトが目的を果たして解散することがあるので。

見ていただくと分かるとおり、安定して機能するチームを作るには時間がかかるんですね。僕の経験だと半年とか、短くて3カ月。

いいチームになるには時間がかかると。

≫中編に続きます。次のテーマは「リーダーシップと権限委譲の仕方」です。

Developers Summit 2016

• 5カ月でAngularJSとTypeScriptでSPAを開発。その技術の選択理由と開発過程は？（前編） Developers Summit 2016
• 強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
• レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
• Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（前編）。Developers Summit 2016
• エンジニアを成長させるためのマネジメントと組織づくりとは～アドテクを中心とする組織の取り組みの例。Developers Summit 2016