史上最大の台風の日の成果（途上）
史上最大の台風がきているのに、日がな一日PCを前にしてやっていたのは本社部門向け講座設計である。
これで得られるものがあればそれはそれで良いのだが、実態はこれからスライドとワーク（ゲーム）を作らないと仕方がない。
実現できるかわからない計画を死守するためにPDCAを頑張るのは何か間違っている
ちょうど、とあるプロジェクトをやっている。全体で見れば年末くらいで一段落つけたいので、そこそこの半年以上のレンジである。
プロジェクトは全社に導入してた業務をある意味リニューアルするもので、仕組みづくりのし直しといった方がイメージはあっているかもしれない。
これはメジャーなマイルストーンを完了させるタイミングで協力をしてくれた関係者に述べるものなのだろうが、なんとなく先にここで書き残しておく方が良いのではないかと思い立ったのでそうする。
あれだ、フラグを自分で立てるようなものだ。
一番関心をしたのは、協力を依頼した全ての方々がとても好意的にいやむしろ積極的に対応してくれたことに関心している。
持ち戻ってどう思っているかはわからないし、依頼していること自体はやらなければならないことは頭でわかっているが、とても手間で面倒な上に業務に差し込む形になるので負担を求める。
であるから、仕事を頼む方としては変にへり下りそうになってしまう。
『忙しいところにこんなことをお願いしてすみません』的な心持ちな変なダークサイドに落ちてしまいそうになる。
そうならないように、依頼することをやり遂げる価値、意味を説明し、メリットをアピールしつつ、対面ではリニューアルした業務の利点、ポイント、理解、価値を単位ごとの組織にインストールしていく。
今思えばこれは教育のキャンペーンだったなと気づく。
このキャンペーンでの説明では何回もしくじり、試行錯誤したことがある。
それは、説明の仕方、である。
実際、50回くらい場を設けて行ったがイメージした通りに進められたは10回程度しかないし、全体の進行としても上手くできたと感じられたのは数回もない。
一見、上手く説明したと思えても、それは参加者のフォローによるところが大きい。
ここまでやってきて、一つの気づきは、PDCAはダメだなということだ。
Pが大きすぎる。
いや、硬直化するのである。
それを死守しようとして過大な負担になる。
それはおかしい。
やりたいことはGOALの達成であり、Pを維持することではない。
実際、このプロジェクトでのGOALは変わっていない。
でも中でのメインアクティビティのアプローチは試行錯誤している。
なぜか。
GOALを達成したいからである。
ではどうやって。
今思えば、OODAループを使っていたのである。
観察→情勢判断→仮説→検証
のループを回していた。
50回。
たかだか教育で、である。
でも、GOALに立ち向かいうならOODAである。
虚構の実現できるかわからない計画というPを死守するためにPDCAを頑張るのは違う。
アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)
- 作者: マイケルアブラショフ,Michael Abrashoff,吉越浩一郎
- 出版社/メーカー: 三笠書房
- 発売日: 2015/05/22
- メディア: 文庫
- この商品を含むブログ (1件) を見る
エンジニアを縛る計画思考
シンポジウムやカンファレンスでワークショップをコマとして設けていることがある。定員制で、グループワークが多い。見聞きしない、でも講演のアブストラクトのキーワードに興味を惹かれて受講する。
ワークショップに参加した。初めて会うエンジニアと顔見知りになれたし、ワークは初めてで理解には及ばないが体験としては楽しい時間だった。ワークショップでこれなら仕事で活かせそうだ、と思ったやり方があった。このワークショップはまずまずだな。
そう思うこともあるだろうし、講師の立場の場合はそう感じてくれるだけでも嬉しい。
ところが、そうした気持ちは最短で会場の扉の外に出た瞬間、忘れてしまう。その気持ちが消えず、現場、チームに持ち帰りやってみたいと思うこともある。それでも、チームのメンバの顔を見るとその気持ちが消えてしまったり、諦めようと思う。
中にはその気持ちを自分に向けて、自分の仕事のやり方を変えてみようとするエンジニアもいる。
でも、多くのエンジニアは何かを得て、使ってみようと思っても実際に使おうとしたとき、使えないと感じてやめてしまう。
使おうと思ったときの対象に対して、仕事に対するアプローチとか手法とかマインドとかそういったもので何かを変えようとする。
その対象は得てして、漠としているか粒度は大きい。
- 生産性をあげる
- 見積もりの可視化
- 納期を守る
- ：
やり遂げられたら素晴らしいことは確かである。ToBeとしても相応しい。
でも、この素晴らしいToBeは実行されない。
いや、できない。
なぜなら、実際に行動に移すとき、粒度が大きすぎるからだ。
『生産性をあげる』ことをやろうと思ったとする。
さて、仕事場で『生産性をあげる』と思い、ワークショップでうろ覚えの記憶を掘り起こし、『生産性をあげる』と思ったとき、手が止まる。
ToBeはToBeのままでは手をつけられない。ToDoへ分解しなければいけない。これが実行されない理由の1つ。
『生産性をあげる』としたままでプランを作ったとする。かなりチャレンジングである。
こうすればできる、
- なぜならチームはこうだから
- プロジェクトはこんな状態だから
- 自分の仕事はここが課題だから
と一人合点してプランを作る。
でも上手くいかない。なぜなら、合点したつもりの前提とした制約条件も前提条件も全ての状況は刻々と移り変わっているからである。
大きな粒度のプランと想定した状況が変わっていることを気づかない。
だから上手くいかない。
こればプランを作ろうとしたときと実際作ったときの変化を考慮していないことと変化に対応できる粒度にしていないことが原因なのである。
山善 防災リュック 30点 セット 幅32×奥行16×高さ43cm 一次避難用 給水バッグ 携帯用トイレ 大容量 レッド YBG-30R
- 出版社/メーカー: 山善(YAMAZEN)
- メディア: ホーム&キッチン
- この商品を含むブログを見る
![[Amazon限定ブランド] #like アサヒ おいしい水 天然水 ラベルレスボトル 2L×9本](https://images-fe.ssl-images-amazon.com/images/I/51EDzo1AW2L._SL160_.jpg "[Amazon限定ブランド] #like アサヒ おいしい水 天然水 ラベルレスボトル 2L×9本")
[Amazon限定ブランド] #like アサヒ おいしい水 天然水 ラベルレスボトル 2L×9本
- 出版社/メーカー: アサヒ飲料
- 発売日: 2019/06/11
- メディア: 食品&飲料
- この商品を含むブログを見る
いわれのない仕事を押し付けられたときに整理する方法
お仕事をしていると、いろいろとあるわけです。自分の担当で終わらせないといけないお仕事や他の方が担当されているお仕事。
組織で働いているので自己完結するお仕事の方が少ない。
団体で働くということは、誰かからのオーダーがあり、何かをインプットとして、加工して、アウトプットし、オーダーをした人に届けるか、次の人に回す。
ときどき、ご自分の都合でこちら（あなた）に接触する方がいらっしゃる。
その理由は、ご自分のお仕事に何かしら関連して、こちら（あなた）に期待をするところがある。
ただ、その期待の現れは、相談か押し付けのように極端に現れることが多い。
それとその期待は、こちら（あなた）は知っている事情のこともあるし、全く寝耳に水だったり、前任者が放置していたことだったり、引き継いでいないことだったりする。
それっぽく四象限にするとこんな感じ。
↑ 知らない事情
押し付け
← ＋ →
相談
↓ 知っている事情
ご察しのとおり右上は相当面倒臭い。
相手もなぜか強気でコンタクトしてくる、大体。
そういったとき、手をつける前に自分の上司を巻き込んだ方がいい。できれば1on1のようなオープンで相談者が自分だけで上司を占有できるときが望ましい。
↑ 知らない事情
押し付け 上司と依頼してきた人の上司を巻き込む
← ＋ →
相談
↓ 知っている事情
なぜなら、カジュアル（無防備に）聞いてもらえるのと、一対一なのでこちらの話に集中してもらえる。
そのあと、必ず依頼してきた人の上司を交えて依頼の意図を確認する場を持つ。
多分に、依頼してきた人も誰かからオーダーがあってのこと。
その場で、目的を整理するとほぼオーダー内容が変わったりする。
知らない事情もわかったりする。
これがチーム内だったりしても、押し付けてくるのがリーダでなければ上司をプロマネなどのリーダに置き換えればいい。
ozendateできないエンジニアは仕事ができない
ozendate＝お膳立て。
エンジニアにカリスマ性か他に類を見ない魅力を持ち合わせていない限り、ozendateのできないエンジニアは仕事ができない。
その素性がバレるまではブツブツと周りが文句を言いながらもやってくれる（ブツブツ言っている周囲のエンジニアの仕事だと思って）。
でも、どこかでブチ切られるか、あっさりと切られる。
それはあなたの仕事です、と。
まるで外で仕事をしているからと屁理屈をつけ、家庭を一切顧みずに定年を迎えたタイイングで離婚を迫られるか、定年後は自分のことは自分でと家庭内離婚を申し渡されるようなものだ。
前準備をしないと言うのは、これから行う仕事に寄生しているだけに過ぎない。
マネージャなら部下にozendateをさせるだろうと思うかもしれないが、そのozemdateをさせる前に、仕事そのものをozendateしている。
実現したいことがあるなら、それを現実化するために頭の中から出さなければならない。
結果、何かしらozendateする。
ところでozendateの上手いエンジニアもそこそこいるのに、一担当のままでいるケースがちらほらある。
これはozendateのスキルをいいように使われているのである。
そのozendateのスキルは、（リーダーシップとして見えるように）上手に使った方が良い。
自分がozendateをしたのに実績を別な人に持って行かれたと思ったら、実際、持って行かれているのだろう。
であれば、自分がozendateをやったと見えるようにしなければならない。
例えば、
- キックオフを仕切る
- 体制図のトップに名前を入れる
- 先々の進む方向を示す
- 問題解決の前に立つ
どうせ全部ozendateの中でやっていることである。
それを視認できるようにする。
前述した項目は、ozendateのできないエンジニアを関わらせないか、ozendateできるエンジニアの指示のもとでやらせる。
現実にはozendatetどころか、ozenに何を載せればいいかもわからないエンジニアもいるのであるが。
パナソニック 炊飯器 5.5合 圧力IH式 Wおどり炊き ルージュブラック SR-SPX107-RK
- 出版社/メーカー: パナソニック(Panasonic)
- 発売日: 2017/06/01
- メディア: ホーム&キッチン
- この商品を含むブログを見る
エンジニアをマネジメントしてはいけない
自分が一兵卒のエンジニアのとき、自分に対してあれこれと言われていたような気がする。
『キミはこうだからできない』とか。アレは自分のキャリアや目標の達成に何一つ役に立たなかった。
1人、自分のキャリアについてマネージャから『キミには選択肢がある。（マネージャとして仕事振りを見ていると）こっちが合いそうだけどどう思う』と自分ではなく、自分のキャリアについて関心を持っていてくれて、先を示してくれた。
もう1人は、自分が選んだ先が実現できるようにマネージャとしてのコネクションを使って実現できる可能性の高い選択肢を調べ、示してくれたマネージャがいた。
どちらのマネージャも自分の『こと』について関心を持ち、考えたり、コネクションを探すなど動いてくれていた。
自分がプロマネのとき、御多分に漏れず進捗はWBSを担当するエンジニアとWBSの難易度で遅れることがある。
遅れるとき、エンジニアと話すのは遅れている『WBS』であり、気にかけているのは『WBS』がいつなら完了の状態になるか、だ。
プロマネとして関心のあることは、
- 計画したとおりに終わるのか
- 終わらない進捗を邪魔する障害は何か
- それはどうやったら解消するか
- それを踏まえて見通しはどうなるか
であるから『WBS』に対してどうこうしようとする。エンジニアと向き合うのではなく、WBSを挟んでエンジニアとどう片付けるかを向き合う。
コントロール、マネジメントするのは『WBS』でありマネージャではない。
マネージャのときは、エンジニアのMBOやOKRに対して向き合う。
エンジニアのMBOやOKRに向き合うとき、
- エンジニアの実現したいキャリアは何か
- それを構成するコンピテンシは何か
- 具体的なObjectsは何か
を時間を相応に掛けて話をする。
フィードバックでも、
- Objectsの進捗はどうか
- 想定と違うことはあったか
- 障害になっている原因は掴めているか
- 障害の除去を手伝う必要はあるか
のようにObjectsを中心に起きエンジニアと向き合う。
冒頭の自分のケースでダメなほとんどのマネージャは、エンジニアに関心を持たず、コンタクトするときにだけ、エンジニア自身に対してあれこれという。
つまりこのようなダメなコンタクトするようなマネージャは、エンジニアを知ろうとしないのだ。
エンジニアのパフォーマンスの結果がマネージャとして担当する事業の成果となるにも関わらず。
エンジニアというリソース全体の2割だけに関心を持ち、その他のエンジニアは関心を割くこともないのだ。
その結果は、関心を持たないエンジニアをマネージャの意のままに動かすようにマネジメントしようとしていたのである。
でも、自分に関心を持っていないマネージャの言うことなんて耳に入るわけがない。
それは発する言葉全てがマネージャの都合でしかない。
マネージャは、
- エンジニアに関心を持ち
- エンジニアの実現したいことを聞き出し
- 示唆し
- 実現するように環境を少し整える
ことをするだけで、エンジニアの成果に繋がる。そうしたことが回り回って担当事業の成果に結びつく。
マネジメントする対象を間違えてはいけない。
チームのパフォーマンスの最大化を考える
社員に計測機器をつけて業務を行い、実証実験することのサムネイル、記事によってデストピアだと評されている。実証実験は緑のある開放的な空間のもたらす効果と称しているが、これは従業員のパフォーマンスの最大化を狙っているのであることは誰でも察しが付く。
マネージャがチームのパフォーマンスを最大にしたいと考えるとき、どのようなアクションをすれば良いのかを考える。
成果をトレースする
観察をシンプルに、つまり最小限の振る舞いで捉えるなら、成果を観察する。
設定した期日に、計画した成果ができていることを確認する。
計画した期日に確実に出来上がるかを知りたければ、ものができるタイミングを計測するために、観察する間隔を短くする。
成果をトレースすることは、マネージャはチームに対して何も貢献しない。
チームが貢献するパフォーマンスに貢献しないばかりか、観察する行為がチームに割り込むためにその分のリソースを使うことになる。
→ チームが計画した期日に成果をだすため
- パフォーマンスを削いでいることになりかねない。
- チームの成果を得るためのリソースを削ぐ。
- パフォーマンスはメンバの慣習、実践知に依存するためパフォーマンスは最大化されない。
製造する手段で性能が違う場合
成果を製造する手段がメンバで違う場合、前述の手法は使えない。
なぜなら、いくら作業を分解し、製造しようとしてもそれを加工し生み出す装置が違うため。
一輪車で運ぶ場合の手段は一輪車であり、運ぶ人もまた手段である。
運ぶ人の能力が違っても、運ぶ能力の差異である。
製造する手段が違う＝装置が違う場合、ばらつきが出る。
マネージャは、チームのメンバそれぞれの製造の能力を知る（計測）する必要がある。
マネージャは個々の能力を把握することで理論値のパフォーマンスを知る必要がある。
メンバの能力を計測する
個々のメンバのそれぞれの能力を計測（評価）する。
能力の高低をレーティングする。
ある工程の仕事をしたときの平均値に近いメンバをチームの標準値とする。
→ この標準値を基準とすると標準値より低いメンバは習熟度をあげる対策となり、
- パフォーマンスの観点でイノベーションは起きない。
- 標準値より高いメンバはさらに引き上げる理由がないためパフォーマンスは悪化する方向に流れる。
- メンバの能力を計測することは現状を把握する目的で利用する価値はあるが、能力の差をメンバが知ることで、副作用もある。
1人のメンバのパフォーマンス
1人のメンバのパフォーマンスは、製造する工程、装置だけに影響を受けない。他の要因からも影響を大きく受ける。
メンバは製造するとき、外部の作用を受ける。その作用は製造の途中でメンバの能力に対して成果を引き上げる影響、引き下げる影響を与える。
外部の作用は、メンバの社会的な関係性を依存する集合体＜チームメンバとの関係＜家族＜メンバ自身の関係で強く影響を受ける。
→ 個々のメンバの能力に左右されるが、
- 能力は外的要因により影響を受けやすい。
計測したパフォーマンスの可視化
マネージャは、パフォーマンスの最大化のために、計測したパフォーマンスは可視化して期待を得られない点をひい上げしたい。
製造の性能が個々のメンバに依存することを理解すると、それを対象に可視化しようとする。
可視化し、視認できる対象に対して対策を講じる。
個々のメンバの能力は、外的要因に影響を受けるため、一時的もしくは少なからず向上する。
その効果は計測を継続している間だけである。
計測を続けることが新たな外的要因となり、メンバの製造能力に影響を与える。
→ パフォーマンスの可視化は、次の目的以外には使えない。
- 期待する能力に到達しないメンバの可視化
- メンバ自身の改善
- メンバの入れ替え
工程を科学する
マネージャはチーム独自の製造工程を観察（計測）する。
観察した定量的な情報、製造の仕組み（段取り、手順）を図式で可視化する。
インプットとアウトプットまでで加工（プロセス）を繰り返さない、移さない、同じ情報を作らない観点で対象になるものがあれば排除対象とする。
ただし、これでは継続的イノベーションとなるので、途中を飛ばす、情報入力の場所を変える、手段を変えるなどの発想が必要となる。
チームに変更した後の案と効果を説明する。
サンプリングで案を複数回トライする。
期待する効果が認められれば、チームに説明し同意のもと導入する。
