中途採用で面接の時にはサービスに積極的に携わりたいと言っていたのに、いざ入社すると受け身姿勢な仕事になってしまい、積極的にサービス向上には関わらなかったり、自分自身から問題意識を持てないと周りからは思われてしまうケースがあります。 仮説としては、 １．前職がクライアントワークだったり、与えられる仕事に対してアクティブに関わるというよりは、受け身的に仕事をする姿勢が板についてしまっている中途採用のケース ２．どうやったらサービスに興味を持ったら良いかわからないケース。当人はやってるつもりだけど周りからできているとは見なされない。考え方が足りないとか、考える方法がわからないとか、考えてる量が圧倒的に少ないようなケース などが考えられます。一定、そこそこの規模のサービスになったりすると、自分自身が関与しているドメインが狭く見えてしまったり、もしくは大きなレバレッジを生み出す余裕がないと思ってしま

僕が所属している会社では、スクラム採用という名の下でエンジニアも採用に携わっています。多くはチームメンバーとして面接に出てもらって、お互いの相性を見たり、アトラクトとして参加してもらったりという手段なのですが、そもそもの面接母数を増やすためのスカウトは主にマネージャ職にやってもらっています。 下記引用は他社様の話ですが、改めて、やっぱりそうなんだよなぁと思って見ていました。 しかもエンジニアを採用するためには、いま自社で働いているエンジニアの稼働時間のうち2～3割を採用、つまり選考のために割いてもらう必要があります。 マネージャがスカウトを行うメリットマネージャがスカウトを行う理由は、チーム組成を担う仕事として、プレーヤよりもマネージャの方が主体的に動けること、人を見る目を養っていく仕事が故に、良い人材へアプローチできることを意識してやっています。スカウトは、こちらが先んじてスクリーニング

以前から何故CTOに代表される技術系の役員という役割が必要なのだろうか？と考えていた。技術が重要なだけなら昔ながらの製造業や通信産業の組織でも似たような役割が設定されていたはずだ。みんなバカじゃないので。CIOはいたがCTOはあまり聞かなかった。その違いはなんだろう？ スタートアップとして投資を受ける時にVCから「あなたのチームは技術者採用できますよね？」というのを証明するためにCTOの設置が求められたりするなど、特にWeb系企業においてはあたりまえの役割として設置されている。つまり技術者のキャリアパスとして、役員クラスまで登れるんですよ、という道筋の提示という役割はまああるのだろう。 ただ、それだと客寄せパンダにしか見えなくもなく、ビジネス的な役割が適切に存在しないのであれば長くは続かない。やはり技術部長やテックリードではなく、役員クラスとしての責任をどう果たすから技術系役員が必要だとい

こういうドキュメントは山程あるような気がしつつ、新しくマネージャになった人とかに読んでほしいなぁということを書いてみます。短い文章です。複雑なMBAの教科書みたいなことを期待したらごめんなさい。どちらかというと研究者向けの名著「アイディアのつくりかた」みたいな感覚で、悩んだりしたら何度も見返せることを想定しています。 記事を有料化させていただきました。理由としましては、見ていただいた方のフィードバックを経て、これが必ずしも一般的な考え方ではないなと言うことに気がつきました。つまり、この考え方には、それに至るための前提条件が存在していて、全てに当てはまることではないと言うことに気が付きました。 しかし、当社の状況という前提条件の共有をオンラインで行うのはさすがにやりにくいので、記事を非公開にしようかと思いましたが、一度公開したものを引っ込めるのもなんなので有料化させていただいて、それでもいい

Web3という言葉で語られるポジショントークはものすごく苦手なのだが、新しいムーブメントになっているのは間違いないので、苦手意識を我慢して勉強している。頭の中が整理しきれていないが、文章を書いて、野に晒すことでレベルアップしてみようと考えたのがこの文章である。 追記はじめ： 以下に批評をいただいてるので、技術的な誤り等については是非、こちらの記事を読んでupdateいただけますと。 https://kumagi.hatenablog.com/entry/re-web3-terrorism また、それに対するアンサーも書いていて、何故こういう記事を書いたのか？という思想面について雑談的に書かせていただいております。 以上追記終わり Web3に必要なキーワードは、「トラストレス」という言葉「トラストレス」というキーワードをgoogleで検索すると、2018年ぐらいの記事が上位を占めているのだが

エンジニアイベントに積極的に参加している人は、自分の活動を仕事としても評価されたいと思っている人がいるんじゃないか？と思う。とりわけその会社内においてイベントに参加している人たちは往々にしてマイノリティであることが多く、高い意識レベルの中で余計に頭の中でモヤモヤがあるんじゃないかと思う。 このことについてどう考えていくか？まだ固まってるわけじゃないけど、試しに世に問うてみる。 基本的な考え方エンジニアのイベントへの参加は、ある種の趣味であるべきだと思う テックリードなどのリードの取り方には種類がある 直接貢献と間接貢献を意識する エンジニアのイベントへの参加は、ある種の趣味であるべきだと思う なにかの活動を評価に結びつけるのであれば、成果について上司との握りが必要だ。時間の使い方を営利業務にどう結びつけるか？を最適にするために目標を設定して、上司と握って、達成して評価につなげる。普通の仕事

これは昼休みに書いた落書きです パソコン通信の時に尊敬していた人たちは、今はどこかに行ってしまった。本質的オタクだから２ちゃんねるみたいなところの匿名の海にいるのかもしれない。 Flashのクリエイターの人たちも見なくなったな。僕の視界だとサブリンさんが場所を変えて活躍してるのいいなと思ってみてるし、深津さんはバリバリの僕とも近しい場所で仕事してる感が見えている。 WebSigで繋がっていたWeb制作系の人たちも安住してしまってる。なによりWebSigモデレータメンバーがほぼ隠居状態みたいになってるしｗ　身の丈に合う範囲にいるのはいいんだけど、うちの会社のメンバーとか知らないからせっかく今をときめくクラシコムの青木さんのプレゼン資料とか良いコンテンツを生み出してきたのに話するのが大変ｗ おっさんになってくると、世の中達観してくるし、何より自分の目線が上がってるから単純なスキル問題とかはどう

組織の話をしていて、何故、エンジニアの上司はエンジニアである必要があるのか？ CTOはいるがCDOがいない会社は多い。マーケティングという専門職の上司が永遠にマーケティングというわけでもない。もちろんCMOもいるだろうが、CTOに比べて常識化しているわけではない。 CTOがいる企業は増えているが、製造業の歴史的に成功した大企業がCTOがいるわけではない。 ただのエンジニアのワガママやエゴなんじゃないか？と思うことも多々ある。だから、たまに迷いが生じる。もちろん採用市場における業界の常識というのがあるので、それを無碍に無視するわけでもない。 いずれにせよ何故、エンジニアの上司はエンジニアであるべきなのか？ということを言語化できることが重要だ。 ー・ー いろいろ考えた末に、僕が一つたどり着いたものは、 ・いわゆる組織図ツリーは、ビジネスを実現するための組織図である。ビジネスが第一義になるので、