合同会社モリカワのブログ

森川敬一。CTOとして30年やってきました。集大成としてCTOを増やすという事を目標にやってます。

開発組織を全て業務委託メンバーで構築した話

CTOやVPoEの皆さんはエンジニアの採用には困っていると思います。もちろん、社長も含めて頭の痛い問題です。
スカウトメールを送ったり、イベントを開催したり、勉強会をやったり、エンジニアブログを書いたり、採用活動は色々とありますが、レッドオーシャン化してます。

業務委託メンバーで構築

社員を取っていくのはとてもハードルが高いので、業務委託メンバーで構築してみました。
業務委託メンバーというのは、

  • SESエンジニアに入ってもらう

  • フリーランスエージェント経由で契約する

  • フリーランスを直接で契約する
    SESエンジニアとフリーランスエンジニアは、特に変わりはありませんが、SESエンジニアの中には、企業の所属しながらSESエンジニアとなっている人と個人契約でSESエンジニアとなってる人がいます。

業務委託メンバーの良さ

1.採用が早い

社員採用となると速くても半年くらいかかると思いますし、半年掛かっても思っていたレベルのエンジニアを見つける事は難しいでしょう。少し妥協しながらの採用になることがほとんどです。
しかし、業務委託メンバーの採用になると、採用レベルと一切変えることなく採用する事ができます。しかも当月に見つかる事も少なくありません。紹介の量も社員の紹介量と比べて10倍以上の量の紹介を受ける事が可能です。スピード感半端ないです。

2.採用費がかからない

通常、社員の場合は、エージェントに年収の紹介費を払う必要があります、エージェントでない場合も、媒体費、スカウト費、イベント参加費等結構なコストが必要です。

3.手間がかからない

採用の場合は、結構なコストが掛かるので退職された場合のダメージが大きい為、人材の選別に時間と労力をかける必要があります。これは家事と一緒で見えないコストがめちゃくちゃ大きいです。採用人件費を考えても凄いコストが掛かってる事を気付いてない場合も多いです。

4.評価制度がいらない

業務委託メンバーなので半年に一度の目標設定とか評価とか、評価のフィードバックは不要です。これもエンジニアマネジメント職にとってめちゃくちゃコストの掛かる部分です。人材の育成・教育・評価等は、組織にとってメインタスクと言っても良いくらい大事です。ここの力抜く訳には行きませんが、業務委託メンバーなら不要となります。

5.教育がいらない

業務委託メンバーは、エンジニアとしてプロの人達です。自分のスキルでお金を稼いでる人達なので、基本的には自分達で勉強します。もちろん案件的にやってみたい言語とかテクノロジー等はあると思いますが、プロなので環境を与えれば自分で解決、自走してくれます。この自走できるエンジニアを採用しようとすると超難しいです。

6.モチベーション管理がいらない

プロの人達なので、基本的にはモチベーション管理等はいりません。仕事で直接お金をもらってるのでモチベーションを下げてられません。もちろん人としてエンジニアとしての人格を否定したりするのは論外です。

7.人数の増減が容易

VUCA時代の経営としては、サービスが上手く行かなくなる事や瞬間的に人を減らす事等あるでしょう。更にサービスやテクノロジーをピボットする事もあります。社員と違って、フレキシブルに変更する事ができます。

8.技術も変更できる

Javaで開発していたものを、AI絡みでPython言語に変更する事があるかもしれません。社員の場合は、Pythonの勉強をしてもらう必要がありますが、業務委託メンバーの場合は、Java言語のプロからPython言語のプロへ入れ替わってもらう事が可能です。

業務委託メンバーがコストが高いと思われているけど

この話をしても社員に拘る会社さんが多いです。一番がコストです。社長が特に言いますね。
でも計算してみてください。

社員の場合のコスト

  • 500万のエンジニアを6名

  • 700万のエンジニアを3名

  • 1000万のエンジニア(VPoE)を1名
    の組織で考えた場合は、
    これに人事の人件費 1名 500万を加えます
    社員の場合は、
    (500万1.2)7+(700万1.2)+(1000万1.2)=7,920万円です
    1.2は、社会保険

業務委託の場合は、

  • 500万のエンジニアを6名

  • 700万のエンジニアを3名

  • 1000万のエンジニア(VPoE)を1名
    採用がないので人事はいりません。他と兼務で良いでしょう。
    (500万1.3)6+(700万1.3)+(1000万1.3)=7,930万円です
    1.3は、エージェントの中間マージンですが、もっと安いです

コスト比較

社員:7,920万円と業務委託:7,930万円でほとんど変わりません。
ここから社員の場合は、採用に関してエンジニアも書類選考・面談に入ります。マネジメント職は、評価・目標設定・教育・モチベーション管理等の人件費を考えたら、きっと1000万は必要でしょう。
圧倒的にコストでも業務委託メンバーの勝ちです。

会社への帰属意識

これについては、絶対的に社員の方が良いです。ただ社員だと言っても来月辞める可能性もあります。今の時代長く勤務してくれる保証は全くありません。これは会社側からの勝手な重い思いだと思います。
ここを大事にするなら、新卒エンジニアの採用に力を入れる事がオススメします。新卒エンジニアの場合は、文化形成含めて最初の会社なので会社と個人の人格も同一化しやすいでしょう。

最後に

開発組織の構築の仕方を社員限定で考える時代は終わってます。フレキシブルな頭でフレキシブルに動ける体制について考えてみて欲しいです。

必見:ChatGPTのテクノロジーの凄さについて

OpenAIにより12月1日発表されたChatGPTですが、世界中で話題になってます。
私も夢中になって色々と調べてます。
日本語でのやり取りも問題なさそうで色々な記事も出てますが、APIとか内部について触れている記事があまりなかったので調べてみました。APIについては下記をご覧ください。
速報:ChatGPTのAPIを叩いてみた
続:ChatGPTのAPI調査
続:ChatGPTのAPI調査・その2
今回は、内部について少し詳しく見ていきたいと思います。

何が起きたのか?

今週、ニューオーリンズで開催される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.
copy

こちらの通りInstructGPTモデルを入れる事で人間の指示に従い安全な物になったという事です。
更に、GPT-3の出力の毒性をInstructGPTモデルで緩和させているみたいです。
人間のフィードバックによりの通り、GPT-3に対して、人間がフィードバックを行い、強化学習させているという事ですね。これは、どのくらいの量のフィードバックが入ってるのかも気になりますが、調べてもあまり情報はありませんでした。

最後に

こちらのGPT-3は、APIという事もあり、誰でも自由にアプリが作れる事がとんでもない事です!!
既にあるチャットボットサービスなんかは、終わりですね。検索エンジンインターフェイスが変わるでしょう。
様々なアプリが変わる革命的な事が起きそうな気がします。
AI化の時代の入り口に僕たちはいると思います。

絶対に止めれないシステムの作り方

絶対に止めれないシステムとは

もちろん銀行システムとかのクリティカルなシステムもそうなのですが、今回は、そこまでではないのですが、データ連携上一部のapiは止めれないシステムを指します。
僕は直面したのが、Lineでのユーザー登録によるwebhookを受け取るって奴です。
昔のキャリアのユーザー登録であれば、止まっていた時には別途データが飛んできてまとめて処理とかも出来ましたが、Lineさんのはありません。ユーザー登録時のwebhookを取りこぼすと2度と受信出来ないのです。
同様にSNS等で登録時にwebhookが来て、対応する必要があるシステムもあると思います。

どうすれば良いか?

先ず思うのは、AWSでLambdaで受け取って処理すれば良いと思うでしょう。
これでも良いのですが、Lambdaがエラー処理で落ちたりすることもあります。

最初の構成

画像

この構成の場合は、通常時は良いのですが、トラブル時にデータをロストしてしまいます。

  • webhook側でエラー

  • ALBとEC2の通信障害

トラブル以外にもデプロイ時のwebサービスの再起動等の時もデータがロストしてしまいます。

改善したシステム構成

なので下記構成にしました。

画像


ALB->Lambda->SQS->Lambda->webhook(API)
1.最初ALBからlambdaを呼び出す
2.lambdaは、SQSでキューを登録し終
3.別のlambdaを定期的起動させ、SQSのキューをチェックさせる
4.キューがあったら、取り出し、webhookAPIをコールする

最後に

これによりシステム停止時にも問題なく稼働するシステムが構築できましたが、SQSでなくても、S3に保存したり、
他にもやり方はあると思います。
皆さんが考えたaws構成について教えて下さい

若手エンジニアに送る:「努力」×「運」×「対応力」で成果が決まる

昔、資格取得にはまってた時期がありました。
その時期は、とにかく資格に受かるのが楽しかった。社内でも誰も取ってない資格にチャレンジして、受かったりするとちょっとした優越感があったり、勉強する事による情報オタクにもなってる自分がありました。
新卒で入社した会社では資格で毎月の手当がでるので、何より手当が貰えるのも資格取得にハマった理由です。

結果を出してる人は努力している

そもそも、資格を沢山取ろうと思った経緯は、自分の価値を客観的に明確にできる手段としたいと思った経緯がありました。
社内でも評判も良く、給与ベースも評価されましたが、それ以上に自分の意見が通るし、結構わがまま放題に仕事ができたのが良かったと思う。
そんな時、同期から、「いいよなぁー。森川は頭が良いから・・」と言われてムカつきながらも呆れる毎日。心の中では、「俺も毎日努力しとんやぁーーー!!」と思ったりしてました。

運がよければ、結果が出るのも事実

運が良ければ、努力をあまりしなくても試験で良い点数を取れる人が沢山いるのも事実です。
運というのは、親ガチャではないですが、遺伝による頭の良い人がいます。当然ながら結果が出やすい。
スポーツも同じ最初からサッカーが上手な人もいます。ただワールドカップに出る様な選手は全員、とんでもない努力をしてると思います。運だけでは結果が出ません。

「努力」×「運」の掛け算が成果に繋がります。

成果が出ない場合は、「努力」を増やすか、「運」を増やす事により、成果の成功確立を挙げていく必要がる。
結果が出ない人は、努力を増やすしかありません。運が他の人の0.7の人は、2倍努力すれば、他の人よりも結果が出ます。掛け算は嘘つきません。諦めずに努力すれば、結果が出ます。
加えて、努力にも質が関わります。がむしゃらに努力するだけでは非効率です。幸いな事に昨今ではネット上に先人の知恵が溢れています。先人の知恵を借りながら、質の高い努力を心がけましょう。

もう一つ大事なのが「対応力」

社会人・企業人としてビジネスの世界で生きていくには、更に、「対応力」という尺度も必要となります。
ビジネスの世界は、試験ではない。問題・課題に対して、一変通りの答えは存在しない。様々な外的要因や内的要因、利害関係者によって物事が左右されていく。
そのため、当初想定していたストーリから状況を把握しながらも、結果に導くための「対応力」が必要となる。
もちろん、ここには、「努力」も必要だし、「運」も必要となる。「運」が強い人であれば、少ない「努力」と少ない「対応力」で結果を導く事ができるだろう。
世の中は、偶然と偶然と重なりあう事により、結果が左右される。
とはいえ、「運」だけに頼っていては、確立が非常に低い物となってしまう。稀にシュートが決まっても、安定したシュートが決まらなくては意味が無い。
対応力は、様々な状況を自分都合にコントロールする力です。ここがビジネスでは大事なスキルとなります。
沢山の「努力」を行って準備を行い、様々な局面に対応できる「対応力」を持った人こそ、安定した打率の結果が出せるビジネスマンになる事ができる。

成果を出すには、「努力」、「運」、「対応力」

結果=「努力」×「運」×「対応力」という事である。残念ながら運は、あまり磨くことが出来ない。伸ばせるのは、努力と対応力だ。質の高い努力と適切な対応力でビジネスの世界を乗り越えていく必要がある事を意識して仕事をしてみてください。

目標に悩んでいるエンジニアへ:楽しんで仕事をする事

昔、インフラの担当者がラックの写真を見せてくれた事があった。
そこには、綺麗に色分けされたLANケーブルがささったラック内のSW(スイッチ)が移ってました。
新設ラックを構築するにあたって、高アベイラビリティ、低コスト、高パフォーマンスのインフラ構築を彼女に担当してもらいました。
本来、経営レベルからのコスト削減を目指して始めたプロジェクトなのですが、どうせならという事で、LVSや、VRRP、ボンディング,etc等のオープン技術を駆使した物も一緒にやりたいという事で、スケジュール的にも非常にタイトなプロジェクトでした。ハードなプロジェクトを見事に対応してくれたのですが、苦労しただけあって、自分で設置したハードの写真を見て、「自分の子供の様にかわいい」と(笑
さぞ、大変で難しくもあったと思います。だからこそ、達成感も並大抵の物ではなかったと思います。

仕事には、自分が好きな仕事と自分が出来る仕事がある

自分のやりたい事が見つからないと言って悩んでいる人がいます。時に相談されたりします。
仕事というのは、

  • 自分が好きな仕事

  • 自分が出来る仕事

があります。最も良いのは、自分が好きな仕事がよいと思います。僕も小学生の頃にプログラマーになりたくて、そのまま今に至ります。イチロー選手も野球大好き少年からプロ野球選手になりました。
引退会見で、好きな事を見つけて欲しいと言ってますが、好きな仕事が出来るのは、一部の人達に限られる場合が多いです。
次にあるのが、自分が出来る仕事、向いてる仕事です。人と話すのが向いてる人は、営業だったり、コンサルだったり、話す仕事は色々とあります。

アウトプットとプロセス

  • 自分が好きな仕事 = アウトプット

  • 自分が出来る仕事 = プロセス

なんですよね。アウトプットを目指して、エンジニアになった僕ですが、実は物作りや何かをソリューションするというプロセスも好きです。これは、エンジニアでなくても叶ったかもしれません。
好きな仕事(アウトプット)を見つけれない場合は、出来る仕事(プロセス)中心に仕事を考えてみるのも良いと思います。

本来、仕事は楽しい事

子供の頃、初めてプラモデルを作って、その体験をベースに将来、車とかロボットを作りたいと夢を描いたり。
親の手を借りながら作った料理を家族に美味しいと言われ、将来、コックになろうと思ったり。
TVでワールドカップを見て、サッカー選手に憧れたり。

本来、仕事というのは、

  • 楽しかったり。

  • 好きだったり。

  • 感動したり。

  • 夢中になれたり。

だからこそ、大変だけど、頑張れるはず。楽しいからこそ、もっと、難しい事や大変な事にチャレンジしたくなれるはず。

  • 初めて自分の作ったプログラムがリリースされた時の感動。

  • 初めて自分の企画が採用された時の感動。

  • 初めて自分で営業して、クライアントから「御社に頼みます」と言われた時の感動。

アウトプットもプロセスの話しもありますが、最後は、楽しんで仕事が出来るかがポイントです。仕事に夢中になれたなら無意識に成長する事ができると思います。

シニアエンジニア必見:ファシリテーション力の向上のさせ方

CTO,VPoE、エンジニアマネジメント職の人々にとって人を動かすためのファシリテーテーション力は重要なスキルです。その割に、あまりファシリテーション力向上について意識をもってる方が少なく思います。

画像

ファシリテーション力とは

ミーティングを円滑に進めるための司会の役割です。参加メンバーの意識を高めて、発言の量を増やしながら、発散しない様にまとめていき、最後は、全員で合意できる結果までもっていく事が必要となります。
この役割の人をファシリテーターと呼びます。ある程度の企業になると経営会議に外部のファシリテーターを参加させる企業もありますが、エンジニアの部分は、分かりにくい部分が大きいのでエンジニアマネジメント職が適切なファシリテーターになれる必要があります。

最初は、目的の共有

ミーティングの目的を参加者全員で共有する事から始めます。ここが揃ってないと議論が発散しますし、目的を共有しても発散する事が多々あります。最初に全員でしっかりと目的を共有しましょう。
例えば、会議の名前が「開発効率化ミーティング」だった時に、

  • ある人は、開発においてのリソースの効率化だと思っている

  • ある人は、開発のコストの効率化だと思っている

  • ある人は、プログラミングの効率化だと思っている

どの部分についての効率化について話合うのが目的なのかをしっかりとファシリテーターから伝えます。全部の話をしたい時は、それを明確するのも必要です。
ある会議のやり方で、最初に全員でミーティングが終わった時に自分を発表させる手法もあります。これも良いですが、個人的には宗教っぽくて嫌いです。

時間割を明確にする

目的と同じで時間割も重要です。気がついたら終了時間になってしまうという経験は良くあると思いますが、最悪です。最後でドタバタして何も決まらないミーティングもあります。議論するのが目的であれば、それも良いのですが、基本的には時間割を明確にしてファシリテーターから伝えましょう。これは段取りを理解してもらうのと時間までに結論を出さねばならないと認識してもらうためです。
更にファシリテーターは、場の状況をみながら、時間割も動的に変更させます。ここはもう少し深堀りが必要そうだと思えば、後工程を調整します。ここの深堀り必要具合のジャッジが必要なため、エンジニアマネジメント職がファシリテーション出来るのが良いです。

発言しやすい雰囲気を作る

ファシリテーターから質問をしたり、あえて難題とか、反対意見とかをふって、それに対して答えてもらいます。あえて議論を発散させる事で発言しやすい雰囲気を作る事が出来ます。絶対に無理でしょ、みたいな話をふると反対意見から発言がしやすくなる訳です。
僕は、あえて会議室を歩き回ります、ファシリテーターが前に座って皆を見てると、話しにくい雰囲気も出ます。歩き回って、上長がいないフラットなメンバーのみの雰囲気を出せます。

議論をまとめる

目的の案に絞る

発言が活発になってくると議論が目的とずれたりします。目的とずれた案は捨てるのではなく、棚上げして、後日検討項目とします。

時間軸をあわせる

目的に沿っていても、時間軸に合わない案も出来てきます。半年間の事を決めたいのに2年くらい掛かりそうな案が出た場合は、こちらも棚上げして、後日検討項目とします。

可能性揃える

発言しやすい雰囲気になると、突飛なアイデアも出てくる事があります。実現可能があまりにも低そうな案については、一旦、棚上げして、後日検討項目とします。但し、時間が立ったり、会社のステージによっても可能性が変わり突飛なアイデアでも無くなったりしますし、可能性が低いとジャッジした事が間違いの可能性もあります。ここは慎重にジャッジしましょう。

終わりは、実行段階まで持っていく

最後は必ず実行段階まで持っていきましょう。

  • 役割を決める

  • スケジュール

  • ゴール
    これらが決まったらミーティングは成功です。但し、役割の担当者の腹落ちにも注意が必要です。流れで担当者になってしまったり、ゴールを理解していない場合もあります。最後に担当者の腹落ち状況をチェックしましょう

最後に

ファシリテーションのポイントいかがでしょうか? 多分、僕はファシリテーションは下手ではないと思ってます。このファシリテーションスキルですが、海外でもある程度通用すると思います。前職でモンゴルエンジニアでも同様にやりましたが、使えました。
エンジニアマネジメント職の方は、適切なファシリテーションで最大のアウトプットを目指してください

プロジェクト管理:品質とコストと納期

システム開発において、品質とコストと納期は、常に課題とされている。
今回は、品質とコストと納期の相関関係について考えてみます。

品質とコストと納期の相関関係

先ず、品質の高いシステムを作るためには、コストが沢山掛かると一般的に思われている。
それは、品質を高めるためには、綿密な設計や幅広いテストが必要だからだ。これには沢山の工数が必要であり、人数が沢山必要だし、スケジュール的にも長くする必要がある。
しかし、これは、間違った考え方です。
高品質のシステムという事は、バグが少なく、保守性も高い。バグが少ない分、TOTALでのテスト工数が減少する。
要するに、コストを幾ら投入しても、高品質のシステムは作る事はできない。高品質なシステムを作るのに、コストは、不要という事になる。

品質とコストは反比例

つまり、因果関係として品質が高いからコストが下がる。
これは、品質とコストは、品質が上がれば、コストが下がるので、反比例の関係にある事になる。

画像

品質と納期の相関関係

品質と納期の関係は、どうだろう。
上記の話の流れからわかる通り、品質の高いシステムは、納期も短縮できる事になる。テスト工程が短縮されるからだ。品質と納期も、同じく反比例の関係にある事になる。品質の悪いシステムは、いつになってもリリース出来ない。品質が下がれば、納期はドンドン大きくなる。

画像

品質が良いとコストと納期は少なくなる

つまりは、高品質のシステムさえ作れば、コストと納期についての問題は、クリアされる事になる。
1.品質とコストは、反比例の関係
 品質が上がれば、コストが下がる
2.品質と納期は、反比例の関係
 品質が上がれば、納期も短くなる
上記は、主軸を品質に置いて、考えた場合である。

コストと品質、コストと納期の相関関係

逆に、コストを主軸に置いた場合は、どうだろうか?
コストを無理に削減しようとして、リソースを削ったままで、当初の納期設定でシステム開発を行うと、出来上がったシステムは、品質も悪く、納期さえ間に合わないかもしれない。
それは、リソースが足りない状況の反面、納期が迫ってくるために、目に見えない部分のバグを隠してリリースしようとするためだ。
では、納期を主軸に置いた場合は、どうだろうか?
同じく、過度な納期設定をした場合、納期に間に合わせるためには、品質を落として開発を行うしか無い。
結果、低品質なシステムが出来上がってしまう事になる。

システムは品質ファースト

高品質なシステム開発は、適切なリソース配置と適切な納期設定を行う事により、実現される事になる。
プロジェクトに関わる人間が、この事を正しく理解する事が重要である。システムの成果物としては、品質重視のリソース配置、納期設定を行う事。これにより、高品質のシステムが、低コスト&短工期で実現される事になる。
コストを下げようとすると結果コストは上がり、納期を早めようとすると結果納期は遅延する。
品質をあげようとするとコストは下がり、納期は短くなる。