【課題】あなたの部下がインシデントを起こした。あなたは責任者として謝罪シナリオを作成しなさい。

これまで何度か仕事上でお詫びをしたことがある。主に、障害報告とか部下の不祥事だと思う。

障害報告だからとか、不祥事だからと特別な服装をしたことはないが、とにかく往訪した目的を果たさなければ楽しくない仕事をしに行った意味はない。

障害報告でも不祥事でも、わざわざ出向いて説明するのは、起きたインシデントに対する事実の確認と事後対処について共有する必要があるステークホルダの立場だからだ。

謝罪の基本

 先方はこちらが起こしたことについて利害関係がある為、(多くは不利益を被っていることについて)事後対処の同意と不利益についての要求がないことの確認をしなければならない。

経験から言えば、次のコンテンツが必要だ。

  • お詫び
  • 事象と経緯
  • 原因
  • 暫定策(恒久策まで時間を要する場合)
  • 恒久策

 ただし、こうした内容はステークホルダである当事者間で行われる内容であり、第三者に公表するようなものではない。

三者へ公表するようなケースは、事故のステークホルダを特定できない場合に広く周知するため、組織の外部向け情報サイトやプレスリリースを利用する。

謝罪の完了条件

では、一体何をどこまで対処すればインシデントを終了として良いか。報告する側、つまり、インシデントを起こした側としては今すぐにでも終わりにしたいだろうが、そうすることはできない。あくまでもステークホルダが同意しなければ何年かかろうが終わらすことはできない。

ここで必要になることは、最初に説明する際に進め方を示すことだ。説明する内容の冒頭にそれを織り込まなければならない。

  • お詫び ← 進め方を合意する
  • 事象と経緯
  • 原因
  • 暫定策(恒久策まで時間を要する場合)
  • 恒久策

障害報告はある意味ではとても対応しやすい。何かしらの制約事項により制限されることが少なくないが、それを守ることができればあるべき姿に戻せば良いので。

不祥事系は、戻すことができないことが多い。これは対価なり、契約変更なり、インシデントを起こしたメンバの出禁や取引停止を引き起こしかねない。なぜなら、そのインシデントが起きるまでは双方、そうしたことを想定していないのだから。

課題

あなたの部下がインシデントを起こした。あなたは責任者として謝罪シナリオを作成しなさい。

 

www.asahi.com

 

 

相手もよろこぶ 私もうれしい オトナ女子の気くばり帳 (SANCTUARY BOOKS)

相手もよろこぶ 私もうれしい オトナ女子の気くばり帳 (SANCTUARY BOOKS)

 

 

 

エンジニアとしての危機感とキャリアプラン

わかりみしかない。

 

lacolaco.hatenablog.com

 

修士号も博士号も持っていない。専門は情報だったが経営寄りで上の子が学んでいる授業に比べたら概論程度のものだった。学科名と選択した授業を思い出すと情報より経営主体だったから、結果的(=今の仕事のロールとして)は、よかったのかもしれないが。

今の仕事(顧客を含め)や組織の同僚、部下の専門を知る機会がある度に、理工学部が多いこととコンピュータサイエンスを学んでいた方が多く、更に言えば高学歴であることがわかると居場所がないのではと思うくらいなのだ。

危機感

危機感を持ったのは、エンジニアとして採用された後、数年後の初めての部内異動で仕事をしたときかもしれない。全くもって実力がないというか数学の知識がないことに愕然とした。

でもその時は何もしなかった。

しばらくして、その部門から他の部門の応援に行くことになり、そこでもまたエンジニアとして、特にプログラミング能力の欠如を知ることとなった。

当時のプロマネがその後異動して直属の上司となり、キャリアは1つではないことを教えてくれた。

キャリアパスを選ぶときの判断基準

そのときに考えたのは、できないからもう1つの道を選ぶような撤退戦をするのではなく、もう1つの選択肢の方が自分の持っている素養により適合しているから選ぶのだ、ということだ。

人は(特に自分は、かもしれないが)、自己に甘い。それはそれで必要なときはあるが、キャリアは収入と紐づく。収入を得るなら自分が持っている性質の中で適合率が高いスキルを生かす仕事を選ぶのが正解だと思っている。 

 適合率が低いキャリアのままで進んでしまうと、不適合部分をカバーするリソースを補填し続けなければならないし、修行を超えた辛みしか生産しない。

これは悪循環である。不適合のカバーで消耗し、本来、将来の自分への投資の道を自ら塞いでしまうのだ。

まあ、こうしたことも選択する際に自分自身の考え方として腹に収めたり、その後経験的に学んだことでもある。

危機感の程度

危機感は自分自身が感じることだ。

他人(例えば上司とか)が言う場合の危機感は、属する組織の事業の方向性からその方向性にあっていないエンジニアに対してキャリア的に外れてしまうことを予測した危機感かもしれないし、事業の縮退予測から今のキャリアのままだと結果的にキャリア転換しないと事業レベルで仕事がなくなる危機感を語っているのかもしれない。 

後者はさておき、心に占める危機感の大半は前者である。

こうした危機感は、自分の成果である保有技術のプラクティスや経験知を外部に発表することや自分の技術を市場価値で評価することで経験できる。

言い換えれば、ニーズがあるかどうかをしればいいのだ。

危機感を軽減するには

 何度か書いてきているが、キャリアプランを作り、それで自分の目指すエンジニアを日々積み重ねるしかない。

ただ、黙々とこれをやっていても頭をよぎるのが

 

「このまま続けていいのか」

「間違っていないか」

 

という不安であるが、これは実績を作り、市場価値を知ることで経験するほかない。

 

結局、身体が物理的に1つしかないので、一度にできることは1つであるということを受け入れることと、どれを選んでも正解はないということを頭だけではなく諦念として受けれることである。

 

Software Design総集編【2013~2017】

Software Design総集編【2013~2017】

 

 

やがて無色のエンジニアになる

対談めいたことをしたとき、何かの拍子に某所(イベントとか)に出て来るようなエンジニアは意識が高いのだ、と言うコメントを聞き逃さなかった。

某所のことを思い浮かべながら、そうか、と。自分がどっち側に着地しているかで物の見方が変わってしまう。更に言えば、着地したままだとそこにいるのが当たり前、日常になってしまうのでどちらかにいるかを忘れてしまうのだ。対岸から見ればわかるものだが。

パレートの法則を持ち出せば、意識高い系エンジニアは20%の方だ。残り80%のエンジニアは対局に置かれ、自虐的にか揶揄されて意識低い系エンジニアにラベリングされるか、ラベリングもされない無印系エンジニアとして放置される。

意識高い系エンジニアがキラキラとしている、どやっている感を醸し出すのとは反対に意識低い系エンジニアはそうしたものがないからまるでダメなエンジニアのようにイメージされがちだが、そんなことはない。目立たず、仕事を処理してくれるエンジニアが居てこそ世の中のITが回っているのも事実だ。

第一、意識高い系エンジニアばかりだったらと思うとそれはそれで胸焼けがしそうだ。カンファレンスの公募があれば、今でさえ落選多出な状態が当選がプラチナ扱いになってしまうだろう。それはそれでやっかみやカオスを生み出すだろう。そして、意識高い系の中でもまた、上澄みの20%が超意識高い系エンジニアとしてカンファレンスを闊歩し、残り80%の意識高い系エンジニアは無色になっていくのだ。

無色のエンジニアとなっても無理に色をつける必要はないと思う。色で競争してもキラキラしている意識高い系エンジニアにすぐに上書きされてしまうのだから。

 

終電ちゃん(5) (モーニング KC)

終電ちゃん(5) (モーニング KC)

 

 

「君達はまだ1円も稼いでいない」おじさんエンジニアは自分がいくら稼いでいるか知らない

新卒のエンジニアが集合研修や配属後の職場でこんなことを言うおじさんエンジニアがいる。

 

「君達はまだ1円も稼いでない」

 

そうだ、新卒で入ったあとの初めて夏の賞与を(気持ちだけ)もらったときにこんなことを言っていたお兄さんエンジニアがいたのを思い出した。

 

「夏の賞与は前の半期の俺たちの稼ぎなんだよ。いなかったのに貰えて云々…」

 

「それで」としか思いようがない。半期前の功績を賞与の制度にしているのは人事だし、入社して間もない新卒エンジニアに賞与を配布しているのも人事が制度として作ったものだ。文句があるなら人事に言ってくれ。

 

冒頭の「1円も稼いでいない」は新卒エンジニアに対して何を言いたいのだろうか。

ポジティブに取って、早く事業に貢献できるように力をつけてくれよ、ならそう言った方がいいし、そう思うなら、新卒エンジニアが戦力になるように関わればいいだけだ。

ネガティブに見るなら、本来、俺たちが貰うはずの給与の上前をはねやがってとでも思っているのだろうか。

いや、ポジティブにもネガティブにも微塵も思っていないだろうし、単に新卒エンジニアとコミュニケーションを取りたいのに接し方がわからなくて難癖をつけている近所のいじめっ子の小学生のようなものだ。

 

先輩はいくら稼いでいるんですか

「まだまだひよこでご迷惑をお掛けします。先輩はすごいエンジニアさんなのですね。先輩がエンジニアとしてどれだけすごいのか勉強したいのでslideshareやカンファレンスで発表したスライドをいくつか紹介してください」

 

「○○さんのようになりたいと思います。○○さんは年間どのくらいのビジネスサイズの案件をキャリーされているのですか。それってどのくらいのROI出ているのですか」

 

今だったら(今から新卒をやり直すのは嫌だなぁ)こんなことを言うかもしれない。言ったら言ったで刺されそうだけど。

でも、身内に、それも新卒のエンジニアに対して、その新卒のエンジニアがどうにもしようもないことを言うのはクレーマーみたいなものだし、おじんさんエンジニアのストレス解消かコミュ障の現われでしかない。

受け流すことに限る。

そんな1円も稼いでいないおじさんエンジニアは、自分にどれだけのコストが掛かっていて、どれだけ稼いでいるかを知っていることはまずない。

そうしたことを知っていたら、稼ぐことの大変さを身に染みてわかっているからこそ、言わない。黙って、早く現場に来て助けてほしいと思うものだ。

何より、新卒が配属されるとその小さなチームが新しいエンジニアを迎えると言うだけで華やかになる。

まぁ、数ヶ月くらいだが。

でも、そうなったらもう戦力の一人なんだ。

 

その作業終わったんですか

「ちょっと聞いてください」
「ちょっと待って、このメール出したら…ではよろしくお願いいたします…と。それで」
「さっき、上司に呼ばれて」
「やらかしたか」
「まだやってません」
「やるのか」
「先のことはわかりません。やるかもしれませんけど」
「よくない話なんだろう。フラグでも立ったか」
「そんなところです」
「…」
「それで、あるプロジェクトの応援に行くことになりました」
「…」
「しばらくお昼は一緒に行けなくなりました」
「そうか」
「そうです」
「それで」
「あまりいい感じのプロジェクトじゃないみたいです」
「だよなぁ」
「ですよね…。それでどうしましょう」
「いつものようにやるしかないんじゃない」
「すばらく様子見してきます」
「そんな余裕があるといいな」

 

「こんにちは」
「あれ以来だな。どう、あっちは」
「今晩、空いてますか」
「空いているの前提だな」
「そんなことありません。よく課外活動されていることはよーく知っているので」
「今日は予定ないよ」
「じゃあ、早いけど行きましょう」
「(これは相当きてるな)」
「何か言いました」
「いや、何も」


「それで」
「エンジニアの仕事ってこんなに属人化しているのかと呆れるというか」
「仕事が属人化とは」
「作業を分担するじゃないですか。みんな終わったというからレビューするんですよ」
「アーキテクトだもんな、レビューくらいするよな」
「そうなんですけど、終わったの状態がみんなバラバラなんですよ。オカシイですよね。完了した状態なんて1つしかないはずなのに」
「ああ、それで属人化か。やっと繋がった」
「どうします」
「俺がするの」
「そうです。どうにかしてください」
「そうだなぁ、全くチームの状況も文化もわからないからな。でも、作業の完了を揃えたいんだろう」
「そうです」
「単純といえば単純。だが、難しい」
「いいから答えてください」
「もう、俺ならどうするかわかっているんじゃないのか」
「いいんです。私が言って聞いてもらえないときは先輩の名前だすので」
風評被害が起きそうだな。言うのやめよう」
「そこはなんとか」
「エンジニアはさ、配属もプロジェクトのアサインも担当するロールも作業もどれを取っても同じエンジニアはいないんだよ」
「…」
「ここが大事なところ」
「はい」
「一人ひとり持っている経験知が違う。いいかい。違う。仕事の仕方は自分で覚えてきたんだよ。生産ラインじゃないので同じ手順でやるわけじゃない。自分で覚えた仕事の仕方でずっとやる。特に、覚えた仕事の最初のやり方が下敷きになる」
「…」
「覚える元はアサイメントされたプロジェクトのプロマネのやり方だけどさ、そのプロマネのやり方だって同じように経験的に覚えたものだ。だから、それを今のプロジェクトでリセットしなければチームメンバの仕事の仕方を揃えるのは無理なんだよ」
「無理だなんて」
「でもさ、チームの仕事の仕方、仕事の終わりを決めて、それ以外は認めなければいい。ただ、仕事の終わり、あれだ、完了の定義をメンバ全員で決めることと決めたルールを守らないとチームはそのメンバを守らないと宣言すればいい」
「あ、完了の定義ですか。あー言われてみればそうですね。なるほど」
「それを忘れるくらいなプロジェクトだと言うことだ」
「すみません」
「そんな状態だから難しいと言っただけ」
「いや、難しくないです。思い出せたので。やります」
「へぇ、勇ましい」
「これ飲んだら帰りましょう」
「それはそれと守らなかったらどうするんですか」
「ずっとリジェクトでいいじゃん」
「進捗困りますよね」
「でもリジェクトするの」
「それでも」
「俺のところに連れてこい」
「お願いしますね」

 

 

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

 

 

 

調達 サクラクレパス 水性ペン ピグマ 黒 5本セット ESDK-5A

 

 

見えるスキル見えないスキル

昨日見かけたツイートのイラストを見て、そうそう、と思った。

 

 

エンジニアに対して同じ観点で見ると、すごいエンジニアの凄さはいきなり凄いエンジニアなわけが無い。色々と経験をしてきている。

凄いと言われるエンジニアから見れば当たり前かもしれないけれど、凄いと見られるまでに、いや、今だって見えないところで経験を積んでいる。

さらに言えば、見栄えがするのはITの適用技術のところであって、それを支えている基礎的なスキルは可視化されることはない。

直接あって話したり、仕事を一緒にする機会があればその基礎的なスキルを実感することになる。 

 

f:id:fumisan:20180515074737p:plain

 

見えるスキルには、例えばシステム開発で必要となる様々な技術や手法がある。そうした技法に経験を絡め、要約されたものがカンファレンスのスライドとして見えるわけだ。

引用元のツイートのイラストで水面下の塊を本当はこっちがすごいと描いてあるが、すごいというよりは塊が大きくなるまで続けていることがすごいのだと思う。

エンジニア目線で見れば、見えるスキルの方が鮮度があるので華やかさを持っており、人の関心を引きつけやすい。

でも、それを支えているのは基礎的なスキルだ。技術スキルばかり長けていても基礎部分がそれに耐えられるスキルがなければシステムを作るどこかで崩壊してしまうのだ。

基礎スキルと技術スキルは両輪なので、両方とも育てよう。

 

Rによるテキストマイニング ―tidytextを活用したデータ分析と可視化の基礎

Rによるテキストマイニング ―tidytextを活用したデータ分析と可視化の基礎