成長組織で取り組むべき「標準化」について

不動産テックで事業部CTOをやっていたと思ったら、HRBrainでEngineering Managerになってそろそろ３ヶ月が経とうとしています。
HRBrainはEQTという約37兆円の資産を有する投資会社が資本参画したHR系のSaaSスタートアップです。CTOやマネージャーを長年勤めてきたことで、タレントマネジメントや評価、労務管理のためにHR系のプロダクトを触る事が多くなり、元々ドメインには興味を持っていました。

常々これらのプロダクトを「もっと良くできるのでは？」と感じていたのもあり、今回転職をすることにしました。入った直後からやるべき事は多くありなかなか大変な状況ですが、「採れる選択肢」も多いことで、楽しく働いています。
人材データプラットフォーム関連市場は約8兆円もあると言われており、日本の労働人口問題と絡めて考えてもまだまだこれから伸びていく市場だと実感してます。

本題ですが、新しい組織に飛び込むたびに考えているのは「何をいつどう標準化するか？」の話です。
スタートアップでは「自主性」を尊ぶわけですが、ある程度の規模のサイズまで組織が成長すると「標準化」と「属人化」のバランスを取らなければならなくなります。
何もかも自由だった時代とは別れを告げなければいけません。
そうでなければ、結局速度が出せなくなり組織としてもチームとしても成長が鈍化するからです。

そもそも「標準化」とは？

手順や水準を定め、社内で認識を統一することです。
例えば、新機能を開発する際において「まず、PdMがPRDを書く。全社からレビューやコメント（Request for Comment）を受け付ける。その後、意志決定者からレビューを受け開発承認される」というフローを定めます。

このフローを決めることの最大のメリットは「早期に重要なフィードバックを得て無駄を省ける」ことです。

「何を作るのか」がチーム内で共通の認識となりますし、「何の機能が、いつ、どのようにリリースされ、どう使われるのか」が関連部署（他のチームやセールスなど）に共有されやすくなります。
新入社員であっても「PRD一覧」をチェックすれば何の機能がどのチームで開発されているか、いつリリースするつもりなのかを知ることができます。

デメリットとしてはチームが「あれやろう」「これやろう」というレベルで意志決定をしていたときに比べると「めんどうくさい」と感じるようになることです。

どうして「標準化」などという面倒なことをやらなければならないのでしょうか？
あれこれ決めるのはチームで好きにやった方が早いのではないでしょうか？

実際には成長組織において属人化が増えると都度都度意志決定が必要になるだけでなく、認識がバラバラのまま組織全体が違う方向に進んでしまったり、防げたはずの間違いを犯しての手戻りも多くなるため加速度的に非効率化が進みます。

標準化を行うのはあなたの大切な時間を節約するためでもあります。

まず標準化を検討すべきもの

これは３つあります。

• 人材、等級、期待値
• コミュニケーション
• パーパス、ミッション、バリュー

人材、等級、期待値の標準化

小さなスタートアップだった時は面接や評価のやり方も判断も何も標準化されていません。
採用であれば知り合いに声をかけたり、仕事が出来そうな経歴の人が組織に加わったりします。
評価も「今期は頑張ったね、来期も頑張ろう」で終わったりします。
やがて、人が増えると徐々に組織に不満が生まれます。

「評価のされ方が明確ではない」
「何を期待されているかわからない」
「新しく入ってきた人のスキルレベルが低い」
「人が足りないのにチームには人がアサインされない」
（以下、無限に続く）

決めなくても何もかもうまくいっていた時代は遠い昔のことになります。

この標準化の第一歩は意志決定者（できればあなた）が「採用のフィルター」「評価のオーナー」になることです。
「どういう人材を、どういう期待値で、何をやってもらうために、いくらくらいの給与で採用するのか」
「誰をどのチームに配置し、リーダーに任命し、どういう行動や成果を高く評価するのか」

必要なポジションの採用のためにJDを明確にしたり、社内での等級や給与レンジなどを踏まえて、期待値を明確にし、キャリアラダーを記述することになるでしょう。
目標設定の妥当性や、従業員の成長実感、評価の納得感などは「説明可能」で無ければならず、「評価者Aさんはこう言ってたけど、評価者Bさんは違うことを言ってて、あそこのチームはズルい」といったことはなくすべきです。

採用や評価に一定の基準を設けることで、組織をより強い状況に導くことになりますし個人の成長にも大きく影響します。

コミュニケーション

コミュニケーションにまでルールが必要でしょうか？

もちろん、必要です。
人が増えてくると、「聞いてなかった」「知らなかった」「共有されていないのはおかしい」「必要なMTGに呼ばれていない」などと、様々な問題が生じます。
組織が拡大するにつれ、人間が認知できる人数の上限（ダンバー数）を超えることになるからです。

人が増えればチーム間のコミュニケーションパスが標準化される時もやってきます。
Slackでチームチャンネルを作って、その中で話をしていれば良かった時代は終わりです。
「オープンに話されているんだから、必要な人は情報を持って行ってね」では組織は回りません。

プル型の情報、プッシュ型の情報整理は不可欠です。
普段から情報の洪水に襲われている私たちが「必要な情報を必要な場所からつかみ取る」なんてことはできません。

• プル型：この最新情報（例えば、各チームの体制や取り組んでいる機能）はNotionのプロダクトページに置いてあるから必要に応じて見てください。
• プッシュ型：Aさんがチームリーダーになりました。これからはHogeプロジェクトの開発の牽引と○○機能の開発を推進していただきます。

……のように使い分けをするべきです。

特に複数チームが連携をするようになると途端にパスが複雑になります。
「聞いている」「聞いていない」だけではなく、「思っていたのと違った」ということが頻発します。

これを何とかしようと思って会議を増やすと「共有ミーティング」だらけの毎日に突入し、あっという間に時間を浪費します。
にも関わらず「共有していたはずなのに」複数チームが絡むような開発が遅延したり、失敗するようになります。

コミュニケーションパスを適切に標準化するのはあなたの「認知負荷」を下げるためです。

パーパス、ミッション、バリュー

パーパス、ミッション、バリューも標準化されるべきものです。
これは簡単に言えば「文化と価値観の標準化」です。

これらを定めなければ「組織が何に魂を持っているのか？　何と戦っているのか？　どうやったら勝つのか？」がわからなくなります。

特にバリューは日々の判断基準や評価、言動にも深く関わってきます。
これらを宗教的だ、気持ち悪いといって敬遠する人もいますが、バリューが本当に上手く機能している時は「組織に異物がない」と感じるようになります。
なぜなら、全社員が同じ方向を向き、同じ判断基準の下で同じことのために仕事をしていると感じられるからです。

スポーツで想像してみてください。
サッカーというスポーツはボールをゴールに入れ、その点の多寡で勝利を競います。
もしこのルールが定まってなければ、選手はフィールドに立ちすくむだけでボールを手でつかんで投げたり、キャッチボールを始めるかもしれません。ルールが無ければゴールの前にキーパーはいないでしょうし、誰かがネットによじ登って遊び始めてもおかしくありません。

そのための組織のルール制定が「文化と価値観の標準化」です。

組織とは、得意不得意が違う人たちが集まって、１人ではなし得ないような大きな目的を達成するためにあるのです。

他に標準化が検討できること

プロジェクトの管理や目標設定、マネジメントラインなど標準化を検討できることは山ほどあります。

オンコール体制やインシデント対応、問い合わせ対応、セキュリティ対策なども検討すべき項目です。これをしない場合、「特定の人だけが対応している」という状況に陥り、○○さんにお願いするしかない、ということが頻発します。

最初からすべてを上手く標準化することはできないので、「単純なことで失敗した」という経験の積み重ねから、誰かが手を挙げて実行することも重要です。

都度都度で意志決定をしたり、誰かに判断を仰いだりするようなことが減ればそれだけ日々の仕事は快適になっていきます。

ただし、完全な標準化はできないため、常に例外も含めて想定すべきです。
組織が成長する限り「標準化は陳腐化する」ことを忘れてはいけません。

絶対に標準化してはいけないこと

反面、標準化を絶対にしてはならないこともあります。

例えば個人の働き方に関して「子供のことなど気にせず、業務時間は業務に集中すべきだ」などと言えば家庭は崩壊し、やがて生産性の低下を招きます。
働き方を標準化しても逆効果なだけです。
同様にチームの中で完結するような細かいやり方を標準化しても意味がありません。

優秀な人材にも「標準」を当てはめない方が良いです。
時には遊撃隊のように動き、時には組織全体の問題に取り組み、対外的な個人活動も行う。
これは「特別扱い」や「好き勝手にやっている」とみられることもあるのですが、トップパフォーマーというのは平均的な開発者と比べて数倍の効率を持っているので、それを妨げるべきではありません。

給与もテーブル上の上限はこれだから、といって制限することも間違っています。
その小さな拘りによって、最大の戦力を失う羽目になります。
最終的に組織が勝ちきるためには「組織を牽引できる存在」が必要なのです。

理由なき標準化もまた悪です。
「他の企業がやっているので」という理由で「誰も困っていないのに」標準化しようとすると、反発を招きます。
特に「本で読んだので」「こないだAという会社でやっていると聞いたので」というような理由で「俺の考えた最強の組織にします」などとすることは止めるべきです。

最後に

大切なのは「標準化すること」と「標準化すべきでないこと」の判断を明確にし、組織の成長にあわせてうまくバランスを取っていくことです。
困ってなければ標準化すべきではありません。すべきことに集中してください。

これらのバランス感覚は物事が変化し続ける環境に身を置き、判断を重ねることで身についていくものですが、特に新しい環境に飛び込んだとき、リーダーシップを持ってこれらに取り組むと良い効果を得やすいので、是非試してみてください！

本記事は、HRBrain Advent Calendar 2024 シリーズ2の23日目の記事でした。

qiita.com

CTOやVPoEと違いEMには再現性がある

こちらはEngineering Manager Advent Calendar 2023 12日目の記事です。

こんにちは、Isoparametric（Yuki Tamura）といいます。
今回はEMはCTOやVPoEの下位互換ではないということについて書きます。

私は今estieというスタートアップでEMをしております。
前職では不動産テックのCTOをしていて、その前はスマートニュースという会社でEMをしてました。
その前は、ディライトワークス、gumiという会社でCTOだったりしたこともあります。

では、CTO/VPoEとEMの互換性/再現性についてなのですが、
皆さんはEM(Engineering Manager)というとどんなイメージを持つでしょうか？
「マネジメントのキャリアパス」「CTOやVPoEの下で働くマネージャー」といった感じでしょうか？

「EMのキャリアパスはEMのEMになって次はVPoEだよ」などという話を聞いたことがあるかもしれません。
まるで、EMはVPoEやCTOの下位互換のように扱われていますが、最初に言ったとおりそれは違います。
なぜなら、EMにはCTO/VPoEとは異なり高い再現性と互換性があるからです。

CTO/VPoEとEMの違い

晴れてCTOの肩書きを手に入れたとして、CTOやVPoEの集いに顔を出せばわかる通り、それぞれの会社で求められているCTOやVPoEの役割というのは大きく違ってきます。
CTOという肩書きでも実質的にはテックリードだったりしますし、メンバーがいないVPoEなんていうケースだってあります。
逆に現場には一切関わらない上意下達だけをする存在ということもあるでしょう。
しかし、EMはそうではなく「どこにいても役割は大きく変わらず再現性がある役割」なのです。

何故かといえば「EMの責務は、チームのアウトプットを最大化すること」だからです。
もちろん、CTOもVPoEもマネージャーロールではありますが、彼らが見ている単位は「チーム」ではなく「組織」です。
「組織」という単位は非常に曖昧で、その数も形も一定ではありません。

しかし、EMは違います。
「高いアウトプットを出せるチーム」と限ってしまえば、その定義は比較的明確に定まるからです。

では、どういうことか説明していきましょう。

生産性の高いチームの定義

「生産性の高いチーム」を生み出したい場合、EMはおおよそ6~8人のエンジニアをマネジメントする必要があります。それが１チームの適性人数範囲だからです。
もしこれ以上のエンジニアをマネジメントすれば、業務過多になりチームやチームの責務に積極的に関わることは難しくなりますし、少なければチームとして機能しにくくなり出力も限られます。
例えば、私は最大23名のレポートラインを持っていたことがあり、それらのメンバーは4~5のチーム（プロダクト）に跨がって関わっていたので、どのチームを主軸にして良いか分からなくなりました。（マトリクス型組織だったのもあります）
また、それぞれのチームに対して新しいメンバーをアサインするために採用を行わなければならないため、採用のニーズは4~5倍になりどうしてもチームに対する関与が薄くなります。

勿論、スタートアップは常に変容する生き物のようなので一時的にこのような大人数を引き受けることも合理的な判断なのですが、長く続ければ将来的には必ず組織的負債を抱えることになります。

マネージャーはチームを拡充し開発力を最大化しなければならないので、チームを8人から10人くらいに成長させ、やがてこれを半分の人数に割るということを行います。
ただ、考えもなしに成熟したチームに対してそんなことをすれば、チームの生産性は台無しになると言っても過言ではありません。
また、頭数だけを揃えたチームを半分にしても生産性はでないでしょう。

スタートアップが「EMが必要です！」と言っている場合、それは「組織を成長させたいから」に他なりません。
「組織を成長させたい」というのは単に「頭数を増やしたい」ということではなく、「生産性の高いチームを複数生み出して、必要なことを同時にやりたい」ということですから、１人のマネージャーが大量のメンバーを引き受けて、それを分割していくようなやり方では絶対にうまくいかないのです。

チームにも状態がある

そもそも、チームには「状態」があります。
例えば、あるチームは常に「人手が足りません」と言っていますし、よくいるPdMたちは「新しくやりたいことがあるんだ」と言いますし、長く所属したエンジニアは「技術的な負債が大変なんです！」と言ったりします。
こういう状況が複雑に絡み合った状態がチームには常に存在しています。

ただ、これらのチームが目指していることはたった１つで「安定的に高い生産性を発揮すること」であり、「新しい機能に取り組みながら、技術的負債を返済し、ユーザーに向き合うためのゆとりが欲しい」と言っているわけです。

残念ながら、物事はそう理想通りに動くことはありません。

チームが「人が足りない！」と悲鳴をあげている状況の時、EMは「自分もコードを書くよ」といってチームに飛び込むべきではなく、あくまでも俯瞰して症状を適切に把握し、戦術的にチームが適切な状態になるように状況を導くことが必要になります。
では、いくつかの症状を見てみましょう。

そもそも人が足りていないチーム

チームが与えられた仕事を十分にこなせていないときは、そもそも人が足りていない可能性があります。この人が足りていないというのは人数だけでなく、必要なスキルセットの人がということもあります。
勿論、単純にやり方が拙いということもありますから、良い人を「採用する」「他のチームから人を移動させる」ことが常に最適解とはなりません。
EMは状況を正しく把握し、足りない人材（メンバーなのか、リーダーなのか、それとも特殊なスキルなのか、の）適切なJDを書き、必要なHC（ヘッドカウント）を確保して、チームの拡充に舵を切るべきなのです。
そうでなければ、いずれ誰かが辞めることでチームが崩壊してしまうでしょうし、いつまで経っても高い生産性など得られる筈もありません。

人数がいる筈なのにチーム

では、人数が既に6人〜8人いるチームはどうでしょう。それぞれのスキルセットを見ても、決して悪くないようです。
しかし、チームの話を聞いてみると「既存の仕組みが良くない」などの声があがったりします。
「技術的な負債がありすぎて、ちょっとしたことをするのにも凄く時間がかかるんです！」と泣きつかれることもあるでしょう。
「○○さんにお願いしないと物事が進まないんです！」なんてこともあります。
これもよくある症状で、アウトプットを出したくてもボトルネックが凄くてブレーキをべた踏みしながらアクセルを吹かしているようなことになっています。
このような状態で闇雲にチームに人を追加してもさらに空回りをするだけですから、EMはチームの優先順位を整理する必要があるでしょう。
もし、技術的な負債が原因なら「新規開発を完全に止めてでも負債の返済に集中するべき」なのかもしれませんし、「チーム外から常に何らかのタスクが割り込んでくる」ようであれば、その露払いをしなければならないかもしれません。
もしくは、「チーム内でブリリアントジャーク（優秀だけど周囲に悪影響を与える人）が暴れている」なら、その人を諫めるのかチームから外す必要があるでしょう。

そこそこうまくいっているチーム

時に何の文句もないチームというのもあります。
このときにメンバーは「何も問題はありません」と答えたりしますし、傍目にもやるべきことはないように思えますが、そうではありません。
チームが一定以上の十分な生産性を有している時は、マネージャーは「新機能の開発」と「技術的負債の返済」のバランスを保つ必要がでてきます。
もしくは、「育成」や「成長」、「挑戦」のバランスをとる必要があるかもしれません。
このような状態は安定しているように見えますが、問題が無いチームというのはほとんどなく、単に「うまくいっているように見えるだけ」かもしれません。
ある日突然、テックリードが「成長を感じられないから辞めたい」と言い出して、突然慌てる羽目になるかもしれないからです。
このような不意打ちを食らわないためにも慎重に見極める必要があります。

チームが完璧に機能している！

いやいや、うちのチームはモチベーションが高く挑戦もできているし、負債も溜まってない。
本当に最高の状態なんだ、ということがあるかもしれません。
この場合にマネージャーは何かをする必要がないように見えますが、実際にはチームを維持し続けるために水面下で様々な努力をする必要があるでしょう。
何故かと言えば、問題はチームの中だけにないからです。

有事に備える

EMはどれだけチームが機能していても決して油断してはいけません。
突然CTOやVPoEが「組織改編だ！」「レイオフだ！」と叫び出すかもしれないからです。
勿論、ビジネス側の都合で「プロジェクトAはもう止めだ、チームは解散する」なんてことが起こりえたりもします。
こういう寝耳に水の事態に備えるのもまたEMの仕事です。

EMがチームをマネジメントしているのとよく起こるのが鶴の一声です。
力のあるCEOが突然「○○という機能を月末までにリリースするぞ！」と言い出したりします。
こうなったら大変です。チームを解散するとまではいかないまでも、タスクフォースいう名の下のチームのエースが招聘されたり、先月まで最優先だと言われていた機能の開発が止まったりと、すべてのチームが大混乱に陥ります。
勿論、EMにこの鶴の一言を覆すような権限はありませんから、やれる対策としては「備える」ことに他なりません。
また、CTOと話をしてチームを守ることを検討できるかもしれません。
「最近のCEOは何を考えていますか？」と訪ねることで事前に予測ができるかもしれませんし、いざ起こってしまった後でも、「うちのチームから○○は出せません。なぜなら、今○○がチームから離れたら主軸となっている××の開発は確実に遅れますし、それが他のチームにとっても大きなブロッカーになります」などと直談判に向かうことで全体の崩壊だけは避けられるかもしれないからです。
このように様々な内的要因、外的要因によってすべてのチームは常に危険にさらされていますから「チームを最大パフォーマンスで動かし続けられる」企業は存在しません。
この危ういバランスをとっているのはEMという仕事なのです。

意図しない人員追加に対応する

上記のような危険なことが起きなかったとしても、あなたが成長する企業で働いている場合、CTOが突然言い出すかもしれません。
「新卒採用をしよう！」「インターンをやろう、どっかに受けいられるチームくらいあるだろう？」「もっと人が必要だから外国人採用をしよう」
こういう時に「もう人はいりません」「いまは難しいです」などと断るのもEMの仕事です。
「人が追加されるんだったら嬉しいでしょ？」と思うかもしれませんが、嬉しいのは「組織の都合」であり「チームの都合」ではありません。
チームが「組織の都合」に振り回されればやがて疲弊し、輝きを失っていきます。

要するに成長する組織からチームを守るのも立派なEMの仕事なのです。

EMの仕事はCTOやVPoEが命じた通りにチームに対して大鉈を振るうのではなく、そのチームがいかにすれば最大のパフォーマンスを維持できるのかを常に考え続けることなのです。

CTO/VPoEとEMの違い

ここまで話してきた通り、EMは常に「チームファースト」であるべきです。
自律性が高く持続性があり高い生産性を出せるのは「チーム」という単位であり、このチームという単位のパフォーマンスを維持しつつさらに向上させるのがEMの責任です。
このチームに人を入れるのも、チームから人を抜くのも、もしくは２つのチームに分けるのも本来はEMの判断次第ということになります。
しかし、人には人の人生があり時にライフイベントによって退職を決意したり、チームの移動を願い出られたり、新しいテックリードの擁立を余儀なくされることもあるでしょう。
いついかなる時にどこからチームに脅威が忍び寄っているかは分からないのです。
それに常に警戒し続けるのがEMの仕事です。

そして、CTO/VPoEはこの視点を持てないことがほとんどです。
なぜなら、視座も違えば解像度も違うので、チームの細やかな内情など考慮に入れることが難しくなってきますから。

適切な評価を与える

また、CTO/VPoEと異なりEMだけに与えられたさらなる苦難があります。
それは、チームに対して適切な評価を勝ち取ることです。
多くの企業においてEMは評価者でありますが、最終的な評価決定者ではありません。
よって、自身のさじ加減によってチームの評価を良くするということはできず、チームの評価はCTOやVPoEから勝ち取る立場なのです。
特に、EMが苦労するのはチームが"keeping the lights on" （灯りを点し続ける）と呼ばれるような地味な仕事をしている場合でしょう。
「今期、君のチームは何も新機能をデリバリーしてないから」と低評価をつけられようとしているチームがいたとしたら、EMは必死で「そうではないこと」を立証しなければならないのです。
実際に「灯りを点し続ける」というのは偉大な仕事であり傍目に何も変わっていないように見えても、そんな筈はありません。
現実世界だって、灯りが燃えるには燃料が必要なことくらい誰にだって分かるでしょう。
時にチームは灯りを吹きすさぶ風から守ったり、それがもし消えてしまった時に備えていたり、より明るく広範囲を照らせるようにしていたり、様々な努力を重ねています。
ただ何もしていないのに、そこに灯りが燃え続けることはありません。
そして、それを知りうるのもCTOやVPoEではなくチームをマネジメントするEMなのです。

最後に

自分はEM（エンジニアリング・マネージャー）だけれどもそんなこと考えたことがない、という人もいるでしょう。
それは、おそらく所属している企業自体の変化がとても緩やかだからです。
そういう意味では環境が違えばEMには互換性がなくなってしまうように感じるかもしれませんが、私はそうは思いません。
学び続けているEMはどこの企業でだって高い再現度でチームをマネジメントすることができます。

スタートアップは半年や１年で社員数が倍増することが多く、１年ごとに別の会社になった、と感じることも少なくありません。
要するに、気がつけばやってきたことはすぐ古くなってしまうのです。
であるが故に、多くの学びがありますし、その濁流の中でそれに飲み込まれないようにチームが成功することを助けるのは最もやり甲斐のある仕事の１つだと私は思っています。

急成長する組織の中でチームをうまく支えるというのは、「銀の弾丸」を見つけるような仕事ではなく、小さく成功を積み重ねていく地道な道しかありえない仕事です。
この地味さ故に実際にはEM自身が"keeping the lights on" という仕事に最も近く、大変苦労する要因でもあるのですが、それだけにEMが正しく理解されることを願ってやまないのです。

EMに転職して1年と5ヶ月が経ちました

ということで、2020年の8月に転職をしましてEngineering Managerになりました。

あっという間に、1年と5ヶ月が経過した（2022年1月現在）感じです。

転職理由は色々ありますが、一番の理由は「人間お金を持つとおかしくなる」ということでしょうか。
希有な機会を与えてくれたことに少なからず恩義を感じているのではありますが、「いつ誰とバスに乗るか」が重要であるように「おかしさを感じてでも同じバスに乗り続けるか」もまた重要でしょう。

また、狂っていくのは本人には自覚できない故に自分も狂っているのではないかということもまた重要です。

もちろん、40を超えて新しいことをしなければならないという気持ちもありました。

 

さて、今回の私自身の新しいチャレンジは「英語でのマネジメントを身につける」ということです。

私が最初に入社したときの構成は、チームメンバーが5人。そのうち、英語話者は1人でした。

英語での仕事などやったことがない人間がそもそもそのようなチームを受け持ちよくしていけるのか、成果を最大化していけるのかと考えさせられる日々です。

それがこの一年半の間にチームは20人になってしまいました。英語話者も9人になりました。

マネージャーとしては1on1をどのようにしていくのかが何より大きな課題です。
日本語なら簡単にできることも英語になった途端どうすれば良いのか解らなくなることもしばしばあり、英語向上のために始めたCamblyも348時間に達したようですが、まだまだ能力が足りない状況です。

紹介コードありのものをリンクにしておいたので、良かったら試してみてください。10分間の無料レッスンがプレゼントされます。
Camblyの強みは「ネイティブであり、かつ教育に熱心なTutorが多く登録している」ことであり、彼らの指摘は非常にためになってます。

Tutorが「CamblyはTeacherではなくTutorだから、役立ててくれ」ということを言っており、なるほどと思いました。

そんなこんなで、Camblyは2020年の9月から週5の1時間でやっています。

ということで、備忘録代わりにCamblyで何をやっているのかを書いていくことにしました。

今日はCamblyで初めての講師を選び様々な会話をしていました。講師はボストンに住んでいるのですが、旅が好きで、ベトナムなどに住んでいたこともあり、このコロナ禍ではあるが、15の国に旅がしたいと言っていました。
また、MMOが好きで、FF14がfavoriteだと言っていたのでゲームの話をしました。
新しいエキスパンションがでるけど、旅行にいくから遊べないんだよね、というような他愛のないことを話しました。
こういう初対面のTutorと何を話すかというのはTutorに任せっぱなしになってしまうので、もっと質問力をあげるべきという気持ちになるやりとりです。

言っていることは解るが伝えられないということもよくあるので、今ある語彙で何とか説明するということを心がけていますが、最終的には自然に受け答えできるようになりたいものですね。

 

リーダーを簡単に辞めさせる方法

幾つもプロジェクトを持っている会社であればチームに必ずリーダーやエースがいると思います。

場合によっては簡単にモチベーションを下げ、辞めさせる事ができる方法を1つ紹介します。

 

「リーダーをそのプロジェクトから強制的に外し、燃えているプロジェクトに何人かリーダーを投下し、誰がやってもいいような仕事をアサインする」

 

です。これでまず１００％デモチして、かつ退職を考えるようになります。

リーダーはリーダーだからモチベーションを持っている

これは一見当たり前の事ですが、誰にでも自尊心があります。仕事を奪い、どうでもいい仕事をアサインする事がその自尊心を傷つけることに十分すぎる効果があります。リーダーからリーダーを意に反して奪うことは非常に強い効果を持ちます。そして、退職を考えます。

誰にでもできる仕事を与える

これも非常に効果的で、誰にでもできるスキルレベルに見合わない仕事を与えることで、無気力感を与えます。燃えているプロジェクトでは仕事に融通が利かないことが多く他にも元リーダーがアサインされているので動きづらくなります。自分はいなくても良いのではと思い始め、そして、退職を考えます。

指示を出す側から指示を出される側に変える

今までスケジュールを考え、タスクを考え、アサインを考えていた人を逆に仕事を与えられる立場にします。スケジュールは考えなくてよくなり、タスクも分解せずに済み、アサインに頭を悩まされる必要もなくなります。そして、退職を考えます。

こんな事がありえるのだろうか？

アサインの権限者がバグってると往々にしてありえます。

よくあるシチュエーションとしては1つのプロジェクトが無茶苦茶燃えていて、それを何とかしようとして他のプロジェクトからリーダーを連れてきて何とかしようとする場合です。現場のリクエストとしては多くの場合「出来る人をアサインしてほしい」となり、通常は「出来る人＝リーダー」となるパターンが多く、リーダーを複数連れてくるケースなどがあります。

対策として

燃えているプロジェクトにリーダーを突っ込む場合、最初から一時的な約束にするか単に突っ込むのではなく裁量を殺さずに課題ベースで仕事を与える必要があります。

この事案に限らずアサインのマネジメントというのは非常に難しいものだと考えます。良い人を採用してもワークしない、というのはこういうケース（とりあえずアサインすれば何とかなるだろうケース）もあると考えています。

æ ªå¼ä¼šç¤¾gumiを退職しました

2015年9月30日をもって、株式会社gumiを退職しました。

入社は2010年6月29日でしたから、5年程度務めたことになります。5年の間に会社の人数は膨れあがり、40人程度だった会社が800人くらいの会社になりました。

5年間の間にフィーチャーフォンのゲームからスマートフォンのゲームの企画開発から、部門の責任者、エンジニアの採用、評価、育成、拠点の立ち上げ、海外での開発、等々、様々な経験を詰むことができました。

会社としては幾度となく危機に見舞われ、倒産すら視野に入ることもありましたが、こちらも大変良い経験となったと思います。

また、この期間の間、gumiという会社が単なる集団から組織にならざるをえない状況でもありました。会社としての機能がほぼない状態で何とか邁進していた集団が組織になるという体験は今までになかったものなので、なかなかに得がたい経験でした。

特に100人の壁、200人の壁、400人の壁といったように、会社が大きくなるにつれそこには明確な壁が存在するようでした。

そして、gumiは上場もしました。執行役員という立場として、内部から上場に向かっていく組織の姿を見ることが出来たのも、良い糧となっています。

今回退職に至った理由としては「次にやりたいことができた」ということになります。

小さな集団が組織になっていくにつれて「ここはああすべきだった」「こういうこともできた筈だ」と感じることが増えました。

今が決して間違いでは無いと思いますが、それでももっと良くできた筈だという思いは残ります。

そして、もっともっと面白いものが作れる筈だという自負もあります。

限られた環境の中で限られたリソースで最善の手を打つ事は自身を成長させるのに十分な状況でありましたが、そうではない環境で自分の力を試したいという気持ちも強くあります。

gumi退職後も、引き続きゲーム開発には関わっていきたいと思います。今後とも宜しくお願い致します。

エンジニア歴14年で自己投資してQoLあがったったもの

Voluntasに、

給与全部使うを読んで @isoparametric しか思いつかなかった。

— voluntas#1345 (@voluntas) 2014, 7月 6

 

こんなことを言われつつ、

http://mizchi.hatenablog.com/entry/2014/07/06/163724

が面白かったので書きます。

常飲用炭酸飲料:月2000円〜

炭酸水ですが、ペリエ派。

ビンの330mlくらいが持てあまさずに使えてよいです。

Perrier(ペリエ) 330ml×24本 [並行輸入品]

 330の24本入りなので1ヶ月もちます。 

　キーボード: 1万~3万〜

キーボードはゲーム会社に入ってから、

会社に落ちてたXBox開発用のMicrosoftのNatural Keyboardを使ってたんですが、

返還するので返せと言われたので、

HHKB派に変わりました。

Natural Keyboardが英語配列だったので、今でも英語配列です。

http://www.amazon.co.jp/dp/B000EXZ0VC/

PFU Happy Hacking Keyboard Professional2 墨 英語配列 静電容量無接点 USBキーボード Nキーロールオーバー UNIX配列 WINDOWS/MAC両対応 ブラック PD-KB400B

昔はこれを持ち歩いてましたが、結構ガタガタになるので家と会社用を買いました。

会社用は、Type-S。

PFU Happy Hacking Keyboard Professional2 Type-S 白／無刻印（英語配列）

 

　会社へ自転車圏内への引っ越し:プライスレス

会社への自転車圏内への引越は当初からやってます。

最初は会社が新宿で、練馬に住んでました。

朝帰りも多かったので自転車は神。

今は会社が新宿で、中野に住んでます。

徹夜あがりの自転車は最高です。（最高に眠いです）

　自転車:１万〜

自転車も、いいものだと道中疲れません。

個人的にはクロスバイクお勧め。

これは個人差あるので、乗って確かめましょう。

自分が乗ってるのはライトウェイのシェファード アイアンF(2012)です。

↓は2014版。

◆14ライトウェイ シェファード アイアン F -LTD カフェブラウン サイズ：510mm(9732518)

 

　ベッド: 5万~

ソファ……はそれほどでもなくて、

やっぱりベッド。

自分はドリームベッドで、Sertaのマットレスを買いました。

ベッド選びは、

http://www.airtravelers.jp/2013/04/sleep.html

ここが参考になります。

 

　ドラム式洗濯乾燥機: 15万~

ドラム式洗濯機

日立のビッグドラム安定です。

Amazonは高いので家電のお店（ヨドバシ、ビッグ）で買いましょう。

日立 10.0kg ドラム式洗濯乾燥機【左開き】マグノリアHITACHI BD-ST9600L-V

 

　ワーキングチェア: 10万~20万

会社はミラチェア、家はバロンです。（勿論、実費）

バロン (Baron) チェア 【エクストラハイバック】 可動ヘッドレスト ポリッシュフレーム 可動肘 座メッシュ ブラック CP81AR FDH1

 これはマジで捗るのでいれるのがお勧めです。

疲れ無さが違う。

バロン (Baron) チェア買うならエクストラハイバックで。

あうあわないがあるので、ちゃんと試しに座れる家具屋で見てから、

最安値のところを探しても遅くないです。

 

あと、ルンバ。

iRobot ロボット掃除機アイロボット Roomba880 ルンバ880

 休日にでも平日にでも回しとけ。

 

　まとめ

→うまい水を飲みながらだとコード書いたり勉強が捗る

→手に馴染むキーボードを使うとコード書く時間が短縮される

→通勤時間が短いと本読んだり、コード書いたりする時間が増える

→自転車で出かけられると、コード書いたりする時間が増える

→良い眠りを得ると、体調が良くなってコード書いたりする時間が増える

→洗濯物を干している時間をコード書いたりする時間にできる

→良い椅子だと疲れずにコード書いたりする時間が増える

→掃除している時間をコード書いたりする時間にできる

 

時間は買えないので、ある程度時間を買えるアイテムを揃えておくと、

時間が有効に使えたりします。（まだまだ自動化出来る気はするけど）

 

最初に投資すると後で返ってくるから畏れず投資せよ。

 

独り暮らしの日々を自動化し時間を得るためのライフハック

こないだエンジニア同士で集まって話していたとき白物家電の話になりました。

日々を最適化するために「これは買うべき」という話で盛り上がったわけですが、自分自身今まで生活してきた中でこれを使うことで日々を最適化し、効率化および自動化できた、と感じたものを紹介したいと思います。

 

１．全自動洗濯乾燥機を導入

こいつは要するにJenkinsです。洗濯物を放り込んでおくと自動的に乾いたタオルやシャツが準備されます。そもそも独り暮らしのエンジニアにとって一番面倒だと感じるのは「洗濯」ではなく「干す」という行為ではないでしょうか。

天気や気温、湿度にある程度のランダム性がある以上、乾きには揺らぎがみられますし、そもそも干すという行為がめんどくさい。となれば、ちょっと考えて安定的にビルド（洗濯／乾燥）してくれる環境が必要ということです。

もの凄く高いものである必要はないのですが、独身エンジニアの間では２０万くらいのが高性能で人気でした。

 

日立 10.0kg ドラム式洗濯乾燥機【左開き】マグノリアHITACHI BD-ST9600L-V

 うちはこれを使ってます。日立が良いのは「風アイロン」という機能が搭載されており、洗濯物の皺取りまでしてくれます。（＝アイロン時間の短縮）

注意点としては、

• 一度に沢山いれすぎないようにしましょう（＝乾きませんし、皺もとれません）
• 型崩れするもの、普段着にしないものは別途洗いましょう
• 縮むことは計算にいれましょう

２．ルンバを導入する

こいつは要するにガベージコレクタです。時間経過と共に部屋には埃という名のゴミが蓄積します。

スケジューラーで不在時に自動で掃除することもできますが、居るときにボタンを押して自動で掃除をさせることができます。一度使って見れば分かるのですが、もの凄い量の埃をとってくれます。

思ったよりも吸引力もあり、落ちているちょっとしたビニールであればサッと掃除してくれます。これで日々の掃除を自動化することで、掃除している時間をもっと有意義に使えるようになります。うちで使っているのは770ですが、今度800シリーズもでるようですので、型落ちなどを狙ってみても良いと思います。

 

iRobot Roomba 自動掃除機 ルンバ 770

 

 

３．２４時間いつでもゴミを出せるマンション

こいつは要するにジョブキューです。

燃えるゴミ、燃えないゴミ、ビン、カン、粗大ゴミ、本当に面倒ですよね。そんなときに便利なのが、いつでもゴミを出せる仕組み（マンション）です。

燃えるゴミの日に出し忘れたらずっとゴミを置いておかないといけない……なんてことになりがちですが、これならいつでも好きなときに捨てられますし、いちいちウェイトしなくてもキューに突っ込んだゴミは詰まらずに順次処理されます。

粗大ゴミも置いておけば日付がこれば勝手に処理されます。

まとめ

エンジニアは日々のプログラム作業を自動化していたりするものだと思います。

ですが、日々のリアル作業も自動化したり、効率化することが可能です。

勿論お金はかかりますが、それに見合う効果が得られますし時間はお金では買えません。

メモリや、CPU時間、プロセス、スレッドと色んなものを自動化する事が日々の助けになるように、リアルな生活も自動化してみてはどうでしょうか。