CTO興味ある人へ：CTOの業務についてその７ 技術力アップ
CTOを長年やってるとよく聞かれる質問です。
CTOの仕事ってどんな仕事があるんですか？
から始まったCTOの業務についてのその7です。
技術力アップ
技術力アップとしては、技術調査、技術投資、研究開発、教育等があります。
大きく分けて、未来と現状の技術への取り組みの話になります。ネット業界の技術進歩のスピードは非常に早く、未来が現実になる部分があっという間です。
うまくコントロールする仕組み作りが必要となります。
技術選定
１．メンバーから意見収集
メンバーの中から注目すべき技術・興味のある技術を収集します。メンバーからだと短期的に興味のある技術にフォーカスしやすいため、短期・長期で技術出しについてファシリテイトしましょう
２．技術トレンド確認
ガートナー社から発表されているハイプ・サイクルを参考にします。最新が時々発表されるので時々、最新を確認しましょう。
■検索ワード：ガートナー ハイプ・サイクル
https://www.google.com/search?q=%E3%82%AC%E3%83%BC%E3%83%88%E3%83%8A%E3%83%BC%E7%A4%BE+%E3%83%8F%E3%82%A4%E3%83%97%E3%83%BB%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB&oq=%E3%82%AC%E3%83%BC%E3%83%88%E3%83%8A%E3%83%BC%E7%A4%BE%E3%80%80%E3%83%8F%E3%82%A4%E3%83%97%E3%83%BB%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB&aqs=chrome..69i57.3083j0j7&sourceid=chrome&ie=UTF-8
■2022年8月16日 ハイプ・サイクル
黎明期： 潜在的技術革新によって幕が開きます。初期の概念実証 (POC) にまつわる話やメディア報道によって、大きな注目が集まります。多くの場合、使用可能な製品は存在せず、実用化の可能性は証明されていません。
「過度な期待」のピーク期： 初期の宣伝では、数多くのサクセスストーリーが紹介されますが、失敗を伴うものも少なくありません。行動を起こす企業もありますが、多くはありません。
幻滅期： 実験や実装で成果が出ないため、関心は薄れます。テクノロジの創造者らは再編されるか失敗します。生き残ったプロバイダーが早期採用者の満足のいくように自社製品を改善した場合に限り、投資は継続します。
啓発期：テクノロジが企業にどのようなメリットをもたらすのかを示す具体的な事例が増え始め、理解が広まります。第2世代と第3世代の製品が、テクノロジ・プロバイダーから登場します。パイロットに資金提供する企業が増えます。ただし、保守的な企業は慎重なままです。
生産性の安定期： 主流採用が始まります。プロバイダーの実行存続性を評価する基準がより明確に定義されます。テクノロジの適用可能な範囲と関連性が広がり、投資は確実に回収されつつあります。
黎明期、ピーク期に話題が集まって、色々とネット上で話題になりますが、技術として特定の分野しか適用が出来ない事が多いです。幻滅期に入ってくると現実的に色々なサービスが増えてきます。短期だと幻滅期の技術を確認し、長期だとピーク期から技術を選定します。
３．競合チェック
競合会社フォーカスとIR情報チェックしたり、リリース情報分析します。
・IR情報
・売上・利益額伸び
・利益率
・事業セグメント
・研究開発費・ソフトウエア資産額
・中期経営計画
最低限の部分として、同業他社の動きに対しての対策検討はCTOの役割です。
体制
こちらは、組織的に部署を設置して対応するのも理想ですが、コスト的な問題や現場を知らないと適切なアウトプットが出ないという問題もあります。そのため下記の２パターンが考えられます。
１．専任部署設置型
研究する対象が明確な場合、優秀だけどコミュニケーションが下手なエンジニアに役割を与えるのが良さそう。
こちらの場合、予算は、事業粗利の１０％程度が目安か
２．全員対応型
２０％ルール等を設定して、業務とは別で対応。研究開発テーマもメンバー自信で決める。企画からプロダクト化まで体験させる教育としても使える。エンジニアだけでなく、事業側、デザイン側が入るのがベスト。
技術・単独教育
１．資格取得支援
前述のスキルアップに対応しグレード毎の取得資格を定義し、自主学習を推進してもらいます。
２．外部セミナー受講支援
外部セミナーやオンライン学習(Udemy等)金額の年額をグレード毎に設定する。
３．社内勉強会
メンバーの自己発信が必要なため、評価と連動させる。
４．社内SNS
情報投稿、stackoverflow的な相談窓口設定等。CTOが率先して返信しましょう。。
技術・グループ教育
１．リーダー研修、マネージメント研修
人事、もしくは外部リソースを活用します。
２．メンター制度
若手のフォローを中堅が行う事によりマネージメントの一貫となる。コミュニケーション量も増えてきます。。
３．合宿
毎回をテーマ設定し、1,2日かけて集中議論し、能力向上と目線をあげる効果があります。
ここのグループ教育は、非エンジニアの方々と同じメニューで、混合型も視野が広くなるため良いと思います。
まとめ
技術力アップは、短期・長期についての考え方が必要です。
長期
CTOが率先する必要がある分野です。特に長期的な技術は、誰にも分かりません。失敗すると会社の存続を脅かす問題となります。そのため、CTOとしての目利き力が期待されます。会社の体力が出てくれば、色んな技術に投資出来ますが、会社体力がない場合は、なるべく近未来になるまでは、様子見でも良いと思います。
短期
会社の基礎力ともなる部分なので力を入れていきたいですが、会社のPL状態が良くない場合は、放置しがちですが、CTOでしか、ここの注力は出来ません。
ひき続き記事を書いていきますので、フォロー、イイねお願いします！
シリーズ記事まとめ
CTO興味ある人へ：CTOの業務についてその４ チームビルディング/キャリア戦略
CTOを長年やってるとよく聞かれる質問です。
CTOの仕事ってどんな仕事があるんですか？
から始まったCTOの業務についてのその４です。
チームビルディング
最も大きいタスクのうちの一つです。チームメンバーが居ないと仕事は始まりません。チームビルディングが上手く出来ればCTOのタスクの半分くらい終わった感じではないでしょうか。ただこのタスクのボリュームが大きいです。
採用、評価制度の次は、キャリア戦略
キャリア戦略は、とても大事な仕事です。これがしっかりと出来ると１年後２年後の組織の状態は全く違ってくるでしょう。ただ、メンバー全員一人ひとりの戦略を考えるため、めちゃくちゃ時間も必要となります。ここは無理をしてでもCTO自らが旗振りをしてマネージャーを巻き込んで設定していく必要があります。
メンバーが育ってない、体制が足りてないと悩んでるCTO、VPoEの皆さん、ここを２年前にやってなかったあなた達の責任です！！未来のために今日からでも取り組んで下さい！！
キャリア戦略
先ず最初に会社内のエンジニア組織としてあるべき姿をイメージします。そうすると足りない部分、弱い部分が見えてくると思います。そこを強化していくためにエンジニア一人ひとりのキャリア戦略をトップダウンで考えます。
その後、エンジニア毎のキャリア戦略をボトムアップで考えます。
トップダウンとボトムアップの２つをマージして個別のキャリア戦略に落とし込むんで行きます。
PPM分析
PPM分析とはマーケティングで使われる分析手法で、「市場成長率」と「市場占有率（マーケットシェア）」の2軸からなる座標に事業や製品・サービスを分類し、経営資源の投資配分を判断するための方法で、戦略として自社および競合他社の事業の立ち位置を確認することに役立ちます。
これを人財育成・キャリア戦略に適用させます。縦軸に評価・給与、横軸に成長率・市場価値として分類します。
-
花形
組織にとって大事な優秀なメンバー、どんどん成長のチャンスを与えて報酬も与える -
金のなる木
中堅、シニアのメインエンジニア。適切なPJにアサインしパフォーマンスの最大化を図る。 -
負け犬
シニアに多い。スキルのセグメントが狭いのでジェネラリストにすべく働きかける。負け犬から花形へ持っていく。
これをベースにしっかりと個別のキャリア戦略を実行する事で、問題児を金のなる木にへ、負け犬から花形へ変化してもらいます。
まとめ
エンジニアの一人ひとりのキャリア戦略を描いてない会社もあるのでは無いでしょうか？
個々人のキャリアをしっかり描き、面談でもそこをしっかりと話合う事により成長の速度も変わってきます。時間は掛かりますが、最も楽しみなタスクの一つだと思います。子供の成長と同じく、エンジニアメンバーが成長していくのは、とても喜ばしい事です。人にとって、すぐに成長する人もいれば、最初は不器用だけど要領を得れば一気に成長するメンバーもいます。是非、じっくりと時間を掛けてあげて下さい。
ひき続き記事を書いていきますので、フォロー、イイねお願いします！
シリーズ記事まとめ
CTO興味ある人へ：CTOの業務についてその１ 会社組織内での話
CTO興味ある人へ：CTOの業務についてその２ チームビルディング/採用
CTO興味ある人へ：CTOの業務についてその３ チームビルディング/評価制度
エンジニアとITコンサルとSEとプログラマー
昔、『なぜSEはコンサルができないのか』という本があった。
内容は、全く読んでないが、タイトルを見て意味不明と思ってしまった。
ただの職種定義なので役割の違い
１．プログラマー
欲しいものをプログラミングして、実装する職種
＊動く物を実装するロール
２．ＳＥ
クライアントの要望を整理し、システムに落とす上での整合性チェック。
システム実現化を検討整理後、プログラマーに伝える職種
＊クライアントの要望を整理するロール
３．ITコンサル
クライアントの業務見直し含め、こちらから提案する。要望の本質を捉え、
システム的に要件を整理する職種。
＊クライアントが思い付かない事も含めて提案するロール
これらは、あくまでも職種定義である。役割分担である。
あなたの職種はなんですか？ ITコンサルとSEとプログラマー
役割＝能力レベル？
世の中で転職価値等を考えていくと、どうしても、３ コンサル＞２ SE＞１ プログラマーとなってしまう。
３，２，１の順で給料が高いためです。人数構成としても３，２，１の順です。
でも、これって本当に価値として、そうなのでしょうか？
職種と職能レベルが一緒になってますよね。
確かに仕事の順番として、３ コンサル＞２ SE＞１ プログラマーの順番となる。いわゆる上流なのはコンサルである。
これにより、本来の意味の職種を世の中が職能レベルと勘違いして、優秀な人間＝上流（職種が高い）という間違った認識になってしまっている。
結果、キャリアプランとして、プログラマーは、SEへ。SEは、将来コンサルを目指してしまう。
システムをエンジニアリングするエンジニアになろう
僕は、SEがコンサルできないとは絶対に思いません。優秀な人間でもSEをやってる人はいるし、コンサルできる人でもプログラマーをやってる人もいます。
何故なら、役割として、職種としてそこをやってるだけで、優秀な人間は、システムをエンジニアリングができる職能を持っているからです。
エンジニアは、コンサルもＳＥもプログラマーとしても、全ての職種をできる様になる必要があります。
コンサルでも、SE、プログラマーでも皆、エンジニアです。システムに関して精通したスペシャリストであるエンジニアになりましょう。
プロデューサーとディレクターも同じ事が言えるでしょう。ディレクション能力も無いのに、プロデューサーに成りたいって話も、僕的には、あり得ない話です。
だから、僕は、プログラマーとか、ＳＥとか分けて考える昔ながらのSIerは大嫌いです。
当然、職種としての役割定義では、使わざる得ないときはありますが。
全て何でも出来る本当の意味での価値のあるエンジニアに育って欲しいと思ってます。
