なぜ変化を起こすのが難しいのか？ - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several yearsRegional Scrum Gathering℠ Tokyo 2023 のクロージングキーノートの資料です。 https://2023.scrumgatheringtokyo.org/index.html
ソフトウェア開発における人的リソースの理想的な配分
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか？ タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
内製化をすすめる知人へのアドバイス - Kengo's blog
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)
単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理
SmartHR社の「バリュー」を1つ増やしました - 宮田昇始のブログ
全社イベントで使用した、実際の資料の表紙 『認識のズレを自ら埋めよう』 2020年7月の全社イベントで、バリューを1つ増やす発表をしました。 SmartHR社にとって7つ目のバリューは『認識のズレを自ら埋めよう』です。 『認識のズレを自ら埋めよう』 人が増えると、意見が増え、相互理解が難しくなる。 建設的に議論ができないときは、前提のズレを疑おう。 相手の意図を聞き、自らも意図を話そう。 私たちは、相互理解と建設的な議論を諦めない。 なぜこのタイミングなのか、なぜこのバリューなのか、はじめて社外向けに書こうと思います。 バリューの変遷 本題の前に、これまでのバリューの変遷を紹介します。 ver 1.0 2015年6月 最初のバージョンをつくった（社員数 2名） ver 2.0 2016年1月 マイナーチェンジ（社員数 7名） ver 3.0 2016年7月 ほぼいまの形に（社員数 10名）
専門職と視座
こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座！視座！」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ
プロダクトが進捗していないと感じた時の戦い方 - hikoharu's blog
この記事は Product Manager Advent Calendar 2019の18日目 です。 はじめに プロダクト作りにおける負債の種類 技術的負債 組織的負債 関係者的負債 思想的負債 負債の誕生 影響し合う負債の恐ろしさ 地道に負債を解きほぐしていく おわりに はじめに Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。 スタートアップの強みはストラテジーと実装の一致 早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。 逆に言うと、これらが一致していない場合、早さは生まれない。 正しい戦略が、組織や技術的負債のために実行されなければバツ。 逆に素晴らしいテクノロジーを扱えるチームがあったとしても、
一休の現在と、ここまでの道のり
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで
【翻訳】「シリコンバレーから生まれた最高の文書」と絶賛されたNetflixのカルチャーガイド全文 - BppLOG
Netflixの企業文化や社員の行動規範を定めたカルチャーガイドが公開されており、FacebookのCOOのシェリル・サンドバーグが「シリコンバレーから生まれた最高の文書」と評価しています。 そのカルチャーガイドはもともと2009年にスライドとして公開され、最新版はNetflixの採用ページ上に掲載されています。今回は許可を得て翻訳することにしました。 Netflix Culture (原文) (目次) 本物の価値観 判断力 コミュニケーション 好奇心 勇気 情熱 無私無欲 イノベーション 一体性 誠実 影響力 ドリームチーム 自由と責任 情報に通じたキャプテン 統制ではなく前後関係 高度に整列し、緩く結合する 卓越性を探し求める まとめ 最後に エンターテインメントは、友情のように、人間が基本的に必要としているものです。エンターテインメントは私たちの感じ方を変え、私たちに共通点をもたらし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
