全社横断！プロジェクトマネージャーとしてタスクフォースに入隊した話

「ランサーズ Advent Calendar 2018」22日目の記事です。

今年、ランサーズではスピーディな課題解決へのアプローチとして初めてタスクフォースという組織体制を取り入れました。
ふだんのプロジェクトチームとは異なる組織構成のため、プロジェクトマネージャーとしてどう関わったのか、なにをしたのかを備忘的に記録しておきます。

はじめに

そもそもタスクフォースって？

特定の課題を達成するために一時的に設置される組織のことで、軍事用語の「機動部隊」がベースになっています。「タスクフォース」って言葉自体なんか入隊したくなるかっこよい響き。
一般的にタスクフォースのメンバーは組織内の各部署から横断的に抜擢され、課題を達成したら解散となります。
プロジェクトチームが比較的長期間にわたる大きなテーマを扱う場合が多いのに対し、タスクフォースは緊急性の高い課題解決にあたる場合が多いと言われています。

【長所】
柔軟かつ速やかに問題に対処でき、一定期間にエネルギーを集中するため、高い成果が期待できる
【短所】
タスクフォースで獲得された新たな知識・情報が、タスクフォースの解散とともに消滅し、組織に浸透しづらい

今回は、解決したい課題の緊急性が高く、部署を横断して取り組む必要があったためタスクフォースの結成となり、プロジェクトマネージャーとしてアサイン(入隊)されました。

タスクフォース概要

• 主に社内向けシステムの開発・運用(システムの主要ユーザーはタスクフォースメンバーに含まれている)
• 期間：約4ヶ月
• メンバー：4部署から集結。計20名(うちエンジニア8名)
• ミッション完遂するためのタスク件数：142件。タスクの洗い出しはすでに実施済みの状態
• プロジェクトリーダー1名、プロジェクトマネージャー2名体制
• エンジニアは1ライン2~3名体制(プロジェクトマネージャーも必要に応じて開発)

というなかなかのヘビーさ

プロジェクトマネージャーとしてやったこと

1. 要件定義

基本的にひとつひとつのタスクは「○○という課題を解決すること」という要望だったため、情報整理や現状のフローの確認、ヒヤリングから要件定義をはじめました。
ここで重要だったのが物事の本質を理解すること。
メンバーそれぞれバックグラウンドや得意領域は異なるため本質を見極めず表面だけで判断してしまったり解決方法を相手任せにしてしまうと「顧客が本当に欲しかったもの」状態になってしまう…
言われたことをそのまま受け取るのではなく、なんのためにやっているのか、本当に必要か？など深掘って意図をつかみ、よりよい解決方法がないか考えながら進めました。

2. スケジュール管理

管理が冗長になってしまいますが用途が異なるため3種類を使い分けていました。
ちゃんとミッションコンプリートできるか不安すぎて1日に何度も確認していたのは内緒。

ちなみに2と3はタスクフォースに限らず普段から日常的に利用しているものです。

1. タスクフォースの全タスク管理(全社向け)
   全体感把握のためすべてのタスクをリストアップして「状態」「完了率」「開始日」「完了予定日」「完了日」を記載。
   主要メンバーの定例ミーティングではこのシートをみて順調かどうかを確認していました。

2. ガントチャート：自分が担当するプロジェクトの全体スケジュール管理(エンジニア向け)
   Googleスプレッドシートのアドオン「project planning」を少しカスタマイズして使用。緑は順調、赤は遅延というように色で表現できるのがわかりやすいです。
   

3. カンバン：タスクの状態管理(エンジニア向け)
   よくあるカンバン方式なので割愛します。通常はZenhubですが切迫した状況のときはホワイトボード&ふせんで運用していました。（いつでもすぐ目に入るし達成感あるのでここぞというときにはいちばん）

3. 関係者向け説明会を開催する

リリースはゴールではありません。実運用において課題解決されていることが重要です。
「使っている」という受け身の状態ではなく「一緒に作る」状態にするため、新しい機能をリリースしたら関係者を集めて使い方説明会を開催しました。目的を理解して使ってもらうことでバグの早期発見にも繋がります。

改善要望はスプレッドシートで一元管理し、棚卸しとしてプロジェクトリーダーに優先順位をつけてもらい、対応するもの/しないものを決めました。

4. コミュニケーションのきっかけをつくる

チームビルディングにもつながる話ですが、普段業務での関わりが少ないとコミュニケーションもとりづらいものです。
キックオフ飲み会では、エンジニア・他部署それぞれがメンバーを紹介するスライドでプレゼンをして活性化をはかりました。

ほかにも、あえて雑談をしてみたり、リリースしたらチャットで共有して反応を欲しがってみたり。

5. 走りながらチームビルディング

ほとんどが初めて一緒に仕事をするメンバーでしたがじっくり時間をとってチームビルディングする余裕はありません。
ときにはわだかまりが生まれることもありました。
そういうときはTeamGeekのHRTをテーマにディスカッションしたり、解決策のアイデアを出しあって実際に試してみたりもしました。

なかでも良かったのが、メンバーの性格やランサーズでも導入しているFFS理論(人の思考行動の特性を5つの因子で計るもの)を活用して得意領域や苦手領域を把握し、アウトプットが最大化するように補完する方法です。答えが足し算ではなく掛け算になるパズルをしているような感覚で、攻略法を組み立てるのが楽しかったです。

大事なのはヒトではなくコトに向かうことだなと。
振り返ってみると、走りながらチームビルティングしていたように感じます。

結果

タスクフォースを結成し、結果的に期限内にやりきることができました。

実証実験してみて有効だということがわかったので、今後またタスクフォースが結成されると期待しています。他の企業でも増えていきそう。
ポイントとしては、全社視点でものごとをかんがえ、お互いを理解しながら関係性を構築し、心理的安全性を確保しながら推進すること。
普段あまりかかわることのない部署同士で業務知識が広がることもメリットだと思います。

改善したいこと

• 他部署メンバーの巻き込みと役割、期待することの明確化を早い時期からしておく
• スケジュールに関しては、たとえば月末など、関係各所が忙しくなる時期もあらかじめ考慮しておく
• 要件定義が必要なフェーズではプロジェクトマネージャーは実装兼務せず要件定義に集中したほうがよい。使う脳みそが違うので効率が悪い

タスクフォースの解散とその後

課題解決と同時に解散となるタスクフォースは、そこで得られた知見を組織運営に生かしにくいというデメリットがあると冒頭で書きましたが、ありがたいことに今回はタスクフォースを引き継ぐ役割として「アフタータスクフォース」を発足したいと自ら名乗り出たエンジニアがいたため継続して組織運営に反映することができています。

おまけ

タイトなスケジュールでのやりきりが評価され、会社の2018年上半期でいちばんチャレンジしたプレイヤー(Most Challenging Player)として表彰されました。
このタスクフォースへのアサインが決まったときにたてた個人目標が「しっかりやりきって、また一緒に仕事をしたいと思ってもらえること」だったのでとても嬉しかったです。
まだまだ足りないところだらけですが、ゴールまで共にかけぬけてくれたみんなに感謝です。

参考: タスクフォースに関しては下記に詳しく記載されています。
タスクフォースとは？迅速な課題解決・編成アプローチ・重要ポイント3点

アドベントカレンダー、こちらもあわせてどうぞ
昨日：@ricky2020「新卒1年目エンジニアが採用活動やってみたらこうなった」
明日：@godgarden 「ランサーズに出戻って1年。担当した開発プロジェクトを振り返る。」