CTOだからというよりは、あたりまえのことを素直に実行しているという印象を持ちました。逆に、それができない(と思い込んでいる)組織は楽をしすぎているということだと思います。

「グレードの高いエンジニアこそ、躊躇（ちゅうちょ）することなく他人にいろいろ聞く。ジュニアエンジニアこそ、こっそり検索をしている」は非常に腹落ちがあります。ジュニアエンジニア並みの組織がまだまだ多いということでしょう。

おお、戸辺さんだ。戸辺さんは「めちゃくちゃ人当たりが良くて話しやすいけど、実は凄く合理的な人」で、言いづらいこともハッキリ言うのが凄いなぁといつも思ってました。そういう戸辺さんっぽさが出ている記事な気がします。

最近はどの会社もエンジニアの割合が高くなっており（弊社も多分エンジニアが社内で一番多い職種です）、かつ採用もリテンションも難しいということで、エンジニアに特化したマネジメント論や書籍が山ほど存在します。中には他職種や会社全体に活かせる知見も多いと思います。例えば昨年一番話題になった書籍は『チームトポロジー』ですが、これは結構エンジニアに限らず使える考え方かなと。
https://www.amazon.co.jp/dp/B09MS8BML8

ちなみにエンジニア論じゃないですが、先進的なテックカンパニーから学べることは多いと思っていて、僕がさいきん読みたいなと思っているのは『Scaling People』です。面白そう。
https://press.stripe.com/scaling-people

挫折/失敗して人は強くなるといいます。

組織では、人が辞めることで強くなる面があると思います。「何が不満の原因」なのか、逆に「不満はあまりないものの、魅力がないのではないか」などなど、いろいろと考えるきっかけになるかと思います。

その点、エンジニアにおける人材の流動性が高さや採用難が、良い方向に作用しているように見受けられます。

その点、私たちNewsPicks編集部も、社内のITエンジニアリングチームの皆さんから、コミュニケーションのあり方から評価の納得性まで、参考にさせてもらっています。

最近では、腕に覚えのあるエンジニアほど、あえて「正社員」にならずに「業務委託」を選ぶ傾向にあるとのこと。我々も、他のメディアも、本当のプロ化が進めば、業務委託が増えているのだろうと思っています

かつて本記事に登場する戸部さんがニューズピックスにいた時、私の専門の組織人事やキャリアについて、記事を書く上でよく相談に行きました。エンジニアの採用について。人の見極めについて，生産性の上がるミーティングについてなどなど。

戸部さんにとっては、ほぼメリットのない時間なのに、惜しげもなく、時間も知識も授けてくれて、まさに本記事にある、斜めの1on1まで手を抜かない。だから私を含めた多くの社員に、信頼されていました。

本文にある、相手が耳の痛いことを言うフィードバックも、規律の守らせ方も、土台に相手のと信頼関係がなければ、聞き流されて終わる話です。まずは、相手の好き嫌いまで知るくらいの関係を作ることが大事だなと。そして、かつての同僚がこのようにまたアンラーンを重ねて、成長している姿を見ると、自分もやらねばと鼓舞される記事でした。

まさかと思ったら戸辺さん！卒業生が編集部に選ばれて記事になるのは嬉しいですね。

僕もCTO兼COOのような期間が長く、人事も兼務していたのでとても共感できます。エンジニアのコミュニケーション、チーム開発手法はロジカルに体系だって組み立てられているので、エンジニアの枠を超えて人事システムとして適応できる部分が多々あると思っています。ユーザベースの人事システムの基礎の部分はエンジニアチームの影響はかなり大きいです。

戸辺さんは、NewsPicksのほぼ同期で年も近かったので、NewsPicksを卒業されるときはとてもさみしいかったのですが、ノバセルでの活躍は素晴らしいですね！スパッと問題点を見抜けいて指摘するキレッキレのエンジニアでいながら、採用の要でしたね。
プレーヤーとマネージャーの異なるスキルは、私も日々考えていた時期もあり、この記事から学びが多かったです。

戸辺さんだ！

戸辺さんがNewsPicksに在籍されていたころ、エンジニアではない自分にデータ分析のためにクエリ（どのテーブルを見ればいいのかなど含めて）を教えてくれた。
何を調べたいかがクリアなら自走する方が早い、といった観点などもあったのではないかと思い、そしてそのなかで支援が本当に上手で（というかNewsPicksのエンジニアの方、全員めちゃくちゃ優しく支援が上手…）、また質問もしやすかった。
そんな観点が本記事からも窺えるのではないかと。

そして専門職の人がリーダーになった場合の汎用的な学びが多いと思う記事。

僭越ながらとても共感できる記事でした。

ソフトウェア設計の考え方を組織にも適用できる、というのは同じ仮説を持っていて、単一障害点を作らないという点もその通りだな、と。レイヤー化による抽象度の調整と、モジュール化によるファンクションとインタフェイスの整理は、大事だと思っています。

阻害要因を取り除く話は、私のメンターにも「モチベーションって風船みたいなもので、無理やりあげなくても重りを取り除いてあげれば自然と上がっていくんだよ」と言われて、はっとしました。

あと、事業フェーズや周りのメンバーによって、コード書きべきか、マネジメントすべきかを変えられる働き方を個人的にも目指しており、それをラグビーのポジションから”ナンバーエイト”と呼んでいます。ジョブ型みたいな働き方はしたくない！

これは理想的ですね。長期休暇なんかでも同様です。普段から業務の棚卸ししておくことが最低限必要でしょう。
"「異動や人が辞めるタイミングで引き継ぎ処理や、引き継ぎのためのドキュメント作りがゼロになるように」"