ITマネジメントを実行していくにあたっては、実行体制が必要です。
実行にあたって人が足りないから必要だということであっても、やたらめったら人を入れるだけでは、コミュニケーションが不十分となったり、意志が伝わりきらなかったりということで非効率さを生み出します。
よってチームという概念が必要となります。
チームと言うからには一人ではありません。もし一人であっても外注する部分があるのであれば、外注の人も入れてチームと考えればいいです。
チーム作りで解決できることとは
ただ集まった人たちではなく、チームということになることによって、個々のチームが役割を持って取り組むことになります。
責任範囲が明確になることで、チームの行動をパフォーマンスよくすることができます。
チームの中においても、チームリーダを中心として分担することで、協業化を促進することができ、マネジメントをうまくいかせることになります。
実行体制の形式化
中心となっているのはマネージャや部門責任者、あるいはプロジェクトマネージャということになります。
マネージャから見ると、多くのメンバがいたとしても、チームを一つの単位として捉えることができるため、分かり易くなります。
多くの人をバラバラに捉えると、見えるものも見えなくなることが出てきます。
事象を形式化して認識することと実行体制を形式化することとは、あまり変わりはありません。
チームという単位で捉えたときは、限られた数で捉えれば済みます。チーム内においても、人数は多すぎないようにすることで、限られた人数でマネジメント可能な人数となります。
一般的には４，５人がマネジメント範囲になります。
一般的にはそうですが、情報の流れが速い場合は、直轄チームなどでマネジメント範囲を狭めて意思決定を早くするということもあります。
チーム作りの7つの手順
チーム作りは手順があります。7つの手順を説明します。
全体をリードする人を決める
全体をリードするとは、全体を一番よく理解し、かつマネジメントできそうな人ということになります。
ITプロジェクトであれば、プロジェクトマネージャという位置づけになります。
全体ということになりますので、全体を既に把握しているか、もしくは把握する能力と時間がある人ということになります。
なかなかこのような人はいないかもしれませんが、この人はもちろん最も重要ですので、なんとかしたいです。
役割を塊に分ける
全体としてやるべきことの計画に従って、タスクを実行する役割をいくつかに分けます。
この時の塊がチームになります。
チームは、いくつかの役割があるかもしれませんが、あまりに違うことをするのはわかりにくいので、似たような役割にすべきです。
塊のリードを決める
役割の塊にはそれをリードする役割の人が必要となります。チームリーダとなります。
チームリーダは重要なポジションです。
というのは、チーム内とチーム間と全体リーダとの接点になるからです。
レイヤを行き来するのは、頭を使います。よってそれができる人でないと務まりません。
誰から何を依頼されているかを明確にする
いつくかの役割を持ったチームが、その役割を果たすために、明確にしておくことがあります。
それは誰から依頼を受けて実行することなのか、ということです。
そんなことは決めっていて、全体リーダから依頼を受けて、後は上意下達にて実行されるのであろう、と思われるかもしれません。
しかし実態はそのような単純なものだけではありません。
ITプロジェクトであれば、ITスタッフが全体リーダとなることがあるかもしれませんが、エンドユーザがチームにも入ってきます。
エンドユーザは要件を決める立場でもありますから、依頼し了承する関係が、チーム間にも発生するということです。
そのような関係も踏まえて、全体を承認するのが全体リードとなるので、単純でない関係を明確にしておかないと、後から了承していないからやり直してくれ、といった意見が出てきてしまうことになります。
役割に漏れがないかを確認する
チームを決めたとしても、全体としての役割に漏れが出る可能性があります。
ITシステムで言えば、機能A、機能B、システム基盤というチームにしたとして、さらに共通機能というものがあったとしたら誰が担当するでしょう。
漏れがないかは実行すべきタスクを実行する人がいなくなっていないかを確認します。
情報の流れに問題がなさそうか確認する
どこかのチームが共通機能のような漏れタスクを割り当てたときに、マネージャとリーダ間という単純なコミュニケーション以外にコミュニケーションが必要となるようなことがあります。
特に共通と言われているような役割は、各チームの役割との関係上、様々なやり取りが発生します。
情報の流れが錯綜してしまいそうな時には、予め別な指示系統にしておくのか等を決めておく必要があります。
その他、チーム分担上ある人があるチームに属していますが、その人はチームの役割に関わらず有用な知識やノウハウを持っていたとします。その際はチームを超えて活躍してもらうこともあり得ます。
情報の流れを円滑にするための役割を追加する
何人かが関わっているのであれば、個々の人がそれぞれ動いていて、結果全体が動く面はありますが、全体の方向性を指示する動きも少なくとも必要となるため、情報の流れというものは重要となります。
チームと言う形を作ってきれいに情報が流れればいいですが、例えばあるリーダの情報が大きくなりすぎて、うまく流れそうにないとか、マネージャが顔を出す会議が多くて、補佐が必要などの現象が出てきます。
その際には、情報の流れを円滑にするにするための役割を追加することも検討したほうがいいでしょう。
上下関係の情報伝達やチーム間の情報伝達の間に入って、情報収集と情報発信を行えるような人がいると、円滑さが変わってくることがあります。
PMOとは
情報伝達の円滑化のために、プとジェクトにおいてはPMOが入る可能性があります。
PMOは、プロジェクトマネジメントオフィスもしくはプログラムマネジメントオフィスが正式な名称です。
プログラムはプロジェクトを複数マネジメントする必要があるときに用いられます。
オフィスと言う名前がついていますので、プロジェクトを傍から見て支援をする組織のようなイメージです。
実際のPMO
近年PMOは需要がかなり増えています。企業では不確実な未来に向けてプロジェクトを立ち上げるケースが増えていますし、自社内のメンバだけではプロジェクトを進めるのはパワー不足のことが多いからです。
PMOは自社内に組織として用意されるものだけでなく、実際は外部より調達するケースが増えています。
PMO案件として、人材が募集されているケースも多いです。
PMOがどのように配置されるか？
PMOはプロジェクトに配置されることもありますし、組織に入り込む場合もあります。
プロジェクトを指揮するような立場で外部から入ってくるケースもありますし、逆にプロジェクトマネジメントの補佐として付帯作業のみを実施するケースもあります。
その言葉を超えて、組織の支援に入り込むと思っていいと思います。
結果的に情報の流れの円滑化のために、PMOという役割をチーム内やチーム間、マネージャ配下など様々に配置することは考えられます。
チーム作りにおいてありがちな問題
チームを組んだとして、見た目はきれいな形になっていたとします。
ところが、実際実行してみるとまったく思ったようにいかないことが多々あります。ではどのような問題がありがちなのでしょうか。
リーダとなる人が足りない
チームを組むということはチームリーダの存在が不可欠です。
チームリーダは、チームのやるべき仕事を把握し、自分を含めて仕事の割り振りを行い、実行状況を把握します。そして上位リーダに報告などコミュニケーションをとる必要があります。またときに他チームリーダとの折衝を行うこともあります。
そのような要の存在であるリーダをチームの数だけ必要ということになりますが、組織には常にリーダとなり得る人はいますでしょうか。
リーダの資質がある人はいるかもしれませんが、数が必要となりますので、全員が適任になっていることのほうがむしろ少ないのではないでしょうか。
リードになりたがらない
リーダはリードする存在となります。リードするとは他の人の仕事も含めて引っ張っていくことになります。
組織や場合によって異なるとは思いますが、リードする責任があるということは、他人の仕事にも責任を持つということになります。
リーダ手当を出している経営者はいますでしょうか。
大抵の場合、管理職でなければ明示的な手当てはないのではないでしょうか。であるにもかかわらず、リード役を行わせるということは、責任だけ重くつくことになります。
やりがいや成長などと言って押し付けることはあるとは思いますし、実際リーダ経験を経て幹部候補になるということはあるでしょう。
しかし、昨今昇給よりも自分の部分だけを責任を持って仕事したい人が増えています。
役割を振っても、実際はリードとして実行しない人もいます。
ITマネジメントはそのようなメンバも含めて全体をコーディネートしていかないといけないといことです。
チームの役割と人の保有スキルが合わない
チームは何らかの役割で分担を決めます。チームという塊を作るとある種の分断が生じます。
チーム内で実行すべき役割がきれいに分けることができればいいのですが、実際は構成するメンバのスキルがチームを跨いでいたり、人数の関係でスキルに無関係のチームに入らざるを得なかったりということはあります。
チームを組成して意思疎通や情報伝達の向上を図るというのは必要ですが、保有スキルと言うのは、実務上は、特に問題解決のために有効なものです。
チームを組んだからと言って、頑なに壁を作るだけでなく、柔軟に情報流通していくことも重要となります。
外注の人とスキルがアンバランスとなる
特にITのプロジェクトにおいては、外注を入れるケースが多いと思います。
外注とともにチームを組むことになります。
チームを組んだ時に、チームリーダは自分のメンバとなります。チームごとに外注のメンバが存在することになります。
立場上、外注の人はリーダにならないようにすることはよくあると思いますが、実務上はスキルが逆転してしまうことがあります。
スキルが高いほうが気を使ってくれるケースはあると思いますが、気を使ってくれないこともあります。
その場合は、リーダができないのをわかっていながら、責任を押し付けるという態度が発生します。
他のプロジェクトマネージャもやらないといけない
ITプロジェクトの場合は、プロジェクトマネージャを中心としてチームリーダが取り巻く体制となります。
一見きれいにチーム体制が組めているように見えます。
ところが、プロジェクトマネージャは別の仕事もしていて、他のチーム体制にも名前が載っているということがあります。
チームリーダでも同じことはあります。
つまり、日常の仕事や他のプロジェクトを実行中でも、スキルを持っている人は少ないため、複数プロジェクトが起こってしまった時は、兼任で実行せざるを得ないケースが起きるということです。
チーム作りとチームワークの推進において本当にすべきこと
チームは人で成り立っていますので、一見きれいなチーム表に見えたとしても、人の問題が見え隠れします。
プロジェクト単体ではチームとしてうまく組まれているように見えても、実際は他の仕事を行っていたり、チーム内の現保有スキルがアンマッチであったりすることもあります。
チーム作りの7つの手順を経て、最後には情報の流れを考慮した仕組みを入れることとしました。
最終的に実行の段階で検証すべきことがあります。
それは、協業化を促進できるようになっているかです。
マネージャおよびリーダがスキルも人格的にもすばらしい人であれば、大きな問題はないかもしれません。しかし、実際には完璧なチーム体制などかなり困難と思っていたほうがいいです。
そうではあっても、全体を円滑に動かすための協業化促進の仕組みがあれば、チームの歪みを補うことができるでしょう。
先に例を出した直轄チームやPMOの役割を随所に入れることは一つ有効な手段です。
ただし、直轄チームも実行できる人がいないと成り立ちません。
またPMOは知識を持っているとは限りません。コトを進めるためのマネジメントには役立つでしょうが、本質的な問題解決を期待するものではありません。
本質的な問題解決には、内部に蓄えられた知識やスキルが必要です。その組織ならではの知識が必要となります。
そのための知識を持ったスキル保有者は、どこにいるでしょうか。
チームの中に散在しているかもしれません。
それらの知識や知恵を引き出すために、アドバイザーのような位置づけを設けたり、臨時チームや集中討議会議などの仕掛けを設けたりといった体制づくりも検討しましょう。
最終的にはITマネジメントは知恵のマネジメントになります。
コメント