そのうち観たい

カッコーの巣の上で [Blu-ray]

リーダの悩みの本質を本人が知ることは難しい

某イベントに招集されたら話す時間を確保したからとメッセが飛んできて何を話そうかと逡巡仕掛けたところで主宰者に「何聞きたい」とビーンボールを投げてみたらいくつかキーワードが拾えたのでスライドを新規に作って話してきたのですけれど、相変わらず時間をギリギリまで使ってしまうのは話していると楽しくなるのでもう少しタイムボックスを気にした方が良いのかもしれない。

聴講者の年齢層が若くてスライドでは、キャリアをどうしてきたかアンチパターン的に話したのが引っ掛かりを作れたようで、時間枠いっぱいに使ってしまったのはそれはそれでよかったのかもしれないということにしておきましょう。

個人のイニシアティブ

キャリアを築くには仕事をしていかなければならず、仕事は面倒で面倒でということについては誰もが同意をしてくれると思うのです。個人的には面倒だから対価を支払ってまで業務委託をしてくれてるのだから面倒な仕事をしようというのが1つのポリシではあるのですが。

何かしらの仕事を任されたとき決してしてはいけないのは任された仕事のイニシアティブを掴み続けることです。間違っても苦しくてもイニシアティブを手放してはいけないのです。イニシアティブはそれを任された人の意思の表現であるのですから。

何をしたいか若しくは何をしようとしているのか

アフターイベント、つまり懇親会に当然行きますよねと選択権の無いままに承諾したところで聴講者の一人から相談したのですかと承諾を願う申し入れが。その取り巻きも顔見知りだったようでこういったときに悩みをきいてもらえと応援しているのか煽っているのかよくわからないけれど笑顔なので相当仲が良いのかもしれないな、と。

＃仲のいい友達なんだろうね。

こうした多くのトーカーの中で相談をしたいと申し出ていただけることはトーカーにとって嬉しいレスポンスなのですよね。

さて、横に席を陣取られて早速と相談ごとを聞かせてもらうのだけれど、どうやらプロジェクトのリーダをしているようです。

聴きながら、思ったより悩みが深い（面倒くさい）ことだとなんとなく端端から推察して行く。

途中、また仲間の友達の方なんだろうけれど、割り込みで意見を言いたそうで顔を急須の口になりかけたところでもうちょっと話を聞きましょうと制する場面に。

なんでもそうなんだけれど、特に相談の後にフォローすることもできないだろうし、その責務も権限も無いときには相談を持ちかけてきた方が自力で進められるように取り付けておかないといけない。

そんなことを頭の片隅に思いつつ相談者の方の話の続きを促すのだけれど、どうも聞いているとさらに状況が悪くなる。

ひと通り聞いたと思ったところで一つ問いを投げ掛けたのです。

「それであなたは何に困っているのですか」

相談事の本質を知ることは難しい

 「何に困っているか」と問うことは簡単なことですが、困っていることの本質を困っている人が自分で到達するのは実は難しいことのようです。

やはりこの相談の方も言葉が詰まってしまったのでした。

多分、相談したい＝現状から予測されて起きるだろう将来のことを色々と考えると耐えられないほどの心配事が頭に浮かんでどこから手をつけていいのかがわからなくなっているのかもしれません。

多くのケースで、課題に手がつかないパターンは不安ごとを多く考えてしまいどこから片付ければいいかの判断がつかないのです。

本当は困っていると思い込んでいるだけなのでは

困っていることが具体的にわからないのならと次のような問いで外堀を埋めて行きます。

「困っていることがないなら変える必要はないのでは」

言葉にはしませんでしたが、組織としてそれを受容しているなら困っていないと見做すことができます。ただ、相談者が見えていることが組織の意思決定の権限を持つロールが見えているとは限りません。

結論的には、組織は受容している状況で将来の不安を感じて変えていかなければならないと思うなら、自分の裁量の範疇から変えて行くことが確実です。それで自分が思っていた不安材料が本当かどうかを確かめられることができるし、間違っていたら自分の範疇でリカバリをすればいいので。もし、効果があればそれを成果にして展開を図る次のステップに移ればいいのですし。

そう言えば、現状でも将来でも不安が見えるという事象が誰にでも見えていると思い込むことは危険です。訴えたい人に伝えるときに、その訴えたい人が見えていなければ意思疎通ができないのですから。もし見えていないとしたらどうしたらいいか。それは、見えていない側でも見えている範囲の表現に置き換えて説明することをすることです。将来の不安を見えている人には手間どころじゃないですが、それをしないと伝えられないのは変わらないですから。

相談事は描く

 この相談ごとを聞くときにしたことは相談ごとを可視化したのです。ノートを出してフリクションのペンで描き、間違いは直し、何に困っているか、何をしたいかを相談者の言葉で可視化します。そうしなければこちらも初めて聞く相談ごとを受け止めきれないのは懇親会でアルコールが入っているということもありますが、何よりその描き止めたことをスマホで撮ってもらいお土産になるからです。

 さて、一つでも将来の不安を解消するアクティビティに繋がればいいのですが。

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)

PMとSEの間で欠落しているのは何で余計なのは何か

エンジニアはエンジニアのスキルとスキルを活かす自由を持っています。言い方を変えれば、エンジニア自身がどのようなスキルを身につけるかはエンジニア自身に委ねられていますし、スキルを身につけるスキルの程度はエンジニアに依存します。卓越したスキルを持っていてもそのスキルを活かすかどうかもエンジニア次第です。

そうなんですよね、システムの仕様を具体化して、仕様を実装するのはエンジニア次第なんです。

そのエンジニアがエンジニア自身でどのようなスキルを身につけようかを考えたり、身につけたスキルをどのくらいまで向上させたりと考え、実際の行動に移すかやめてしまうかもエンジニアがどう考えるかに依存します。さらに言えば、そうして身につけたスキルを持っているスキルのどのくらい（持っているスキルを100としたときに発揮しようとする度合い）活用しよかと決めるかは、エンジニアがアサイメントされるプロジェクトのリーダであるプロジェクトマネージャとの間にエンジニアの行動基準をどれだけ受けれられるか、若しくはプロジェクトマネージャの行動基準がエンジニアにとってどの程度受けれられるかに影響されるのです。

プロジェクトの中では権限分掌の観点から最小で二つの役割が存在します。一つはプロジェクトマネージャというリーダの役割。二つ目はシステムを実現するメンバの役割。この二つの役割に応じた意思決定の権限と責任が割り当てられます。プロジェクトマネージャにはプロジェクト全体の責任に応じたプロジェクト全体に掛かる意思決定の権限を持ち合わせます。メンバには担当するシステムに対する実現の責任と実現方法の権限を持ちます。これらのロールと責務には上下関係の関連はなく、役割分担をしているという関係だけで紐づけられているところを権限だけで上下関係に関連づけてはいけません。

お仕事でプロジェクトマネージャとエンジニアの役割を分担しているのですからそれぞれの役割をそれぞれの責務の範囲で履行さえすればプロジェクトに起きる外的な進捗の障害はプロジェクトマネージャが内的な進捗の阻害要因の除去はエンジニアが担い、解消すればプロジェクトは完了します。

ところが現実にはそうならないのは、プロジェクトマネージャとエンジニアの間に存在しなければならない何かが欠落しているか何かが余計だからです。

欠落しているのは何で余計なのは何か。

役割分担でバウンダリを明確にしてプロジェクトマネージャとエンジニアの境界に隙間がなければ欠落しているものはプロジェクトマネージャとエンジニアの外周にある外界との隙間になります。その外周と外界も接しているとすればやはり埋まっているように見えるプロジェクトマネージャとエンジニアのバウンダリの間に実は接しきれない欠落している何かがあるということになります。

何だろう。

一方の余計なものがプロジェクトマネージャとエンジニアのどちらかか双方にあって阻害するものがあるとしたら何だろう。

冒頭でエンジニアにはスキルを身につけることもスキルのレベルをどの程度にまで向上することをできる自由を持っているとしました。これは真理でもあると思います。実際の現場でアサイメントされたプロジェクトで同じロールで担当が機能違いのエンジニアがいた場合、そのエンジニアたちが同等のスキルとスキルレベルをプロジェクトが終わったときまでにOJTを介して備えているかと言えば、そんなことは全くあり得ないことは現場のエンジニア自身が良く理解していることだと思うのです。

やるかどうかはエンジニアの自由に委ねられているということです。

その自由はさらにプロジェクトの中でプロジェクトマネージャとの関係で持ち合わせるスキルをどの程度発揮するかは無意識か意識的にを問わずに何かしらのバイアスから影響を受けているのです。

そのバイアスを掛けているのはエンジニア自身の感情に由来するエゴです。エゴは感情そのものと言っても良いかもしれません。このエゴにより知らず知らずにエンジニアはスキルの発揮にブレーキを踏んでいるのです。それは感情が引き金となって。

では、プロジェクトマネージャとエンジニアの間に欠落しているものは何でしょうか。エゴや感情ではない何かが欠落していることにより引き起こされているとしたら、それは解消することでプロジェクトの進捗を阻害する要因を除去することができるということになります。

それはプロジェクトマネージャもエンジニアも双方の内心で囁く小さな自分自身の声であり、思いです。この声はそれぞれの立場で期待される貢献を理解し、それを実現するために何をすれば良いかを理解し、出来ること出来ないことを明らかにすることにより小さな声はしっかりと明確な意思として認識できるようになります。認識できるかどうかが感情で支配されるエゴを牽制し、本来プロジェクトマネージャやエンジニアとして取ることを期待される行動を選ぶように作用します。その意思を醸成できるかどうかはプロジェクトチームの目的やプロジェクトマネージャの行動規範に対して自己のエゴよりそれを優先してでも行うことに対して価値を見いだすことが出来るかどうかに掛かっています。

結局、プロジェクトの進捗を阻害する内的要因はプロジェクトマネージャとエンジニアの各々のエゴよりチームとしてプロジェクトを進めようと思える共通の価値観に基づいているかどうかで大きく左右されるのです。

行動経済学まんが ヘンテコノミクス

割とエンジニアの組織は自由が多い

どこまで組織が体系的に且つ網羅的且つ最新の世の中の動向に追いついているかどうかに依存するのですが、ほとんどの組織で規程しているルールの改訂履歴を参照すると最後の改訂から5年以上経過していたり、小改訂であったりします。

平たく言えば、ザルです。

まあ、大きな網を掛けて守らせたい範疇とそれ以外のバウンダリだけを明確にして中身を制定する必要のあった事項だけを決めていく、感じな規程体系とするかISOのマネジメントシステムの目次構成をパクっているのでまあ、みたいな。あとは法的な決めておかないといけない条項を並べたとか。

それで初版を作る人は考えるんですよね。主管部署の部長か役員が責任者となることが多いのでそうしたステークホルダも真面目に読みます。初版は。

ところが改訂になると担当は変わっていたり、承認レベルの長も関心がなく改訂箇所のみだけ直せ、みたいなことを言い始めてだんだんとつぎはぎになっていくのですが、それはまた別の話ですかね。

最初の立て付けで決まると言えば決まるのですが、前述のような経緯を辿るので、最近多い社外活動やITツールの業務利用とかはカバーしているわけがないのですよ。あと副業もあるけれど、多くは本業に差し障りがあるからでしょうけれど内部情報漏洩の観点で禁止をしていることもあるのです。

今の現場にないことをやってみたいとか、副業ではないけれど外部の団体でボランティアをしてみたいとか思ったときに組織の規程でどうなっているかは気にかけておきたいところです。

一番まずいのはあとで主管部署からクレームがつくことです。変に拗れて始末書なんてなったら次やれないですし、それを防止する禁止条項ができてしまいます。

日本人の特性として面倒ごとは全部禁止してしまうことで当事者が楽をするという性質があるのでそれをさせないように回避したいところです。

ではどうするか。

「○○を禁止した規則があるか」それだけを確認します。あれこれ余計なことを喋って自分から情報提供をして勘ぐられたり、詮索させたり、先回りされてはいけません。

確認が取れたらそれと日時と担当者をメモしておきます。その上で、マネージャに（できれば部門長）に

「これこれやります。主管部署には問題がないことを確認してあります」

と事前報告なり申請ワークフローを回しておきます。実際、先に主管部署に禁止した規程がないことを確認しているので問題がありませんから。

そして、やりたいことをやります。

どうしてマネージャ、それも部門長に入れておくかというと

「俺の知らないところで問題起こしやがって」

となることを回避するためです。

さらに、事後は簡単なサマリを報告しておくと受けがいいです。これを繰り返しやるとマネージャはそういったことに関心があるとか、例えばアジャイル系とかIoT系カンファレンスに出ているから組織内で話題になったときに名前が出てきやすくなります。

「IoTか」
「Aがよくカンファレンスの活動しているから聞いてみよう」

 とかね。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

滞留するエンジニアは隣の芝の青さに憧れ続ける

一つの技術をやり続けることは担当する技術の幅を広げ、深め続けているならプロフェッショナルとしての位置を確保できるかもしれません。ただ、現実には技術の展開や深掘りをしているエンジニアは稀です。プロフェッショナルと呼ばれるエンジニアが希少な現実を目の当たりにする限り、そういった見方はあながち間違いではないのかもしれません。

プロフェショナルなエンジニアが技術の横転、深掘りをしているときに、同じエンジニアでありがなら価値観の違いからか与えられた仕事、与えられた役割で滞留するエンジニアも存在します。プロフェショナルなエンジニアは興味か何かに動かされまるで鮪のように常態的に技術の海を泳ぐことを続けますが、滞留するエンジニアはその１点に留まり続けているのです。

「隣の芝は青い」という慣用句がありますが、隣の技術をやりたいというエンジニアをときどき見かけます。隣の技術をやりたいというのならまだ良い方かもしれません。自分やってみたら、と言えるので。ひどいなと思うケースは、やれどこのチームが表彰された、他社はこんなことをやっている…おいおい、子どもと仕事をしているのかと疑いたくなったこともありました。

こうした隣の芝は青い的なことを口に出すようなエンジニアに「じゃあやってごらん、サポートするから」といったところで何かしら一歩を踏み出したケースはないのですが。

30年前ではないのですからコンピュータリソースも技術公開も進んでいる今なら本当にやりたいのであれば、業務をやりくりして青く見える芝が本当に青いか片鱗でも覗きこむことができる時代です。実際に隣の芝で活躍しているエンジニアが勉強会やカンファレンスで事例などをオープンにしているのですから、その青く見えている世界の縁にタッチすることもできるのです。

外野からみていた色と中から見た色が違うことはよくあることです。というか、仕事の大半は泥臭い、地味で、ちまちました作業の積み上げです。それはそうでしょう。アウトプットを作るために作業を机上で分解して、その分解した作業をつみあげ、繋げ合わせてアウトプットに構成するのですから。

実際、隣の芝が青く見えるかどうかは踏み込んで見なければわかりません。逆に、隣の芝の中から見ればこちらの芝の方が青く見えているかもしれません。これは立っている芝の領域の中の常識だけで外界の芝を眺めているといくらでも青く見えるということです。

つまり、自分で隣の芝が青く見えるようにバイアスをかけている、ということなんですよ。

じゃあ、本当に隣の芝が青いのかどうか、エンジニアとしてはより興味を引き、自己の学習欲を満たす仕事をしたいと思うのならば、担当する業務は業務として片付けておくとして、業務外の技術である隣の芝に関わりを作ることが結果的に今のポジションを見つめ直す良いきっかけになるのではないかと思うのです。

さて、あなたは隣の芝が青いといつまで羨んでいるのですか。

Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)

メンタルダウンの部下を持ったら

なんとなくタブーな気がしないこともないけれど。でも現場にはメンタルダウンしてから復帰しようとしているエンジニアもいれば、まさにメンタルをダウン仕掛けているエンジニアもいると思うのです。でも現場のエンジニアもマネージャもメンタルダウンの専門知識はないからどうしていいのかわからない、とも思うのです。

突然複数のメンタルダウンの部下が

ある組織のマネージャになったんですね。そこそこの規模の組織だったのですが、着任後、人事関連の方から呼び出しがありまして。

「あの方とその方とあと…はメンタルダウンなんですよ。それで…」

 まあ、そうなんだ、としか言いようがないですよね。病気ですから病気と付き合って仕事をしてもらうんだな、他の疾病もそうだし、みたいな感じしかリアクションは取れないんですよ。

マネージャは病気の専門家ではない

 人事関連の方の説明を聞いて自分に言い含めたのは、自分は専門家ではないということでしょうか。

素人考えで病気の部下に対して業務以外のことをあれこれ指示なんてできません。ただ、できることは予備知識として人事関連の方から教えてもらうことや書籍から知識として知っておくことは出来ますね。そのくらいの情報は持っていないといざというときに間違ったアクションを取ってしまうかもしれませんから。

リソースとしてカウントしない

 マネージャとしては辛いところですが、リソースとしてカウントしない方が良いでしょう。あくまでもリソースとしては。組織の一員ですから病状が良くなれば、産業医と復帰プログラムを開始することになります。立場的には現場に復帰して貢献してもらえると嬉しいです。ただそれだけ。

焦らせない

他の長期疾病も同じですが勤務実績がなければ給与は出ません。勤務期間に応じて保険などから7割給付されるのですが、とにかく収入がないので本人は焦ります。

自分で負荷を掛けてしまうのです。

前のめりにさせない

長期療養していると、他のメンバに申し訳ない、迷惑をかけていると思いがちです。だから早く復帰して仕事で貢献したいと思っていることが多いです。

これもまた自分に負荷を掛けてしまいます。

納期のないチームのタスクなどプレッシャの少ないタスクから徐々に。

距離感

 メンタルダウンしているから特別に扱うことはなかったです。基本は他のメンバと同じ距離感の関係性を保つ方が良いでしょう。あまり深い意味はなく普段から希薄なので。

これはメンタルダウンだからということに限らないですが、個人の日常にどこまで踏み込むか、という関係性の考え方に依存するところだと思います。

自分から相手の領域に入るならある程度の覚悟が必要だと思います。関わるなら後始末を考えてからでも遅くはありません。 

メンタルダウンは多い

 仕事に対するプレッシャが高まり続けるとメンタルダウンで療養するメンバがじわじわと増えていきます。これは気づくと周りのかなりの数のメンバが程度の違いはあっても経験者だったり、療養中だったりしているということです。

幸いにも復帰できればいいのですが、メンタルは再発しやすいようです（人事関係談）。

メンバとしてなら普段どおりに接する他なく、マネージャなら急がさせず一つひとつステップを踏ませて現場復帰出来るようにアサイメントをする以外は出来ることが限られると思います。

くれぐれもメンタルダウンの専門家でないことを忘れないように。

もし部下がうつになったら

クラッシャー上司 平気で部下を追い詰める人たち (PHP新書)

調達 薬用石鹸

薬用石鹸、いつも使いがいつの間にかディスコンになってた…

【純日本製】最高峰シルク“生糸”の５本指靴下-紳士用２足組『くつしたの下』生成り/蒸れ・水虫にも

透明レスタミン石鹸

薬用アルボース