新人含めてリモートワーク体制にする方法 前口上 内定式のシーズンですね。本記事執筆時点で日本はまた感染者数が谷に入り、ちょうど入国規制が緩和されました。とは言え、リモートワークを部分的にしろ全部にしろ実施しているIT企業がまだ多いです。おそらく元に戻ることはないと思います。 実際、一つの統計では年収800万円以上のITエンジニアの8割がフルリモート勤務となっており、シニアエンジニアになるほどフルリモートワークを選択しています。 一方で新人はリモートワークはつらいという声もちらほら聞きます。メンターはリモート勤務希望なのに、新人は出社の方がいいという声がある、ねじれの構造があるわけです。 今回ねじれ解消の一つの方法論としてペアプロを提案してみます。 ペアプログラミング 最初に簡単にペアプログラミングについて説明します。 ペアプロ、ペアプログラミングは一つのプログラムを二人で同時に共同開発する

少数株主を無視できなくなってきた 前口上 2022年6月、フューチャーベンチャーキャピタル(FVC)の経営陣の総入れ替えがありました。4月に個人株主の金武偉氏が行った株主提案によるもので賛成率68%で可決となり、金氏は社長に就任しました。 株式会社において大きな決定をする際、持株比率が50%以上あるとほとんどの決定を単独で行うことができます。ライブドア事件の時に話題になったように実際は議決権ベースでの過半数だともう少し実際の持株比率が低くても大丈夫なのですが、それでも何かを通すときに持株比率は多い方が有利というのが基本です。 金氏は2.5%しか株を保有していなかったにもかかわらず提案を通しており、象徴的な事例なので復習しておきます。 持株比率でできること まず会社法の復習をしておきましょう。持株比率が低くてもできることがあります(少数株主権)。ざっくり以下が可能です(弁護士ではないのであく

SQLの次に獲得すべき技術スキルは何か 前口上 破談になりそうですが、Twitterの買収をイーロンマスク氏が実行しようとした際、マネージャーの解雇が話題になりました。 いわく、「IT分野の管理職は高いIT能力を持っていなければならないと思う。優れたコードを書けないソフトウェア部門の管理職なんて、馬に乗れない騎兵隊の隊長みたいなものだ」 最近のスタートアップだとエンジニア経験のないCTO/エンジニアリング・マネージャーは少数派だと思いますが、例えばITがメインでない会社のCIOをガチガチの文系出身の方がやられていたり、採用難でCOOがEMを兼務しているような組織はちらほら見たことがあります。 また、業務システムなどにおいて機能の深さが競争力になってくると、PMでもよりシステム理解がないと厳しいと感じたこともあります。 エンジニア経験がマイナスに働く場合もあるのですが、逆にエンジニア経験があ

評価制度設計の一例 前口上 仕事の報酬を考えた時、個人としてはもちろん5000兆円欲しい訳ですが、経営者視点で見ると投資効率へのプレッシャーを投資家から受けたり、事業が上手くいかなくなった際の倒産確率を低めるためにも、全ての従業員を5000兆円で雇うわけにはいきません。 一方で少子化やIT化の流れの中で、IT系の人材は需給上労働者側有利なのも事実で、伝統的日本企業モデルで新人から定年退職までにゆっくりと昇給するような賃金カーブは乖離が生じがちです。 海外や他社の事例を踏まえつつ、いいところを本記事では狙ってみます。 自分の得意な職種だけ厳しくしない まず評価制度を作る上で一番しがちなミスは自分の得意な職種だけ厳しくしてしまうだと思います。 エンジニア出身の人ならエンジニアの評価はわかるけれど、デザイナーやPMとなるとさっぱりだったり、営業出身の人なら営業目標は立てられるけれど人事や広報だと

GraphQLは銀の弾丸か 前口上 Webやアプリ開発において、サーバー間やサーバークライアント間でデータを受け渡す方式には色々なものがあります。 古くはSOAPやXML、最近のWEB APIはほとんどの場合JSONのREST API、マイクロサービスならProtocol BuffersでgRPCが多いところでしょうか。 GraphQLはFacebookによって開発されたAPI用の言語です。一般に少ないリクエスト回数で柔軟にデータを取得できるのが利点とされています。一方で、使い所を選ぶツールでもあるので今回取り上げてみます。 GraphQLの基本構造 まずJSON API とGraphQLを比較してみましょう JSON REST APIの例 GET /posts/1 request params なし response { "user": { "name": "user1" } "titl

独自理論を提唱してみる CTEO体制から成長時の苦悩 技術職のキャリアパスとして最近は技術専門性に特化したIndividual Contributorなども注目されていますが、逆に管理もやるような職種がCTOと呼ばれることが多いように思います。 スタートアップ初期のCTOは実装面でもリードしつつ、管理職もやるのでCTEO(Chief Technology and Engineering Officer, この記事内の造語)的であります。無事事業が成長しフェーズが上がってくると人数も増え、チーム分割やマネージャーのマネージャーをやる必要があり、もちろんチームを一つ任せられる人を既存メンバーから出すか、新たに採用する必要があります。 チームを任せる人をうまく見つけられなかった場合に、キャリアパスとしてエンジニアリングマネージャー(EM)かテックリード(TL)かの二分論だけでなくプレイングマネー

生え抜きでなくても活躍したい 前口上 日本企業の雇用形態は伝統的メンバーシップ型雇用から、ジョブ型雇用に変わったと言われることもありますが、割合歴史の浅いIT企業においても移行は完璧にはできておらず、とりわけ管理職やシニアポジションの募集をしていないという企業はちらほらみかけます。そういった企業では一担当として入ってからの昇進が基本的キャリアパスです。 管理職の評価が難しいというのもあるのですが、アメリカのTech業界では数年での転職が普通かつそれでも回っているということもあり、日本が技術立国するためにはそういった人材の互換性というか、シニアメンバーを受け入れる土壌が必要になってきます。他社で十分活躍している人を現在のロールより低いロールで雇うのは普通に考えて厳しい。 企業再生の案件ではプロ経営者が経営のうまくいっていない企業にジョイン後100日以内に具体的な事業再生の計画を建てます(10

チーム分割について思うこと TLDR Zennに「チーム分割の独自ガイドライン」を投稿しました。 自分が開発チームを分割する場合に、どういった目安で実施するか、どういったところに気をつけるかについて書いています。 zenn.dev Future Works 一番大事などうやって合意を取り付けるか、調整をうまくやっていくかのコツについては書けなかったので、またどこかでまとめたいと思います。 評価制度と連動しているところもあるので、それについても書きたいですね。

内側から見た富士通を読んだメモ 内側から見た富士通を読んだ 2004年の本でだいぶ古い本なのですが、富士通の成果主義の内部事情を書いた『内側から見た富士通「成果主義」の崩壊』を読みました。 元々年功序列だった富士通においてどう成果主義が導入され、どこが上手くいかなかった書かれた本です。著者という一人の視点でしかないのですが、タイトルからも分かるように上手くいかなかったことがほとんどというトーンで書かれてます。 富士通グループは2021年度だとで正規12.4万人、非正規1.2万人の大企業です。組織体制の話だとスタートアップが急成長する際のつらみなどはよく記事にされるのですが、大企業で細かく書かれた事例は珍しく感じました。 目次は以下の通りです。 急降下した業績 社員はこうして「やる気」を失った 社内総無責任体制 「成果主義」と企業文化 人事部の暗部 日本型「成果主義」の確立へ ひたすら問題を

まず止血する 前口上 Webサービスを運営していると気をつけていてもしばしば障害が発生してしまうことがあります。 全てのケースを網羅したつもりだったのにコーナーケースを考慮できておらずエラーとなったり、開発環境の少ないデータでは問題なかったのに本番環境でデータが増えるとパフォーマンスの問題で捌ききれなくなってしまったり色々です。 そういった障害は避けるべきものではありますが、やんごとなき事情により起きてしまう場合もあり、そういった際は障害の対応が必要になります。 よくある間違い: 自分の実装が常に正しいことを仮定してしまう そういう意味で臆病さというか、駄目だった時のことをあらかじめ考えておくのは大切です。 データベースのスキーマの変更とアプリケーションの変更を一緒にしないだったり、大きめのライブラリーのアップデートと通常のデプロイを分けるだったり、切り戻しのしやすい変更に落とし込むのは良

よく使うgemをまとめてみる 前口上 先月まとめたように、SaaSブームの中でアプリからWebへの回帰が少し起きている感覚があり、アプリのバックエンドでAPIだけなら軽量フレームワークでいけた場合でも、画面の描画もやる場合はなんだかんだでフルスタックフレームワークの方が融通がきくように感じています。 とりわけB向けサービスではアクセスがそれほどないが業務要件が複雑という場合もあり、ORMの能力がダイレクトにビジネス上の競争力につながるため素朴なRailsでActiveRecordの構成がはまるケースも多いです。 Ruby on Railsでの開発は枯れに枯れているのですが、まとめたことがなかったのでよく使うライブラリー(gem)について書いておきます。 gemの選び方 他社事例を調べるのも大事ですが、Ruby Toolboxでだいたいの人気感を探るのもよいです。 www.ruby-tool

面白そうな技術ブログをまとめてみる 前口上 普段技術情報を追うのにニュースレターやSNS、ソーシャルブックマークをベースに使っています。ニュースレターは英語、SNSやソーシャルブックマークは日本語が多いです。 これで概ね面白い記事や動画、ポッドキャストなどはカバーできているのですが、英語圏の企業ブログだと見逃してしまう場合もありました。ニュースレター自体は英語であるもののオープンソースのリポジトリーや個人ブログの紹介が多く、はてなブックマークだと日本の企業ブログはのびるものの、英語圏の企業ブログはあまり注目されていませんでした。 自分が割合フルスタック志向で時期によって興味が変わり、ちょうど人が作ったおすすめにのるだけだと限界を感じはじめていたので、手始めに個人Slackに技術ブログを流すようにしました。 調べる中でリストができたのでここに共有しておきます。 対象 企業や組織のブログ 年間

ぼくのかんがえたさいきょうのの日本再生プラン 前口上 日本において子供が産まれる数は年々減っており、移民の受け入れも消極的なため、人口が減ってきています。 国力は概ね人口に比例するので、ほっといてもGDPが成長する発展途上国と違い、凡庸な動きをしている限り衰退していきます。また生産性も悪いため今のペースだと一人当たりGDPで韓国に数年で負けるそうです。 一方で少子化、高齢化自体はどの先進国でも抱える課題であり、移民を除けば人口が減少している国はそう珍しいものではありません。その中でも、フランスやスウェーデンは上手くやれている(いた)国として上げられることが多く、他国の政策から学べることはないか独自論点交えて見ていきたいと思います。 少子化は本当に回避しないといけないのか 他国の比較をする前に少子化は本当に回避しないといけないのかという論点も必要なので軽く論じておきます。 人が減って何が困る

死なないメタバースの作り方 前口上 メタ社がメタバースに力を入れると発表した際は猫も杓子もメタバースだったのですが、Googleトレンドの推移を見ていると少し過熱感が落ち着いてきたようにも感じます。 メタバースがいつ実現するかは各社意見がバラバラなのですが、メタ社の言い分だとメタバース実現に10～15年かかります。ESGファンドなんかは長いこともありますが、VCの投資期間は通常10年。スタートアップがVRメタバースをやるには実現が困難な可能性もあるわけです。 一方でgatherのような2Dタイル表示の交流プラットフォームはオンラインカンファレンスの懇親会でも使われている印象で、メタバース=3Dに拘らず、端末のサポートレベルが複数あるような2D<=>3D互換メタバースがあるとスタートアップでも死なずに事業を継続できるのではと思い検討してみます。 メタバースの類型 自分の観測範囲でメタバースの

プロダクトの変遷でアーキテクチャーがどう変わったか 前口上 Web開発においてとりうるアーキテクチャーにはいくつかパターンがあります。 サーバー構成をモノリスかマイクロサービスかで分ける場合もありますし、データベースを内製で持つか外部のmBaaSに任せるかで変わる場合もあるでしょう。認証部分をOAuthに切り出したり、全文検索部分だけ外部サービスを使うこともありますね。 とある時は新しい技術Aを使うことがいけてるという時があれば、少し経つとその技術が終わったことにされる場合もあります。 こういった技術のトレンドにはその時にビジネスチャンスが広がったプロダクトのトレンドに影響されていることも多く、サーバー・クライアント比率の観点で見るとうまく整理できることに気づいたのでまとめてみます。 System of RecordとSystem of Engagement のっけから人様の資料で恐縮です

アルセウスで遊んでみる Pokemon LEGENDS アルセウスとは www.pokemon.co.jp Pokemon LEGENDS アルセウスはポケモンの新作ゲーム。 古き良きポケモンはRPGよりでジムリーダーを倒してポケモンバッジを集めたり、ポケモンバトルに重きを置いているが、アルセウスはどちらかというとアクションゲームより。 ジムリーダーはおらず、大型ポケモンの攻撃をリアルタイムに避けて鎮静薬を投げる。ポケモンバトルも少しあるものの、道にポケモントレーナーは基本的におらず、大量のたんぱんこぞうに鉢合わせすることもない。 ポケモンを捕獲してコンプリートする部分に重きが置かれており、気づかれないように忍びよったり、逆に問答無用で攻撃してくるポケモンに気をつけなければならない。 そんなアルセウスを英語でプレイしたログ 単語 pasture 放牧場 quarters 自宅(拠点) sa

チャット機能の難しさについて 前口上 新しい技術やプロダクトトレンドを追うのが好きで、よくピッチイベントを見たりするのですが、その中でプレゼンされるプロダクトの中にはチャット機能を持つものがしばしばあります。 システムは何かしらの利用料を得て生存するので誰かと誰かを繋ぐという意味ではわかりやすい機能なのですが、必ずしもリアルタイムである必要がない場所でも出てきがちな印象があります。 おそらく非エンジニア、特にITリテラシーが高くない創業者が一番よく使うアプリがLINEなんだと思います。 Facebookメッセンジャーやカカオトークなどもあるにはあるのですが日本国内ではLINEのシェアが高いです。 競合が現れない理由には技術的難しさもあって、以下チャット機能の難しさについて書きます。 法律の制限、個人情報の取扱 弁護士ではないので、この情報は参考程度のものですが、公開されている掲示板形式と違

チームで知見を貯め、会社を会社として成立させる方法 前口上 小説家なんかだと割合個人プレーの場合もあるのですが、何かを制作するためには複数のスキルが必要なことも多く、個人単体で全てをカバーできないので、規模の大きいビジネスは徒党を組むことが多いです。 ソフトウェア開発も例外ではなく、一定規模のアプリやWebサービスは複数人で作るのが通例で、規模が大きくなると認識の違いによって不具合だったり、本来同じレベルの人でも開発速度に差が出たりするものです。 社内Wikiへのノウハウのストックを推奨するのは属人化を避けミスを防ぐ優れた方法ですが、ツールを導入したもののストック化が進まないという会社もしばしば見ます。そういったケースでの一つの参考として個人的ドキュメントの育て方をまとめておきます。 持続的活動には持続的投資をする 情報のやりとりにはフローとストックがあり、前者がチャットツールで後者が社内

雇用する側圧倒的不利な状況の改善手法 前口上 技術者の求人倍率は高く、IT・通信では10倍、Web系に絞ればもっと高くなっています。一人の人間を10以上の企業が取り合っているということです。 この需要はスタートアップが牽引しており、転職の平均を見ると大企業から若い企業への人流が多いです。VCの方の話を聞いても採用目標を達成できたスタートアップはほぼいないということで、雇用する側の難易度の高さを物語っています。 IT業界に限った話ではないですが、少子化もあり、企業側が強気でも人を雇えていた時代は終わり、労働者側に歩み寄っていく必要があります。以下簡単に歩み寄り方をまとめてみます。 大前提: 最高の職場を作る はじめからはしごを外してしまうと、小手先のテクニックよりまず労働環境を整えることが重要です。給料ももちろん重要なのですが、仕事内容や働き方、採用技術や一流の人と働けるかも重要です。 とり

アニメで三味線に入門してみる ましろのおとについて ましろのおとという津軽三味線をテーマにしたマンガがあり、2021年4月から3ヶ月間アニメが放送されていました。 アニメに連動してTwitterに三味線講座も上がっています。 togetter.com アニメに感化されしゃみせんBOXという簡易三味線を買って遊んだのでそのメモです。 まずは演奏でも 下手なりに弾いたのでまずは動画でも。本当はバチで弾くんですがなんちゃってでピックで弾いています。 www.youtube.com 本物も欲しくはあるのですが、値段がそれなりにするのでしゃみせんBOXという簡易三味線でまずは気分を味わっています。ふるさと納税でも買えます。 shami1000rakuya.com このメーカーは商品開発に積極的でもっと紙の三味線も作っているのですが、それよりは本物に近いです。エレキ三味線なんてものもあります。 三味線