老害の初期症状を患うと『苦笑』や『ニヤニヤ』するのだそうだ。どうだろう。少し思い出そうと思い最初に浮かんだシーンは会議だ。60くらいの役職の面々が並ぶ会議の場で、熱く語る若手を『苦笑』したり、乗り込んできた関連組織の物言いにお手並み拝見と『ニヤニヤ』している風景だ。 老害を患い『苦笑』や『ニヤニヤ』するのは患っている方にアドバンテージがあるからだろうか。それとも老害を患っているからこそ自身に不安を抱えているからだろうか。 自分はどちらでもないと考える。 自分の考えは、老害の初期症状を患い始めることで外部から自身の内部に新しい情報を取り入れる壁を作り始めているため、自分の経験や過去の古くなった知識だけで反応しているだけに過ぎないと言うものだ。 この考えからいえば、老害の初期症状を患い始めてもアドバンテージを持っているかは、あえて面倒臭い新しい情報がどんな馬の骨か（使えるのか）を吟味するために

引き継ぎの形態には、だいたいこの3つくらいのパターンがある。 工程が進み前工程から人員を絞り込む（要員減） プロジェクト期間中に要員が離任する（交代） 定期ローテーションによる交代（交代） 引き継ぎは1つのプロジェクトくらいの大変さがある。その上、引き継ぎを完了したと報告を受けても実際に引き継いだ要員が引き継いだ業務を引き継ぎ前と同じように行えるか確証はない。 実際のプロジェクトで引き継ぎを受ける側になったり、引き継ぎで渡す側になったりすると、これであとやれるのとかどうなるかわからんとか思いながら引き継げたことにしていた。 引き継いで渡す側の立場で思うことは、引き継ぎは無理ゲーだなと。 引き継ぎを渡す側（高いスキル）と受ける側（低いスキル）のスキルセットの違いは引き継ぎで埋められない 引き継ぐ業務の情報（リポジトリ）が多過ぎて実態は引き継げていない 完了条件の間違い 引き継げているか検証で

ちょっとした理由で年末から酒を全く飲んでいない。たかだかひと月くらいなので自慢するほどでもないことだが、飲んでいない。途中から、このまま飲まないことを願掛けという理由にしておけば、対外的な『お酒を飲まない理由』にすることができると気づいた。 通年、年末の11月から1月に掛けて変化することがある。ズバリ体重である。じわじわと11月から右上がりになっていく。1月を超えた頃にまずいと自覚してジリジリと下げる活動に入っていく。ウエストもキツくなるし、運動の負荷も掛けなければならないし、食事も気ままにしないように少しだけ気を配るのでいい気分ではない。 年明けにフィットネスジムに行き、早歩き程度で走って汗を流した後に体重を測ると年末の数字と同じで増えていない。 素晴らしい。 以前は、飲みながら料理を作り、食べながら飲んでいた。その飲みながらの部分をアルコール取り去ったわけだが、はて、これはいわゆる惰性

ベテランエンジニアにちょっと引き上げてやらないとあとあと厳しそうな中堅エンジニアや受け身の若手エンジニアの育成を頼むと大概何をしたらいいか悩み始める。こちらとしては、後進育成自体、ベテランエンジニアの仕事であると方針を出しているので後はお任せする。 マネージャは更新育成をしないのか、だって。育成の機会とコストを持つのがマネージャの役割である。あと、方向性。ベテランエンジニアでもリソースの使い方の意思決定権は職務上持ち合わせていないので、それをデレゲートすることでベテランエンジニアが将来マネージャになり、育成を推進する立場になったときの練習をしてもらう。これも育成なのである。 それで今の機会に仕込んでおかないと色々と厳しそうな中堅エンジニアや受け身の若手エンジニアの育成である。悩んているところを放置プレイするのも忍びないので週次ミーティングの最後の時間で『育成の方はどうか』と相談に乗る。 ベ

昨日の業務知識をテーマとしたエントリを書いた後、20年くらい前に『それはやばいな』と思い出した。 その前に、昨日書いた業務知識の元のエントリでは、どうやら最後に述べたことがそのエントリで言いたかったことだったようだ。端的に言えば、ユーザ業務ではなく、ユーザ業務を実現するITを含む、というものである。 20年前のことに話を戻そう。 当時、所蔵する組織のミーティングか研修か何かしらの集まりの場でエンジニアが一人前になるまでどのくらい時間が必要かというものだったと思う。 身につけるまでに10年掛かる業務知識 ある事業所では、事業会社のアプリケーションを開発しているが、一人前に育つまでに10年かかるのだという。10年掛かるのはそれだけ知識として必要となる業務が複雑で難易度も高いことが考えられる（詳しくは知らないので想定でしかないがそうでなければ辻褄が合わない）。さらに予算的な制約があり、何人もエン

昨日見かけたブログで『業務知識を持たないリーダーで大丈夫か？』という問いかけがあり、自分が携わっている事業会社のことや組織の中でのリーダの分掌とは、などをモニョモニョと考えていた。 きっかけのブログでは、組織づくりばかりしていても製品は良くならない、と戒め的なことを書かれていて、ごもっともだなぁと思う。 さて、観測の範囲（携わっている事業会社や過去の別の事業会社など）を一般論として考えると、組織構造は、現業である事業部門と本社IT部門で構成されている。もちろん、事業部門は製品開発や販売をするのでそのトップはその事業を経験されてきている方がされている。製品開発もIT投資も主体者は、事業部門であり、本社IT部門から見れば事業部門主管のIT投資は関与できない。できて予算管理だけである。こうした形態を取っている事業会社のリーダは、必然的に業務知識を身に着ける。 本社IT部門は、事業部門でのITを担

以前に比べれば、去年はそこそこメンバを褒めることができたのではないか。でも会話の中でどのくらい褒めてあげられたのだろうかと思い出してもよく思い出せない。やはり、あれこれと（やっていいかとか、確認を聞きに来ることが多いので）事務的に指示するシーンばかり思い出してしまう。それでも、それまでより去年は笑顔で褒める機会を意識し、褒めることができたはずだ。 褒めるために意識すること。 無意識に褒めようともせずに褒められるとしたら、それは素晴らしい才能である。そのような才能をお持ちなら色々と勉強させて欲しい。ごく稀にそういう人がいるのが世の中の不思議ではある。 才能のない自分なりの褒めるために意識をする。心構え的なものである。 話しかけられたら、一呼吸おく。 すぐに応えない。 感情を感じたら黙る。 褒めるのはメンバである（上長を褒めることはしない）から、基本的なハンドシェイクはメンバからである。つまり

今年、ここ数年の略歴からいくつかを掻い摘んでまとめたポートフォリオを整理して提示する機会があった。まとめたポートフォリオを提示したとき、ポートフォリオに対する価値は、それを書いた自分より、それを見て潜在的なニーズを持っている方が価値を認め易いのだと言う経験をした。 ポートフォリオを書く側としては、やってきたことをやってきたままで書いただけであるから、価値云々は意識しないで書いてしまう。 ところで、同じような経験を価値を感じる側として何度もしていたことを思い出した。メンバの年度の目標管理の評価では、設定した目標の達成に対し、ビジネス的な価値があることを認めるのがマネージャとしての仕事である。メンバはやった、達成したとしか書かないところに価値が伝わるような説明を付加させるのである。 『キミの実績はビジネスにこのように貢献しているのだから、そう書いて欲しい』と。 立場が変わると同じことをしていた

平成最後の年末年始は曜日がよく、4日を休めば29日から6日までの9日間になる。金融のエンジニアだとシステム更改などで大晦日から3日までは仕事かもしれないが。 年末年始のシステム更改でデータセンタに詰めると不自由するのが食事である。当たり前なのだが、世間様は大晦日であり、夜が明ければ年始になる。データセンタがあるような地域は地盤がしっかりしているところでそこそこの土地を占めるから郊外や地方が多い。 そうした場所だと駅に出るまでが一苦労だったり、駅前に出ても閑散としていたりする。コンビニもお正月モードで仕事をしているこちらの気分とは合わない。そんな中、気の利く人は出前ができる店を探し、配達を頼んだりする。あと、流通も2日からは動くから情報システム部などの中の人も出る人はいるだろう。 それでも多くのエンジニアは正月休みなのだろう。これまでのエントリでお薦めしているのは、3が日のうちに新年の1年分

エンジニアのイメージってどうだろう。 映画に出てくるようなステレオタイプなイメージだと太っていてピザを食べているような姿だろうか。アマゾンプライムで観れるシリコンバレーだと割とスリムなのはスタートアップが舞台だから食事が自然と節制になっているからか。 エンジニアに運動しているか、と問えば思った以上に運動をしている人がいる。マラソンをしたり、筋力をつけたり、と。まあ、思った以上に、だから母数に占める運動をしていない方の人が圧倒的に多いい。 計測範囲でいうと通っているフィットネスジムの利用者の多くは高齢者ばかりだ。それもおばあちゃんが多い。自分と同じ年齢層もいることはいるが、さらに40代、30代なんてチラホラしか見かけない。街としてはまだ新しく市報を見る限り経年で人口増なのでいわゆる高齢化しているわけではないから、子育てなどに忙しくお金のかかるジムには来ないのかもしれない。 50歳を超えてわか

多分、今所属する組織の中でOUTPUTしているの部類としてはトップかその次くらいじゃないか、と根拠もなく思っている。特に2018年はカンファレンスなどの登壇も多かったので露出の点では多分そうなのだろう。 ときどき、カンファレンスに出ているのを同僚が知るとそうした活動に関心をされるのだが、自分としてはその同僚を含め、外に出すと喜ばれるだろうコンテンツを持っているのだろうと思っているのでやろうと誘うのだが、ほぼやらない。 じゃあ、なぜやっているかという疑問を持つかもしれない。 確かに、自分はなぜやっているのだろうか。 後付けの理由はさておき、自分もこれまでいくつもの勉強会やカンファレンスに足を運び、気づきをもらってきた。その気づきはもちろん、現場で必要だったから自分から取りに行き、現場に持ち帰り試行錯誤しながら当てはめ、テーラリングを行うことで適用して現場の問題を乗り越えてきた。勉強会やカンフ

先延ばししてしまう理由は、先延ばししているタスクが大きいからだという。確かに、タスクが大きいままだと、手に余す。『うわぁ大変そうだ…ちょっと後にしておこう』ということをしているのだろう。結局、手をつけなければならなかった時点から放置されるのだから、事象としては先延ばししていることになる。 先送りしている理由は、 タスクが大きい 手の持て余していたら日が経ってしまった ということになる。 若手エンジニアに多い、なかなか進捗が出ないケースはこれなのだろうか。 自分としては、やり方を知らない（経験したことがない）から、始末のつけ方を知らないので、手がつけられないということではないかと思っている。 大きいことがタスクに手をつけることを遅らせる真因なのだろうか。タスクのサイズが問題なのか。 では大きなタスクを分解して小さなタスクにすれば良いことになる。えっと思うかもしれないが、 『大きなタスクで躊躇

業績評価ではメンバの目標設定に対する評価を行う。OKRを導入していたとしても、事業の業績連動でもなければ、結局、メンバごとに業績評価行うことになる。それは、期末になれば誰もが評価を受け、事業に貢献したと評価される個人が出てくれば、評価されないメンバも出てくる。さらにマイナス評価（翌年度給与が下がる）を一定の評価枠を設ける組織もある（外資に多い）。 これまでのエントリでは、エンジニアが目標達成するためのチート的な目標設定自体や、途中でのふりかえり、業績評価につながる成長の確認などを述べてきた。また、業績評価をする側のマネージャの役割や評価方法なども言及してきた。 では、標題のように業績評価で個人の今年の業績への貢献をプラスマイナスゼロ（＝スティ）やマイナス評価とする場合、どのように伝えれば良いのだろうか。 ステイ、マイナス評価対象を個人に伝えることはとても心苦しいものだ。マネージャとしてはこ

以前の担当のチームでは、約10年くらいマネージャをしていた。そのチームで退職したいと言って来たエンジニアは皆無だったが、自分が別のチームに移って1年経ったくらいに数名が『退職します』とわざわざ自分のところまで挨拶に来たことがあった。 そう言えば、自分がそのチームのマネージャになる前も何人か退職していた様だった。 退職はエンジニア個人の理由（そうそう、会社都合での退職はないの）で職を辞することを決める。辞めると話に来てくれたエンジニア達とは日を改めて会う機会を作り、卒業をお祝いする。 卒業を『祝う』という感覚に違和感を覚えるだろうか。 自分としては、元の部下であるメンバが組織の中での異動や組織の外へ転職をしたとき、新しい場所で活躍していると聞くことがマネージャとしての醍醐味の１つだと思っている。 そう思っているので、（自分のときにはいなかったが）転職した元メンバが新しい職場に慣れ、笑顔で話を

メンバに『これやって欲しいんだけどやれる』『はい、できますよ』なんて会話はどこの現場にもある日常風景だと思うのだが、じゃあ実際、できますよと言われて任せて置くと進まないこと、進んでいないこと。 タスクを受け取ってもらい、自分で進められる様にするためには次の項目を詰めてから手を付ける必要がある。 アウトプット（成果物）の確認 期限の確認 仕様の確認 制約事項の確認 これをしないとタスクを受け取った側として何を作ればいいのか最終形態のアウトプットをイメージできないことと、最終形態のアウトプットはイメージしたものでいいのかの確認をなんどもしなければならないので手戻りばかりになってしまう。 中堅エンジニアになれば、経験則的にこうした手をつける前に確認することを自然としているが、若手でまだ痛い目に合っていなかったり、仕事の進め方を身につけていられなかったりすると最終形態のアウトプットを言葉だけで捉え

2019年にと付けたのは、釣りである。折角なので、このまま読んで感じたことをブコメ*1でもしてくれたら嬉しい。 何故このタイトルは釣りなのかというと、2019年『に』ではなく、2019年『以前から』ずっと、エンジニアに必要なスキルであるから、だ。 このように、エンジニアに必要とされるスキルは多い。ところで、2018年のエンジニア界隈では、PMというキーワードが多かったのではないか。この『PM』はプロジェクトマネージメントやプロジェクトマネージャではなく、『プロダクトマネージャ』『プロダクトマネジメント』の方で有る。自分としては、PMはプロジェクト、PdMはプロダクトと使い分けることで同音異義語を回避したい。 さて、PMよりPdMに関わるエンジニアが多くなってきたところでその界隈のエンジニアの『基礎スキル』として必要になるスキルが『課題設定』に関するスキルである。 ウォーターフォールに代表さ

朝会はいつものとおり終わったのだが、どうも今月から参画してきたパートナのメンバの進捗がおかしい。ここ数日、実績が80％と言っている。このプロジェクトでタスクを担当するとき、進捗のステータスは、未着手か、完了しかないハズだ。朝会では、実績、予定、進捗上の障害があれば自分から申し出ることになっている。進捗上の障害かどうかの判断は、見積もり時間の半分を過ぎたとき、想定した時間で終わると見込めなかったら、その時点で誰かに声を掛けることになっている。それを守っていないことをセンパイは気づいているハズなのに。どうして見逃しているのだろう。 わたし「あの、先月から参画してきたパートナーの人の進捗、先週も80％でしたよね。何かはまっているんですか」 センパイ「いや、標準サイズだと思うけどね。プランニングポーカー的には」 わたし「どういうことですか」 センパイ「技術レベルがチームの平均以下か、甘く見られて手

どうしてもシステム開発の開発手法にアジャイル開発（のどれか）を取り入れたいと思ったとき、真正面からマネージャや周囲にアジャイル開発の手法を取りれたいと言っても拒否されるだけだ。 なぜなら、人は他者から慣れ親しんだやり方を変えられるのは嫌だからだ。その、変えたいやり方でやると毎回デスマになったとしても。 問題　導入したい手法を自分でやった経験はあるか まずは導入したい本人に経験があるかどうか。 Yesの場合、プロジェクト（チーム）でやったか。または、個人でやったか。 チームでやった場合、自分でリードできるか。リードするとは導入した手法がうまく運営するように面倒を見るということだ。その覚悟をすること。 個人でやった経験がある場合、チームでやる経験は持っていないがやりたいならやはり、手法を導入した際にはチーム全体の面倒を見ることを覚悟すること。単純に見積もって、仕事が倍になると思っておいた方が良