エンジニアのキャリアデザイン・アンチパターン

タイトルにつられたんだね。実はアンチパターンというほどのものではないんだ。なぜなら、パターンになっていないからね。まぁまぁ、折角寄ってもらったのだし、もう少し話を聞いていっても良いじゃないか。

キャリアデザイン

エンジニアの仕事に就いてそのままエンジニアでいたいと思ってもエンジニアになってみると実は色々な専門職で構成されていることを知るわけですが。

希望する専門があって、それで応募して採用されて、実務も希望する専門でやっていければそれはそれでよかったね、なのですが、多くのパターンはSEとかザクッとした採用で採用されてその組織の事業に割り振られて…がほとんどですよね。

仕事なんてマネージャのアサイメントに全くもって依存しています…と思ったら多分、今後やりたいことが出てきたときにチャンスを掴めないかもね。 

アンチなキャリアデザインは、流されて使われて中程度の待遇で終わってしまうパターンだと思います。同じ仕事をするならやりたい仕事をしたいでしょうし、待遇だってやった分だけはもらいたいですよね。

キャリアのロードマップ

 専門性をもつエンジニアの仕事は細かすぎるし組織に依存するところが大きいので一歩ひいて眺めることにするとエンジニアの仕事は3つに分けられます。

エンジニア→プロのエンジニア
　　　　　＋プロマネ
　　　　　＋マネージャ

エンジニアもずっと今のポジションで良いのかと問われたら評価されてレベリングしたいと思うでしょう。給与に連動したりするので。

そこは組織でキャリアコースがあるならそれを知らないとアプローチがあべこべになってしまうので、お作法はお作法として理解しておきましょう。 

ロードマップのアンチは、組織の育成ロードマップに自分が希望するロードマップをマッピングせずに他人任せにしてしまうことです。マネージャは将来の事業を担うエンジニアかどうかをこの瞬間もしています。

アサイメント

 いくらキャリアデザインを考えても、実践がなければ実績にならずキャリアを積み上げることはできません。

アサイメントするマネージャは、実務経験あり＞なしで確実な方を選びます。育成目的があれば別でしょうけれど。

誰でも最初は未経験ですが事前に予備知識を得ることは誰にでもできることです。でもやらない人の方が多いのはキャリアデザインを具体的に考えていないからいつ、どんな準備をしておこうと考えないのでしょう。

 じゃあ、これを読んでやりたい仕事、実現したいキャリアがあるなら準備をしておきましょう。あとは、目標設定のときにどういったエンジニアになりたいか将来像を伝えてマネージャにすりこむことも忘れずに。

アンチは…キャリアデザインのロードマップを作ってもマネージャに伝えないで自分の中だけで持っていることです。伝えなければ優先してアサイメントされません。

転職

 今の仕事が向かない、組織の事業ではやりたい仕事がない。だから転職する。そういうケースは少なからずあると思います。

転職するなら準備と調査はしっかりやってくださいね。人の意見をそのまま鵜呑みにしないことです。自分で判断するように。

でも、転職する前に組織の中で組織内転職、つまり、異動でやりたいことを実現できないかを考えてみることをお勧めします。何より、社内なので給与体系は同じ（そこに不満を持っていなければ）だし、知った同僚との仕事の方が多いでしょう。

社外への転職はコミュニケーションコストと転職後の貢献プレッシャが半端なく高いです。それを踏まえた上で、社外への転職の方がメリットがあるかどうかを一度は検討してください。

ブラックやハラスメントが蔓延しているような組織なら即刻転職ですが。

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

「３びきのかわいいオオカミ」とは

セブンネットなら在庫があるらしい。 

３びきのかわいいオオカミ（セブンネット）

３びきのかわいいオオカミ

3びきのかわいいオオカミ (大型しかけえほん)

環境に流されると技術的成長が止まってしまう

もう20年くらい前のプロジェクトでのこと。ふと「このまま今の仕事をしていると二度とコードを書く機会はないのでは」と焦燥感を感じたときがあったんですね。

いえ、前に書いているとおりコードを書く技術レベルが低いのは自分がよく知っていることですけれど。それでもアサイメントされて期待されている仕事はそれなりに出来ていると思うと「今はこのままでいいかな」と心の隙を自分で作ってしまうんですよね。

そうした心の隙は自分の選択の積み重ね、自分の判断のつながりだから誰にも責任を転嫁することは無意味なのです。コードの技術レベルが低いなら自分でOSSのコードを読んだり、アルゴリズムをトレースしてみたり手を動かせばいいだけでそういうことは誰も何も言ってくれないんですよ。だって、何を感じ、何を考えているかは誰も知りようがないのですから。

プロジェクトにアサイメントされるということはそのプロジェクトやプロジェクトの中で担う役割があって何かしらエンジニアとして働く環境が構成され、その構成された環境にひどく引っ張られてエンジニアは仕事をすることになるのですが、そうした外的要因が良い面にも働くし悪い面にも作用することを経験値的に気づけることができるエンジニアもいれば、置かれた環境に順応してそのまま埋もれてしまうエンジニアも出てきます。

ここ最近、切り口を変えてTLを賑わすエンジニアの勉強のあり方は、前述したプロジェクトの環境に依存するのではないかと思うのです。何が依存するかといえば、アサイメントされて置かれる環境に馴染むことを優先し、実際慣れてしまうとその環境の居心地がそこそこであれば大方のエンジニアは環境に流されてしまうということです。

環境が新しい技術の更新を必要としなければ、エンジニアは業務上必要とされない技術は必要に迫られたときまで関心を示さないでしょうし、それは、新しい技術を必要に狭された当事者になっていないからです。

新しい開発手法に関心を示さないのは、プロジェクトの環境が開発手法を変える必要がないからです。まず最初に導入された開発手法は、外的要因、それも変えなければその存在を失ってしまうほどのインパクトがなければ変更されることはありません。製品サポートの打ち切り、ビジネスの転換などを目の前に突きつけられなければ。

結局のところ、エンジニアも一度にひとつのことしか出来ませんから、何かしらを選択しているわけですが、この環境に要求されず時間だけが過ぎていくということは、エンジニアの技術的な成長を促すにはエンジニア自身の身の上に起きるであろう災いが降りかかってくることを想像できるか否かにかかっているのだろうと思い至るのは自分の経験値的から言えることかと思うのです。

 まあ、だからいくら勉強しないとと言っても困っていないのでそれで技術的な取り組みを始めるエンジニアが少ないわけで。

そういうことがひとつの答えだとすると、ローテーションで強制的にプロジェクトを変えてしまうのは技術習得を強制するのでエンジニアの技術的成長の観点では良策なのかもしれません。

マッピングエクスペリエンス ―カスタマージャーニー、サービスブループリント、その他ダイアグラムから価値を創る

プロジェクトにおける技術的課題の進め方

こちらの記事を読みながら技術の実現性検証ってモノ作りの頭かその外でやっておかないと技術的リスクがコントロールできないんだよなと思い浮かべたり。実際、ウォーターフォールでも技術課題は（リスクコントロールするつもりなら）やるし、事業企画でも正にフィージビリティスタディするしなぁ、と。

www.ryuzee.com

なぜ技術的検証をするの

技術的検証をする理由を挙げると…

• 顧客要求が想定している適用技術で実現できるか不確か
• 論理的には実現できるが顧客環境で実現できるか不確か

などなどいくつか出てくると思います。 

 技術的検証をするのは、それをやっておかないとあとあとできませんでした、となる可能性がプロジェクトとして認識しているからです。言い換えれば、今やばそうだとわかっているのに出来るかどうかを今確かめないということは将来のプロジェクトがトラブルかもよ、ということです。

技術的検証をやらないとどうなるの

 ある技術的を適用することを想定していたとします。もし、何かの理由でその技術が適用できなくなったとしたらどうするかを考えてみましょう。

• プロジェクトを中止する
• 技術が適用できるようになるまで待つ
• 別の解決方法を検討する

プロジェクトの中止をする方が一番コストインパクトが少ないですが中止をすることで業務課題の解決を先送りするのでビジネスインパクトはホールドしたまま、となります。

技術のアップーデートを待つのは待っている間コストか掛かりますし、いつまで待てばいいのか問題も出てくるので今ひとつです。

別の解決方法を検討するのが一番世の中で取られている選択肢ではないかと思うのですが。ただ、これも想定していた適用技術と比較してコストが掛かったり、業務課題の解決に制限を設けたりする副次作用が出てくる可能性があります。検討しないとわかりませんが。

どこまで技術的検証をすればいいの

 本番環境が用意できるのであれば想定する環境を全て用意して検証すればいいです。リソースが確保できるなら検証したい項目を全部検証しましょう。

でも、現実的にはどちらもできないことの方が多いです。NWを使用した負荷テストはNWの仕様により対象にできる機器が限定されるでしょうし、当てられるバジェットも限られるでしょうから、検証項目は厳選されるでしょう。

物理的な制限とリソース的な制限下で、論理構成上の要素を確保しつつ項目を優先順位づけします。

他に気をつけることは

 技術的検証をする際に外部からの制約となる制約条件やそれに引っ張られて実施できる技術検証のスコープとゴール設定をステークホルダと合意してください。

特に、技術的検証では時間も限られるのでどこまでの検証項目を必須とするか、線引きを始める前にしておくことあとあと揉めなくて良いです。

もう一つ、技術検証自体でトラブった場合、どこまで突き詰めるかも方針としては決めておいた方が良いです。そうしないと本体のプロジェクトが引っ張られますから。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

デスマの成分が少ないです

お勉強が好きな人が多いかどうかは別にして必要に迫られてという人は少なくないと思うんですよね。御多分に漏れず規格の本を読んだりしましたし。

でも、ですね。どちらかいうと必要に迫られて読む本より読んでおこうかなという感じで書籍で勉強をしたり、会合で人と会話をすることでぼんやりと考えていたことや方向づけの裏付けとして他者の意見や経験談を教えていただいたりすることもままあります。

やはり、必要に迫られての方が切迫した締め切りなり準備期間満了だったりがあるから実戦で使う確率は多くなるのですがたまに方針転換やアプローチ変更で空振りとなったりすることもあるのですけれど。けれども、まあそれは勉強をして使うときの話なので使いかけた、手をつけた、使い損なった、と繋がっているので良いとは思うわけです。それで、勉強したけれどしただけのはどうなんだ、と。

書籍も相当売れ行きが悪いので価格が上がっていますからね、特に技術書は。

とは言え、使わないなら勉強するのは無駄だ、というつもりはないんですよ。例えばこんなノベルがあって今期アニメでやっているところもあって（まだ未視聴ですが）原作を読んでみようか、と。

デスマーチからはじまる異世界狂想曲 (単行本)

これもコミュニティのTLの中でアニメ化された「デスマから」がタイトル詐欺だ（デスマ成分が少ないという意味合いで）というコメントを見かけたら読もうと思ったんですね。

勉強というよりはどんなデスマかいなという興味とデスマ成分の割合を知りたくて読んだんです。デスマを実務では経験したくはないですし、できれば関わりたくないですし。第三者としてどんなものかと覗くくらいにしないとSAN値が削られるので。

それで読了したわけですが、292ページもあるのにデスマは5−10ページの６ページ相当です。それだけ。ガッカリです（何が）。独特の描写になれず、半ばまで読んでようやくリズムになれましたが、この異世界俺つえー系ってどうなんでしょうね。経験するたびにスキルを獲得していくあたりの構成が続巻で回収していくのでしょうけれど。

ところで、デスマの成分って何もシステム開発の専売特許ではありません。システム開発の上流であるコンサルだってありますし、スポンサーサイドの顧客側だってあります。というか、発注者側の方がデスマですね、常態的に。失敗るとキャリアが傷つきますからね。そりゃ必死です。兼務多いし。１人月を超えているのは顧客サイドなんですよね。だから、いくらシステム開発のプロジェクトで顧客レビューしたくて召喚してもキーパーソンはレアキャラだったりSSRだったりするわけです。

で、ひっくり返すんですが。

コンサルは顧客にバカですね、できていませんねというお仕事ですが、アウトプット（成果物と書かないのは準委任契約、つまり請け負える成果物を決めて見積りできるような調達仕様を顧客が書けないほどぼんやりした要件だからだけど）は契約時と変わっていることの方が多いのは顧客の中のドキュメントの書きっぷりや構成やカウンタの担当者のマネージャの趣味などで切り口を変えられるからなんですけれど。単価高いし、次もご指名いただきたいし、スポンサーの意向に合わせるのもコンサル業の仕事のうちですし。このご意向が強すぎたり後半に近づけば近づくほどデスマ成分が増えていきますね。これまでのセッションで積み上げてきたマテリアルがパーにならないようにしないといけませんし。ダメならスパッと…。

顧客サイドの企画業も企画したらそれを実現するフェーズに入りますから、ケツ持たないといけません。それをマイクロマネジメントされるわけです。企画だからなんちゃらPとかみたいなチャラい感じでやっていられるのはある意味で才能があるのだと思います。真面目なのはエンジニアの特許ではないですし、企画の人は高学歴が多いので頭切れますからね。別世界の話ですが、やっぱりそこにもデスマはあるのは前述したとおりで。とにかくやることが多いですね。見ていると不憫です…。

とここまで書いて本より現実の世界の方にデスマ要素が多いんだと気づくなど。 

デスマとオフィスラブって…。

デスマーチと銀の弾丸 (メリッサ)

デスマーチに追われるIT技術者が勉強せずに英語力を身につけてキャリアアップした方法

プロマネ現場読本 デスマーチを乗り切るために持っておくべき知識のすべて

鑑賞 バーフバリ 伝説誕生 うわ、おもしろい

インド映画と侮るなかれ。色々エフェクトもおもしろいw

バーフバリ 伝説誕生(字幕版)

バーフバリ 伝説誕生 [Blu-ray]

バーフバリ2 王の凱旋 [Blu-ray]

続けることで普遍に至るか多様な経験から普遍に至るか

エンジニア業も年数だけを数えればそこそこやっているのだけれど、中堅エンジニアに至るまでに事象から事象の本質を捉える技術が必要になる仕事が多くなってくると思っています。

事象の本質とは見えているものを含めたその裏側や中身を捉え、起きている事象を捉え直すとた方がイメージしやすくて良いかもしれません。

この本質として捉える対象は普遍であり、辞書を引けば2（イ）に当たります。

ふ‐へん【普遍】の意味
１ 全体に広く行き渡ること。例外なくすべてのものにあてはまること
「人類普遍の原理」⇔特殊。
２ 哲学の用語。
㋐宇宙や世界の全体に関していえること。
㋑特殊・個物に対して、ある範囲のすべての事物に共通する性質。 

dictionary.goo.ne.jp

この普遍に至るには2つの道があるのですがどちらで習得するかは全くもって仕事の機会に依存するのでなんとも言えませんが多くは片方に寄っているケースが多良いのがエンジニアが普遍を身につけるパターンだろうと思っています。

専門を続けることで普遍に至る

エンジニアに多いと言うか日本に多いかもしれませんね。続けることに割と美学を持っているじゃないですか。なんでも道にしてしまうので。少しは減って来たかもしれませんが年功序列なんてサラリーマン道そのものですし。

話を戻してエンジニアも続けることで専門を身につけやすい職業だと思います。そして専門を続けるからこそ経験則で得る知識が個人に属人化することで

「俺はこうして覚えた」

的な育成を対象者に丸投げするケースが多いかと。全くもって再現性がないのでどこにエンジニアリングの要素があるのかと思いますが。

それはさておき、専門を身につけることで普遍を掴む技術を身につけるということは現場を歩いていれば割と見られるのですが、じゃあそれは事象の範囲を広げたら同じようにできるかと言えばそうならないところが面白いところです。

何を言っているかというと、隣の技術エリアに入った途端持っている専門とは違いますから普遍を掴むことができなくなるんですよね。不思議ですが。

多様な経験から普遍に至る

 一方、反対に位置するのが多様な経験から普遍を捉える技術を身につけるというケースもあります。どちらかと言えば専門を突き詰めるよりは技術領域は広く間口を広げ、物事の本質、性質の中から共通項を取り出すことが出来る技術を身につけているとでもいいましょうか。

一言で言えばゼネラリストなのですけれど。

そこそこの経歴を振り返れば、製造業、金融業とセクター的に歩かされたし、アプリからインフラの経験をさせてもらったのは、普遍の観点で見返せば専門の突出がない分、普遍を身につけられる環境にあったのかもしれません。

また、PMBOKのようなフレームワークはその出自が普遍の代表のようなものですからPMBOKを学びイズムを理解できるということは多様な経験から普遍に至る典型だったのかもしれません。

個人的な考えとしては、専門から普遍に至ることはそれに至る（と思うかどうかは別として）ためには経験する事象が類似ばかりで共通項である性質に気づく訓練の機会が少ないと思うのです。

つまり、普遍に至ること自体に無理ゲーさの難易度がある、と。

その観点から思うのは属する組織の中でも業種を変えるとか普遍性のある思考的なフレームワークを嗜むことを自ら進んでいかないとどう足掻いたって向こうからやってこないのですけど。

そうすると専門から普遍に至るエンジニアは極端に減るんですよね。勝手に落ちていくというか。だってそればっかりやっていて、身につけることは類似案件ばかりで狭い範囲で気づく機会があるのかと。

そうした結果が技術を身につけること自体が道になり、エンジニアの普遍から遠ざけ、見える事象に対する対処しか技術（それを技術というのかという考え方は別にあると思うけど）としては持ち得ない、と思うのです。

全員が全員では切り替えてとは言えないのは業務ドメイン的な知識も必要でしょうが、普遍を捉える技術はやはり多様性の経験から組み合わせる選択肢を増やさないと発想自体が生まれないので多様性をいかに身の回りに置くかが普遍の技術を身につけるために大事なんだと思うんです。