素振りだけのエンジニアは使えない

いくつか書き残したいキーワードがあったはずなのだが、そのいくつかを覚えておくことは自分にとっては難易度が高いようだ。つまり、忘れた。それでは続かないので、近況的な体験を綴ろう。

ある日、会合に出てフローな状態で議論でき、良い結果を得られたことがあった。会合のオーガナイザーであるし、召集日を調整して決めているのは自分なので、参じてくれる方からすれば、色々といい感じに促してくれるのだろうと思っているかもしれない。

暗黙で、召喚されれば半ば受け身で参画するのは自分とて同じである。

実際は、オーガナイザーだとしても、ノリノリで望むかといえば、そうでもない。モンエナをチビチビとやっても集中力がキープできなかったり、議論に置いておかれそうになることもままある。議題を提示して、方向性の素材を撒いてメンバに任せてしまう度合いが高いからかもしれない。

ところが、その日は全然違ったのである。頭のクリアさがずっと続いている。何が冴えない頭の時と違うかを考えてみると仕事のアウトプット量と比例しているような気がしてならない。

どういうことかというと、その日は段取りの手筈や事前調査などでのある程度のアウトプットを出してから会合に来ていたのであった。

無の状態から企画の方向性を仮説を立てて形作り、網羅的にカバーできているかとか、収集可能な情報を怠らずに集められているかだとか、あとで周りから突っ込まれない程度にはやることをやるために終日頭を使っていたのである。

多分に、終日高回転していたまま会合に突入できたので、続く会合もいい成果に結びついたのではないか、と。

別の見方をすると、やっとその領域の仕事の仕方を再現できる程度に身につけることができた、のかもしれない。

仕事はやった、では評価されない。違うな、専門家としては、再現性のない仕事のやり方は評価しない。インプットにある程度の幅があったとしても、期待する結果を再現できるやり方で実現するのがプロってものだ。

そのためには、鈍な刃であっても切れるように研ぎ続けなければならないし、切れることを日々確かめなければならない。

研いで、素振りだけではダメなのである。実際にきっていないと。

再現性がない仕事を評価しないのは、なぜか。その仕事のやり方自体の成熟度をあげられないし、いざというとき、失敗できないときに確実に失敗するのである。

プロを名乗るなら、プロと第三者からみられるなら、失敗してはいけないのである。客前では、たとえ失敗したと内心思っても決して失敗したと言わず、最後には、それっぽく整えるのがプロである。

逆に客がいない内輪の場では、失敗はプロであればあるほど、ひけらかす必要がある。そうして自分をネタに後進の学ぶ機会を与えるものプロの仕事である。

プロとしてであることの一つがオーガナイザーとしての振る舞いにも現れているとすれば、それはまた嬉しい気づきでもある。

ねんどろいど 刀剣乱舞-ONLINE- 骨喰藤四郎 ノンスケール ABS&PVC製 塗装済み可動フィギュア

OSK 弁当箱 ベージュ 約780ml 刀剣乱舞-ON LINE- 曲げわっぱ弁当箱2段 3Pセット WRW-2

SIプロジェクトは案件ガチャか

SES案件はガチャらしい。

案件がガチャだなんてどれだけ運まかせなのだろうか。ガチャと言うからには、決まっているのはガチャを回して得られる対価以外は神のみぞ知るセカイと言うことなのだろう。本来の意味でのガチャは小銭を入れて回すが。

SIプロジェクトで誰がガチャにしているか

SESは業務委託であるから、SIプロジェクトも維持管理もほぼ、あらゆるITに関する契約を包含する。なぜかはわかると思うが、請負契約も準委任契約も業務を請け負うからである。請負契約以外は派遣契約である。

では、請負契約であるSIプロジェクトをガチャにしているのは誰だ、と疑問が生じる。

通常、契約を結ぶ権限を持つのは営業である。営業を置かない組織では管理職がそれを行うこともあるようだ。

いずれにしろ、契約を結ぶ権限を持つロールが案件を見積もり、交渉にあたる。それを担うはずの権限者に案件がガチャかどうかの目利きができないと言うことになる。

SIプロジェクトがガチャか判断するなら

 請け負うには『何を』請け負うか、知らなければならない。何に対して成果物を納める履行義務を負うのか明確でなければ請け負うことはできないのである。

受託する『予定』の案件の要件、諸条件、指定される適用技術などを理解しなければ、請け負えるかどうかを判断することはできない。

逆に言えば、請負契約にしろ、準委任契約にしろ、派遣契約でなければ見積もりができなければならないし、何を履行するか見積れているのであれば、見積もり前提条件が付されなければおかしい。

SIプロジェクトをガチャにしてしまうのは、

• 成果物の定義をしていない
• 見積もり前提条件が提供時間しか存在しない

かどうかで判断できる。

見積もり仕様を出せばガチャ度は下がる

 引き合いがあり、話を聞きに行く。QCDSのようなSI案件の諸情報を尋ねるだろう。さらに、案件に見合うエンジニアがいるならSI案件のどこを引き受けられるかスコープを詳細に尋ねるだろう。

こうしたヒヤリングは、委託元のSI案件の理解度、確度、客バカ度を見極めるのに役に立つ。

ヒヤリングで網羅的に、SI案件を請け負えるかどうかの観点で聞き始めると相手の本気どもわかる。

ここで相手が説明を嫌がる場合は、ガチャ度が高い。要件が曖昧、委託元の予算が少ない、工期があり得ないほど短い、など諸条件のどれかか複数に危うさが確実にある。

だから、説明を嫌がる。

そうしたSI案件は高い条件を出すかエンジニアのタイミングが合わなとしてやんわりと辞退することが望ましい。

受けるにしても、危うさは価格なり工期なりに超過して計上しておく。

委託元が必死に引き止める時もガチャ度が高い。過去に失敗しているか、委託元内で無理なコミットをしているかさせられているか、である。

そういったSI案件であれば、スコープを分解して、危うさを回避するか、他社を立て、恣意的にアンダーに入り、諸条件をてんこ盛りにして危うさを転化するのが望ましい。

何も好き好んで悪条件で請け負う必要はないのだから。

SIプロジェクトはガチャか

 結論は何を履行するか見積もりしていないから自らガチャにしているのではないか。

つまり、案件ガチャとかそもそもが馬鹿らしい話なのである。

神のみぞ知るセカイ（１） (少年サンデーコミックス)

FLAG. 7.0「Singing in the Rain」

理想のマネージャ

誰にとっての理想のマネージャなのかという観点を忘れてしまうとこのようなテーマを扱うと議論が発散してしまう。

組織　→　マネージャ　←　部下
↑
マネージャ自身

少なくとも３つの視点がある。視点というよりは立場、である。組織は組織としてマネージャに対する期待を持っているし、部下は部下でマネージャに対する期待を持つし、マネージャはどのように振る舞うことがマネージャとして良いのか悩み続ける。

またマネージャ自身も自分の上にマネージャを持っていて、自分自身が部下の位置になる。その意味では、マネージャは2つのロールの立場で物の見方を暗黙に要求されていることになる。

部下としての理想のマネージャ

部下から見たときの理想のマネージャ像は、なかなかこれだと1つには絞りきれないだろう。マネージャと部下は１対Nの関係になるため、一人ひとりの部下であるエンジニアの理想を尋ねれば、尋ねたときに部下が関心を持っていることについて教えてくれるだろう。大事なことなので重ねるが、『尋ねたとき』に関心を持っていることについて、である。

キャリアサポート、アサイメント、PC環境、職場環境、労働環境…評価、給与、承認要求…マイクロマネジメント、組織の情報（主に社員で手に入らない情報）…作業負荷、不公平感…コミュニケーション、対人関係、振る舞い、言葉遣い…最新技術の担当、有償カンファレンスの費用、海外カンファレンスの費用…。

 きりがないが、部下にとってその瞬間は大事なことなのである。そして、そうした大事なことは言うこと自体を部下が抑制するので知らされない。

経験から言えば、自分のことを観察していて、マネージャから見た自分の適性の可能性を示してくれたマネージャには感謝している。そうしたアドバイスのないマネージャは信頼することはなかった。

組織としての理想のマネージャ

これは単純で、組織の課題を解決してくれるマネージャであり、指示どおり動いていくれるマネージャである。

その解決方法のアプローチは問われないが、組織のルールがあればそれを遵守することは無条件に求められる。

まあ、そうだよね、くらいでしかない。

マネージャ自身としての理想のマネージャ

 マネージャの理想のマネージャ像を聞く機会はこれまで何度かあった。だいたい2つのパターンに分かれる。1つ目は、過去に部下になった上司を理想とするパターン。2つ目は、理想のマネージャを尋ねられ、そのときに思いついた人物や理想だと言うマネージャが備えている能力を言うパターンである。

これはマネージャ像の確固たるモデルが存在しないことによる。

後者は、理想を尋ねられたマネージャが持っていないと思っている能力をあげることが多い。持っていない能力は欲しい能力で、そうした能力は振り返りをする度に自分で持っていないことをせめ、自身の評価を下げてしまうマネージャもいる。

部下から見れば、部下自身のことを認めて、導いて欲しいと思っている。組織からすれば、組織の課題を理解して解決して欲しいと期待している。どちらも共通していることは、対象を『把握』できるかできないかで評価が分かれると言うことである。

マネージャは『把握』する対象を知り、『把握』するために情報を集め、『把握』したことをから課題設定し、『把握』したことを解決する。

把握できるマネージャは1つの理想のマネージャなのかもしれない。

美人女上司滝沢さん (ドラゴンコミックスエイジ や 3-1-1)

スコープの境界線を引く

個人的な嗜好として、使える業務をデザインすることが好きである。業務をデザインするというのは、新規業務に関わる登場人物の役割、振る舞いを仕立てることである。

さらに言えば、そうした新規業務を企画する業務自体も好きである。

ただ、どちらにしろ前例がない。

当たり前である。だから、新規業務なのである。

振り返ると、誰かに押し付けられる業務はとても好ましくない。できればやりたくない。事務手続きなどは決められたとおりに手続きしないと処理が進まないため、それに合わせて処理をするし、その手続きがとても大事だと思えば、先に根回しをして処理が滞らないようにまでしておく。

一方、誰かからの指示で、自分に関わらないことはとても気が進まない。そうした仕事は組織の中のことで多いが、仕方がないと思えるまで消化する時間がかなり必要となる。

話を戻して、新規業務を作ることの楽しみはどこにあるのだろうか。

新規業務を作るためには、自分から主体的に背景を知り、ゴールを設定し、関係者を洗い出し、場を作り、コンセンサスを積み上げ、稟議を回し、ローンチまで行う必要がある。

本番は、ローンチした後の運用であるが。

そうした新規業務を作り上げることが好きなのなら、さぞかし最初からズバッと確信をつくような、課題解決をするような新規業務のたたき台を作れるのだろうと思うかもしれないが、それは残念ながらそうならない。

自分の無能さは棚にあげるとして。

実態もイメージもない新規業務のイメージを初めから100点でもっていくことは自分にはできない。

どちらかと言えば、思いっきり外す。ある意味、関係者がイメージするだろうこと違うことをたたき台に出して、それではないことを確認するようなものだ。

言い換えると、例外処理から仕様を見せるようなものであるし、集合の外側の部分のようなものを可視化して、それではないことをわざわざ確認しているようなものである。

これは１つの効果がある。それは、スコープの境界線をハッキリとさせることができるのである。

このスコープの境界線、界面がどこかを線を引くことは、新規業務のような実態のないもののイメージ像を作るときにとても必要なポイントだと思っている。それをしないといつまでたってもスコープが決まらないとか、クリープしていくのである。

まあ、方向性とか目的とかは外してはいけないが。

Nintendo Switch ポケットモンスター Let's Go! イーブイセット (モンスターボール Plus付き)

エンジニアの評価は誰もできない

エンジニアがマネージャになって困ることの１つにエンジニアの評価というものがある。

それはそうだと思わないだろうか。エンジニアからマネージャになったとして、では、エンジニアを評価できるようになるかといえばエンジニアであったときに一度も他のエンジニアの評価をしていないのだから、未経験なのである。

さて、そうしたマネージャにエンジニアの評価ができるだろうか。

エンジニアの評価は、エンジニア自身が関心を持っているもので、ときどき、勉強会などでも見かけるときがある。エンジニアの流動性と技術への関心が一部とは言え高まっていることは、これまであまり日の目を見てこなかったというか日本人の変なお金に対する潔癖感というか大事なはずの賃金を公にすることを回避することが美徳のような考え方が変わってきたことは好ましいのではないかと思っている。

組織によっては、役員報酬をオープンにしたり、社員は全員公開しているケースも見られるようになった。圧倒的に、従業員は給与テーブルだけ公開し、評価レベルは非公開が多いが。

話を戻して、マネージャ歴の長い人でさえ悩みを持っている方が少なくない。だから悩みを聞かされるわけだが。

多くのマネージャに対して、エンジニアに対する評価を説明することを求めると、多分、評価の根拠を説明できない。

なぜなら、どのような評価基準を持っているかを聞いても答えられないからだ。では、なぜ答えられないのかを突っ込んで尋ねると、うまく説明してもらえない。

これ以上は聞いても答えられないケースが多いだろうからとそれ以上は突っ込まないが、ひっくり返してみればわかることではある。

評価基準を持っていないためである。

割と衝撃的かもしれないが現実とはその程度である。

別な視点で言えば、評価基準を持っているマネージャは、業務目標の設定でかなり定量的に設定することをエンジニアに要求し、双方の合意を図っているものだ。

これも逆が成り立つ。業務目標を定量的に設定することを求めないマネージャは評価基準を説明できない。

では、誰がエンジニアの評価をできるのだろうか。

エンジニア自身が自己評価をさせても過小評価する場合と期待値を含めた過剰評価の二極に分かれてしまう。

一緒に働くエンジニアに評価をさせたとしても忖度が働いたり、自分より低いレベルのエンジニアには関心を持たないが、自分より高い評価をされているエンジニアに対しては関心を持つことが多い。

独自だとしても評価基準を持っているマネージャは少ない。

結局、エンジニアを適切に評価する解決策はないのである。

くまモン の スタンプ / 大変 よく出来ました / はんこ ゴム印 / ゆるキャラ グランプリ 2011 1位獲得 熊本 県 の キャラクター / くまもん グッズ 通販

上司ガチャ

これを読んだときに

『子供に、『両親ガチャは当たりだった』と思ってもらえるような家庭にしよう』

という文があって、同じことを考えている人はいるものだと思った。

書いた方の両親が当たりだったからそう思ったのか、外れだったからそう思ったのかまではわからない。

少なくとも自分の子どもが生まれたとき、振舞われていたことはしないようにと自分に言い聞かせていた。

あれから20年経ったのだが子どもはどう思っているのだろうか。

同じガチャに上司ガチャがある。外れれば仕事の振られ方はひどいし、無理難題を押し付けられるし、評価も思うようにされない。

ただ、このガチャは引き直しができるところが両親ガチャと違うという点がある。上司ガチャの引き直しは自分からもできる（異動願いや転職）し、上司側から（人事異動で）もできる。

上司ガチャの上司の立場で、メンバにどう接するかは１つのポリシを持って接している。それは、メンバが他に異動したり転職したときに、移った先で実力を認められるように育成するということである。

同じようなマネージャが集まることがあると、せっかく育てても持っていかれるのが困るということをいうマネージャを見かける。

自分としては、マネージャは人を事業に貢献するように育てるのも仕事のうちであると考えているので少し意見が違う。自分のような見方もあると認識していれば、こんな言い方はしないと思う。

マネージャとして優秀な人材を送り出すことこそ、使命の１つなのである。

上司ガチャが外れだったと思ったとき、長く部下である必要はない。ただ、自分がそう思ってしまっている『何か』がなんであるかははっきりとしておいた方がいい。少なくとも、コミュニケーションは双方で取るものなので、部下であるエンジニア側に『も』なにかしら足らないことがある。 

何がずれていているかを認識しておかないと、移った先で同じようなことを起こす『問題児』になってしまう。そうすると部署をたらい回しれて、ずっと評価されないかもしれない。

そうした評価は一度ついてしまうと取り替えるのはほぼ無理なのである。なぜなら、上司であるマネージャの流動性は組織の中においてとても低いからである。

まあ、ダメなマネージャを引いたらさっさと引き直すに越したことはない。

バンダイ公式 ガシャポンマシン

調達 業務用5kg フォンテラ社グラスフェッドバター

リピート。バターコーヒー用に。

業務用5kg フォンテラ社グラスフェッドバター