未知の未知を既知の未知へ / Unknown unknowns to Known unknownshttps://future.connpass.com/event/318520/ FUTURE TECH TALK #1 ボトムアップで考えるアーキテクト教育Lunchセッション会 2024.06.05（Wed）12:00–13:00
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
チームの機能と配備を考えるための7つのチーム責務定義ガイドライン - mtx2s’s blog
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
チーム開発における技術選定の進め方 - ROUTE06 Tech Blog
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
カミナシ社の執行役員 CTO に就任しました｜Tori Hara
トリ(@toricls)です。 カミナシに入社してから早いもので3ヶ月 + α が経ちましたが、さすがのアーリーステージなスタートアップという感じです。前職では想像もしなかったようなスピード感で激☆動イベントがポコポコ発生し、つい先日書いた入社エントリがすでに遠い過去のことのように感じます。 というわけで、本日(2022年7月1日)付けでカミナシの執行役員 CTO に就任しました。 本記事では、あらためてカミナシという会社やサービス、それらを支えるエンジニアリング組織の話とともに、就任にあたっての今後への思いをしたためようと思います。 CTO 就任の経緯これまで公にはしてなかったのですが、実はもともとカミナシからの入社オファーは『CTO 候補』というタイトルでもらっていました。僕はこれまで CTO という役割を経験したことがないため、まずは入社して一緒に働いてみて、僕も会社もお互いに期待に
Openness について - satoshihirose.log
"不必要なコミュニケーションを制限する" チームトポロジーを読んでいる。 一環して、逆コンウェイの法則に従うように、つまり理想のシステムアーキテクチャに沿うように組織設計をしようと主張する本である。 チャプター2 で、不必要なコミュニケーションを制限する という節がある。 コンウェイの法則の示す重要な点は、すべてのコミュニケーションとコラボレーションがよいとは限らないということだ。したがって「チームインターフェイス」を定義し、どんな仕事には強力なコラボレーションが必要で、どんな仕事には必要ないのかという期待値を設定することが重要になる。多くの組織はいつでもコミュニケーションは多いほうがよいと考えるが、実際にはそうではない。 必要とされるのは、特定のチーム間における集中的なコミュニケーションだ。予期せぬコミュニケーションを探し、その原因に取り組むことが必要なのだ。 ソフトウェアエンジニアとし
誰も手をつけたがらない仕事を拾う親切心とその危うさ | Q by Livesense
落ちているボールを拾う、という比喩がある。職場で使われるときはもっぱら、ボールという言葉は仕事を意味している。 だから、落ちているボールを拾うという比喩は、誰も手をつけていない仕事に自ら手をつける、ということを指す。ボールというくらいだから、だいたいそれは軽微な仕事に限られる。 落ちているボールを拾うことは、基本的にはいいことだとされている。ボールが落ちていては、仕事が進まない。 ちょっと資料を直したり、誰かに依頼の連絡をしたり、スケジュールを引き直すほどではない、小さな仕事は日々たくさん生まれる。会議の終わりには「これは誰のボール？」と聞いて、ＴＯＤＯが零れ落ちないよう確認したりする。 それでも落ちてしまうのがボールというものの（つまり仕事というものの）困った特性で、拾ってくれた人には「拾ってくれてありがとう」と声をかけることもある。 落ちるボールはさまざまだが、誰でもできるようなものが
Good Tech Lead, Bad Tech Lead
A brief guide to tech leadership at Foursquare, inspired by Ben Horowitz’s Good Product Manager, Bad Product Manager. TeamworkGood tech leads act as a member of the team, and consider themselves successful when the team is successful. They take their share of unsexy grungy work and clear roadblocks so their team can operate at 100%. They work to broaden the technical capabilities of their team, ma
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
「Retrospectives Antipatterns」を読んだ - 勘と経験と読経
先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみた。アンチパターン好きなもので。すごい有用な本だった。 Retrospectives Antipatterns 作者:Corry, Aino,Corry, Aino発売日: 2020/11/02メディア: ペーパーバック 著者サイトはこちらのようだ。https://metadeveloper.com/ 全体的な感想 えてして「ふりかえり」のファシリテーターは孤独だと思う。特にファシリテーションすること自体を主な仕事にしている場合、「より良い
テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
以下のイベントの投影資料です。 https://d-cube.connpass.com/event/187308/ お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料内にあるURL】 ▽P2：書籍『Agile Testing Condensed』 https://leanpub.com/agiletesting-condensed-japanese-edition ▽P36：書籍『A Practical Guide to Testing in DevOps』 https://leanpub.com/testingindevops ▽P55：プランニングポーカーかんたんガイド https://www.slideshare.net/Ryuzee/ss-11644359/4 ▽P69：Agile Testingのエッセンス #scrumosaka h
ボロボロの情シスを立て直すためにやってきたこと
数年前、今の会社の情報システム部（以下、情シス）のマネージャとして着任したとき、情シスはボロボロだった。社内ITを司る部門が体を成していない以上、会社のITガバナンスは当然存在しないようなものだし、情シス部門の社内からの信頼も低く、雑務を押し付けられる感じだった。当然ながら、部内の雰囲気も悪く、正直、大変なところに来たものだと思った。 とはいえ、それより悪くならないだろうと、こつこついろんなことをやってきた。 結果として、今は社内から感謝され、事あるごとに相談されるIT部門に成長した。数年で部のメンバの数も倍以上の人数になった。決して私1人の力で出来たことではないけれど、部門のトップとしてやってきたとこを振り返ってみると、大きく5つのポイントがあったのかな、って思う。 １．ルールを作り公開する まず絶対必要なのが、ルールを作り公開すること。反発の少ない小さな単位から一つ一つ増やしていく。ル
IaC Maturity Model と学習ステップ #srefm - ツナワタリマイライフ
はじめに 先日、ノリと勢いで企画した SRE.fm を行い、ゆるふわに Terraform や IaC の話をしました。 sre-fm.connpass.com 実際にやってみて、質問への回答を行う中で、IaC に関わるひとたちのマジョリティと自分たちには大きな隔たりがあるような感覚を持ちました。そういった中で、質問の1点1点に答えるというよりも、大局的な理解であったり、その本質的な要素であったり、段階に分けた学習ステップ等を言語化することが必要なのではないか、と（その後の二次会で）たどり着きました。 「IaC は当たり前になった」というのは Infra Study Meetup #1「Infrastructure as Code」 での Mizzy さんの言葉で、これに関しては大きく同意するものの、この「当たり前」は「誰でもしている状態になった」「できていないのはありえない」というもので
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary
RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DX DevEx 360 | Technology Radar | Thoughtworks
組織の生産性を高める意思決定の構造と方法 / How to do make decision rapidly and effectively
主体性を失わせるアンチパターンをやってしまっていた話 | ドクセル
あなたのチームの「いい人」は機能していますか？
