平成最後の年末年始は友人と互いにエンジニアとしての価値を見つけてはどうか

今年、ここ数年の略歴からいくつかを掻い摘んでまとめたポートフォリオを整理して提示する機会があった。まとめたポートフォリオを提示したとき、ポートフォリオに対する価値は、それを書いた自分より、それを見て潜在的なニーズを持っている方が価値を認め易いのだと言う経験をした。

ポートフォリオを書く側としては、やってきたことをやってきたままで書いただけであるから、価値云々は意識しないで書いてしまう。

ところで、同じような経験を価値を感じる側として何度もしていたことを思い出した。メンバの年度の目標管理の評価では、設定した目標の達成に対し、ビジネス的な価値があることを認めるのがマネージャとしての仕事である。メンバはやった、達成したとしか書かないところに価値が伝わるような説明を付加させるのである。

『キミの実績はビジネスにこのように貢献しているのだから、そう書いて欲しい』と。

立場が変わると同じことをしていた。

これは当たり前だと思ってやっているからかもしれない。もしかしたら、やっているときは初めてのことでもこれまでの経験や新しく導入した手法や方法論やツールを手探りで使いつつ結果を出しきったあと手離れしてしまい、関心が離れてしまっているからかもしれない。

価値を感じる側は、価値を必要とするビジネスニーズを持っている。経営課題や体制強化など課題を持っているし、それを解決したいと考えている。だから、その課題を解決する価値を探しているのである。組織の課題であるからそれを持たされる担当も真剣に探す。だから、解決する可能性を持つポートフォリオを真剣に探す。

エンジニアは、自分の経験である略歴、ポートフォリオの見せ方、切り口をもう少し工夫した方が良いのではないだろうか。

例えば、エンジニア自身は、プロジェクトマネージャを経験したとして、今後はマネージャを目指したいと考えたとする。そのプロジェクトはどのような課題を解決したのだろうか。インフラ基盤を更改して固定費を削減したのか、それともセキュリティを向上しビジネスへの脅威を低減させたのか、UXを改善しビジネスを拡大させたのか。

ビジネス視点でどのような課題解決をしたのかを書いた方が良い。

特に、事業をしている相手にとっては、その方が先方のニーズに訴求力を持つ。

つまり、エンジニアは一担当であったとしても、参画したプロジェクトにおいてどのような業務課題を解決するのかをプロジェクトの中で理解しなければならないのである。その上で、プロジェクトの中での役割、適用技術をどのレベルで使えるかをポートフォリオの中で要約するのである。

特にSIerのエンジニアはただアサインされたプロジェクトと次々とこなしているだけだから、略歴から価値づけるポートフォリオとしてサマライズする習慣を身につけておかなければ、言われたことを言われた通りにしかできない単価の安く、都合の良いエンジニアで終わってしまうだろう。

 エンジニアは自分の技術を高く売らなければならない。高く売るためには、必要とするニーズを持つ需要家の課題を解決するのは自分であると売込まなければならない。

今年の締め括りは、ご自分のポートフォリオをサマライズしてはどうだろうか。それをエンジニアの友人同士でやってみるのもいい。友人があなたの価値を再発見してくれるだろう。

使ってポートフォリオ

ポートフォリオで「できる自分」になる！

ブランド・ポートフォリオ戦略

年末年始こそ、薄い本でも厚い本でもいいから知識を更新しておきたい

平成最後の年末年始は曜日がよく、4日を休めば29日から6日までの9日間になる。金融のエンジニアだとシステム更改などで大晦日から3日までは仕事かもしれないが。

年末年始のシステム更改でデータセンタに詰めると不自由するのが食事である。当たり前なのだが、世間様は大晦日であり、夜が明ければ年始になる。データセンタがあるような地域は地盤がしっかりしているところでそこそこの土地を占めるから郊外や地方が多い。

そうした場所だと駅に出るまでが一苦労だったり、駅前に出ても閑散としていたりする。コンビニもお正月モードで仕事をしているこちらの気分とは合わない。そんな中、気の利く人は出前ができる店を探し、配達を頼んだりする。あと、流通も2日からは動くから情報システム部などの中の人も出る人はいるだろう。

それでも多くのエンジニアは正月休みなのだろう。これまでのエントリでお薦めしているのは、3が日のうちに新年の1年分の自分の育成計画を立てておくというものだ。マネージャであれば、メンバ全員分の育成計画のアウトラインを決めておくのが望ましい。酒を飲み、駅伝を見ているくらいなら、それを終えてからでも十分追いつける（駅伝だけに）。

全体に占める2割くらいのエンジニアにあなたがいるとするならば、何か新しい技術やこれまで忙してく手を出せなかった言語やAWSなどのクラウドを使い、手を動かすだろう。7日から年度末を控え、また忙しくなればまとまった時間を取るのは難しいと知っているからだ。

そこで1つ提案がある。読書スピードに依存するが、その技術への興味をプロジェクトマネジメントかチームビルディングに振り分けて欲しい。基礎の『キ』の字の部分だけで良い。ほんの先っちょだけ、で良い。

これまでプロジェクトマネジメントもチームビルディングもあまり関心がなかったかもしれない。確かに、プロジェクトマネジメントとタイトルがつく本には硬いものが多いし、読んでいても面白くない。チームビルディングも同じだし、リーダーシップも内容は、マネジメントやリーダー、あってサーバントリーダーシップが精々であるから、避けてしまうのも仕方がない。

これまでなら。

最近、商業誌でない分野のいわゆる薄い本の界隈にエンジニア向けのものが増えているようだ。そうした中にもプロジェクトマネジメント を扱ったものやチームビルディングを扱ったものがあるという。

どこから手をつけようと全く構わない。薄くても厚くてもいい。この年末年始に、プロジェクトマネジメントやチームビルディングの知識やプラクティスを取り込んでおき、新年に試して欲しいのである。

新年は平常に戻るまで、数日のプリヒートに時間がかかる。そこで試し始めると周りも正月明けでニュートラルに戻っているので感覚が掴みやすいのである。よく言えば、失敗しても正月明けだから、と躱せるのである。

2人から100人でもできる！ 15分でチームワークを高めるゲーム39

いつかリーダーになる君たちへ　東大人気講義チームビルディングのレッスン

SIerのマネージャとして機能するために

SIerのマネージャは、所謂、従来のマネジメントの役割をロールとして担わされている。従来のマネジメントの役割とは、分掌するビジネス領域をキャリーし、部下へ指揮命令を行うことである。分掌自体は組織の役割分担で決まるからビジネス上のスコープ（業種業界、ソリューションなど）は固定である。

部下への指揮命令は、アサイメント、プログラム・プロジェクトマネジメント（マネジメントとして）、育成、その他多岐にわたるため、そのマネージャが優先する業務に傾斜が掛かる。

担当ビジネスにおけるプロジェクトにフォーカスすると、プロジェクトの見積もり、契約に関わる（マネジメントとしてその案件をやるかやらないかの意思決定）。GOをかければチーム編成にも関わり、プロジェクトチームのプロジェクトマネジメントのモニタリングを開始する。

モニタリングを開始し、プロジェクトの進捗が滞るとか進捗上の障害が発生するとプロジェクトチームに口を出し始める。

程度の違いやマネジメントの関心事に依る優先順位で濃淡はあるにしても、こういうことをやってきたはずであるし、やっているはずである。

観測範囲で言えば、モニタリングをろくにせず、問題の火を消せなくなってしまってから口先介入をするようになり、問題の根本解決には至らないリソースの暫時追加や介入によるオーバーヘッドを余計に作っているように見える。

全くもって阿呆らしい。

問題になるのは、プロジェクトチームとして満たさなければならないスキルセットとレベルをマネージャが見切れていないでGOを出すことであるし、条件付きでGOするならモニタリングの閾値を下げ、感度を上げておかなければならないはずである。

根本は、案件のリスク識別が根っこにあり、それを識別できないからプロジェクトとして必要な、でも過剰でないプロジェクトのスキルセットを構成できない。

どうして出来ないのか。

これを端的に『不確実性が高まっているから』で片付けてしまうと先に進まない。出来ないマネージャは、ビジネスとしてやると判断する案件を『自分がやる』つもりで見ていないからではないか。誰か（部下）にやらせるから、細いところは部下にやればいい。そこにリスクを識別する機会を自ら失っているのではないだろうか。

『マネージャは忙しい』『それもやるのが部下の仕事だ』と思ったら、それはマネージャの仕事を増やしているだけだと理解すべきだ。マネージャのリソースが問題であるのなら、組織の役割を見直さなけばマネージャは仕事をしていないことにもなる。

その解決方法が、PO（Product Owner）、SM（Scrum Master）、EM（Engineering Manager）という役割分担なのではないか。

そうだとすると、従来のマネージャはそうしたいくつもの仕事を一人でこなしてきたということだ。なぜ今では複数の人に割り振っている仕事を出来ていたのか。多分に、それまでの経験知で対応できる反復型のビジネスであったからなのだろう。ほとんど同じように繰り返される案件だから、脊髄反射的に対応してもなんとかなってきたのではないか。ところが、今は案件ごとの性質にバラツキが大きく、組み合わせるパーツがそれこそ型にはまらなくなっている。だから、部下に『やって』『やりました』と行かなくなったのだろう。

マネージャなのだから、自身が担当するビジネスの中では規程で制限されていなければ、内部の組織デザインは裁量で可能である。であるから、ビジネスの実現方法も（結果が伴えば）フリーハンドである。

マネージャのリソースが足らず、ビジネスの案件の不確実性が高いと認識する（できる）のであれば、組織内のデザインを速やかに変えなければならない。

それが組織を機能させることであり、生き残る戦略なのである。なお、配下のことなので、成功してから組織内へ成功事例としてアピールすれば良く、わざわざマネージャ自身で成功のハードルを上げる必要はない。

FGO手帳2019.4-2020.3

フレディ・マーキュリー~孤独な道化~

メンバとマネージャの距離を詰める

 みなさんの立場からみたら50歳を超えたマネージャはどうか感じるだろうか。みなさんが30歳前後だとすると20歳も年が離れているのでご両親に近い年齢と思うかもしれないし、（たまたま仕事場での上司だから見知っているが知らなければ）怖そうなおじさんと思うかもしれない（イケメン設定ではないので）。50にもなれば、顔にシワもシミもあるおじさんであることには変わりない。自分が新人エンジニアとして入社した頃の課長は40代のヒゲのおじさんだったし、その上の次長は50近かったのではないか。何にしろ、遠い存在だった。

遠く感じたのは、年齢差だけだったかと思い返せば、そうではない。いわゆる管理職は現場にいなかったのだった。話すのは年に1回あるかどうか。次長、部長なんて話す機会もなかった。そう、物理的な距離も離れていた。

幸い、今のチームとは同じ場所で働いているので前述の距離感の感覚は自分は感じない。それでも、メンバにとってはマネージャは意思決定をする人、評価をする人であることは自分が新人エンジニアであった頃と変わらないから、そうした役割に紐付く権限は変わらないから、メンバにとってはその辺りは気にするのかもしれない。

脱線するが、話す相手を受け入れているのであれば、尊重をした上で行動をとっているのであろうから、全く持って気にならない。そこから外れれば、一言言わなければならない。ハラスメントもその予兆があるものだと思っているので、どこからがダメとマネージャが思っているかははっきりと示さなければ伝わらないのである。

さて、メンバとマネージャの距離を詰めるにはどうしたらいいか。ロールに紐付く距離感は相手が感じるものではあるのだが。

例えば、ミーティングで議論をしたり、アイデア出しをするときに、メンバと同じ立場で参加する。これはマネージャは10票、メンバは一人1票のような物言いをしないということである。アイデアを出す権限だけ1票もらうことにして、アイデアを出し合う。さらに意思決定はチームに委ねる。チームの意思決定の方向性が明後日の方向でなければ、進めてもらう。

先日も来年のテーマのアプローチをチームで検討していたとき、1つのアイデアを出した。バズワードとテーマの組み合わせであったから技術的な裏付けは取れていなかった。ただ、感覚的にできるだろうという根拠のない確信だけは持ち合わせていたのだが。

そうした変なものを足す発想はエンジニアは普通しないものである。なぜなら、経験か知識として持っている机上でも裏付けがあるものからでしか考えないからである。そこに変なことを言い出して実現可能性を技術的に優れているメンバに揉んでもらうのである。マネージャの立場としては、専門外は仕組みは理解できたとしても実装までの勘所を持ち合わせていないことの方が多い。そうしたそれぞれの専門性を活かすことでマネージャからメンバと距離感を詰めていくのである。

まあ、どう距離を感じているかはわからないが。

 さて、大掃除と仕事おサメ。

INTERIOR COMPANY (インテリア カンパニー) スリッパ・ルームシューズ グレー 幅11×奥行27×高さ10cm、適応サイズ/約23~24cm

エンジニアと運動の続け方

エンジニアのイメージってどうだろう。

映画に出てくるようなステレオタイプなイメージだと太っていてピザを食べているような姿だろうか。アマゾンプライムで観れるシリコンバレーだと割とスリムなのはスタートアップが舞台だから食事が自然と節制になっているからか。

エンジニアに運動しているか、と問えば思った以上に運動をしている人がいる。マラソンをしたり、筋力をつけたり、と。まあ、思った以上に、だから母数に占める運動をしていない方の人が圧倒的に多いい。

計測範囲でいうと通っているフィットネスジムの利用者の多くは高齢者ばかりだ。それもおばあちゃんが多い。自分と同じ年齢層もいることはいるが、さらに40代、30代なんてチラホラしか見かけない。街としてはまだ新しく市報を見る限り経年で人口増なのでいわゆる高齢化しているわけではないから、子育てなどに忙しくお金のかかるジムには来ないのかもしれない。

50歳を超えてわかることに、体力は落ちる。運動をしなければ身体の柔軟性はなくなるし、ちょっと運動をサボっただけで、階段を駆け上がれば息が切れる。それより先に脹脛を痛めるかもしれない。

今通っているフィットネスジムに入会したときにインストラクタに言われたのは、2回/週通わないと身体は変わらない。つまり、1回/週だと維持するくらいなのだという。効果的なのは、運動をした日から次の日の間を数日インターバルを持つことらしく、そうすると平日に1回通わなければない。数回やってみたが、ちょっとしんどくて結局週一に落ち着いている。

そんなこんなで10年くらいは通っている。

運動したくなる動機。

自分は仕事着も普段着も自分で選び、買う。当たり前じゃないかと思うかもしれないが、そうすると自分の身体のサイズを知っているのは自分である。もちろん、体重も知っている。食事の量や飲酒が多ければ無条件で太る。太ればジーパンはキツくなり、より大きなサイズを買わなければならない。つまり、サイズの意味での体調の変化は自分が一番よく知る立場にある。

ファッションも購買層が多いサイズにより多く種類を出すから、サイズが大きくなると選べる衣料が減ってしまう。何事も選べるということは大事なのである。その意味合いで、着たい服を着られるように体型を維持するとか少しだけ痩せたいと思うのは当然なのだ。

自分の場合は、たまたまフィットネスジムに通っている同僚が身体を動かすことは楽しいと言っていたので、そうかと思って通い始めたのがきっかけだった。それを習慣化できたことがよかったのかもしれない。

レッスンのクラスに入ってみたり、変えてみたり。トレッドミルで走ってみたり、マシンで筋肉を動かしてみたり。

結局、トレッドミルで軽く流して走るだけに落ち着いている。空いていればフリーウエイトをすることもあるが、まれ。

行く曜日と時間を決めて、それで動く。ただ、週末は色々とイベントが入ることもあるのでそうしたときは、スキップするが習慣化しているので次回に行く。そのくらいにしておくと続けられる。

働いているうちは、週一でも続けて行きたい。

タニタ 体重 体組成計 日本製 BC-705N WH 自動認識機能付き/測定者をピタリと当てる

OUTPUTとは知の連鎖を担うことである

多分、今所属する組織の中でOUTPUTしているの部類としてはトップかその次くらいじゃないか、と根拠もなく思っている。特に2018年はカンファレンスなどの登壇も多かったので露出の点では多分そうなのだろう。

ときどき、カンファレンスに出ているのを同僚が知るとそうした活動に関心をされるのだが、自分としてはその同僚を含め、外に出すと喜ばれるだろうコンテンツを持っているのだろうと思っているのでやろうと誘うのだが、ほぼやらない。

じゃあ、なぜやっているかという疑問を持つかもしれない。

確かに、自分はなぜやっているのだろうか。

後付けの理由はさておき、自分もこれまでいくつもの勉強会やカンファレンスに足を運び、気づきをもらってきた。その気づきはもちろん、現場で必要だったから自分から取りに行き、現場に持ち帰り試行錯誤しながら当てはめ、テーラリングを行うことで適用して現場の問題を乗り越えてきた。勉強会やカンファレンスの登壇者にはビールの１杯でも奢りたい感謝の気持ちでいっぱいである。

その気持ちをフィードバックできればいいのだが、気づきを現場で活かすまでの時間があり、ズレが生じる。そのうち、どこで気づいたかもあやふやになる。ただ、現場の問題は解決している。

現場の問題が解決したのだからいいじゃないかと思うかもしれないが、感謝の気持ちはどこへ行けばいいのだろうか。感謝の気持ちを知ったとしても、伝える先がわからないのだから間抜けな話ではある。

自分でできることは何か。

もしかすると、自分の経験を形式知として共有することで何処かの誰かが自分と同じように気づきを得られて、現場の問題を解決できるかもしれない。

エンジニアを10年もやっていればそれ相応に経験を積んでいる。各自の中で経験知が温められている。そうした知は知っている人だけが使える。各々が持っている知を自分だけで使えば、その人の仕事はそれなりに結果を出すことができるだろう。

でも、その人だけしか使わないのだから、価値はその人が仕事をうまくできるということだけの価値しか産まない。もし、その人が持ち合わせている経験知を誰かに伝え、気づきを得た誰かが問題を解決できると新しい価値を産む。

それをやろうと思ったのである。

まあ、やってから書いているのでこれも後付けの理由なのだろう。

日々書きたいことを書く環境を持てるということは何と素晴らしいことだと思う。さて、こんな理由でOUTPUTしているので、聞いてみたいこと、相談してみたいことがあったらブコメか、ツイッターか、質問箱で気軽に聞いてみてほしい。経験していることなら答えられるかもしれない。

ちびしかくちゃん 2 (りぼんマスコットコミックス)

30年前の新人エンジニアのときに知っておきたかったこと

平成に社会人になったので、平成時代＝エンジニア歴となる。まだ悠々自適なリタイヤ生活には入れない（多分、動けるうちはずっと働くのだろう）のでエンジニア歴の方が長くなりそうである。

それで、30年前の平成に入った年に新人エンジニアとして一歩を踏み出したのだが、何にせよ無知すぎた。多分、あなたが自分に対して持っているイメージより桁違いに自分は物知らずで、不勉強の負債を抱えていたのだ。その上、身近なところに組織で働く際のイロハを語る人も居らず、若さゆえの持つ知識の少なさによる固執した考え方を持っていた。あと、他人が言うことのその言葉の裏側を深く知ろうとしなかったり、予言めいたことに対して感覚だけで気づかないふりをしていた。

人は知識を得れば得るほど謙虚になる。それの真逆であった。

仕事の仕方について。30年前に知りたかったことはたくさんあるし、早く改めておけば良かったこともたくさんあった。

30年前に知りたかったことを書き並べてみる。

1. 学び方の学び方
2. 習慣の作り方
3. 時間の使い方
4. 組織のキャリアパス
5. キャリアへのアプローチ方法
6. メンタルモデルの必要性を知る
7. 3年後、5年後のマイルストーンの必要性
8. １年後を意識した課題設定
9. プロ意識
10. タイムボックスで仕事をする
11. 仕事以外での自己研鑽の価値
12. 自身の理解度の検証方法
13. 成果の見せ方
14. メンターを探す
15. お金と少しの法律知識

今の時代なら、それこそブログで知を共有する仕組みがあるので、こうしたテーマを認識さえすれば、容易に情報を集めることができる。30年前は多くの本を読む（ここは今も変わらない）か、知人の話を聞くくらいしか方法がなかった。

共通しているのは、後になって早く知っておきたかったことは何かということである。知らないのだから気づきも認識もない。そうなると早くどこのタイミングで視界に入れ、引っ掛かりを見つけるかどうかというレベルの話になってしまう。

結局は、トップにあげた『学び方の学び方』をどれだけ早いうちに身につけているかということである。優秀な人たちは、これは学生のうちに身につけているものだが。

学びを結果に変えるアウトプット大全 (Sanctuary books)