matsumoto.s

MaaS 関連プロダクト群の技術戦略・データ戦略・エンジニアリングマネージャー / ex- CRMツール開発のテクニカルディレクター、エンジニアリングマネージャー、ソフトウェアエンジニア / バックエンド、ビッグデータ、データビジュアライゼーション / モビリティ、マーケティング、CRM

[matsumoto.s @mtx2s]

執筆した書籍のタイトルと発売日が決まりました！

8/25発売
チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計

カバーイメージはまだですが、既にオンライン書店には並んでいるようです
内容については、ひとまずこちらの概要文をご覧ください
https://t.co/G6oMJruy6J

[matsumoto.s @mtx2s]

@R5ni4 こちらこそお招きいただきありがとうございました！
台風で電車が止まらないかと、少しヒヤヒヤしましたね
また機会がありましたらぜひお邪魔させてください

[matsumoto.s @mtx2s]

本日はフェンリルさんのオフィスで開かれたイベントにお招きいただき、「コードレビューを制するチームがソフトウェアデリバリーのフローを制す」というタイトルで登壇しました
資料は公開済みですが、実は各ページに細かな注釈を仕込んでいました
参加された方もぜひお楽しみください

[matsumoto.s @mtx2s]

CodeRabbit User Group Osaka #2
https://t.co/FVeY5wxtsu #CR_UG

[matsumoto.s @mtx2s]

いよいよ来週6/2（火）の大阪での登壇に向け、資料を作成中・・
テーマは、人間によるコードレビューを今後どうしていこうか、というもの
お近くの方は、ぜひご参加ください

[matsumoto.s @mtx2s]

面白い
こうやってストーリーとして描かれると、今どこへ向かいつつあるのか、何を目指しているのか、何をやればいいかがイメージしやすくなるなあ

[iwashi / Yoshimasa Iwase @iwashi86]

2年後のエンジニア（やチームの）働き方ってどうなるだろう、ってのを想像して書いてみました。

"開発があまりに早すぎるので、仕様書は書かれた瞬間から古くなっていく。誰も無条件には仕様書を信用しなくなった"

"コードオーナーシップという概念は、もはや個人の単位では成立しない"

"まずコードを書く時間が減った。これは間違いない。でも、コードを書く時間は2025年末には大きく変わっていた。それ以上に変わったのは、〜"

など、色々想定して書いてみているので、1つの方向性としてどうぞ。

https://t.co/oYxwKVBBs6

[matsumoto.s @mtx2s]

この記事の音声解説版（ポッドキャスト）はこちら
「（音声解説版）スプリントレビューこそがスクラムを駆動している」
https://t.co/hI3RX78If9

[matsumoto.s @mtx2s]

スクラムでの開発を言い換えるなら、スプリントレビュー駆動開発ではないか。スプリントレビューを見据えて計画し、結果で計画を適応させる。このフィードフォワードとフィードバックが、チームの次の行動を導く。そんな記事を書きました。
https://t.co/sKdlCE302f

[matsumoto.s @mtx2s]

スクラムでの開発を言い換えるなら、スプリントレビュー駆動開発ではないか。スプリントレビューを見据えて計画し、結果で計画を適応させる。このフィードフォワードとフィードバックが、チームの次の行動を導く。そんな記事を書きました。
https://t.co/sKdlCE302f

[matsumoto.s @mtx2s]

@goofmint お声がけいただき、ありがとうございます！
後ほどDMにてご連絡いたします

[matsumoto.s @mtx2s]

はてなブログに新しい記事を投稿しました
「人間によるコードレビューに依存しすぎない“速さと品質の両立”を開発ライフサイクル全体で支える」
https://t.co/fb2jMyI4TD
ボトルネックになりがちなコードレビュー。その役割をSDLC全体に分散することで問題を解消できないか、という話です

[matsumoto.s @mtx2s]

この記事の音声解説版（ポッドキャスト）はこちら
https://t.co/qbPLjwrUIC

[matsumoto.s @mtx2s]

はてなブログに新しい記事を投稿しました
「人間によるコードレビューに依存しすぎない“速さと品質の両立”を開発ライフサイクル全体で支える」
https://t.co/fb2jMyI4TD
ボトルネックになりがちなコードレビュー。その役割をSDLC全体に分散することで問題を解消できないか、という話です

[matsumoto.s @mtx2s]

エピソードのリンクはこちら
https://t.co/S24vUIxsPK

[matsumoto.s @mtx2s]

先日投稿したこのnoteの音声解説板をポッドキャストで公開しました
大きく出すほど価値検証は遅れ、障害時の原因特定は難しく、現場も消耗しやすい。それでもビッグバンリリースが選ばれるのは、その組織なりの合理性があるからだったりする。それにどう対処しようか、という話

[matsumoto.s @mtx2s]

・本番デプロイの失敗に怯えながら、祈るような気持ちでリリースボタンを押す
・苦労して出したのに、ユーザーに刺さらない

それでも繰り返される「ビッグバンリリース」とは何なのか
採用する“理由”、抱えやすい“リスク”、その“軽減策”についてまとめました
https://t.co/IDs2YzUo2w

[matsumoto.s @mtx2s]

ブログ記事の音声解説台本、ついにCodexだけで実用レベルまで自動生成できるようになった！
記事の原稿を入れると、10分ほどで台本ができあがる流れ。
課題はまだ多いけど、NotebookLMに頼らず生成できるようになって、台本のスタイルをかなり自由にコントロールできる点が大きい。

[matsumoto.s @mtx2s]

・本番デプロイの失敗に怯えながら、祈るような気持ちでリリースボタンを押す
・苦労して出したのに、ユーザーに刺さらない

それでも繰り返される「ビッグバンリリース」とは何なのか
採用する“理由”、抱えやすい“リスク”、その“軽減策”についてまとめました
https://t.co/IDs2YzUo2w

[matsumoto.s @mtx2s]

エピソードのリンクはこちら。
https://t.co/DgADPyY8vz

[matsumoto.s @mtx2s]

ポッドキャストエピソードを公開しました
→（AI解説版）コードベースの分散度合いや複雑性、規模がAI導入効果にどう影響するか
・集約型は4倍、分散型は2倍
・グリーンF×低複雑タスクは30-45%, ブラウンF×高複雑タスクは0-10%の向上
・コード行数が増えるほど効果が減衰

[matsumoto.s @mtx2s]

調査によると、AIコーディングエージェントのパフォーマンスはリポジトリが高度に分散していると半減する
AI導入効果が低いのはツールの性能ではなく開発環境に原因があるかもしれない
これを、コードベースの分散度・複雑性・規模に関する調査をもとに考察した記事を書いた
https://t.co/LuWA5NhOs3

[matsumoto.s @mtx2s]

調査によると、AIコーディングエージェントのパフォーマンスはリポジトリが高度に分散していると半減する
AI導入効果が低いのはツールの性能ではなく開発環境に原因があるかもしれない
これを、コードベースの分散度・複雑性・規模に関する調査をもとに考察した記事を書いた
https://t.co/LuWA5NhOs3

[matsumoto.s @mtx2s]

実作業より調整に時間が溶けていると感じるなら分業が原因かもしれない、というエピソードです。
仕事を細分化するほど本来不要な「調整コスト」が膨張します。「人手不足」の正体は、実はこのオーバーヘッドにあるのかもしれません。https://t.co/ti9wwvVau9

[matsumoto.s @mtx2s]

単独で完結できる仕事でも手分けする弊害。こうした分業が進むほどフローが複雑化し、不要な調整コストが増大する。このオーバーヘッドが「人手不足」という幻想を生む要因にもなる。そういう「不合理な分業」が発生するメカニズムについて書いた記事です。
https://t.co/2naRxwL0cr