チームビルディングと情シス

チームビルディングにあたり

　チームビルディングに必要な要素ってなんでしょうか？私自身は、大なり小なり新しいことをやるときには、下記の手順でやっています。

１）プロジェクトの目的をまとめる
２）システム化の絵を描く
３）プロジェクトメンバー（体制）を決める
４）システム化方針の合意をとる
５）コミュニケーションルールを決める
６）大工程を立てる
７）キックオフをやる
８）WBSを作る

ある程度書類のフォーマットや手順などはテンプレ化されていますが、自分自身が一番気を付けるのは２）３）４）６）です。

システム化の絵を描く

　事業部門やスタッフ部門から「こんなことをしたいんだけど？」という相談が来た時に、これをやります。何を使ってシステム化するか、ということですね。この要素とこの要素は既存のこの仕組みを使って、この部分はまったく新しいものだから作らなきゃとか、そういった整理をやります。複数のシステムが関連するものだとごちゃごちゃ手書きで絵をかいて後からまとめます。

　ここで大事なのは、システム化の手法とシステム化する範囲をシステム主導でふるいにかけ、整理してある程度整理しきってしまうことです。要件の中には「これはシステム化するのは非効率だってわかっているけど自分の大変さを分かってほしくて混ぜた」みたいなよくわからない案件が混ざっています。ええ、一定規模の案件なら大体まざってますので、こんな「私の不満を聞いて」みたいなやつは全部ふるいにかけてしまいます。

体制を決める

　プロジェクト体制を決めるときには、「意思決定をする人」「リーディングをする人」「機能ごとのオーナーとなる人」の３つで整理しています。機能ごとのオーナーの人が全部を統括しているような顔でいろいろ話していた内容が、そもそもの意思決定をする人の意志と完全にずれていたり、リーディングする人がうまく機能せず、機能横断の件の調整がしづらくなったり、あるあるです。

システム化方針の合意をとる

　体制を決めたら、上に書いたシステム化の手法や範囲について、先にリーダーとすりあわせてオーナーと合意をとってしまいます。こういった部分はある程度トップダウンでやるべきで、機能ごとのオーナーには「決まっている」こととして実務レベルの話を詰めていった方がお互いにとって幸せだからです。下手に、こういったところを現場の意思決定に任せるとプロジェクトが迷走します。

　なおこの時点で、意思決定のプロセスについても事前合意をとってしまいます。「検討はリーダーに任せる、決まったら持ってきて」っていうオーナーが全体をひっくり返すのもあるあるですからね。。。

大工程を立てる

　以前の私は、プロジェクトのキックオフ前に綿密なWBSを立てていましたが、今はこれはやらないようにしています。弊社の場合、現場に任せる風土が強いので、このやり方だと「こんな勝手に決めて！」みたいになってうまくいかないからです。まずはみんなが進め方のイメージがつかめるように、大工程だけきっちり決めこんでおくようにしておきます。

　大工程を立てるときには、これくらいしか書きません（大規模なものならもっと書きますが）

・初回キックオフ
・要件の確定日
・見積受領日
・社内承認を受ける日
・テスト開始日
・リリース日

結構大事なのは社内承認を受けるタイミングですね。これに間に合わないとGOできないですからね。逆に開発スケジュールについては、内製でもアウトソーシングでも、見積が決まったところでもっと詳細なものを開発側で作成しますから、ここでは決め込みません。もちろん、無理のないスケジュールでひいてはおきますけど（その見計らいもPMの腕の見せどころ）。

「関係者全員集まれ！」は、大体何も決まらない

　以前、とあるリーダーが、とあるリニューアルプロジェクトで、上記をなにもしていない状態で「関係者全員集まれ」ってやってしまったことがありました。で、当日いきなり私に「来てね！」と振られて、本人はドタキャン。20人くらいいる会議室で「〇〇はどうなるんですか？」「この仕事はどうなるんだよ！答えろよオラア！」（本当にこう言われた）といったやり取りが繰り広げられ、10分ストップして方針をユーザ・ベンダー側のリーダーと急遽すりあわせる羽目になったことがあります。やめてほしいです。こういうの。