CTOやVPoEと違いEMには再現性がある
こちらはEngineering Manager Advent Calendar 2023 12日目の記事です。
こんにちは、Isoparametric(Yuki Tamura)といいます。
今回はEMはCTOやVPoEの下位互換ではないということについて書きます。
私は今estieというスタートアップでEMをしております。
前職では不動産テックのCTOをしていて、その前はスマートニュースという会社でEMをしてました。
その前は、ディライトワークス、gumiという会社でCTOだったりしたこともあります。
それが何故またEMをという感じですが、入社の経緯などは、会社のブログの方にありますので興味があれば読んでみてください。
CTOを辞めて各社のCTOや最強のエンジニアが集う梁山泊estieに入社した理由 - estie inside blog
では、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人のエンジニアをマネジメントする必要があります。それが1チームの適性人数範囲だからです。
もしこれ以上のエンジニアをマネジメントすれば、業務過多になりチームやチームの責務に積極的に関わることは難しくなりますし、少なければチームとして機能しにくくなり出力も限られます。
例えば、私は最大23名のレポートラインを持っていたことがあり、それらのメンバーは4~5のチーム(プロダクト)に跨がって関わっていたので、どのチームを主軸にして良いか分からなくなりました。(マトリクス型組織だったのもあります)
また、それぞれのチームに対して新しいメンバーをアサインするために採用を行わなければならないため、採用のニーズは4~5倍になりどうしてもチームに対する関与が薄くなります。
勿論、スタートアップは常に変容する生き物のようなので一時的にこのような大人数を引き受けることも合理的な判断なのですが、長く続ければ将来的には必ず組織的負債を抱えることになります。
マネージャーはチームを拡充し開発力を最大化しなければならないので、チームを8人から10人くらいに成長させ、やがてこれを半分の人数に割るということを行います。
ただ、考えもなしに成熟したチームに対してそんなことをすれば、チームの生産性は台無しになると言っても過言ではありません。
また、頭数だけを揃えたチームを半分にしても生産性はでないでしょう。
スタートアップが「EMが必要です!」と言っている場合、それは「組織を成長させたいから」に他なりません。
「組織を成長させたい」というのは単に「頭数を増やしたい」ということではなく、「生産性の高いチームを複数生み出して、必要なことを同時にやりたい」ということですから、1人のマネージャーが大量のメンバーを引き受けて、それを分割していくようなやり方では絶対にうまくいかないのです。
チームにも状態がある
そもそも、チームには「状態」があります。
例えば、あるチームは常に「人手が足りません」と言っていますし、よくいるPdMたちは「新しくやりたいことがあるんだ」と言いますし、長く所属したエンジニアは「技術的な負債が大変なんです!」と言ったりします。
こういう状況が複雑に絡み合った状態がチームには常に存在しています。
ただ、これらのチームが目指していることはたった1つで「安定的に高い生産性を発揮すること」であり、「新しい機能に取り組みながら、技術的負債を返済し、ユーザーに向き合うためのゆとりが欲しい」と言っているわけです。
残念ながら、物事はそう理想通りに動くことはありません。
チームが「人が足りない!」と悲鳴をあげている状況の時、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の責任です。
このチームに人を入れるのも、チームから人を抜くのも、もしくは2つのチームに分けるのも本来はEMの判断次第ということになります。
しかし、人には人の人生があり時にライフイベントによって退職を決意したり、チームの移動を願い出られたり、新しいテックリードの擁立を余儀なくされることもあるでしょう。
いついかなる時にどこからチームに脅威が忍び寄っているかは分からないのです。
それに常に警戒し続けるのがEMの仕事です。
そして、CTO/VPoEはこの視点を持てないことがほとんどです。
なぜなら、視座も違えば解像度も違うので、チームの細やかな内情など考慮に入れることが難しくなってきますから。
適切な評価を与える
また、CTO/VPoEと異なりEMだけに与えられたさらなる苦難があります。
それは、チームに対して適切な評価を勝ち取ることです。
多くの企業においてEMは評価者でありますが、最終的な評価決定者ではありません。
よって、自身のさじ加減によってチームの評価を良くするということはできず、チームの評価はCTOやVPoEから勝ち取る立場なのです。
特に、EMが苦労するのはチームが"keeping the lights on" (灯りを点し続ける)と呼ばれるような地味な仕事をしている場合でしょう。
「今期、君のチームは何も新機能をデリバリーしてないから」と低評価をつけられようとしているチームがいたとしたら、EMは必死で「そうではないこと」を立証しなければならないのです。
実際に「灯りを点し続ける」というのは偉大な仕事であり傍目に何も変わっていないように見えても、そんな筈はありません。
現実世界だって、灯りが燃えるには燃料が必要なことくらい誰にだって分かるでしょう。
時にチームは灯りを吹きすさぶ風から守ったり、それがもし消えてしまった時に備えていたり、より明るく広範囲を照らせるようにしていたり、様々な努力を重ねています。
ただ何もしていないのに、そこに灯りが燃え続けることはありません。
そして、それを知りうるのもCTOやVPoEではなくチームをマネジメントするEMなのです。
最後に
自分はEM(エンジニアリング・マネージャー)だけれどもそんなこと考えたことがない、という人もいるでしょう。
それは、おそらく所属している企業自体の変化がとても緩やかだからです。
そういう意味では環境が違えばEMには互換性がなくなってしまうように感じるかもしれませんが、私はそうは思いません。
学び続けているEMはどこの企業でだって高い再現度でチームをマネジメントすることができます。
スタートアップは半年や1年で社員数が倍増することが多く、1年ごとに別の会社になった、と感じることも少なくありません。
要するに、気がつけばやってきたことはすぐ古くなってしまうのです。
であるが故に、多くの学びがありますし、その濁流の中でそれに飲み込まれないようにチームが成功することを助けるのは最もやり甲斐のある仕事の1つだと私は思っています。
急成長する組織の中でチームをうまく支えるというのは、「銀の弾丸」を見つけるような仕事ではなく、小さく成功を積み重ねていく地道な道しかありえない仕事です。
この地味さ故に実際には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つ紹介します。
「リーダーをそのプロジェクトから強制的に外し、燃えているプロジェクトに何人かリーダーを投下し、誰がやってもいいような仕事をアサインする」
です。これでまず100%デモチして、かつ退職を考えるようになります。
リーダーはリーダーだからモチベーションを持っている
これは一見当たり前の事ですが、誰にでも自尊心があります。仕事を奪い、どうでもいい仕事をアサインする事がその自尊心を傷つけることに十分すぎる効果があります。リーダーからリーダーを意に反して奪うことは非常に強い効果を持ちます。そして、退職を考えます。
誰にでもできる仕事を与える
これも非常に効果的で、誰にでもできるスキルレベルに見合わない仕事を与えることで、無気力感を与えます。燃えているプロジェクトでは仕事に融通が利かないことが多く他にも元リーダーがアサインされているので動きづらくなります。自分はいなくても良いのではと思い始め、そして、退職を考えます。
指示を出す側から指示を出される側に変える
今までスケジュールを考え、タスクを考え、アサインを考えていた人を逆に仕事を与えられる立場にします。スケジュールは考えなくてよくなり、タスクも分解せずに済み、アサインに頭を悩まされる必要もなくなります。そして、退職を考えます。
こんな事がありえるのだろうか?
アサインの権限者がバグってると往々にしてありえます。
よくあるシチュエーションとしては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くらいが持てあまさずに使えてよいです。
330の24本入りなので1ヶ月もちます。
キーボード: 1万~3万〜
キーボードはゲーム会社に入ってから、
会社に落ちてたXBox開発用のMicrosoftのNatural Keyboardを使ってたんですが、
返還するので返せと言われたので、
HHKB派に変わりました。
Natural Keyboardが英語配列だったので、今でも英語配列です。
http://www.amazon.co.jp/dp/B000EXZ0VC/
昔はこれを持ち歩いてましたが、結構ガタガタになるので家と会社用を買いました。
会社用は、Type-S。
PFU Happy Hacking Keyboard Professional2 Type-S 白/無刻印(英語配列)
- 出版社/メーカー: PFU
- メディア: エレクトロニクス
- クリック: 21回
- この商品を含むブログ (3件) を見る
会社へ自転車圏内への引っ越し:プライスレス
会社への自転車圏内への引越は当初からやってます。
最初は会社が新宿で、練馬に住んでました。
朝帰りも多かったので自転車は神。
今は会社が新宿で、中野に住んでます。
徹夜あがりの自転車は最高です。(最高に眠いです)
自転車:1万〜
自転車も、いいものだと道中疲れません。
個人的にはクロスバイクお勧め。
これは個人差あるので、乗って確かめましょう。
自分が乗ってるのはライトウェイのシェファード アイアンF(2012)です。
↓は2014版。
ベッド: 5万~
ソファ……はそれほどでもなくて、
やっぱりベッド。
自分はドリームベッドで、Sertaのマットレスを買いました。
ベッド選びは、
http://www.airtravelers.jp/2013/04/sleep.html
ここが参考になります。
ドラム式洗濯乾燥機: 15万~
ドラム式洗濯機
日立のビッグドラム安定です。
Amazonは高いので家電のお店(ヨドバシ、ビッグ)で買いましょう。
ワーキングチェア: 10万~20万
会社はミラチェア、家はバロンです。(勿論、実費)
バロン (Baron) チェア 【エクストラハイバック】 可動ヘッドレスト ポリッシュフレーム 可動肘 座メッシュ ブラック CP81AR FDH1
- 出版社/メーカー: オカムラ (岡村製作所)
- メディア: オフィス用品
- クリック: 10回
- この商品を含むブログ (3件) を見る
これはマジで捗るのでいれるのがお勧めです。
疲れ無さが違う。
バロン (Baron) チェア買うならエクストラハイバックで。
あうあわないがあるので、ちゃんと試しに座れる家具屋で見てから、
最安値のところを探しても遅くないです。
あと、ルンバ。
休日にでも平日にでも回しとけ。
まとめ
→うまい水を飲みながらだとコード書いたり勉強が捗る
→手に馴染むキーボードを使うとコード書く時間が短縮される
→通勤時間が短いと本読んだり、コード書いたりする時間が増える
→自転車で出かけられると、コード書いたりする時間が増える
→良い眠りを得ると、体調が良くなってコード書いたりする時間が増える
→洗濯物を干している時間をコード書いたりする時間にできる
→良い椅子だと疲れずにコード書いたりする時間が増える
→掃除している時間をコード書いたりする時間にできる
時間は買えないので、ある程度時間を買えるアイテムを揃えておくと、
時間が有効に使えたりします。(まだまだ自動化出来る気はするけど)
最初に投資すると後で返ってくるから畏れず投資せよ。
独り暮らしの日々を自動化し時間を得るためのライフハック
こないだエンジニア同士で集まって話していたとき白物家電の話になりました。
日々を最適化するために「これは買うべき」という話で盛り上がったわけですが、自分自身今まで生活してきた中でこれを使うことで日々を最適化し、効率化および自動化できた、と感じたものを紹介したいと思います。
1.全自動洗濯乾燥機を導入
こいつは要するにJenkinsです。洗濯物を放り込んでおくと自動的に乾いたタオルやシャツが準備されます。そもそも独り暮らしのエンジニアにとって一番面倒だと感じるのは「洗濯」ではなく「干す」という行為ではないでしょうか。
天気や気温、湿度にある程度のランダム性がある以上、乾きには揺らぎがみられますし、そもそも干すという行為がめんどくさい。となれば、ちょっと考えて安定的にビルド(洗濯/乾燥)してくれる環境が必要ということです。
もの凄く高いものである必要はないのですが、独身エンジニアの間では20万くらいのが高性能で人気でした。
うちはこれを使ってます。日立が良いのは「風アイロン」という機能が搭載されており、洗濯物の皺取りまでしてくれます。(=アイロン時間の短縮)
注意点としては、
- 一度に沢山いれすぎないようにしましょう(=乾きませんし、皺もとれません)
- 型崩れするもの、普段着にしないものは別途洗いましょう
- 縮むことは計算にいれましょう
2.ルンバを導入する
こいつは要するにガベージコレクタです。時間経過と共に部屋には埃という名のゴミが蓄積します。
スケジューラーで不在時に自動で掃除することもできますが、居るときにボタンを押して自動で掃除をさせることができます。一度使って見れば分かるのですが、もの凄い量の埃をとってくれます。
思ったよりも吸引力もあり、落ちているちょっとしたビニールであればサッと掃除してくれます。これで日々の掃除を自動化することで、掃除している時間をもっと有意義に使えるようになります。うちで使っているのは770ですが、今度800シリーズもでるようですので、型落ちなどを狙ってみても良いと思います。
3.24時間いつでもゴミを出せるマンション
こいつは要するにジョブキューです。
燃えるゴミ、燃えないゴミ、ビン、カン、粗大ゴミ、本当に面倒ですよね。そんなときに便利なのが、いつでもゴミを出せる仕組み(マンション)です。
燃えるゴミの日に出し忘れたらずっとゴミを置いておかないといけない……なんてことになりがちですが、これならいつでも好きなときに捨てられますし、いちいちウェイトしなくてもキューに突っ込んだゴミは詰まらずに順次処理されます。
粗大ゴミも置いておけば日付がこれば勝手に処理されます。
まとめ
エンジニアは日々のプログラム作業を自動化していたりするものだと思います。
ですが、日々のリアル作業も自動化したり、効率化することが可能です。
勿論お金はかかりますが、それに見合う効果が得られますし時間はお金では買えません。
メモリや、CPU時間、プロセス、スレッドと色んなものを自動化する事が日々の助けになるように、リアルな生活も自動化してみてはどうでしょうか。
本当に怖いC++erとC++という糞言語
かつて、ゲームプログラミングはアセンブリが主流で、8bitのCPUは掛け算や割り算すらないものでした。割り算がないCPUっていつの時代だよ、っていう人たちもおりますが、ゲームボーイアドバンスに搭載されているARM7TDMIは除算の命令を持っていません。(故に除算を書くと死ぬほど遅いので、乗算で代用したりする)
また、浮動小数に対する演算ユニットを持っていないハードウェアもあります。ニンテンドーDSに搭載されているARM946E-Sですら、浮動小数演算ユニットはありません。(CPUの機能としてはオプションで存在する)そのために固定小数点といった技術もあるわけですが、古くさい話です。
これらはCとC++の機能を駆使していかにパフォーマンスを出すかを余儀なくされた時代です。
さておき、最近はスマートフォンでのゲーム開発も進化しており、C++がiPhoneとAndroidの両方で動くということもあり、C++でのゲーム開発の需要が高まっている中で、それでもC++は人的な最適化(適切な使い方)を余儀なくされる言語であります。そこで「こんなC++erは嫌だ」という話をまとめてみました。
(決して他の言語が適切な使い方をしないでいい、という論旨では無い)
1. dynamic_castとstatic_castの違いが分かっていない
「dynamic_castとstatic_castわかる?」
「あー、あの動的なキャストと静的なキャストのことね」←まるでわかってない
RTTI(Run-Time Type Information)の関する知識が無いままにC++をプログラミングしているケース。
他の言語においては、型情報を普通に備えている訳だが、
C++はCの規格上動的に型情報を備えていないケースがある。
(オーバーヘッドに対して明示的にOFFにされるケースがある)
RTTIが有効であれば型情報を備えているが、これらのcastが何を意味しているかわからない場合はC++を使えていないと思って良い。
C++では適切に型情報を理解しなければcastは使いこなせない。
特にstatic_cast/reinterpret_castは型情報を騙して(強制して)本来取り出せない筈の情報(例えば、privateやprotectedなメンバ変数)を取り出すことができる手段の1つとしてとても重要なものだ。
(ただし、この動作は言語仕様としては未定義であり、処理系としてそういったコードを生成するケースが多いというだけ、ということに注意)
SDK側でインスタンスを既に作成しているケースなどでは、こちらで継承をしてそれらを作り直すことは難しい。
だが、メモリ上にある数字は防御されることなくプログラマによって書き換えられる。
protectedであれば継承を使う。
privateであれば強制キャストを使い、同じアライメントにある値を書き換える。
そして、このことはhackされたiPhone/Androidは常にメモリを書き換えられて不正をされる可能性を秘めている事と同義だし、そういう意識を持つべきだ。(C/C++でなくても、メモリ空間は書き換えられるが)
2.mapとhash_mapの違いがわかっていない
「mapとhash_mapのアルゴリズムわかる?」
「あー、mapね、mapは使った事があるよ」←まるでわかってない
二分探索とハッシュテーブルの差がわからず、アルゴリズムを理解しないままにC++でプログラミングをしている。
他の言語においては、連想配列や集合などのアルゴリズムとして覆い隠されているケースが多いが、
C++においては、これらの知識を持つべきである。
JavaのHashMap、PerlのHash、Pythonのdict、RubyのHash、JavaScriptのobjectなど他の言語で身近に使われるものであり、
高速化には必須の概念である。
C++ではSTLの規格で二分木のmapを提供するが、別途に実装系の拡張としてのhash_mapや、C++11のようにunordered_mapを提供するケースが多い。
これらの使い分けは必須であり、特性を理解して使うべきである。
また、vectorのアルゴリズムを理解していない場合、reserveを適切に使えないケースがある。
各種のコンテナの速度比較を以下に示す。
mapとunordered_mapになぜ速度差があるのかはアルゴリズムを考えればわかる筈。
3.スマートポインタ(弱参照)に対する知識がない
「shared_ptrとweak_ptrの使い分けわかる?」
「あー、話には聴いたことあるけど。weak_ptrってのは知らない」←まるでわかってない
弱参照を理解していない場合、リファレンスカウンタの所有権と循環参照に苦しめられる。
殆どの言語が(GCで管理されている言語でさえ)弱参照を持っている。
Objective-Cなら、__weak、
これほど言語に標準的に備わっている機能なのに殆ど知られていないのが弱参照だ。
C++なら既に死んだポインタを判別できるし、ポインタの消滅を邪魔しない。(弱参照は所有権を持たない)
弱参照という概念は他の言語においてでも標準的に用いられる概念であるのにも関わらず、軽視されている傾向がある。
すべてのプログラマは「所有権」について考える必要がある。
まだ他にもあるけど、長くなるのでここまで。
まとめ
C++使うならちゃんと勉強しろ。
C++使いたいならちゃんと勉強しろ。
C++使って無くてもちゃんと勉強しろ。
C++は、恐らくちゃんと理解されずに使われてしまっている言語だと思います。
故に多くのケースで糞言語と化しますし、(メモリはリークしまくり、所有権は無茶苦茶、何でも線形探索など)
cocos2d-xを使っていてもC++だけど、メモリ管理はcocosがしてくれるからしなくてもいいよ、安全だよ、なんて話を聴くと悲しくなります。
もっとC++の事を知ってからコードを書いても良いのではないでしょうか。
そして、他の言語を使う人たちも言語の事をちゃんと知ってあげて下さい。
- 作者: Bjarne Stroustrup,ビョーンストラウストラップ,επιστημη,岩谷宏
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2005/01/19
- メディア: 単行本
- 購入: 2人 クリック: 322回
- この商品を含むブログ (160件) を見る
C++ Advent Calendar 2013 の記事でした。
http://partake.in/events/91328710-3c7b-436e-bd4e-4d98d88333f9