マネージャは落ち葉拾いというリスクマネジメントしながら自分の仕事をしなければ失格です
初めて部下がいる管理職（わざわざ部下がいると書いたのは部下なしの管理職もいるから）になったとき、事務担当の方に何すればいいのって聞いてみたら
「決まっていません」
と返ってきて何してもいいんだと好意的に解釈したのはもうずっと前のことだなぁ。
これ、部活での役割を下敷きに女マネをどうしてマネージャと呼ぶんだと問題提起しているわけで。で、ここで登場人物を整理すると、
- 監督
- 顧問
- 選手
- マネージャ
4つの役割になるかと思います。それでじゃあその役割にアサイメントされる人が何を分掌しているかって話です。
- 監督・・・活動の指導
- 顧問・・・活動の責任者
- 選手・・・プレーヤー
- マネージャ・・・身の回りの世話
分掌から言えばマネジメントをするのは顧問の先生ですよねぇ。女子に限らないけれど女マネはお世話係ですよね。プレーヤーから身の回りの世話に掛ける時間を減らしてプレーヤーの活動に時間というリソースを最大限確保できるように、と。
役割の名称と分掌が捻れてしまっているのでおかしいのですけれど。
分掌の大切さ
分掌の意味を辞書で確かめましょう。辞書を引こう。「仕事を手分けして受け持つ」とありますのでSOWと理解していいですね。
役割を分けるのは全体としての仕事の活動として期待する結果の一部分に責任を負うということです。
なので、役割に紐付ける分掌の定義はとても大事です。役割の名称、名前付けも可能な限り役割が負う分掌を表す名称をつけたいところです。
分掌の曖昧さがトラブルを引き起こす
プロジェクトの規模が大きくなればなるほど、分掌の定義がされていなかったり、曖昧さがあるとプロジェクトが進行してから分掌した役割同士でトラブルが生じます。
例えば、アプリケーション開発のフレームワークに責任を負うのはアプリチームが担うのか、インフラチームが担うのか。ミドルウェアまではインフラチームが担うのはわかります。
DBはDBのインスタンスを用意するまでで、テーブル定義以降はアプリチームと分掌するバウンダリーをスパッと線を引っ張って置けばあとはその分担の上でどう助け合うかどうかになるのですが、アプリは面倒だからフレームワークのところはやりたくないとか、インフラとしてはアプリが使うのでなんでインフラがやらねければ習いあのだとか子供の喧嘩レベルで揉めるんですよねぇ。
これはプロジェクトチーム内でも分掌をはっきりしておかないと揉めますが横並びのプロジェクトやベンダ間でも同じようにはっきりしておかない場合は揉めます。
機能であればシステム間インタフェースで切るわけで、同じように責任分界点もインタフェースで切れば回避はできるのですけれど。
それでも雑用係は（本来の）マネージャの仕事なのは
そうして分掌を役割、チームで分担すればうまくいくかと言えば、生き物のプロジェクトでは計画が進捗し始めると様々な仕事が増えていくのです。
分掌、SOWをインタフェースで分界していればほとんどは誰かの役割に落ち着きます。ただ、分掌で決められた役割の人が気づいて拾えば、です。そう、気づかなければ誰かが落ち葉拾いをしなければならないのです。
プロジェクトでの落ち葉は課題や課題から問題に昇格したリスクです。放置しけ置けば全部プロジェクトマネージャにブーメランとなって戻ってくるのです。
部活の女マネの分掌は、顧問の先生から指示されるプレーヤーが成果に結びつく優先順の高い活動に専念するために手の回らない仕事を定義して割り当てるのが適切だと思います。その方が、雑用ではなくての回らない仕事の専門家として目標設定できるので。
そして、マネジメントは顧問先生が采配するのが役割のバランスから言っても適当なのでしょうが本業の教員の職務の多忙さがマネジメントとして不作為を生じさせ、自然と監督にマネージャとしての顧問の仕事を片寄しているのだろうと思うのです。
仕事であれば、分掌としての責任を果たさせることが必要です。それをさせるのもマネージャの仕事です。結局、雑用という便利な言葉がマネージャのお仕事になるわけです。
問題なのは、マネージャ自身が自分で仕事を考えないことです。何をすればマネージャの仕事として責任を果たすことができるのかということを。それをせずにメンバがやりたがらない事務処理や業務の催促や締め付けばかりやっていてはそれこそマネージャの仕事をしていないので。
