マネージャは50代になったら現場に戻そう

ずっと前から思っているし、結果的に自分もそれをしているのでそうした方がいいと思うことに、

「マネージャは50代になったら現場に戻せ」

という考え方だ。

なぜ、そうしたことを思っているかというと、マネジメント、中間管理職が硬直化するからだ。

所属する組織のマネージャの顔を思い出してみよう。ずっと同じ顔ぶれではないか。マネージャも1年過ぎれば1歳年寄りになる。顔ぶれが変わらなければ、ずっと古い成功体験だけを引きずり、古い価値観だけで意思決定を続けるのだ。

デメリットはそれだけではない。マネジメントの次世代が育たないのだ。50代のマネジメントの空き席が出来なければ、一切更新されないし、空きができてもプレミアチケットのようなものだ。そしてその席も暫くは空かない。

現場に戻すマネージャになにもプログラムを書けとまでは言わない。大規模プロジェクトの支援役（という名のアドバイザでも顧問でも助言者でもいい）や、複数のプロジェクトのプログラムマネジメントでもいい。もちろん、プログラムを書いてもいい。

もし、50代で今更現場なんてと思うようなマネージャが上司だとして、現場に戻れないというマネージャの下でエンジニアが働こうと思うのだろうか。

いや、若しかしたら50代になって現場に戻られると嫌な方はエンジニア側なのかもしれないが。

スーパーエンジニアへの道―技術リーダーシップの人間学

計画を立てないという負債

何事もことを成すには『計画づくりが大事だよ』ということについて反論する人はいないはずだ。殊更、エンジニアがプロジェクトを立ち上げ、プロダクションシステムなり、Webサービスなり、APIなりをリリースするなら当然である。

ところが実際はどうか。

ひどい話になると計画をろくすっぽ立てなかったり、それを計画と呼べるのかという程度の自称計画がまかり通っているのが現状ではないか。

だいたいそういった計画とは呼びたくもない計画を作っているエンジニアは計画を作らない理由ばかりを並べる。ひどいエンジニアになると

「アジャイル開発なんですよ」

などとアジャイルを知っているエンジニアからマサカリが雨あられの様に投げ込まれても文句を言えない様なことをいう始末だ。

計画を作らないことは負債を作り込むということを理解すべきだ。

計画を作るということは、ガントチャートやWBSを作るという様な、見た目の話ではない。

計画を立てるとということは、計画を実行するまでに次の3点をしなければならない。

1. 情報収集
2. 分析
3. 準備

情報収集は、自らのことに関すること、他のことに関することについてデータを集めることを言う。分析は、それらを定量的な情報として分解する。準備は、計画として組み合わせる。ここまで出来て初めて実行に移せる。もう少し、噛み砕くと次の5項目があげられる。

1. 目的（ゴール）を明確にすること
2. チームの実力（as isのスキルセット）を客観的に把握すること
3. 影響を与える外部の因子（ステークホルダ）を明らかにすること
4. 客観的で定量的な情報（諸元）を収集すること
5. to beのスキルセットへ教育すること

逆に言えば、計画を作らないということは、次の様に言い換えることができる。

1. 目的がモヤっとしている
2. 誰が何をできるか誰も知らない
3. 自チームの独りよがりで考える
4. こうなるだろうと勝手に期待だけする
5. チームが頑張ってくれる

 一番いけないことは、計画を作る立場のエンジニアが自分ではない別の誰かがいい様にしてくれると言う根拠のない期待を抱くことだ。

計画を立てない負債の根源の全てはこの考えが根っこにある。

人を使い、自分で足を運び、情報を収集し、その情報の確からしさを確かめなければならない。

なぜなら、計画は仮説でしかないからだ。

計画が仮説だと認識できれば、計画は1つだけではありえないことに気づく。情報の分析で分解するのは組み合わせ、ケースを知るためでもある。

骨格となる軸は、様々なパラメータを動かしても計画の本質は変わることがない。ただ、状況の変化で対応を変えられる柔軟性を持ち合わせられる。

こうしたことを考え、チームが実行できる様に準備をするのが計画を作ると言う行為なのであれば、それをやらないのは最初から、自らハンディキャップを負うと宣言する様なものだ。

[まとめ買い] あそびあそばせ

あそびあそばせ 7巻 アニメDVD付き限定版 (ヤングアニマルコミックス)

調達 ヒカリ (Hikari) 咲ひかり金魚 育成用

ヒカリ (Hikari) 咲ひかり金魚 育成用 沈下 1kg

若手エンジニアが成長に必要なもの

自分のことで話をするとプログラミングのスキルが必要だった。本当にセンスはないし、本を読んでも頭に入ってこなかった。

多分、もっと写経をした方が良かったんだろう。

不思議なことに、得意と思っている若しくは苦手意識のないことは本を読んでも理解できるし「自分が今参画しているプロジェクトを当てはめるとこんな風になるな」と妄想も自然と出来る。

全くもって不思議だ。

よく、スキルをレーダーチャートにプロットして得手不得手を可視化して見せられることがある。直感的に表でスキルを○や×で列挙されるよりレーダーチャートのグラフを見る方が『わかった』気にさせられる。

実際には、得られる情報量も質も同じなのだが。

目標管理の中でメンバの目標を設定させるときに意識的にしているのは、メンバ自身がなりたい将来像（それ自体あまり考える機会がないので都度の思いつきか前年の継承なのだろうが）になるために必要なスキルの項目を自分自身で選ばせている。

ここは一切、口出しをしない。

なぜなら、彼彼女の人生だからである。彼彼女のエンジニアとしてのリソースを使うのだから、自分で悩んで決め、試行錯誤しながらピボットを続けて欲しい。

そう思っているし、そうするようにしているので、どのスキルを伸ばすか設定するときには得手不得手のどれを選ぼうと構わない。

得意なスキルを楽しみながらさらに伸ばすのか、不得手なスキルを無理して引き上げるのかは、好きにしたらいい。

どっちだったかと言えば、自分は結果的に得手を伸ばしてきたのだろう。そうすることで余裕が出来たからか、得手とは違う、でも関心を持ったスキルや、次のロールを担うために必要だと思ったスキルを身につける準備をしてきたのだから。

そこに置いてきぼりとなったのはプログラミングだ。これは相変わらず野ざらしにされたままだ。

ただ、60歳くらいになったらもう少し時間ができるだろうから、そのときにでもやろうと思っている。そのときの流行りの言語で「Hello World!」をしているかもしれない。

そうなったら、それはそれで面白い風景かもしれない。

Webプログラミングが面白いほどわかる本　環境構築からWebサービスの作成まで、はじめからていねいに

仕事に行き詰まったときのハックの仕方

仕事をしていると、ざっくりと2つの種類の仕事があることに気づくと思う。1つは定型化された業務である。例えば、経費処理や勤務実績申請などだ。組織に属しているならば誰でも同じて手続きを行わなければならない。他には、プロジェクトなどでも同じような定型化された業務は存在する。進捗報告はその1つだ。決まったフォーマットもしくは分類に従い、求められる情報をスナップショット的に切り取り、情況を報告する。

2種類目の仕事は、非定型の仕事だ。一度きりの仕事である。企画を起こしたり、一品ものの資料を作る、などがある。

2種類目の仕事を『非定型の仕事』とした途端、1種類目の仕事は途端に増える。例えばシステム開発のプロジェクトで非定型の仕事は実はそれほどない。文書を書く作業は基本的に、全ての工程を通して同じ手続きを踏む。文書のネタ＝インプットを集め、集めた情報をもとに仕様を検討　→　文書としてアウトプット　→　文書の品質を検査するフロートなる。モデルにするとこんな感じだ。

情報を収集　→　情況を判断　→　仮説　→　検証

モデルにしてしまうとわかるが、どの工程の、どんな文書の種類でも同じフローである。違うのは文書の中身、コンテンツだけだ。

では、コードを書くフローはどうかというと、同じフローであることがわかる。

情報を収集　→　ロジックを判断　→　コーディング　→　検証

文書作成の仮説は執筆だし、コードはコーディングである。コードを書くことの検証はテストだ。

仮説で文書を書いているときに仕事に行き詰まった感を感じたら、情況を判断する＝文書で具体的に何を書くと仮に決めたことの仮のレベルが仮説で執筆する際に必要な情報の粒度になっていないことを疑うと良い。

さらに言えば、情報として収集した情報の粒度にバラツキがあり、その粒度の違いが情況を判断する際に判断するポイントを誤った判断をさせたり、脳内でそのギャップを解消するために時間を余計に取られたりした結果、仮説で破綻していることが判明して手戻りや無理に突破しようして行き詰まってしまう。

リズムの違う楽器の演奏をいきなり合わせて不協和音になるようなものだ。

定型化された業務は、金銭の処理であれば最終的に勘定科目で仕分けされ、会計処理するためのインプットになるため、最初から情報の粒度が揃えられている。非定型の業務も同じように粒度を決めておけばリズムが揃う。リズムが揃えばあとは作業を片付けるだけになる。片付ければ良いようになれば、どれだけ気が進まなくても1つ片付けることで1つ進捗する。

1つ片付けたら、片付いた事実を見返そう。「行き詰まっていた仕事が1つ片付いたオレすげー」と労おう。それを2つ目、3つ目を繰り返すとテンポが出てくる。 

まあ、「3つだけ終わらそう」と決めて片付け始めるのがいいのだが、揃えてテンポを作る下地はやっておこう。

ハッカーの学校 IoTハッキングの教科書

「読める！読めるぞ！！」

字下げは4文字スペース派か…。 

スラスラ読める Pythonふりがなプログラミング (ふりがなプログラミングシリーズ)

組織の冠を外したとき、自分を『高く』売れるか

これまで自分の転職に対するポジショントークをするのであれば、会社を変える転職は最終手段（ブラックは別）で、まずは組織の中での組織内転職、それもエンジニア（例　アプリ）→エンジニア（例　インフラ）で仕事を変えるということと仕事を変えた後の自分自身の環境変化への順応性の閾値や関係性の構築能力を知るのが良いとエントリでも書いてきた。

一方、いつでも所蔵する組織の冠を外して、市場で『高く』売れるエンジニアであり続ける必要があることも主張してきた。

なぜ、組織を跨る転職は進めないのに、所属する組織の冠を外しても売れるエンジニアでなければならないと言うか、その背景を簡単に書いておこう。

入社した組織が合併や資本参加などがあり、所属する組織は自分の意思とは別のところで変わっていくのだ、と言うことを学んだ。企業価値を高めるために経営者が事業をあれこれするのは当たり前であるのだが。

もう一つは、バブル崩壊を読めずに採用した結果、赤字転落で希望退職を募った経緯があり、やはり、自分ではなんともし難いところで組織は動いていると言うことを学んだからである。

これらのことから学んだことは、組織は組織の都合で変わっていくので「自分を預けてはいけない』と言うことである。

言い換えれば、（組織に属するが）組織をあてにしていると痛い目にあうリスクをエンジニア自身がホールドすることになる、と言うことだ。

そうしたリスクがあるのだから、エンジニアは所属する組織の冠が組織の都合で外れたとき、市場で自分を『高く』売る技術を持っていなければ、全く売れないか、叩き売られる状態になることを予見しなければならない。

なんだか矛盾していると感じたらそれはそれで正しい。転職するくらいなら組織の中でにしておけ。一方、組織なんていつ無くなるのかわからないのだから、いつでも市場で評価されるようにしておけと言っているのだから。

ところで、ここ最近、少しだけこれまでの主張を変えようと考えに至るようになった。マネージャの経験をそこそこ積んできたところで、開発部門のエンジニアの育成や事業を新しい場所でやってみたいと思うようになった。ベンチャーで数十人のエンジニアの規模になると、エンジニアのキャリアとビジネスを両輪としてマネジメントする必要が出てくる。そうしたオファーがあれば、そういった機会でこれまで経験した知見を出し惜しみすることなく、活かしてみたいと思うようになった。

まあ、自分の年次が進まなければ経験していないことがわかるから、そういったこともあるのかもしれない。いづれにしろ、自分の考えを柔軟にすることにした。

ただ、上述している組織内での転職や市場でいつでも『高く」売れるエンジニアであり続けることの主張は引き続き変えない。変えるのはいい感じに経験を重ねたマネージャをそのまま組織の中で滞留させるより、必要とされる組織外で活かす選択肢を持つことが、価値があると思っているからだ。

まあ、それも市場としてニーズがあればである。

「死ぬくらいなら会社辞めれば」ができない理由（ワケ）