開発組織の新しいカタチ
CTO,VPoEはじめエンジニアマネジメント職としては、強い開発組織について、いつも頭を悩ましていると思いますが、ステレオタイプになっていないでしょうか？
柔軟な開発組織のススメ
以前下記の記事を投稿しました。
■モンゴルに開発部隊を求めた話
https://qiita.com/k1morikawa@github/items/61e5cf9520725b4706bb
■開発組織を全て業務委託メンバーで構築した話
https://qiita.com/k1morikawa@github/items/b2257661dd75e7365507
１．海外に開発組織を構築する
コロナのお陰でリモートワークが進み、皆さん、リモートワークのノウハウが貯まり、エンジニアが隣にいないと駄目という状況でも無くなってきてます。東京でのみ採用という固定概念は捨てて、地方採用、海外採用を進めてみてはいかがでしょうか？
今年に入り急激に円安が進みました。これにより、日本人の単価は世界からみて安い方になってます。中国、韓国からみると日本は安い国となるので、それ以外の国でないとコスト的なメリットはありません。
しかし、コスト中心に考えるのではなく、開発組織が作れるかどうかにフォーカスして考えてみてください。
モンゴルでは、東大レベルの理系卒のエンジニアが採用できます。日本だと無名ベンチャーには絶対に無理でしょう。
２．業務委託メンバーで構築する
社員採用の様な昭和の終身雇用制度から脱却し、フレキシブルな雇用の業務委託メンバーで開発組織を作ることにより、より速くより高品質なサービスが出来上がる可能性もあります。業務委託メンバー型組織のメリットは山の様にあります。
３．縦割りから横割り組織へ
通常、開発本部という形で開発メンバーが集まっている組織を作ると思います。この組織は、上長がエンジニアでありエンジニアスキルに対して適切なジャッジ、評価が可能となり、部署のメンバーが全てエンジニアなのでスキル共有も進みやすいです。しかし、一方で売上に向けての意識やエンドユーザーに向けたサービス等は、組織が違うので温度感が伝わらず弱くなる傾向にあります。
エンジニアを各事業部側に配属し、事業意識をあげる形に変更してみましょう。そして横串でエンジニアの管理・評価をCTO、VPoEが担当します。
４．DAO型組織
エンジニアとしてマネジメント職は存在させながら、ステークホルダとなってもらい。サービスや組織に対しての意識をもってもらい。報酬も事業成功に連動させるモデルです。フラットの組織の場合は、色々と弊害があるため、DAOの良さをとった形になります。
フラット組織の弊害は下記をみてください
https://qiita.com/k1morikawa@github/items/7237dd1f61525abb3cb4
5.新卒エンジニアのみ
新卒エンジニアのみの組織。CTOのみ居て、採用は全て新卒エンジニアです。エンジニアって出来る奴は、１年あれば１０年目のエンジニアをあっという間に追い抜きます。新卒エンジニアで文化レベルも合わせながら育てていくのもやり方として面白いと思います
６．ラボ型、レベニューシェア型
全て外部委託にて開発してもらう組織です。ラボ型にする事により、見積もり等のオーバーヘッドを無くせますし、レベニューシェアなので事業部目線にもなりやすいです。昔からある形ではあります。
最後に
開発組織の新しいカタチについては、色々とアイデアが出てきそうですね。ゲーマーのみや女性のみ等の属性を絞ったエンジニア組織も無駄なコミュニケーションコストが省けて良いと思います。
ステレオタイプから脱却して新しいカタチの開発組織にチャレンジしてみてください！
フォロー、イイねお願いします。
開発組織を全て業務委託メンバーで構築した話
CTOやVPoEの皆さんはエンジニアの採用には困っていると思います。もちろん、社長も含めて頭の痛い問題です。
スカウトメールを送ったり、イベントを開催したり、勉強会をやったり、エンジニアブログを書いたり、採用活動は色々とありますが、レッドオーシャン化してます。
業務委託メンバーで構築
社員を取っていくのはとてもハードルが高いので、業務委託メンバーで構築してみました。
業務委託メンバーというのは、
-
SESエンジニアに入ってもらう
-
フリーランスエージェント経由で契約する
-
フリーランスを直接で契約する
SESエンジニアとフリーランスエンジニアは、特に変わりはありませんが、SESエンジニアの中には、企業の所属しながらSESエンジニアとなっている人と個人契約でSESエンジニアとなってる人がいます。
業務委託メンバーの良さ
1.採用が早い
社員採用となると速くても半年くらいかかると思いますし、半年掛かっても思っていたレベルのエンジニアを見つける事は難しいでしょう。少し妥協しながらの採用になることがほとんどです。
しかし、業務委託メンバーの採用になると、採用レベルと一切変えることなく採用する事ができます。しかも当月に見つかる事も少なくありません。紹介の量も社員の紹介量と比べて１０倍以上の量の紹介を受ける事が可能です。スピード感半端ないです。
2.採用費がかからない
通常、社員の場合は、エージェントに年収の紹介費を払う必要があります、エージェントでない場合も、媒体費、スカウト費、イベント参加費等結構なコストが必要です。
3.手間がかからない
採用の場合は、結構なコストが掛かるので退職された場合のダメージが大きい為、人材の選別に時間と労力をかける必要があります。これは家事と一緒で見えないコストがめちゃくちゃ大きいです。採用人件費を考えても凄いコストが掛かってる事を気付いてない場合も多いです。
4.評価制度がいらない
業務委託メンバーなので半年に一度の目標設定とか評価とか、評価のフィードバックは不要です。これもエンジニアマネジメント職にとってめちゃくちゃコストの掛かる部分です。人材の育成・教育・評価等は、組織にとってメインタスクと言っても良いくらい大事です。ここの力抜く訳には行きませんが、業務委託メンバーなら不要となります。
5.教育がいらない
業務委託メンバーは、エンジニアとしてプロの人達です。自分のスキルでお金を稼いでる人達なので、基本的には自分達で勉強します。もちろん案件的にやってみたい言語とかテクノロジー等はあると思いますが、プロなので環境を与えれば自分で解決、自走してくれます。この自走できるエンジニアを採用しようとすると超難しいです。
6.モチベーション管理がいらない
プロの人達なので、基本的にはモチベーション管理等はいりません。仕事で直接お金をもらってるのでモチベーションを下げてられません。もちろん人としてエンジニアとしての人格を否定したりするのは論外です。
7.人数の増減が容易
VUCA時代の経営としては、サービスが上手く行かなくなる事や瞬間的に人を減らす事等あるでしょう。更にサービスやテクノロジーをピボットする事もあります。社員と違って、フレキシブルに変更する事ができます。
8.技術も変更できる
Javaで開発していたものを、AI絡みでPython言語に変更する事があるかもしれません。社員の場合は、Pythonの勉強をしてもらう必要がありますが、業務委託メンバーの場合は、Java言語のプロからPython言語のプロへ入れ替わってもらう事が可能です。
業務委託メンバーがコストが高いと思われているけど
この話をしても社員に拘る会社さんが多いです。一番がコストです。社長が特に言いますね。
でも計算してみてください。
社員の場合のコスト
-
500万のエンジニアを6名
-
700万のエンジニアを３名
-
1000万のエンジニア(VPoE)を１名
の組織で考えた場合は、
これに人事の人件費 １名 500万を加えます
社員の場合は、
(500万1.2)7+(700万1.2)+(1000万1.2)=7,920万円です
1.2は、社会保険等
業務委託の場合は、
-
500万のエンジニアを6名
-
700万のエンジニアを３名
-
1000万のエンジニア(VPoE)を１名
採用がないので人事はいりません。他と兼務で良いでしょう。
(500万1.3)6+(700万1.3)+(1000万1.3)=7,930万円です
1.3は、エージェントの中間マージンですが、もっと安いです
コスト比較
社員：7,920万円と業務委託：7,930万円でほとんど変わりません。
ここから社員の場合は、採用に関してエンジニアも書類選考・面談に入ります。マネジメント職は、評価・目標設定・教育・モチベーション管理等の人件費を考えたら、きっと1000万は必要でしょう。
圧倒的にコストでも業務委託メンバーの勝ちです。
会社への帰属意識等
これについては、絶対的に社員の方が良いです。ただ社員だと言っても来月辞める可能性もあります。今の時代長く勤務してくれる保証は全くありません。これは会社側からの勝手な重い思いだと思います。
ここを大事にするなら、新卒エンジニアの採用に力を入れる事がオススメします。新卒エンジニアの場合は、文化形成含めて最初の会社なので会社と個人の人格も同一化しやすいでしょう。
最後に
開発組織の構築の仕方を社員限定で考える時代は終わってます。フレキシブルな頭でフレキシブルに動ける体制について考えてみて欲しいです。
必見：ChatGPTのテクノロジーの凄さについて
OpenAIにより１２月１日発表されたChatGPTですが、世界中で話題になってます。
私も夢中になって色々と調べてます。
日本語でのやり取りも問題なさそうで色々な記事も出てますが、APIとか内部について触れている記事があまりなかったので調べてみました。APIについては下記をご覧ください。
速報：ChatGPTのAPIを叩いてみた
続：ChatGPTのAPI調査
続：ChatGPTのAPI調査・その２
今回は、内部について少し詳しく見ていきたいと思います。
何が起きたのか？
今週、ニューオーリンズで開催されるNeurIPS2022でGPT-4の噂が飛び交う中OpenAIからChatGPTが発表されました。AIを利用した大規模言語モデルのGPT-3ファミリーの新しいモデル、text-davinci-003を発表しました。これは、「GPT-3.5 シリーズ」と呼ばれるものの一部であり、より複雑な指示を作成し、より高品質で長い形式にも対応してます。
OpenAIとは
OpenAIは、人工知能（AI）を研究する非営利団体です。そしてみんな大好きイーロン・マスク氏が立ち上げメンバーです。但し、2018年にイーロン・マスク氏は利益相反があるとして退任してます。
GPT-3とは
GPT-3は、Web等から収集した45TBもの膨大なテキストデータのうち、いくつかの前処理を施した570GBのデータセットを学習に用いたデータセットに対して、 1,750億個のパラメータを持つ自己回帰型言語モデル（ある単語の次に出てくる単語を予測するモデル）を学習することで、 今まであった「BERT」や「GPT-2」のデータ学習量を遥かに超えた、巨大な言語モデルを形成しています。
GPT -> 1.1億パラメータ
GPT-2 -> 15億パラメータ
GPT-3 -> 1,750億パラメータ
とバージョンアップしてきました。
2020年6月にGPT-3をインターネット経由で利用できるインタフェース（API）を限定公開してます。
今回のdavinci-003とは
InstructGPT に基づいて構築されており、強化学習と人間のフィードバックを使用して、言語モデルと人間の指示をより適切に調整します。人間が書いたデモンストレーションと高得点のモデルサンプルで教師付き微調整を使用して生成品質を向上させるdavinci-002とは異なり、davinci-003は人間のフィードバックによる真の強化学習 (RLHF) モデルです。
との事です。
RLHFとは
https://www.marktechpost.com/2022/02/05/openai-team-introduces-instructgpt-model-developed-with-reinforcement-learning-from-human-feedback-rlhf-to-make-models-safer-helpful-and-aligned/
記事がありました。
GPT-3は、自然言語処理(NLP)が優れていたけど、意図しない出力が出ることがあったけど、人間のフィードバックからの強化学習でInstructGPTモデルが出来たとの事です。
Explicit Intentions – following user instructions
Implicit Intentions – Staying genuine and not being biased, poisonous, or otherwise hurtful.
こちらの通りInstructGPTモデルを入れる事で人間の指示に従い安全な物になったという事です。
更に、GPT-3の出力の毒性をInstructGPTモデルで緩和させているみたいです。
人間のフィードバックによりの通り、GPT-3に対して、人間がフィードバックを行い、強化学習させているという事ですね。これは、どのくらいの量のフィードバックが入ってるのかも気になりますが、調べてもあまり情報はありませんでした。
最後に
こちらのGPT-3は、APIという事もあり、誰でも自由にアプリが作れる事がとんでもない事です！！
既にあるチャットボットサービスなんかは、終わりですね。検索エンジンもインターフェイスが変わるでしょう。
様々なアプリが変わる革命的な事が起きそうな気がします。
AI化の時代の入り口に僕たちはいると思います。
絶対に止めれないシステムの作り方
絶対に止めれないシステムとは
もちろん銀行システムとかのクリティカルなシステムもそうなのですが、今回は、そこまでではないのですが、データ連携上一部のapiは止めれないシステムを指します。
僕は直面したのが、Lineでのユーザー登録によるwebhookを受け取るって奴です。
昔のキャリアのユーザー登録であれば、止まっていた時には別途データが飛んできてまとめて処理とかも出来ましたが、Lineさんのはありません。ユーザー登録時のwebhookを取りこぼすと２度と受信出来ないのです。
同様にSNS等で登録時にwebhookが来て、対応する必要があるシステムもあると思います。
どうすれば良いか？
先ず思うのは、AWSでLambdaで受け取って処理すれば良いと思うでしょう。
これでも良いのですが、Lambdaがエラー処理で落ちたりすることもあります。
最初の構成
この構成の場合は、通常時は良いのですが、トラブル時にデータをロストしてしまいます。
-
webhook側でエラー
-
ALBとEC2の通信障害
トラブル以外にもデプロイ時のwebサービスの再起動等の時もデータがロストしてしまいます。
改善したシステム構成
なので下記構成にしました。
ALB->Lambda->SQS->Lambda->webhook(API)
１．最初ALBからlambdaを呼び出す
２．lambdaは、SQSでキューを登録し終
３．別のlambdaを定期的起動させ、SQSのキューをチェックさせる
４．キューがあったら、取り出し、webhookAPIをコールする
最後に
これによりシステム停止時にも問題なく稼働するシステムが構築できましたが、SQSでなくても、S3に保存したり、
他にもやり方はあると思います。
皆さんが考えたaws構成について教えて下さい
若手エンジニアに送る：｢努力｣×｢運｣×｢対応力｣で成果が決まる
昔、資格取得にはまってた時期がありました。
その時期は、とにかく資格に受かるのが楽しかった。社内でも誰も取ってない資格にチャレンジして、受かったりするとちょっとした優越感があったり、勉強する事による情報オタクにもなってる自分がありました。
新卒で入社した会社では資格で毎月の手当がでるので、何より手当が貰えるのも資格取得にハマった理由です。
結果を出してる人は努力している
そもそも、資格を沢山取ろうと思った経緯は、自分の価値を客観的に明確にできる手段としたいと思った経緯がありました。
社内でも評判も良く、給与ベースも評価されましたが、それ以上に自分の意見が通るし、結構わがまま放題に仕事ができたのが良かったと思う。
そんな時、同期から、｢いいよなぁー。森川は頭が良いから・・｣と言われてムカつきながらも呆れる毎日。心の中では、｢俺も毎日努力しとんやぁーーー！！｣と思ったりしてました。
運がよければ、結果が出るのも事実
運が良ければ、努力をあまりしなくても試験で良い点数を取れる人が沢山いるのも事実です。
運というのは、親ガチャではないですが、遺伝による頭の良い人がいます。当然ながら結果が出やすい。
スポーツも同じ最初からサッカーが上手な人もいます。ただワールドカップに出る様な選手は全員、とんでもない努力をしてると思います。運だけでは結果が出ません。
｢努力｣×｢運｣の掛け算が成果に繋がります。
成果が出ない場合は、｢努力｣を増やすか、｢運｣を増やす事により、成果の成功確立を挙げていく必要がる。
結果が出ない人は、努力を増やすしかありません。運が他の人の0.7の人は、2倍努力すれば、他の人よりも結果が出ます。掛け算は嘘つきません。諦めずに努力すれば、結果が出ます。
加えて、努力にも質が関わります。がむしゃらに努力するだけでは非効率です。幸いな事に昨今ではネット上に先人の知恵が溢れています。先人の知恵を借りながら、質の高い努力を心がけましょう。
もう一つ大事なのが「対応力」
社会人・企業人としてビジネスの世界で生きていくには、更に、｢対応力｣という尺度も必要となります。
ビジネスの世界は、試験ではない。問題・課題に対して、一変通りの答えは存在しない。様々な外的要因や内的要因、利害関係者によって物事が左右されていく。
そのため、当初想定していたストーリから状況を把握しながらも、結果に導くための｢対応力｣が必要となる。
もちろん、ここには、｢努力｣も必要だし、｢運｣も必要となる。｢運｣が強い人であれば、少ない｢努力｣と少ない｢対応力｣で結果を導く事ができるだろう。
世の中は、偶然と偶然と重なりあう事により、結果が左右される。
とはいえ、｢運｣だけに頼っていては、確立が非常に低い物となってしまう。稀にシュートが決まっても、安定したシュートが決まらなくては意味が無い。
対応力は、様々な状況を自分都合にコントロールする力です。ここがビジネスでは大事なスキルとなります。
沢山の｢努力｣を行って準備を行い、様々な局面に対応できる｢対応力｣を持った人こそ、安定した打率の結果が出せるビジネスマンになる事ができる。
成果を出すには、｢努力｣、｢運｣、｢対応力｣
結果＝｢努力｣×｢運｣×｢対応力｣という事である。残念ながら運は、あまり磨くことが出来ない。伸ばせるのは、努力と対応力だ。質の高い努力と適切な対応力でビジネスの世界を乗り越えていく必要がある事を意識して仕事をしてみてください。
目標に悩んでいるエンジニアへ：楽しんで仕事をする事
昔、インフラの担当者がラックの写真を見せてくれた事があった。
そこには、綺麗に色分けされたLANケーブルがささったラック内のSW(スイッチ）が移ってました。
新設ラックを構築するにあたって、高アベイラビリティ、低コスト、高パフォーマンスのインフラ構築を彼女に担当してもらいました。
本来、経営レベルからのコスト削減を目指して始めたプロジェクトなのですが、どうせならという事で、LVSや、VRRP、ボンディング,etc等のオープン技術を駆使した物も一緒にやりたいという事で、スケジュール的にも非常にタイトなプロジェクトでした。ハードなプロジェクトを見事に対応してくれたのですが、苦労しただけあって、自分で設置したハードの写真を見て、「自分の子供の様にかわいい」と（笑
さぞ、大変で難しくもあったと思います。だからこそ、達成感も並大抵の物ではなかったと思います。
仕事には、自分が好きな仕事と自分が出来る仕事がある
自分のやりたい事が見つからないと言って悩んでいる人がいます。時に相談されたりします。
仕事というのは、
-
自分が好きな仕事
-
自分が出来る仕事
があります。最も良いのは、自分が好きな仕事がよいと思います。僕も小学生の頃にプログラマーになりたくて、そのまま今に至ります。イチロー選手も野球大好き少年からプロ野球選手になりました。
引退会見で、好きな事を見つけて欲しいと言ってますが、好きな仕事が出来るのは、一部の人達に限られる場合が多いです。
次にあるのが、自分が出来る仕事、向いてる仕事です。人と話すのが向いてる人は、営業だったり、コンサルだったり、話す仕事は色々とあります。
アウトプットとプロセス
-
自分が好きな仕事 = アウトプット
-
自分が出来る仕事 = プロセス
なんですよね。アウトプットを目指して、エンジニアになった僕ですが、実は物作りや何かをソリューションするというプロセスも好きです。これは、エンジニアでなくても叶ったかもしれません。
好きな仕事（アウトプット）を見つけれない場合は、出来る仕事（プロセス）中心に仕事を考えてみるのも良いと思います。
本来、仕事は楽しい事
子供の頃、初めてプラモデルを作って、その体験をベースに将来、車とかロボットを作りたいと夢を描いたり。
親の手を借りながら作った料理を家族に美味しいと言われ、将来、コックになろうと思ったり。
ＴＶでワールドカップを見て、サッカー選手に憧れたり。
本来、仕事というのは、
-
楽しかったり。
-
好きだったり。
-
感動したり。
-
夢中になれたり。
だからこそ、大変だけど、頑張れるはず。楽しいからこそ、もっと、難しい事や大変な事にチャレンジしたくなれるはず。
-
初めて自分の作ったプログラムがリリースされた時の感動。
-
初めて自分の企画が採用された時の感動。
-
初めて自分で営業して、クライアントから「御社に頼みます」と言われた時の感動。
アウトプットもプロセスの話しもありますが、最後は、楽しんで仕事が出来るかがポイントです。仕事に夢中になれたなら無意識に成長する事ができると思います。
