阿吽の呼吸を信じるな！ 業務の引継ぎとデリゲーションポーカー【途中参入したプロジェクト】
阿吽の呼吸は信じるな
人工衛星プロジェクトに限らず、経験して思ったことは、阿吽の呼吸なんて信じてはいけない。
絶対取りこぼす。
タスクというか仕事が突然降ってくることはないでしょうか。
これがシステムから機械システムへ、さらにはサブシステムへと流れていくことになるかと思います。
この時、各担当はその領域内で動くことが求められており、その領域を明確にしておく必要があります。
しかし、途中で発生した事象や、境界が不明瞭な部分を頼まれるかと思います。
頑張って、少し多めに検討するのもありですが、いつもそんな余裕があるとは限りません。
自分の領域を守りつつ、どこまで対応するのか明確にしておく必要があります。
もちろん、強力なリーダシップを発揮する人がいれば、領域の明確化といった考え方は必要ないかもしれません。
しかし、すべてのプロジェクトにおいて、組織のリソースもあるため、強力なリーダーシップを発揮する人が配置されるわけではないのです。
領域の明確化を行う手段、デリゲーションポーカーを使用した、システム、機械システム、電気システム、ソフト(制御)システムなどの領域を確認してみましょう。
上司や管理職を私の視点として、カードを出し合い、領域を仕分けてみましょう。
カードとしては次の7つがあります。
レベル1. 命令する : 私が彼らに決定を伝える
レベル2. 説得する : 私が彼らに売り込む
レベル3. 相談する : 彼らに相談し私が決める
レベル4. 同意する : 私が彼らと合意して決める
レベル5. 助言する : 私は助言するが彼らが決める
レベル6. 尋ねる : 彼らが決めた後で私が尋ねる
レベル7. 委任する : 私は彼らに完全に委ねる
このゲームで分かることは、上司の人がどのようにプロジェクトあるいはチームになりたいかを明示することあります。
具体的でなく、曖昧で、皆でやってもらいたいなどと、皆に権限を与えているように見えて、なかなかチーム側に決めさせてくれない場合は、お互いの持つべき権限の認識が違うから発生していまうのです。
リーダーの人がみんなに知られずに、細かい調整をしていたとしましょう。
そのプロジェクトは問題ないかもしれませんが、後続に立ち上がるプロジェクトはどうでしょうか。
細かい調整を知らずにリーダーを任せられるため、多くの失敗を起こしてしまい、結局は、前のリーダーが出てくることになるのです。
全くをもって、後継者を育てるのが下手だとしか言えないのです。
そのような組織では、変わった人が入らない限り、技術の継承がなく途切れてしまうことでしょう。
自分の役割をすべてさらけ出しつつ、権限を移行していく。
その中でリーダーは、向かっていくべきチーム像を作り上げていってもいいのではないでしょうか。
進まない課題と進まないプロジェクト
機械システム設計の傍ら、各サブシステムと調整した時によく発生したのが、それは別のサブシステムから情報がないと進まらないといったことでした。
あるサブシステムは、情報の優先度が分からないため、他を優先して保留としている。その調整情報は、別のサブシステムが決めるものだと思っていた。といった反応が返ってきました。
お互いの優先度と、領域が不鮮明であるがゆえに発生した事象です。
作業がひっ迫していなければ、各サブシステムで余力のある人やできる人が、不鮮明な領域をコツコツ実施することもあるかもしれません。
あるいは、ほとんど何も知らない人が、騒ぎ立てることで、今考えなければいけないことが明確となり、効率的ではありませんが進めることはできるかもしれません。
大きなプロジェクトで、その権限の領域が一見明確であったとしても、各人の認識の違いで課題が取り残されてしまうことはあるのです。
いくつか一例を示しましょう。
- システムハーネス
そもそも、システムハーネスとは、人工衛星に搭載するすべてコンポーネントを接続していくケーブルのことです。
人工衛星の質量でも1割～3割を占める重量物でもあります。
システムハーネスをメインで実施するのは、計装系あるいは機械系が担当することが多いです。
ただし、ハーネスのサイズ(径)は、流れる電力や通信信号、一部はシールド線の使用などが関係するため、電力系や制御系の協力が必要です。
基礎情報がないために機械系が動かないと考えるか、ハーネスをルーティングする空間がどれほど余っているから分からない。電力系としては、なるべく太いハーネスにしたいために、情報を待っているといったことが発生しかねません。
さらに機械系としては、ノイズの発生を抑えるルーティングの判断がつかないため、電力系や制御系の情報を待っていたりします。
- 機器の配置
機器の配置については構造系が受け持つことが多いのですが、姿勢系との兼ね合いもあります。
お互いに譲り合い、無難な配置になることもあります。無難だとリスクが小さく良い面もありますが、設計の進捗に合わせた設計変更に適応しにくいというのもあります。
- 人工衛星側の送信データのフォーマット
人工衛星のデータは、工夫して送られます。
周回衛星の場合、取得できる時間が限られているため、繰り返し同じデータを送信したり、人工衛星の周波数を地上局側でキャッチしたことを確認してから送信するといった方式がとられます。
ミッションデータとなる画像データを送信する際に、無圧縮状態で送信するか、圧縮した状態で送信するか検討することになります。
システムとして、目的をもって選択することもありますが、汎用性の高い人工衛星とする場合、どちらをベースにして送信するかということを決めなければいけません。
どちらでもできるはいいのですが、ユーザーインターフェースを考えてどちらがいいのか決める必要があります。
システムとしては無圧縮方式を進めていたが、制御系としては圧縮方式で検討を進めており、最後のシステム試験や軌道上で明らかになるなんてこともあり得るのです。
権限移譲により、相談するきっかけを作るのもありなのです。
相手にやってほしいことも作業リストに上げることが大事
権限移譲を行うには、自分の担当範囲がどこまであるのか把握している必要があるとともに、相手にはこの部分を担当してもらいたいという項目も上げておく必要があります。
だれも上げなかった項目は、だれもやらずに取り残されるのです。
実施する項目を分類し、整理していく行為をWork Breakdown Structure(WBS)と呼び、作業分割構成と日本語にて略されます。
なぜ、権限委譲ポーカーにおいて、最後にWBSを例にしたのかというと、それはWBSを作成する一般的な目的にあります。
1つ目は、プロジェクト全体をを正確かつ具体的に整理することができるからです。
整理することで、成果物や目的を具体的に、現実味のあるものを明示させてくれるからです。
2つ目は、責任の割り当て、リソースの割り当て、プロジェクトの監視、およびプロジェクトをコントロールを行うためです。
成果物や目的を達成するために、何が必要が把握することができ、コストやリスク、実作業レベルからプロジェクト全体の作業レベルを明確化させてくれます。
3つ目は、すべての成果物の詳細と担当者を再確認し、欠落または重複がないことを明らかにするためです
WORK BREAKDOWN STRUCTURE (WBS) PURPOSE, PROCESS AND PITFALLS
作業の権限委譲とともに、プロジェクトの計画を見直し、各担当が明確な成果物を把握しながら進めていった方が、よりモチベーションを高めつつ、作業をこなせるのではないでしょうか。
小さな目標だけでは、自分が何の役に立っているか分からず、モチベーションは下がってしまうでしょう。
新規に担当になった人も、最終的な成果物や目的を見失わず、継続して作業を進められるのではないでしょうか。
引継ぎや新たに作業を依頼する場合、全体像から話した方がよりよいかと思います。
もし全体像を話せなければ、依頼される側も不安が残ったままになってしまうのです。そういった環境に慣れてしまうと、モチベーションが下がるだけの組織になってしまうかもしれません。
まあ、人によりけりかもしれませんが。
