吉祥寺.pm32におけるトークパート「なぜ人は組織から去っていくのか？」の登壇資料です。 ■イベント情報 https://yumenosora.connpass.com/event/241175/ ■今後のイベントについてはこちら https://yumenosora.connpass.…

第1回 Platform Engineering Meetupで発表した資料です。 #PFEM

こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズ開発本部では、2022年5月に大規模な組織変更を実施しました。詳細は下記の記事をご覧ください。 blog.cybozu.io 今回の組織変更では、職能ラインと人材マネージャーを整備した結果、新たにスクラムマスター職能が誕生しました。 本記事では、スクラムマスター職能を作った背景や、現在の取り組みを紹介します。 サイボウズ開発本部におけるスクラムマスター職能の定義 サイボウズ開発本部におけるスクラムマスターの責務は、「チームを健全に保つことに責任を持つ役割」と定義しました。2020年版スクラムガイドには、スクラムマスターは「スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ」と書かれていますが、組織のすべての人がスクラムチームに所属しているわけではないため、チームがスクラムをしているかどうかは職責に

昨日と比べて今日一歩前進してる？ もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり（幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった） そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない 計

はじめにみなさん，こんにちは。めもりーです。株式会社トラーナで執行役員 CTO になってから 1 年が経過しようとしているので，来年の所作も踏まえて，そろそろ記事にしようかなと思っています。 1年間 CTO としてどうだったか正直，CTO という職務が何をするべきか，常々悩んでいます。 上記の記事のように私の中では CTO の職務というのは "技術資産を常にフル活用できる状態にすること（意訳）" だと定義しました。 もちろん，会社によっては CTO は「技術のプロフェッショナルでテックリードの上に起つ存在である」であったり「ボードメンバーの一人として，経営に携わり技術的な意思決定をする」であったり「課題を洗い出し，技術的にどのように解決できるかのリードをする」といったり，十人十色だと思っています。 その中で，私自身の答えとしては，上記の技術資産の活用であると導きだしているものです。 CTO

転職・求人情報サイトのtype エンジニアtype 働き方 「EMやること多すぎ問題」が組織にもたらす弊害は？Chatworkの失敗事例に学ぶパフォーマンス最大化の秘訣【田中佑樹✖️岩瀬義昌】 【PR】 2022.10.21 働き方 Chatwork岩瀬義昌EMプロダクト注目企業 テクニカルマネジメントをはじめ、採用、育成、組織開発など、エンジニアリング組織のあらゆる仕事をカバーするエンジニアリングマネージャー（EM）。 その業務範囲の広さから、「やること多すぎ問題」が“EMあるある”として話題にのぼることも…。 ロールの多いEMが業務を円滑に、かつ最大パフォーマンスで進められるようになるためには、一体何から手を付ければいいのだろうか。注力すべき課題を見極める方法はあるのか。 国内利用者数No.1（※）の中小企業向けビジネスチャット『Chatwork』を提供するChatwork株式会社のプ

全てはこのツイートから始まった tokorotenさんのツイートの「大本営」という部分。 「我々は勝っている、我々は価値がある」という常勝の発表を社内向けに繰り返す上層部というニュアンスで大本営が使われているように見えます。 そもそもなぜ「大本営」なる組織が必要になるのでしょうか？ 体感では40人程度の組織までは、大本営なしでも組織は機能します。 ところが100人を超えたあたりで抽象的な問題を扱い、非抽象的な問題に転換するための組織である「大本営」が設立されます。 この記事で書きたいこと なぜ大企業で「大本営」が必要とされるのか？ また「大本営」が「大本営」であるがゆえになぜ途中でつまづくのか？ という話を書いていきたいと思います。 そもそもなぜ「大本営」が存在するのか？ はいここから私の仮説。 大体こちらの通り、一般の人は抽象度が高い問題を抽象度が高いまま扱うことができません。 ではどう

プログラミングが好きなエンジニアの渡辺です。 先日 TechMTG という社内のエンジニアミーティングの場でお話させて頂いたことを書いてみようと思います。 表題の「正解にする力」というのは様々な意思決定に適用出来るものとして考えていますが、今回は技術選定という観点でお話します。 技術選定というと、世の中のデファクトだとか、新しい技術だとか、社内で実績のある枯れた技術とか色々な理由や基準で選ぶのが良いと、至るところで言われていると思います。 選定時に議論が平行線にならないように、判断基準を設けるべきというのもあるでしょう。 これらは重要であり、検討、準備することは必要ですが、それに加えて「正解にする力」というのも重要なのではないか？という提案です。 まず、組織における技術選定とは「正解を選ぶ」ことではないと思っています。 これはその技術選定結果はその人個人についてまわるのではなく、組織として

近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも

最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。 【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。 チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料 課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした

<? include("abc.php"); include("def.php"); include("conf.php"); include("db.php"); include("some.php"); include("what.php"); Define("NUM", 100); class super_calc extends great_calc { /* * * * コンストラクタ * * * * */ public function super_calc($initial_num){ $this->db = DB::getDb(DSN); $this->initial_num = $initial_num; } /* * * * チェック * * * * */ public add_ok($add_num){ $res = $this->addable($add_num);

こんにちは! ソウゾウのSoftware Engineerの@ogataka50です。連載：メルカリShops 開発の裏側 Vol.2の9日目を担当させていただきます。 9日目はメルカリShopsを開発する中でのDesign Docsの運用について紹介させて頂きます。 Design Docsとは Design DocsとはGoogleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的になります。 例として、GoogleでのDesign Docsについては下記にまとめられています。 Design Docs at Google メルカリShopsでのDesign Docsのte

開発と運用の理想的な関係とはどんな姿か。すでに「DevOps」という言葉は浸透しているものの、理想的な形で実践できているかとなると、話は別だ。現場ではどんな障壁があり、DevとOpsが分断されているのか。打開していくにはどうしたらいいのか。DevOpsという言葉が生まれる前から、その本質を実践してきたAmazonのカルチャーにヒントがありそうだ。AWSジャパン 塚田朗弘氏に聞いた。 今回お話を伺った、アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 塚田朗弘氏 ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」 Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の

これは、はてなアドベントカレンダーの25日目の記事です。昨日は id:nabeop による Hatena Developer Blog 編集部の活動の紹介 でした。 こんにちは。CTO の id:motemen です。CTO としては、はてなにおけるエンジニア組織全体を見ています。この機会に、はてなの技術組織が現在どのようであるか、について概観を書いてみます。 はてなのプロダクトたち はじめにこの話の前提として、はてなの事業やこれまでの組織について軽く触れておきます。 会社情報ページにあるように、はてなは「コンテンツプラットフォーム」「コンテンツマーケティング」「テクノロジーソリューション」という3つの分野でサービスを展開しています。それぞれ、 はてなブログやはてなブックマーク はてなブログMedia GigaViewerやカクヨム、Mackerel が代表的なプロダクトです。これらを70

2022.01.19 働き方 芹澤雅人SmartHRLayerX松本勇気CTO クラウド人事労務ソフト『SmartHR』を開発運営するSmartHRの創業者で代表取締役の宮田昇始さんが1月1日付で退任。後任には取締役CTOだった芹澤雅人さんが就いた。 CEO交代を告げた宮田さんのツイートは多くの注目を集めた。中には「今回のようなCTOからCEO（代表）のキャリアが今後のトレンドになっていくのでは」と指摘する声もあった。 この度、SmartHRの社長を退任することに決めました！来年1月1日で交代します。 新CEOは現CTOの芹澤さんです！ @masato_serizawa 私は取締役として残り、SmartHR 100%子会社をつくって、新規事業やります。 次は SaaS + FinTech をやるぞ〜！1人目のエンジニア募集中です！https://t.co/NmASulCwNC — Shoj

こんにちは、CTOの山岡（@hiro_y）です。このエントリーは「イノベーター・ジャパンAdvent Calendar 2021」の24日目の記事です。 あなたの会社に「頼りにできるエンジニア」はいるでしょうか。業務に必要なドメイン知識を持っていて、技術的にも複数領域携われる力があるような、そういう存在。 非常にありがたい存在なのですが、彼らに対して私たちはどうしても依存しがちです。この人に聞けば答えてくれる、安心感。それはいつしか依存に変わります。いつの間にか、その人なしではプロジェクトがまわらないようになっていたりしないでしょうか。その人がいるから他にエンジニアを入れなくていい、と判断してしまうこともあるかもしれません。 プロジェクトが小さいうちは、それでもシステム開発が成り立ちます。しかしプロジェクトが大きくなったり、継続性を考えなければならなくなったときに個人の力に頼りすぎてしまう

こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ

この記事は Kyash Advent Calendar 2021 2日目の記事です。 2020年1月から2021年6月まで、1年半ほどKyashでEngineering Managerをやっていました。2021年7月からはロールを変えて、QAチームのいちメンバーとしてAPIのテストやテストの効率化に取り組んでいます。 EMをやめた経緯とやめた後の所感を備忘として残しておきます。 EMとしてやっていたこと 2020年にやってきたことは去年まとめました。 konifar.hatenablog.com 2021年は、共有口座やイマすぐ入金、セブン銀行出金などのリリースに向けてMobile / サーバーサイド / QAのチームでプロジェクトを進めたり、プロダクト開発フローを整えたり、エンジニア採用のリードをしたりしていました。 EMをやめるきっかけ そんな中で、3月くらいに「なんだか最近仕事が面白

全社員がリモートワークで働くGitLabが今日、米NASDAQ市場に上場。時価総額は約1兆2000億円に GitLab社が米NASDAQ市場に上場を果たし、14日午前9時半（現地時間）にニューヨークにあるNASDAQ市場のオープニングベルを鳴らすセレモニーを同社共同創業者兼CEOのSid Sijbrandij氏と同社共同創業者でエンジニアリングフェローのDmitriy Zaporozhets氏が行いました。 売り出し価格は77ドルで、同社の時価総額は110億ドル、日本円で約1兆2000億円となりました。 同社がサービスを提供しているソースコード管理の分野やDevOpsの分野には、マイクロソフトに買収されたGitHubという強力な競合企業がすでに存在し、それ以外にもDevOpsのためのソフトウェアやサービスを提供する企業が多数存在しています。 そうした中で、創業当初からオフィスを持たず、世界

柴田(@4bata)です。「それぐらいわかるだろ･･･」が通じなくなるタイミングがあるんだなという発見です！ 考えたきっかけ：「オープンでフラットだと思ってたけど、結構閉鎖的なところもある」というセリフを聞いたその人に情報が伝わってなかったのかな。私の最初の感想は「前からそうだった気がするけどな･･･」。以前から整った形で情報はちゃんと流れてない。私にとっては、今働いている会社が閉鎖的には見えてない。実際には閉鎖的な部分があるのだろう。その差を理解してみたくなった。 情報の伝わり方を単純化して考える近くにいる人には自分の活動内容や背景にある意図が勝手に届くとする。携帯の電波が届く範囲、みたいなイメージ。 接触頻度が高い人同士は、いろいろ理解できている。 人数が少ないときは、何もしなくても相互に活動内容や意図が伝わっている・自分が理解できない情報も、一緒に仕事してる隣の人に聞けば情報の背景が