AWS DevDay 2023 登壇資料

hacomono CTOのまこ(@macococo)です 今年最後のテックブログでは、2022年の hacomono の開発組織を振り返りたいと思います。 ちなみに昨年の振り返りはこちら。 開発組織の変化 2021年末の段階では、正社員が15名ほどの組織でした。当時の課題は、私自身が開発も担当しており、CTO という役割以上に開発チームのリーダーとして開発の中心に居たことと、私自身が開発に多くの時間を割けられずにボトルネックになってしまっていたことでした。2022年からはチームを分け、3月のB調達を経て採用が強化されたことで、チームもメンバーも大きく成長する年になりました。 (コードを書ける時間が減ったのは悲しいですが。。) 非常にありがたいことに、今年も多数の優秀かつバリュー体現の高いメンバーにJoinいただき、プロダクト組織全体で48名と約3倍の組織に成長しました。業務委託・アルバイト

みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー

ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から

ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては

会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。） 自分が苦しくならないようにする 究極的には本人が自分でスタイルを確立するしかない。 「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。 どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。 「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。 一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。 例えば自分自身は、人付き合いがすごく

新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA！！」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ

組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか

マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい

心理的安全性とは、「一人ひとりが恐怖や不安を感じることなく、安心して発言・行動できる状態」のことを指します。アメリカGoogle社のリサーチチームが、“チームのパフォーマンス向上のためには、心理的安全性を高める必要がある”と発見・発表して以来（参照：Google re:Work『「効果的なチームとは何か」を知る』より）、多くの企業が関心を示しています。今回は、そもそも心理的安全性とは何か、どのような効果が期待できるのか。そして、心理的安全性の測り方や担保する方法などを紹介します。 無料ダウンロードはこちら 90秒で読める「心理的安全性の作り方・測り方」 心理的安全性とは、恐怖や不安を感じることなく自分の意見を伝えられる状態を指す 心理的安全性とは、「psychological safety（サイコロジカル・セーフティ）」という英語を和訳した心理学用語で、チームのメンバー一人ひとりが恐怖や不

To Stop リストとは仕事や私生活で「やるべきこと」をまとめた To Do リストを作っている人は多いだろう。 では「やめるべきこと」をまとめた To Stop リストについてはどうだろうか？ どんなことでも、一度はじめてしまうとなかなかやめづらいものだ。そして「はじめてしまったからやめない」ことが積み重なっていくと、自由になる時間がどんどん少なくなっていく。 三ヵ月に一度でもいい。半年に一度でもいい。もしかしたら一年に一度でもいいかもしれない。「これ、本当に続ける必要あるの？」というものを整理した To Stop リストをつくってみよう。 To Stop リストの効果To Stop リストをつくることで、惰性でなんとなく続けてしまっている無意味な定例会議や、もう飽きているのにずるずると時間やお金を使ってしまっている趣味に別れを告げることができる。手作業でやり続けるのは非効率だとわかっ

はじめに ソフトウェアエンジニアリングマネージャ（以下、EM）に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ（会社を変えても有効であると思える程度）が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ

前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ

2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ

新型コロナの影響で、すっかり海外出張がご無沙汰なんですが、1月にメルカリからSmartNewsに転職して、早速シリコンバレーのGoogle本社に飛んだ時のメモがあったので、ブログに書き残しておきますね。 ちょうど、この出張の時です。 シリコンバレーにあるGoogle本社でのマネジメントWorkShopから帰国したので、US出張の雰囲気を伝えたくて動画にしてみました。最近はアプリだけで、お手軽に動画編集できてめちゃくちゃ便利。ちなみに背景で使っている音楽はJoJo好きならわかりますよねw pic.twitter.com/uaKV3YZ0wq — たいろー / メルカリ&スマニュー (@tairo) January 26, 2020 当日はGoogleplex（カリフォルニア州マウンテンビューにあるGoogle本社の愛称）でプロダクトマネージャーやエンジニア、エンジニアリングマネージャー、Sa

概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ

「PDCA」という言葉。知らない人はいないと言えるほど、日本のビジネスにおいて広く浸透している言葉ですよね。 でも、このPDCAはもう時代遅れかもしれません。なぜならば、世界では今、それに代わる「デザイン思考」が主流になりつつあるからです。いつもPDCAを回しているつもりの人は、自分自身の仕事を知らず知らずのうちに “遅くしている” ことを、今すぐ自覚するべきです。 “変化し続ける世界” にPDCAはそぐわない 「Plan（計画）」→「Do（実行）」→「Check（評価）」→「Act（改善）」→「Plan（計画）」→……というサイクルを回してビジネスを進めていく「PDCA」が、なぜ時代遅れになりつつあるのか。それを理解するには、PDCAが考案された当時の時代背景を知る必要があります。 実は、PDCAという言葉は日本人が作ったのです。戦後、来日した統計学者デミングによる統計的品質統制 （SQ