はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答

Measuring developer productivity is a difficult challenge. Conventional metrics focused on development cycle time and throughput are limited, and there aren't obvious answers for where else to turn. Qualitative metrics offer a powerful way to measure and understand developer productivity using data derived from developers themselves. Organizations should prioritize measuring developer productivity

エンジニアリング戦略室の高井といいます。 みなさん、開発生産性を高めていますか？　近頃、開発生産性という言葉をよく聞くようになってきました。開発生産性について書かれたブログや技術イベントでの発表を目にする機会が増えています。これはソフトウェアの重要性が高まってきていることや、またアメリカの金利政策によってマクロ経済状況が変化したという背景が影響しているようにも感じます。開発生産性という言葉がバズワードのようになりつつあります。 誰もが重要だと考えている開発生産性ですが、それが何であるのか、またどのように改善していくのか、という具体的な話になると喧喧諤諤の議論になってしまうようです。開発生産性とは、どうにも茫漠としていて、とらえどころがない、そしてなかなか難しいものです。 本エントリーでは、いくつかの研究を補助線にしつつ、開発生産性というよりも開発者体験にフォーカスしてみた私たちの経験につい

はじめに自分たちのチームがどういう状態なのか推定するための指標として、開発生産性フレームワークSPACEの活用を試みているところです。いまのところは概要記事を読んで、元の論文をざっくり読んで、それをもとに「自分たちで追いかけるならこういう指標かな？」って考えて、チームに共有して、みんなでどうするといいだろうねって考える段階。だからnoteとかにまとめるのは、もうすこしカッチリ言語化できたり、その指標を追うことで何か変化が起こったタイミングにしようと思っていました。 先日参加した「EMゆるミートアップ vol.6〜LT会〜」で、HACOBUのけんにぃさんが「チーム実績をSPACEで表現してみるチャレンジ」という発表をされていました。なぜSPACEで表現してみようと思ったのか、何に気をつけているのかなどがコンパクトにまとまった良いLT資料なのでぜひ目を通していただいたのですが、この発表を聞いて

NTT Comの技術顧問が「目標設定の基本」について講演する「エンジニアリングマネージャーと目標設定」。ここで株式会社アトラクタ Founder兼CTO / アジャイルコーチ兼NTT Comの技術顧問の吉羽氏が登壇。目標設定のやり方とその運用方法について話します。 「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話 吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。 「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。 僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があ

サマリー：本稿では、マイクロソフトがどのように組織文化の変革を実現したのか、筆者が実施した調査を元に解説する。一定の利益を出す既存事業に安住してしまう状況は、組織文化が旧来のままであるために起こった。その後、サ...　もっと見るティア・ナデラの下で、組織変革を遂げ、いまに至る。その変遷を、グーグルと対比しながら解説する。　閉じる マイクロソフトはどのように組織文化を変えたのか ハイテク業界では長年、マイクロソフトはウィンドウズで市場を独占したことにあぐらをかいている前世紀の成功企業とみなされてきた。なにしろ同社はもう数十年も、画期的なイノベーションを起こしていない。他社を素早く追従するファストフォロワー戦略を取れるだけの潤沢な資金はあるが、どの市場においてもリーダーになるには大きすぎ、官僚的すぎた。アマゾン・ドットコムのジェフ・ベゾスは東を指差し、社員に「シアトルの隣人のように自己満足に陥

イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。

カテゴリー DX (2) 一般 (58) 研究会 (6) 働き方 (4) 技術 (351) Edge AI (2) Edge Computing (12) Erlang (1) FIWARE (2) Fog Computing (9) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (4) RealTime Web (14) SRE (2) Webサービス (42) インフラ (7) コンテナ (3) ストレージ (92) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (214) 仮想化 (110) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティング

8月に出る新刊のお知らせです！ 企業でよくある人事制度では、技術職の上位職としてテクニカルスペシャリスト職とマネジメント職が用意されている、というのをよく見ます。 わたしも前職でまさにそういう人事制度のもと、管理職として本を読んだり研修を受けたり相談したり、いろいろやってた記憶があります。 いざ管理職になるといっても、用意されている研修プログラムは薄らボンヤリした一般的な内容で（そりゃそうですよね、マネジメントって人が相手なのにその実装を抜いた話はボンヤリするに決まってる）、結局マネジメントのしかたなんて誰も教えてくれないし、上司やデキる人の真似をするぐらい。個人が体得していく専門性なんて怪しいもので、センスのある人はいいマネージャーになるけど、センスがない人は全然ダメ。センスのないマネジメントの部下になんてなったら最悪。そもそもセンスってなんだ！ いいマネージャーかどうかって何をもって評

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書

fukabori.fm fukabori.fmは2018年からiwashiさんが運営している（すごい！）、技術・組織・開発などを中心に話すTech系のPodcastです。 実はお仕事のご縁でiwashiさんの社内向けラジオ（一般公開なし）に出たことがあるのですが、 それ以来ひさびさにお声がけいただき、2021年12月に発売された拙訳『チームトポロジー』について話してきました。 （話の中でたまに "チームトポロジーズ" って言ってるんですが、正しくは "チームトポロジー" ですね。英語タイトルが "Team Topologies" だったので…） fukabori.fm 月並みな感想ですが、社外の人と雑談をすること自体も久しぶりで楽しかったです。 ライブ感のある収録で、聞き直してみると「あー、ここは言葉が足りなかったな」とか思うところはあったり、ちいとぽ関係ないじゃんみたいな話も盛り上がって

世界中で、熱心なファンが急増しているNotion。2021年10月には2億7500万ドル（約307億円）の資金調達を発表し、評価額は100億ドル（約1兆1200億円）へと上昇。急成長を遂げているNotionのプロダクト開発と組織作りについて、エンジニアリング責任者 Michael manapat（マイケル・マナパット）さんが語ってくれた。 目次 ・Notionの組織構成 ・Notionの製品決定プロセス ・Notionのプロダクトデザインの考え方 ・Notionのプロダクトとビジネスニーズのバランス ・Notionで働くエンジニアの役割 ・Notionのエンジニア採用 ・Notion流PLGにおいて大事なこと ※2021年12月9～10日に開催された【PRODUCT LEADERS SALON 2021】より、Notionにてエンジニアリングの責任者を務めるMichael Manapatさ

5年前に出た翻訳書『ジョイ・インク 役職も部署もない全員主役のマネジメント』が、やっと2刷となりました！🎉 愛読者を公言してはばからないクリエーションラインの安田さんに「遅いよ！」とご叱責を受けながらも笑、5年の時を経て増刷に至ることができたのは、その安田さんを含めご愛読いただいた読者の皆さまのおかげでじわじわと浸透してきた結果なのかなと思っています。 ほんとうにありがとうございます。 「実践！ ジョイ・インクへの道」クリエーションラインが文化を変えるためにやったこと【デブサミ2020】 (1/2)：CodeZine（コードジン） 第2刷を記念して、翻訳者であるKiro、やっとむさん、Ryuzee、かわぐちさん（書誌情報の翻訳者順）と安田さんとともに座談会をしました。 わたし「ビジネスのアイデアはないけど作ること自体が喜びなんだっていう人からしたら、こういうところで仕事をするのってめちゃ

n @_sh0he1 - ビデオ通話・対面などの同期コミュニケーションが減り、チャット・メールなど情報量が少ない非同期コミュニケーションが増えた - グループ内にリモートに転向した同僚がいると、オフィスに残った同僚でも同様の変化が見られた（！） (2/n) 2021-09-11 00:52:29 n @_sh0he1 結論：リモート化は組織内のサイロ化を進める、質と量で劣る非同期コミュニケーションの増加を招き、労働者のアウトプットに長期的に影響する恐れがある。また、ハイブリッド型勤務でも”全員出勤日・リモート日”を設けるなど工夫しないとリモートの悪影響を受けることがわかった。 2021-09-11 00:54:53 リンク Nature Human Behaviour The effects of remote work on collaboration among information

小中高 SRE チームで Engineering Manager をやっている @yuya-takeyama です。 Quipper にはスタディサプリ ENGLISH の SRE である ENGLISH SRE チームと合わせて 2 つの SRE チームがありますが、この記事では自分たち小中高 SRE チームについての話です。 少し前の話になるんですが、小中高 SRE チームの Vision, Mission, Values というものをチームで作りました。 Quipper には会社としての Vision, Mission そして Quipper Identities というものがあります。 これらは策定から数年以上経っていますが、Quipper の社員にとって今も変わらず大事なものです。 が、SRE チームにとっては教育や学習に対して直接的に貢献しているとは言いづらい状況です。 そこで

ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin

『Harvard Business Review』を支える豪華執筆陣の中で、特に注目すべき著者を毎月1人ずつ、東京都立大学名誉教授である森本博行氏と編集部が厳選して、ご紹介します。彼らはいかにして現在の思考にたどり着いたのか。それを体系的に学ぶ機会としてご活用ください。2020年6月の注目著者は、ハーバード・ビジネス・スクール准教授のイーサン・バーンスタイン氏です。 アマースト大学時代に 日本の同志社大学で学ぶ イーサン・バーンスタイン（Ethan S. Bernstein）は1976年、米国カリフォルニア州ロサンゼルスに生まれた。現在44歳。ハーバード・ビジネス・スクール（HBS）の組織行動ユニットに所属し、エドワード W. コナード記念講座准教授を務める。 HBSのMBAコースでは２年生の「ヒューマン・キャピタル・マネジメント」を担当している。2013年から2017年までは、１年生の必

同僚のキャリー（仮名）が退職した。理由は会社外の事情で母国に戻らないといけなくなったから。同い年だったけど、彼女は僕にとってのロールモデルだった。まだまだ学びたいことも多かったので、いなくなってしまったのはとても悲しい。彼女こそが僕をDuolingoに誘い入れてくれた恩人だったのだから。 キャリーからとつぜん連絡があったのは、2020年3月のこと。Duolingoにこない？と。 もうあれから1年経つのかー 少しセンチメンタルな気持ちになりつつ、当時の選考過程を思い返した。 *** Duolingoの採用プロセスは本当にすごかった。他の外資企業の面接もいくつか経験してきたが、それらと比べても濃密で、隙のない面接体験だった。これは絶対に多くの企業の参考になる。キャリーの退職きっかけではあるけど、自分が体験したプロセスをできるだけ詳しく紹介していきたいと思う。 恐ろしく長くなってしまったけど、日

本書は、"Jonathan Rasmusson. Competing with Unicorns: How the World's Best Companies Ship Software and Work Differently. The Pragmatic Programmers, LLC, 2019. 978-1-68050-723-2"の全訳です。著者の訳書は『アジャイルサムライ』（オーム社、2010年）、『初めての自動テスト』（オライリー・ジャパン、2016年）に続く3作目です。 本文中では明示されていませんが、本書の対象読者について、著者は出版後のインタビュー記事で次のように語っています。「業務としてソフトウェアデリバリーに関わっている人たち（開発者、テスター、デザイナー、マネージャーなど）なら誰でもだけど、本当の対象読者は経営リーダーを始めとした、チームをプロダクトやソフトウ