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人のメンバのパフォーマンスは、製造する工程、装置だけに影響を受けない。他の要因からも影響を大きく受ける。
メンバは製造するとき、外部の作用を受ける。その作用は製造の途中でメンバの能力に対して成果を引き上げる影響、引き下げる影響を与える。
外部の作用は、メンバの社会的な関係性を依存する集合体＜チームメンバとの関係＜家族＜メンバ自身の関係で強く影響を受ける。
→ 個々のメンバの能力に左右されるが、
- 能力は外的要因により影響を受けやすい。
計測したパフォーマンスの可視化
マネージャは、パフォーマンスの最大化のために、計測したパフォーマンスは可視化して期待を得られない点をひい上げしたい。
製造の性能が個々のメンバに依存することを理解すると、それを対象に可視化しようとする。
可視化し、視認できる対象に対して対策を講じる。
個々のメンバの能力は、外的要因に影響を受けるため、一時的もしくは少なからず向上する。
その効果は計測を継続している間だけである。
計測を続けることが新たな外的要因となり、メンバの製造能力に影響を与える。
→ パフォーマンスの可視化は、次の目的以外には使えない。
- 期待する能力に到達しないメンバの可視化
- メンバ自身の改善
- メンバの入れ替え
工程を科学する
マネージャはチーム独自の製造工程を観察（計測）する。
観察した定量的な情報、製造の仕組み（段取り、手順）を図式で可視化する。
インプットとアウトプットまでで加工（プロセス）を繰り返さない、移さない、同じ情報を作らない観点で対象になるものがあれば排除対象とする。
ただし、これでは継続的イノベーションとなるので、途中を飛ばす、情報入力の場所を変える、手段を変えるなどの発想が必要となる。
チームに変更した後の案と効果を説明する。
サンプリングで案を複数回トライする。
期待する効果が認められれば、チームに説明し同意のもと導入する。
スタートアップの情熱は後付けである
形もイメージもなければ対象になるものが存在しない。だからそれを好きになったり、可能性を見いだすことはできない。『いやそんなことはない』と言える時点で、すでに対象となるイメージを脳内に持っているか、虚像として捏造している。
事業を立ち上げる、起業家になるといったときにイメージか虚像を持っていなければ、その時点での熱量は全く存在しない。イメージして、イメージして、イメージし続けて、違うと否定し、クシャクシャにして捨て、拾い、また捨てて、いくつものイメージを想像して、言語化して、輪郭をシェイプして行く過程でイメージとの摩擦が生じて熱量が生まれる。これがスタートアップや起業家のもつ熱量を供給し始める。最初は本当にぼんやりとしたイメージでしかない。そのぼんやりとしたもののディテールアップを始めるとコストを投下し始めるために次第に覚悟をしていく。積んであった預金残高は投下に応じて湯水のように減っていく。覚悟と現実はプロダクトへ向かう情熱の燃料に変わる。スタートアップや起業家の情熱は投下したリソースを燃やして得られるのである。
始める前から情熱を持っている自称スタートアップや起業家は怪しい。
- 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
- 出版社/メーカー: 日経BP
- 発売日: 2012/04/12
- メディア: 単行本
- 購入: 24人 クリック: 360回
- この商品を含むブログ (96件) を見る
『ふーん』から脱却できないプロマネ講座
SIerのエンジニアならプロジェクトに参画するから基礎知識としてプロジェクトマネジメントの講座を受けるだろう。もし受講する機会がないとしたら、組織としてプロジェクトをやるつもりがない（つまりSESをビジネスにしている）か、エンジニアに対する教育をすることで（プロマネの講座の場合は）プロジェクトの成功率を上げたいとかエンジニアの付加価値を上げたいということが念頭にないのである。
スタンスはさておき、プロジェクトマネジメント講座を受けても全く身につかないだろう。キーワードはところどころ記憶に残ったとしても、それでプロジェクトをどうマネジメントするか仕組みとしては組み立てられない。実践知としプロジェクトの経験を持っていれば、講座で確認した知識体系により実践知は整理されるので意味があるのだが。
プロジェクトマネジメント講座の内容はPMIのPMBOKの内容を要約して説明する講座である。もしプロジェクトマネジメント講座と称していながら、システム開発（それもウォーターフォールで）を説明する講座だったりしたらそれはそれでひどい話である。
前提知識がないのであるから（だから受講するのであるが）、受講者の立場になればプロジェクトをうまくやりたいだけでの話で、延々とPMBOKの知識を説明されても頭には入らない。言葉は聞きなれないから頭に入らないし、持っている知識とも紐づかないから感覚的に理解できない。結果、ふーんで終わってしまう。
自分の経験から言えば、プロマネの講座をいくつか受講したり、プロマネ講座の中で品質に特化した講座などを受けてきたが、内容もこの程度のなのかと受講から数時間して興味を失ったこともあった。
プロマネの知識を使ってプロジェクトをやるのではなく、プロジェクトの目的の設定と、どうやって（how）作るかの実現手段の確立があって、初めてプロジェクトマネジメントが出てくる。作りたいものを作る行為をコントロール（マネジメント）するため、であるからである。
プロマネ講座でふーんで終わらないようにするためには、この点を受講者の業務をベースにプロジェクト化してコントロールすることを体験できなければ、ふーんから脱却できない。
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/09/19
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
アプリ開発チームのためのプロジェクトマネジメント チーム駆動開発でいこう！
- 作者: 稲山文孝
- 出版社/メーカー: マイナビ出版
- 発売日: 2015/04/28
- メディア: Kindle版
- この商品を含むブログを見る
オープンコミュニケーションというハラスメント
オープンコミュニケーションを文化の一つとしてうたう組織は少なくない。衝突を避けるために思っていることや感じていることを言葉にして発することをやめたり、言ってしまった後にどう思われるかを憂いて押し黙っていたり、勝手に慮って遠慮をしたり。
本来のオープンコミュニケーションには次の効果を期待する。
・お互いの性格や価値観を知り合えることで違いを理解できる
・コミュニケーションの取り方を変えられる
・相手を理解した上で意思を伝えられる
・余計な心配、誤解が減る
ところが、オープンコミュニケーションを自分が感じた感情のまま伝えることがオープンコミュニケーションだと思い、相手の価値観に一切の配慮もなく言葉をぶつけてくる人がいる。
これはオープンコミュニケーションとは違う。オープンコミュニケーションだろうがなかなろうが、相手を尊重することはコミュニケーションを取る上で大前提でなければならない。そうしなければコミュニケーションを取りたい相手から相手にされない。
仕事ならそういうわけにもいかないと思うかもしれないが感情の強い言葉を受けた側は、そのように発する相手を避けるようになるし、対応するとしても後回しにされるか事務的な対応しかされない。
そのようなコミュニケーションを取る時点で前項の最初のステップにさえ到達していないのである。心理的安全性云々と話題になることが多いが、その前コミュニケーションを取る相手の尊重がそこにあるかどうかを人差し指を自分に向けてみよう。
SIerでチームを継続することの難しさ
SIerでのチーム。チームは組織図上のチームか組織図とは別にプロジェクトチームの2つに分類されるだろう。プロジェクトチームはマトリックス組織の上に仮想的に作られるか、組織図にもプロジェクトチームとして表現されるだろう。
プロジェクト視点で見ると、組織横断的なプロジェクトか部や課に閉じた組織内のプロジェクトのいずれかになる。
プロジェクトチームはプロジェクトの定義からいずれ解散か改組され組織図上に組み込まれる。
SIerに限らずプロジェクトチームは期限性を持つから目的を達成するか中止の判断で解散する。いくら良いチームを作っても有期限性を持っているので最初から解散は決定事項である。
ではSIerではチームを継続して成果を継続的にアウトプットするチームは実現できないのだろうか。
SIerの事業会社のITプロジェクトを切り出して請け負うビジネスモデルの観点で考えれば可能であり、難しい点もある。
チームを継続できるビジネスは、アウトソーシングや維持管理の事業を思いつくが継続した成果を出していることは事実（だからアウトソースの契約を継続できているはず）だろうが、そうしたビジネスモデルで継続されているチームで成果をアウトプットしているなどと耳にすることはあまり聞かない。アウトソーシングのプロジェクト内で表彰や謝恩として事業会社から称されるケースもあるが、内輪でやっているためにSIerの内部まででしか公開されない。
このチームはアウトソースのなかでエンジニアを閉じてしまうため、技術の更新は停滞し、不連続の成長の機会を失う。そこにチームはあるのに成長が鈍化する。
プロジェクト型のチームではどうか。組織横断型はマトリックスのプロジェクトチームとなるため、プロジェクト終了とともに解散するため継続しない。SI後はアウトソーシングとなるためSIのプロジェクトチームを縮小するか、アウトソーシングの部門に引き継ぐ。
もう一つは組織内でのプロジェクトである。これは組織である部や課に閉じたプロジェクトであるから、組織長の采配でどうにでもできる。継続して成果をアウトプットするチームを作ろうと思えば作れるが条件がある。
まず最初に継続してアウトプットできるチームをどう作るかであるが、部なり課なりで1つのチームとして同じバリューを持つ。意思決定、判断、振る舞いの最低限のラインを合わせる。言い方を変えると部なり課なりでエンジニアを1つにプールする。持っている技術はエンジニアごとに違いがあっても価値観は同じであるからプロジェクトチームを組織内で編成すれば継続してアウトプットは価値観の共有レベルで期待できる。
問題はその組織、部や課の事業分野からのプロジェクトの受注に依存する。受注（組織内の予算でも構わない）がなければ組織上存在できない。これが最大の難関なのであるが解決方法は小さなチームにすることである。小さいチームであっても継続して成果をアウトプットしていれば事業分野に関わらず生き残れるだろうし、それこそが生存戦略になるだろう。
ただし、経営サイドが成長を求めなければ。
SIerとしての継続的なビジネス成長を求められるので組織長が特段保護しないと受注のパラメータで狂ってしまう。
SIerで継続して成果を期待以上にアウトプットするチームを作ることは難しいという理由は上記のように考えているからである。
ガールズ＆パンツァー 最終章 継続高校はらぺこ食事道(1) (電撃コミックスNEXT)
- 作者: あしもと☆よいか
- 出版社/メーカー: KADOKAWA
- 発売日: 2019/06/10
- メディア: Kindle版
- この商品を含むブログを見る
