システムエンジニア５０歳限界説
システムエンジニア３５歳定年説はあまりにも有名ですが、じゃあ、本当のところはどうなんだろう、と。
ワタシ個人の見解としては、システムエンジニア３５歳定年説は３５歳になったらプロジェクトマネージャやマネージャにキャリアパスを変えていく年齢だから現場から離れていくということを間接的に言っているのではないか、と思うのです。
たが、現実的には組織が大きくなってもキャリアパスを変える、変えられるシステムエンジニアは限られているためにシステムエンジニアは３５歳を過ぎても現場の第一線で奮闘する他ないのだと思うのです。
なぜキャリアパスを変えられるシステムエンジニアが限られるかといえば、他の業種と同じように組織化され、組織の規模に応じたポスト＝役席しか設けられないからであるのが一つ。もう一つは、システムエンジニア自身が皆同じようにキャリアパスを変えていくことを望まないためです。
若いシステムエンジニアは４０代、５０代のプロジェクトマネージャやマネージャに対して、年齢を重ねると経験値も相応に増え、できることも経験とともに増えていくように見えているかもしれません。
ところが、実際にはその真逆を進んでいることは誰もそれを公表しませんし、場合によっては当事者が気づいていないケースもあるのです。
なぜ、年齢を重ねて経験値が増えているはずの４０代、５０代のプロジェクトマネージャやマネージャができることが増えないか。
それはプロジェクトマネージャであったとしても、実務から遠ざかり、手を動かさななくなるからです。実際に設計書やコードを書くのは担当のシステムエンジニアやアーキテクトです。
キャリアパスが示すように、PMBOKで示される適切なスキルを人的リソースとして調達し、計画にアサインして進捗させるプロジェクトマネジメントの専門家として振る舞うことをすればするほど現場で手を動かす経験から遠ざかるのです。
ましてやマネージャになれば、組織を守るための交渉が仕事の大半になるのでいよいよ現場とは距離が離れる一方になるわけです。
なんか、システムエンジニアも企業経営の組織論からいえば、普通の企業と変わらないんだ、ということです。やっている業種がITなだけなんだ、と。
じゃあどうしたら良いかといえば、５０歳にもう一度現場に戻れるように学習し続けることが必要だ、ということです。
あったりまえなことなのかもしれませんけど。
当たり前に思えても４０代、５０代になるといくらその気概があっても、できることが加齢とともに減っていくことを知っておかなければいけません。これはもう、退化すると捉えた方が良いかもしれません。
体力や身体機能が経験疲労でガタが来るのに定期メンテナンスでアッセンブリー交換ができないからです。セキュリティパッチもバージョンアップもできない。
しかし、知識や技術習得はスローダウンしつつも継続することで維持をすることはできます。この場合の維持は持っている経験から自身ができることを守るのではなくて、世の中のITの世界で自分を高く売るための技術を提供することができることを指しています。
そのための維持には相応の時間と継続的な活動が自分の意思として求められるのです。平日早朝夜間、週末の時間をどう使うかで５０歳以降のシステムエンジニアとして自分を高く売り、相応の対価を得られるかがそこにかかっているのです。
キャリアパスでマネージャになって１年もすれば技術よりだったシステムエンジニアなら不安になるのは自分の技術を維持する時間が削がれ、組織の対応しかできる時間が業務時間内では取れなくなってしまうためです。
その上、キャリアパスを進もうとしても役席の数は次第に絞られるし、社内政治を強いられれば技術からさらに遠ざかってしまう。
気づいたら、５０歳です。
その年齢を迎えてシステムエンジニアとして何ができるのか。
そして、組織人事上マネージャを外されたとき、何ができるシステムエンジニアかを問われると古い技術しか持ち合わせていない、経験知でしか物事を判断できないシステムエンジニアでしかない自分とその時になって初めて向き合うことになるわけです。
システムエンジニアとしての限界を超えてしまっているのです。
そうならないように、システムエンジニアとして何もできなくなってしまうという限界線を超えないように先のキャリアパスを考え、自分の技術を維持することを続けなければならないのです。
上流工程を担当するSEには行動基準を作れるスキルが必要なんですよ
上流工程、要件定義では業務フローがインプットの一つになるので確認することがありますが、なかなか顧客から出てこないケースがありますよね。終いにはデリバリーチームに作ってなんていい始める顧客もないわけでもない。まあ、こんな顧客は早々に切るか骨の髄までパックンっといただくつもりでないとお付き合いしきれませんが。
業務フローは誰の仕事か
どちらにしても業務があってそれを要件に沿って機械化するのがデリバリーチームのお仕事ですし、業務の主体は顧客ですから業務フローに可視化できるのは顧客です。
＃まあー現場の仕事もあってそこまでリソースが割けないからその可視化の部分を切り出してよ、という背景もあるのですけどね。コストが費用として貰えて、リソースも用意できるならやればいいですけど。
それ、現状の機械化でしかないのでは
で、誰が作るかは差し置くとして、業務を可視化（業務フロー図）して、それをシステム化するじゃないですか。で、プログラム作ってテストしてリリース、と。
でも、それって現状の業務を機械化しただけなんですよ。
一つ抜けているんですね。それはプロジェクトの目的の業務の課題です。その課題が生産性（作業スピードをあげてたくさん処理する）や正確性（正しいルールで繰り返すことでミスをしない）であれば、そうですね、機械化でオーケーなんですがそんなの昭和の時代に終わっていますよね。別のプロジェクト化した目的を考慮することが抜け亭rんですね。
ToBeをシステム化するのがプロジェクトの目的でしょ
そうすると現状の業務を可視化した業務フローから、目指す業務に変えなければならないことになります。その目指す業務を可視化してそれを検証し、システム化しなければプロジェクトの目的に到達できないんですよ。
新しい判断基準の必要性
そこで必要になるのが新しい業務、目指す業務での振る舞いの判断基準です。code of bookというかismというか。目指す業務を可視化して作業者が振る舞い、インプットする、操作するときの判定基準が必要になるんですね。
プログラムはルールですから、元となるルールがないとコード化できないです。書いたようにしか動かないし、書けなければコードにできない。
新しい判断基準を検証する必要性
目指す業務を誰が作るにしても、その目指す業務を理解して、コードに変換するのはシステムエンジニアなんですよ。で、目指す業務の業務フローを見たときに何に基づいているのかを理解し、システム的（データと処理）に合理性を持っているか検証できないと作っても使えない、間違った機械化をしてしまうお手伝いをしかねないんですね。
それはお互いに不幸だし、顧客としてはシステム化のプロフェッショナルに業務委託しているのですし、システムエンジニアとしてもプロとしての責務もあるのですよ。
＃イズム、ですね
結局、システムエンジニアも顧客が示す目指す業務の判断基準が正しいかを見抜ける技量、スキルが必要なるんですね。だって、そのスキルがなければシステム要件や方式、実現仕様として検証できませんから。
遠慮するメンバがいる居心地の良いチームはパフォーマンスに応えられない
居心地の良いチームは良いと思うし、それを目指そうとしますよね。例えば、心理的安全性の高いチームはその類似例かもしれないです。
ただ、この居心地の良いチームがパフォーマンスが高いかと言えばそうでもないのではないかと思うわけです。
過去のプロジェクトで、プロジェクトの仕事の中ではロールに応じた（大人的な表現）役割を求めあい、互いに期待されるパフォーマンスを発揮できないときちんと指摘し、指摘されてた方は対策をするということをやっていたとき、それはそれでパフォーマンスは高かったです。言い方を変えれば緊張感が張り詰めている感じでした。
ところが、飲み会となればオンとは反対にものすごくフレンドリーで懇親するんですよ。
＃ある意味こっちの方が大人の行動なのかもしれませんけど。
ワタシ個人的にはこちらのチームスタイルが口に合います。個人的な嗜好ですが。がっつり意思伝達して、パパッと帰ってもらう方がいいし、そうやって考える時間を作って次に備えたいですし。
居心地の良いチームは２つある
居心地の良いチームは２つのパターンがあると思うんですよ。良い解釈としての居心地の良いチームはパフォーマンスの良いチームでもある。しかし、居心地の良いチームに見えて実は単なる仲良しクラブでパフォーマンスがさっぱり出ないチームだって少なくないんですよ。
後者の居心地が良いチームなのにパフォーマンスが出ないチームの特徴は変に気を使って言わなければならないことを言わない・言いにくい関係のチームです。
これ、実は身の回りに多くないですか。それも「大人の対応」とか言って言わないことをよしとしているチームが。
遠慮を美徳と勘違いしていると期待に応えられない
そういうチーム、つまり居心地がいい割に期待されるパフォーマンスが出ないチームのメンバは、遠慮を美徳のように振る舞う特徴を持っているんです。
相手を認めて、理解して対応する応対と何から何まで自分を卑下してそれを遠慮しているから失礼はないだろうと思っている人は全然違うと思うんですよ。
何にかと言えば、成果に対するパフォーマンスの出来です。出来と言っても過剰な金メッキとかのレベルの話ではなくて、プロジェクトの目的を由来とする品質要求を満たしているか、それを満たそうとしているか、です。
自分を卑下して遠慮を振舞っている人は、自分で勝手に品質要求レベルを下げてしまうんですよ。それも他責にして。
理解することと遠慮することの違い
相手を認めて、理解して対応する応対ができる人たちのチームは総じてパフォーマンスが高い。なぜなら、こちらのやりたいことの障害を明らかにして、必要なら利害関係者と調整することを黙っていてもやってくれるからです。
これは単純な話で自分のタスクの達成のために何をしなければならないかを自分で組み立てられるからですよね。卑下していたら、必要もないのに膝を詰めずに逆に下がるわけですから結果的に自分で自分の首を絞めているだけなので、目的から遠ざかる一方です。そりゃパフォーマンスに応えられるわけないです。
用法の注意事項
ただ、勘違いしてはいけないのは、言いたいことを言い放題にすればいいということではありませんよ。相手を理解する≠受け入れることでもないです。あーそうなんだね、です。でも、こっちもこーなんですよ、と。じゃあどこで、でもプロジェクトの目的はこうだから、じゃあここですね、という意思疎通をするのがパフォーマンスにつながると思うのです。
自分のやり方で満足していると無知であることに気づかない
自分の知っている情報や技術だけでアウトプットするシステムエンジニアがいたんですね。
担当するプロジェクトだと、割と新しい技術を調べなければならなかったり、集めた情報や技法などを評価分析して、あるべき姿＝ToBeモデル的な世界を表現する必要があるんだろうなぁ、と横で見てたんですね。
日常会話やときどき担当している資料を説明してもらって聞いているとどうにも引っかかる思考をしているなぁって。
全く調べないわけではなく、本人なりに調べてはいるように見えるのだけれど、その対象は集める情報だけに限られているようにしか思えないんですね。
で、その集めた情報を仮説を立て、検証してモデル化するんだろうなぁと思っていたんですが、その仮説検証の前に結論ありきで情報を整理しているんですよ。
これは違うものができる可能性があるなぁ、と。
なんでこんな感じになっているのかなと。ヒントは「結論ありき」なんですね。自分の仕入れた情報だけで結論を出して、それに合うように過程を引き摺り込んでいるんですね。
それって自分で固定観念持っちゃっているんですよ。だから、他の案を検討しようとしないんですね。
増えない知識
情報は集めているんですけどね、モデル化する際のロジックがないんですね。乱暴な表現をすれば、表面的な情報は集めているのでそれっぽく見えるけれど、要求されているアウトプットは違うよ、ということです。なんでそうなってしまうかは、情報から仮説検証する道具立てがないから。
そのシステムエンジニアに必要なものは情報はもちろんだけど、道具だったんですね。でも、それを学ぼうとしないから知識が増えない。知識が増えないから持っている経験則だけでアウトプットするんですね。
そうしてアウトプットされたものは、見る人が見れば一発で「違うよ」とダメ出しを出されるんですよ。
お腹いっぱいと錯覚している
会話をしていてもそのシステムエンジニアは「自分はこのやり方でいいです」的なことをいうわけです。
必要な道具は持っていると勘違いしている。もう必要なことは全部知っていると思っているのかもしれません。そういうシステムエンジニアは学びませんね。
もう、何を言っても学びません。もちろん、大人に対して「学べ」とは言いませんけど。
「こういった方法もあるよ」
と言っても言う甲斐がないんです。困ったことに。いや、困るのはご本人なのですけどね。ダメ出しされるから。
ワタシは学もないし、経験も浅いと思っているので世の中にはもっといいやり方があると思っているんですよ。そう思っていると気になるんですよね。こんな考え方があるのか、とか。
でも、学ばない人は気にしていないから視界に入らないんですよね。これは大きいんですよ。気にしないと視界に入らないって。
やり方に、それも自分流のやり方で満足していると無知であることに気づかないんです。
すごいエンジニアもWIPは１である
ずっと前にプロジェクトマネージャをしていたチームにすごいシステムエンジニアがおりまして。おりましてというか、そのプロジェクトの技術的なキーパーソンでして、その人がいないと「プロジェクトが成り立たない」ということがプロマネのアサインをされるときにわかったのでリソース要求では「キーパーソンがいないなら受けない」とまでいいきり、なんとか確保したのでした。
さて、もう、この時点でフラグが立っているように感じられたらあなた、鋭い。はい。フラグです。
すごいエンジニアはやぱり凄かった
上流工程のWBSを作るときも進め方についてはキーパーソンやメンバには
「こうしたいんだけど」
「いいんじゃいない」
みたいなやり取りをして計画を詳細したんですが、方式設計などでのレビューではやっぱりできるエンジニアは
「目の付け所が違うな」
と思うコメントをくれるのです。わかってらっしゃる人はわかってらっしゃる。
すごいエンジニアはやばかった
プロマネも汗をかき、メンバも汗をかきで進めていたわけですが、プロジェクト最適化というプロマネの都合でアサインをするとどうなるかといえば、すごいエンジニアに難易度の高いタスクばかりが集中するようになります。
プロマネから見れば、スキルレベルに応じてタスクの難易度を振り分けているので
最適化している「つもり」
になるんですよ。
ところがこれがまずかった。
難易度の高いタスクだから思うように進まない＝進捗しなくなるのですよね。すごいエンジニアからしたら難しいタスクやっているんだから進捗なんて
「ベストエフォートでしか進まないよ」
となるんですけど。
すごいエンジニアもWIPは１である
二つのことを同時にできる人はいませんから当たり前のことなんですが、エンジニアがタスクを進捗させようとしたら１つのタスクに専念させてあげないと複数渡したタスクは全部締め日までに出来上がりません。
たとえ一つであっても、難易度の高いタスクなら進捗は計画した通りに進みません。大概、何かが起きますからね。
まずは、どんなにすごいエンジニアも所詮一人であることを理解することです。で、タスクは順次渡す。WIPは誰でも１なんですよ。
進捗遅れはプロマネの問題
進捗が計画どおりにいかないのは、結局、プロマネの問題なんですよね。メンバに変に期待値を持ってしまって。
そういう計画を作っていたら誰かによく見られたいとプロマネ自身が思っているんですよねぇ。初めてのプロジェクトだからとか、重要な顧客だからとか、何かよくがあるんですよ。
それは大体上手くいかないですね。プロジェクトの目的やそれから設定した目標でないから。プロジェクトの目的からの要求ならどうすれば実現できるかを導けても、欲をかくと歪むんですよね。判断力が。だから上手くいかないですね。
結局、プロジェクトの目的に立ち戻って、やらなければならないことを確認して、メンバと分担するほかないんですよね。
そういう意味では、計画の考え方を共有しながら進めていたので再分担はすんなりできましたし、計画を調整したのでマイルストーンまでには滑り込めました。
2017年にビジネスが開発チームに求めるもの
ここ数年ビジネスサイドからの要求で次の事項がITサイドに求められるが、実現性のある選択肢はどれか
- 素早く立ち上げる
- ビジネス価値が検証できている
- 実現性のリスクが少ない
- 小さく立ち上げて、大きく成長させる
素早く立ち上げる
ためには、リソースが揃っている必要があります。人的リソース、物理的リソース、そして立ち上げ時に必要なバジェット。
素早く立ち上げるために必要となる人的リソースには何が求められるかを考えると、これが実現できる組織は人的に裕福であると言えるでしょう。なぜなら素早くたちあげることが必要となったときに、立ち上げに必要なチームとしてのスキルセットが充足できるほど人的リソースの余裕があるからです。
また、物理的リソースが確保できるということは予算が確保されているということであり、必要なものを要求すれば必要なタイミングで手に入れてられることであり、これはバジェットが確保されているということにつながります。
ビジネス価値が検証できている
ためには、素早くビジネス価値を検証するモデルを実践して、素早く実装するか別にピボットするかの判断をする行動力が必要です。
それができなければ、他社のビジネスモデルをパクる二番煎じか二匹目のドジョウを狙うしか方法はありません。こうした判断をよしとする組織では未来永劫自組織でビジネス価値を検証することはできないでしょう。
なぜなら、自社でビジネス価値があるかないかを検証できるスキルをもてないからです。
実現性のリスクが少ない
ためには、ビジネス価値の判断を様々な手法でやるとしても、検証に求めるレベルが高い＝失敗しないことを求めるような組織文化では素早いのスピード感は桁違いに遅いです。
スピードの差異はビジネスサイドが早く立ち上げることで生じるリスクを取るか取りたいがらないからで分かれます。
また、実現性のリスクが少ないことを求める結果、枯れた技術しか採用できなくなってしまうことにも注意が必要です。
小さく立ち上げて、大きく成長させる
素早く立ち上げるためには、広いスコープでは実現できません。これは物理的に人的リソースや物理リソースを揃えても多重で同一のレベルでは進められないからです。
ビジネス価値の検証もMVP（実用最小限の製品）、つまり最小の価値に絞れば検証する対象が小さくなるのでスピードが殺されませんし、小さなスコープですから間違いかどうかの検証期間も短くて済みます。検証期間が短いのであれば、間違いからのピボットの判断も早くすることができます。
実現性のリスクが小さくすることは、小さく立ち上げれば投下するリソースもバジェットも時間も小さいため、ビジネス的なリスクはコントロールしやすくなります。
正解はこの４番になります。
これFSでは
で、これフィージビリティスタディと同じですよねぇ。使う道具は違いますけど。考え方は新しいものではないわけです。車輪の再発明というか、不足しているところを補ったというか。
小さく立ち上げて…はスパイラル開発が近いですがリリースするプロトタイプとして作って評価するか、リリースするプロダクトを作るかの違いがありますけど。
最短でリリースする
これなんですよね。ビジネスサイドがやりたいことは。アジャイルだろうがなんだろうが手法はなんでもいいわけです。すぐにリリースしたいんです、ビジネス側は。それが１番の投資対効果を得られる最短路なのですから。
アラフィフ・エンジニアの目標設定の立て方
気づけばアラフィフも半分折り返ししていて、定年を６０歳とすれば後１０年もなく、６５歳とすれば後１０数年しか残っていないんです。
あ、今自分はまだ先の話だと思ったシステムエンジニアがいたら、あっという間にこちら側になるんだと頭の隅に入れておいて欲しいんですよ。あっという間です。システムエンジニアの人生なんて。
それはそうと、アラフィフ・エンジニアの目標の立て方です。
前提事項
定年だからと早々と隠居を決め込むことは考えていません。ご近所の元エグゼクティブも役員のみなさまも仕事から遠ざかると一気におじいちゃんになってしまう。これは嫌なのです。ワタシは自分の得意分野で仕事を続けたい。現場に居続けるのは無理であっても、ノウハウを伝授するとか問題解決の方法を教えるとか、一緒に課題を解決するなど関わりたいし、コンテンツを出し続けたい。
つまり、自分の専門性を使って仕事をし続けたいと思っています。
１０年後の予測
１０年後なんて誰にも予測はつきませんが、一つだけ予測できることは、生きていれば１０歳年をとったワタシがそこに存在するわけです。
今のワタシ＋１０歳
これは誰でも予測できること。
でも、インシデントで不測の事態が起きるか、病気で絶命する可能性もありますが、それはリスクとして識別し、エクスボージャとして捉えらときの対処のコストと比較するとそれほど対策で得られる効果はないと思っています。
ですので、リスクは識別するけど、受容する対策にして、今は可能性の高い＋１０歳の自分が存在することを予測しておきます。
１０年後の目標
専門であるプロジェクトマネジメントでプロフェッショナルでありたい。すでにPMIのPMPを取得して１０年を超えていますが、認定ではご飯が食べられないのは当たり前なので、ご飯が食べられるプロフェッショナルになりたい。
マネージャを続けるという選択肢もありますがちょっと違うかな、と思っているので。
で、プロフェッショナルになるには、自己研鑽をすることと事業を作ることが必要かと思うのです。一人でできることは限られているので仕事では周りを巻き込んで、プライベートでは自分の時間を活用して、になりますが。
今年の目標
今年の目標は、相変わらずの品揃えですが、こんな感じです。
・事業のエンハンス
・担当プロジェクト（企画・計画・実践）の推進
・メンバの育成（育成目標設定）
・オポチュニティのエンゲージ
・自己研鑽
全くもって、代わり映えしないのですが、３０歳を超えたらこのカテゴリは同じで、違うのは担当するエリアの広さやロールとしての役割でしょう。
言い換えれば、このカテゴリで自分の目標を設定すればシステムエンジニの全年齢に対応できる公式でもあるわけです。
じゃあ、お前は具体的にどんな目標を立てるのかと言われるかもしれませんが、そりゃ生々しいい話になるので書けませんよ、と。ここに書いてい情報漏洩するわけにもいかず。ただ、誰が目標を立てるにしても、このカテゴリでこの１年で何をするのか自分にコミットメントすればいいんですよ。
特に自己研鑽は、オンオフ関わらず、自分に負担をかけるところだけれど、それを超えていかないと次が先延ばしになって、ずるずるとしていると自分で自分の将来の可能性を溶かしてしまうのでよろしくないです。
仕事は結果を出して当たり前。出せるように目標を設定すればいいけれど、自己研鑽は自分自身のエンジニアの生命線なのでおろそかにできないんです。
具体的な活動イメージ
とは言っても、自分自身に対しての具体的な１年の目標のイメージを文字にしておかないと、やらないことになってしまうし、今年の年末にふりかえったときや、四半期のタイミングでの見直しでベンチマークできなくなってしまうので比較対象が必要です。
・事業のエンハンス
→ プロジェクトテーマを広げる
・担当プロジェクト（企画・計画・実践）の推進
→ 広げたテーマを含めて
・メンバの育成（育成目標設定）
→ 現在のメンバのうち、優先順位をつけて個別のテーマを与える
・オポチュニティのエンゲージ
→ 現状の事業から新規案件を見つけ、プロジェクト化する（規模は問わない）
・自己研鑽
→ 講演、イベントのプレゼンター役や主宰の機会を増やすことで認知度を増やす。
さて、どのくらいできるかはわかりませんが年末覚えていたらふりかえりをしましょう。
