どうやって40名のチームを組織化するか?

仕事

どうやって40名のチームを組織化するか?

この2年ほどはひたすらソフトウェア開発に関わっておりました。その開発陣は約40名ほどいて、その他にもカスタマーサポート(事務局)で10名程度、制作関連で10名程度が常時サービス運営にあたっていて、その他にもステークホルダーが複数存在しています。

ここで書く「組織化」とは、それらの人々がそれぞれに違うバックグラウンドを持っており、もちろん性格も異なり、人の追加や入れ替え、ステークホルダーの方針変更に伴う柔軟な対応が求められる中で、どのように「ガバナンスやフローを定め」、「役割の明確化と業務を設計する」ことで「各人の裁量範囲を定め」て「ある程度の余白を持ちながら」も「ある程度ベクトルを合わせ」て「連携して極力効率的に課題を解決」していけるのか、という意味合いで「組織化」と書いております。

はじまりの2年前から色んな事情のもと、私達はかなりの無理をするしかありませんでした。 始まった時から近い将来の問題は見えていたのですが、それでも踏ん張ってとにかく目前の問題をひたすらに片付けていく毎日が1年と数ヶ月ほど経った頃、問題が問題を産む速度が急速に高まり、非常に苦しい状況になりました。

しかし、逆にそれを機に整理整頓をはじめ、前述したような「組織化」に取り組んだのです。

これが最も重要で最も苦しいことの一つになりましたが、人はなかなか問題とは向き合いたくないものです。 向き合うための言い方や、見える化、いかに全体を網羅して整理するのか、検討のテーブルにのせるための合意形成のとり方、といったことを私たちは試行錯誤しながらようやくステークホルダーを含めて向き合うことができたのです。

問題の連鎖によりどこから手を付けなければならないのかも見失いそうになる中でしたので、ディテールを追っていては到底ゴールにはたどり着けなさそうです。そこで私達は、大きく大きく問題を捉えることを心がけました。

まず、仕事が流れていく順番に大きく3つのグループが関与します。まず第一グループ、次に第二グループ、最後に第三グループといった具合です。この中で特に第一グループ、次に第二グループがいろんな仕事(課題)に対して兼務しているため、遅延や認識の齟齬の発生、要件の精査や影響調査漏れといったことに繋がり、結果的に第三グループにしわ寄せが行き、問題が問題を産んでいたのです。

ということを明らかにすることからはじめました。

そこでその課題に対してはシンプルに、「兼任を禁止して専任化」すること。さらに稼働率を80%で見積もり、残り20%をレビューに回すことを決めました。もともと40名も必要な開発にあたり、兼務が可能な類の業務ではなかったのです。

すなわち、40名を3つのチームに分け、抜けもれなく被りなく各チームの中で第一から第三のグループが、必要な役割とスキルセットが伴う形で再構築しました。さらに、その3チーム内のスキルや経験に紐付くようなバランスが崩れないように、「3チームを横断してレビューする専任者」も決めました。

とってもシンプルなものですが、性格や経験領域、やりたいこと好きなことやスキル等を鑑みながら成り立つようにするのは意外と摩擦を産むものです。 粘り強く対話をしていく必要がありました。ちなみに、役割上「兼務」が必要なケースも出てきますが、その場合は「関与を薄く」するように業務を設計します。

ここまで整理が進むと次は、3チームの各チームがやるべきミッションを明確にすることはもちろんですが、そのミッションを進めていく「工程の標準」を定めました。

プロジェクトのはじまりから、終わりまで。A→B→C→D→E→Fという工程標準を定め、各工程ごとに必要な「承認プロセス」と、「標準となる成果物」を規定しました。承認プロセスは途中経過の大きな確認点として重要ですし、成果物を具体的に規定することでヌケモレを防ぎやるべき作業のベクトルを合わせることができます。

成果物に関してはどのような目的を達成するものなのかを明記し、それぞれに「サンプル」を用意することで作業がしやすくなるようにし、またヌケモレなく作業段取りが組めるように共通認識化を進めました

これで標準は定めましたが、実際はケースバイケースになるため、工程の標準は一番端から端にあたる範囲ではあるものの、ある程度は裁量を渡して省いて良いもの、簡略化しても良いもの、他のチームに渡すもの、などについては「余白を持った運用」を心がけています。

ここで書いた「余白」とは、それによって仮に失敗したとしても、リカバリー可能な範囲。 という意味です。

ここまでが開発チームのことになります。もっと思い返すと他にもいろいろと出てくるでしょうけれども一旦ここまでにします。

サービス運営にあたっては残りの「カスタマーサポート(事務局)」と「制作関連」にもチームがあります。制作関連についてはそこまで深くはないため、週次での情報共有で問題ありませんが、「カスタマーサポート(事務局)」と「開発陣」は密接に関わる必要があります。

開発に関連する取り組みの裏で、カスタマーサポート(事務局)に関する取り組みもはじめました。カスタマーサポート(事務局)はもちろんのこと、顧客の声を一番聞く場所になりますのでとても重要だと考えていましたが、実情は「コールセンター」のように受け付けるのみになっていたのです。

そこで、開発陣と同様に取り組みを進めます。

これまでに蓄積された顧客の声の整理整頓からはじめ、顧客が求めることを洗い出していきました。それらをまとめていく過程で意志を入れ、方向性を示します。つまり、「事務局(コールセンター)の開発一体化体制への移行」です。

顧客の質問に答えるのはもちろんのことですが、電話口で解決できる範囲や深さを広げること。さらには、顧客が求めることをより良い機能開発にフィードバックしそれを管理していくこと。そして、障害等が発生した場合に顧客へのアナウンスと解決を迅速に対応できることを主な要点として「開発一体化体制の事務局」とし、各ステークホルダーとの合意形成を進めました。

そんなことをする人の肩書を「プロダクト・マネジャー」と呼び、そのあとは開発陣と同じように、プロダクト・マネジャーがやるべきタスクを決め、その成果物を定義し、サンプルを用意する。それらが達成できるであろう想定の人物像やスキルセットを洗い出し、いちから採用活動をしました。

こちらはコールセンターという言葉から連想されることを生業にしている関係者との合意形成はことのほか摩擦を生み、困難を極めましたが、それでも一つ一つ整理整頓していくことで方針が定まりました。

最後に、これまでにおいて整理整頓してきたことは大きく、「体制の整備」と「工程の標準化」という2つのこと柄に集約されます。ただ、これらは大枠を定め合意形成したまでに過ぎませんので、最も大切なのはどう「運用」していくのか、というところにあります。

さらに、問題は「交差点」に発生しやすいため、開発陣であればチームをまたぐところや技術をまたぐところ、開発と制作、開発と事務局、事務局と制作といった狭間に注意する必要があります

そこでこれまでに整備してきた「体制」と「工程標準」を地図にして、各チーム・各担当がどこを歩いており、標準に則っているのかを事細かに追うことが「運用」時に大切になってきます。言葉を変えると「定着活動」や「浸透」といったことになると思います。

これについては週次で開発・制作・事務局の各担当が集まり、前述したような共通認識となる地図を元に議題を展開し、自分の領域はもちろんのことそれによって生じる他チームや他者への影響という観点で会議体の運営ルールを定めて運用しています。

そうして私たちは、開発陣40名(+他20名)を組織化してきたのでした。

この記事が気に入ったら
いいね ! しよう

Twitter で
Tetsunori Yuasa

Tetsunori Yuasa

1983年9月8日 福岡県生まれ。住んだことがあるのは福岡・大阪・東京・ハノイ・名古屋。海外旅行、Netflix、漫画、寝ることが好き。詳細なプロフィール、旅した世界の写真たちまとめ、ご質問は質問箱まで。連絡先 tetsunori.yuasa@gmail.com

コメントを残す