潰しの効く技術よりやりたことがあると言う方がキャリアに効く

入ってはいけないIT企業ってどんなユーザ系IT企業かと思ったらどうやら違ったのはどうでもいいのだけれど、書かれていることの言葉としてはそれどうなの、と思ったところがあったので。

 

anond.hatelabo.jp

 

で、それが

数十倍潰しが効くようなサーバサイドのマイナー技術

の潰しが効くようなの箇所。ここはさぁ、と思いながらコーヒーを淹れようと思ってキッチンに立ち、鉄瓶に火を掛けたところで、企業において潰しの効く技術、潰しの効かない技術ってITの製品を使う技術じゃないんだよと思いが移ったところでさらに、潰しが効く技術をやれるやれないは職についた組織の事業によるし、幸いに潰しの効く技術を事業としてる組織に入ったとしてもその組織のどの職種(エンジニアとか社内エンジニアとか企画管理部門スタッフや営業とか)で採用されるかはまた別の問題というか入ってからの2段階目の話だな、と。母数的に外貨を稼ぐエンジニアの方が多いので確率論的にはエンジニア一択の職種だろうと思っていてもいいのだけれど、人事担当スタッフにならないという保証はどこにもないわけで。

さらにツラツラと脳内の思考を繋げていくとその潰しの効く技術をやりたいのかやりたくないのか(=別の)とかやりたいことがあるかどうかの方が大事なんだよ、と。もっち大事なことは、何をやりたいか口に出して言っているかどうかの方なんだと思うんですよね、経験値的には。

やりたいことがあると具体的に言う

多分、前に書いていると思うのだけれど2000年の少し前に入っていたプロジェクトがひどかったと思う理由に自分の技術のレベルも基礎スキル的なレベルも今から思えば程度がひどくて今の自分がそのプロマネだったとしたら、退場を言い伝えたかもしれないくらいだと思っていることはあまり話に影響しないので棚にあげるとして、どっちにしてもひどいプロジェクトだと思っていたんですよ。

不幸なことにどうやらそのプロジェクトで構築したシステムのお守りをして欲しいと打診があって、もともとヤバイぞと思っていたからさてどうしようかと。はあ、そうですかとは聞いていたかもしれないけど、それより前に異動をする際に入れ知恵してもらったことを思い出してどうやってこの退路のない状態から浅い傷のまま回避できないかを考えてこちらから伝えたのはyes,butと言う言い方で且つ期限をつけたんですね。

「1年ならやります。ただ、オープンシステム開発をやりたいのでそれで戻してください。約束してくれるならいいです。」

そのオープンシステム開発ってなんだ、って感じですが1年越えてアサインしたら暴れるとでも思ったのか、 大人しいから押し付けるつもりか誠実に仕事をやってくれると思っていたら自分の思いを持っていたんだと思ったのかは知らないし、もしかしたら別の神の手が助けてくれたのかもしれないけれど、結局は別の中堅エンジニアがアサインされてそれはそれであとが…。

自分のことだけを顧みれば、やりたいことがあると言うことを声に出して言うことの重みは言う側はもちろんのこと、それを聞いてしまった側の受け止め方にも影響を与えるのですよ。

それは自分自身がマネージャ業を続けていると適性や事業上の可能性で実現性はまたべなんだけれど、エンジニアがやりたいことがあると言ってくれると言った以上、それから逃げなることはないだろうと思うし、言葉にして受け取ってしまうと全体の育成計画を考えるときに思い出してバイアスが掛かるのです。ワタシはそう言っていたなとアサイン面や小さな機械で様子を見ますけど。

 

潰しの効く技術の話は明日にでも。

 

 

 

エンジニアの成長戦略

エンジニアの成長戦略

 

 

 

自分で考えて対処できるようにしたければ考える仕事をアサインし続けなければできるわけがない

相談は、困ったことが起きたら「自分で対応策を考えて持って来い」と言うことをカッコいいことだと勘違いしてあからさまに放言する管理職が以前より増えてきたと思うのですがそんな管理職や上司は周りにいませんかね。

まあ、勘違い管理職はいつの時代にもいたのかもしれませんが、そんな管理職の下になったら上手に手のひらの上でいい感じで転がしてどこかのタイミングでハシゴを外したいものです。

定型作業の特性とトラブル対処

知的生産性の高い業務へのシフトが言われて久しいような気がしますが、過去に経験していない事案への対処を考えると言う行為はとても難易度の高い業務だと思います。

一般的に組織の業務は、組織の規程で定められた若しくは内規としての運用ルールを定め定型作業を業務の特性であるサイクルで繰り返し行います。システム開発でも標準化や作業プロセスを定義してチームで同じように作業をするのは作業の標準化による作業品質の確保の狙いもありますが、繰り返し作業により労働集約と言う生産性の確保と言う狙いもあります。何れにしても定型作業化することが生産性の確保と確実な作業完了に繋がります。そうした定型作業では作業の仕方を覚えることが作業の熟練度を上げ作業スピードを上げるのです。

こうして行われる業務はまさに作業であり、基本的に考えて何かを作り出すと言う行為ではありませんから過去に未経験の事象が起きれば、過去に経験した類似の事例があればそれと結びづけ、対処方法を導き出すことは可能です。

でも、類似の経験があれば、です。

考える仕事も日常的に訓練しないと

 もし、普段の業務が繰り返しの定型作業しか経験したことがなければどう対処できるのでしょうか。

 

ある研修のデザインをしているときに、ワークショップ形式で演習を体験させ、未経験の事象をそのワークショップで習得させたい手法をやってもらおうということになったのですが、講師陣が集まって講座設計をしているところで、演習の体験方法に取れる時間が限られ決められたシナリオに従ってなぞるような手法のトレースになりかかっていたのでした。

その研修では手法を体験させることが狙いですが、もちろん、受講後は自ら率先して機会のあるたびに使ってもらいたいと思っていたのです。であるなら、写経をするだけでは講座の狙いは達成されない、と言うことに気づいて演習をした後にどう考えて何を習得したかを整理させる時間を確保しなければならないとして、演習時間の延長と他の説明の圧縮とその圧縮された分の補填をテキストで伝えると言うデザインの変更をしたことがあります。

話を戻して、管理職が部下に対して困っていることを自分の対処案を持ってきて相談に来いと言うなら、普段から裁量を与え、自分で対処するまで見届けるくらいのデレゲーションは勿論のこと、マイクロマネジメントはせずに日常の業務から考える業務課題を与え訓練するように業務アサインを仕向けてから物を言え、と思うのです。

 

未経験者に専門家のような対処をしろと言うのはDT=年齢のエンジニアにホストのようにもてなしことを要求するようなものです。そういった管理職は無神経に結婚しないのとか仕事に関係ないことまで土足で踏み込んできますけどね。

 

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

 

 

 

自分都合駆動型エンジニアは自分を塩漬けにする

定年が伸びると言うことは、働く期間が延びると言うことと同じです。確か社会人になった頃は55歳くらいが定年だったので今の再雇用延長で65歳と比べると10歳も働くことが長くなっています。

社外のお友達を見渡すと若くても独立したり、法人成りしたりする方や退任してからの働き方の布石を打っている方もちらほらと。みなさん、FBに書くのでなるほどなーと眺めています。

大人になって、それも大分経ってから思うことは40歳になっても50歳になっても子供のまま歳を取っているエンジニアが多いなと言うことです。男性はもちろん、女性であっても仕事に対する考え方、所作が子供なエンジニアが多いのです。

長くなる働く期間。そうか、働き方改革で1日あたりの労働時間を削減することに躍起になっているのは長期間働かせたいけれど、支出は変えたくないので縦軸の高さを減らして横軸の長さを伸ばすことで全体の面積を変えないようにしているのではないかと思いついたのだけれどどうなんだろう。

もしそうだとすると、いよいよ所謂昇格するペースが落ちていくことになることは容易く想像できるのですが。

子供のまま歳を取って中年ゾーンに入ってくるエンジニアは、得てして昇格することに対してコンプレックスを持っているのは日常的に同期などの他者と自分を比較し続けているからであり、それを続けている限りは不満は蓄積し続けるのです。

子供なままのエンジニアは対外的に活動したり、目立つために考えながら準備をしているところに気づきもせずに、スポットライトに当たっているシーンだけをみて羨みます。

そうした子供のままのエンジニアの働き方をみていると、長い時間を使い、自分がその仕事をやっていてあげていると言う言い方をすることも見逃せない事象です。やってあげていると言う考え方が自分中心の判断基準を強くし、仕事の目的に即した価値判断から自ら遠ざかっていることに気づくことはありません。

いませんか、あなたの周りに子供のままで振舞っているエンジニアが。

子供心を持っていると言う表現とは違います。心を持てるだけの余裕も余裕を作ろうと仕事のやり方を突拍子も無い方法でやってみたらどうなるかと言う発想自体が無いのです。

こうした子供のままのエンジニアは仕事に対して抜本的なやり方を変えようとする思考を持ちませんから、仕事が難しくなれば時間が掛かるようになります。その仕事も仕事の目的を達成するためにしているのではなく自分の仕事を消化するためにやっているので自分の都合で判断を変えてしまうほどロジックを持っていません。自分都合駆動型で仕事をするので報われたいと思っています。でも、他者と比較するのは評価でどうして他者が評価されているか評価基準までには至りません。

子供なままで自分を塩漬けにしているのは子供なままのエンジニア自身です。

では子供なままでないエンジニアはどのようなエンジニアなのでしょうか。それは子供を抜け出したときあとで気づきます。ああ、子供だったな、と。

 

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

 

 

30人くらいの組織でセルフマネジメントしていた話

ここ数年、ウォーターフォールでない、つまりアジャイル開発系界隈で組織的なテーマが(観測範囲では)話題となっているような気がしていて、組織化を意識するほどのビジネスボリュームが出てきた証左かなと思ったりしているわけです。

ある時期、30人くらいの組織の責任者だったとき、ビジネスの形態もあって少人数のプロジェクトチームを複数並行で動かしながら考えていたことがもしかすると参考になるかもしれないと思っているのですが、それは読み手にお任せするとして。

フラットな組織

所属する組織の制度的には多分、組織図に掲載する複数の公式なチームに分割することができました。イメージしやすくするために仮の話をすれば人数的に3チームぐらいかもしれません。 

もし3つのチームにしたらどうなるか。責任者があと2人増えることになります。組織のビジネスがそれでやっていけるならいいのですが、2人分のコストをただ増やすなんて馬鹿らしいと思ったんですね、当時は。

それで上申して1つのチームに併合したんです。確かに当時はフラットな組織が流行っていて組織のフラット化の流れがあり、部下なし課長、部長などのなんちゃって管理職という問題もありましたが、こちらとしてはフラットな組織の意思決定の速さをもしかしたら適当に理由の一つにしていたかもしれませんが、ビジネスのコストを軽くすることの方が優先順位が高かったですね。

セルフマネジメントのチーム

責任者としての管理スパンが増えるのでマイクロマネジメントなんてしようとは思いませんし物理的にしようと思ってもできません。リソースは有限なので。

そこで、プロジェクトごとのチームを作るときに実績に応じてデレゲートするわけです。こちらとしてはリソースをリスクの高そうなプロジェクトに集中したいというニーズはあるし、ベテランで任せておけるだけの信頼に値するリーダは関与しなくていいよと思っているので、関与の度合いを下げることは立場的な思いは違うけれど合意するポイントは同じなんですね。なので任せた、任せられたと言えるわけです。

でも全くのノーコントロールかといえばそんなことはしないです。こちらがきになるところはずっとモニタリングしているんです。そうですね、レポートの端に現れる雑さを見るというか。手が回っていないところはリーダの優先順位が下がっていると判断してそこだけ見ている感じです。それを意識的にリーダがしていれば受け流すし、カバー漏れならケアしておいてねーとメッセージを伝えればいいだけです。

こうして濃淡をつけることでリーダとそのチームが自律的に自主的に動ける裁量をバーンと渡してしまうことでセルフマネジメントが働くようになります。

本当のセルフマネジメントチームかといえばそうではないかもしれないですけど、本当かどうかなんて答えはないし、組織構造に現れる管理の細かさでそうしたところの良し悪しも変わってくると思います。

大事なことは、自分の頭を使って考えて行動して結果を出してもらうことです。それがエンジニアの評価につながるのですから。

 

あと、自分がいなくなったら(バスに轢かれたとか異動したとか)になったときにはよろしくね、とリーダたちにはよく言っていましたね。先も考えて、と。

 

 

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

 

 

自分に買ったのに読まれなかった本と読んだ本

おかしな話である。自分が読もうと思ったから買ったはずの本が自分に読まれないまま本棚に積まれたままになっている本がある。そんな本はある時点でより前が多い。その時点を具体的に言えば、エンジニアとしての生き方を真剣に考えたターニングポイントがそれで、その顛末はこれまでのエントリの中に書いてきた。今日は、自分のために買ったのに、買い与えた自分に読まれなかった本と読んだ本の話である。

ターニングポイント以前

まずは、ターニングポイントの前に買った本の中で読んだか未読のままかは問わず記憶に残っている本について。

読まれなかった本

基礎は大事なんだと思って買ってみたけれど、結局数ページだけページをめくってそのまま手付かずになった本の代表のようなもの。

マスタリングTCP/IP 入門編 第5版

マスタリングTCP/IP 入門編 第5版

 

 子どもが新版を買っていたが読んだのだろうか。

読んだ本

 ワインバーグと関連するシリーズ本は読み物として面白くて一時期集中的に買って読んだ。

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

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

 
ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

 

 言語の本で読んで印象に残っているのはラクダ本。2000年頃に何年もコーティングから遠ざかっていてそれでなくても覚束ないコーティングスキルが消えてしまいそうだったので、ある業務で勉強をするつもりでデータ処理にPerlを使おうと思って読んだ。一応、なんとか作りたいものはできた(バグはあったけど)再利用するものでもなかったので一部のデータは手で補正して形を整えた。 

初めてのPerl 第7版

初めてのPerl 第7版

 

 プログラミングは向いていないとやっぱり思った。

ターニングポイント後

 要は、PMPを取ろうと腹を括った後の話です。

読まれなかった本

 英語…時々読んで読みと思って買ってみるけど読まれないんだよねぇ。

 これとか。

TOEICテスト新公式問題集< Vol.6>

TOEICテスト新公式問題集< Vol.6>

 

読んだ本 

でも英語版しかなかったんだなー。当時は。10数年以上前のことだけど。資格を取ることが目的だったから、この他にも有償セミナーで良いと言われていたexamの本を何冊かPMIのストアから買って読んだり、解いたりしていた。受験料も高いので多分、それまでの人生で初めて勉強したかもしれない。それにしても大きくて重くてつらたんだった。 

A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )?Fifth Edition (ENGLISH)

A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )?Fifth Edition (ENGLISH)

 

まあ、合格してしまえば新版なんてそうそう読まないですわ。日本語でも。 

そのあとはToCとか人月の神話とか読んでいたみたいですね。あとでToCは無意識に考えていたのは先に読んで記憶にあったからかもしれません。 

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

 
人月の神話【新装版】

人月の神話【新装版】

 

 このハーバードのシリーズは絶版ぽいけど、役に立ったですね。こういった知識を持っていると現場で心理的余裕が持てる。

ハーバード・ビジネス・エッセンシャルズ〈5〉交渉力 (ハーバード・ビジネス・エッセンシャルズ 5)

ハーバード・ビジネス・エッセンシャルズ〈5〉交渉力 (ハーバード・ビジネス・エッセンシャルズ 5)

 

 自分のスキルアップを考えて足らない本は意識して読んでいたと思いますね。

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

 

一時的に盛り上がったCMMiも若干話題になっていて笑う。 

CMMI標準教本 ~プロセス統合と成果物改善の指針

CMMI標準教本 ~プロセス統合と成果物改善の指針

 

 数字に明るくないとね、と思ってこんなのは読んだな。 

【増補改訂】 財務3表一体理解法 (朝日新書)

【増補改訂】 財務3表一体理解法 (朝日新書)

 

 新任で管理職になったらいたから勉強しました。はい。 

もし部下がうつになったら (ディスカヴァー携書)

もし部下がうつになったら (ディスカヴァー携書)

 

 だいぶ飛んでこんなのとか。 

リーンソフトウェア開発と組織改革

リーンソフトウェア開発と組織改革

 
トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 

 ここ5年はまた買っている本が多くて割愛。

 

 

 

 

あなたが好きなアジャイル開発はウォーターフォールの中にある

よく知られていることだけれど、現代のソフトウェア開発の主流となったウォーターフォールの元と言われる論文が存在のですよ。 

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS Dr. Winston W. Rovce

 2つ目の図(Figure 2. Implementation steps to develop a large computer program for delivery to a customer. )がウォーターフォールと呼ばれるきっかけとなった(らしい)。

f:id:fumisan:20180102102705p:plain

 確かに漏刻に似ている感じはあるよね。

https://museum.seiko.co.jp/knowledge/type/nature/images/index_ph07.jpg

引用 セイコーミュージアム 自然の力を利用した時計 水時計

 

ただ、冒頭の論文にはwaterという言葉が1回も出て来ない。

f:id:fumisan:20180102103820p:plain

つまり、論文を書いたDr.RoVceではない後でこの論文を読んだり、引用した人の中にウォーターフォールと名付けた人がいたということだ(ろう)。

そして次の図を見せると多くのエンジニアは「え」っと擬音が漏れる。

f:id:fumisan:20180102104056p:plain

テストしてコードが要件を実現していなかったらプログラム設計を修正すればいいよと取れるし、プログラム設計がソフトウェア要件を設計できていなかったらソフトウェア要求まで戻ってソフトウェア要求の分析からやり直そうよ、ということを論文の中で言っている。

あれ、これウォーターフォールの原型の論文ですよね。でも戻っていいんですよ。元祖の論文では。

追い打ちをかける(誰にだ)ように、ソフトウェア要求の分析を前に事前プログラム設計をしたらいいじゃん、とも言っています。

 

f:id:fumisan:20180102105444p:plain

これ、フィージビリティスタディですね。本来は、予備設計だから設計を間違えないようにする目的で行うことですけれど。そういう意味では、後段の作業プロセスを試験しているようなものです。

さらに2回作業を繰り返しなさいとおっしゃっている。

f:id:fumisan:20180102110122p:plain

すっかりイテレーションに見えてきました。あれ、ウォーターフォールの元と言われている論文です。

それにテストをテストの専門家を使ってやりなさい、と。

f:id:fumisan:20180102110852p:plain

うーん、今風のテストも専門家のポジションが少し向上してきましたが、それを予言するような書きっぷりです。

最後は顧客を巻き込め、と。

f:id:fumisan:20180102111051p:plain

早いうちから顧客を巻き込んで関与させなさい、と。あれ、アジャイル開発そのものじゃないですか。

さて、ウォーターフォールとは家系図的に繋がってしまったわけです。概念的にはそうだと言ってもいいでしょう。こうしたことをつらつらと思っているだけでも人って新しいことを考えるときには今目の前にあって知っていることだけをベースの知識としてそれを変えていくんだなと思うのですよ。

ウォーターフォールアジャイル開発も単なる道具でしかありません。それを使う人に全てはかかっているのです。そのシステム開発手法、誰がやりたいのですか。それとも、システム要求にフィットする手法として選んでいますか。

 

 

The Management and the Worker (Classic Reprint)

The Management and the Worker (Classic Reprint)