『レベル３』の開発生産性を実現するための技術経営とSaaSファースト戦略
株式会社アンチパターン 小笹 佑京さん
- レベル3の開発生産性
- 生産性 = アプトプット / インプット
- レベル3はエンジニアの領域を超えた事業部門全体に対する生産性
- 売上や利益
- 生産性の段階
- レベル1：仕事量/開発チーム
- レベル2：期待付加価値/プロダクト開発組織
- レベル3：実現付加価値/事業部門全体
- 企業経営におけるエンジニアの関わり
- 売上向上
- コスト削減
- リスク低減
- 生成AI時代
- 小さいチームで大きな仕事
- エンジニアも経営者視点
- 業務領域の分類
- 事業的に競争領域かどうか/技術的に競争領域かどうか
- 領域によってコストをかけるべきかどうかの判断
- SaaSを使うのが効率いい領域もある
- コア領域にどれだけ注力できるか
レベル1の開発生産性向上に取り組む─日々の作業の効率化・自動化を通じた改善活動
ソーシャルデータバンク株式会社 櫻田 健治さん
- レベル1の生産性工場の事例
- IP制限の自動化
- 検証環境をインターネット上に公開したくない
- 依頼する人される人の作業と待ち時間
- アクセスすると数時間アクセスできるようになるWebページを作った
- 情報共有の効率化
- ポストモーテムのチーム間共有
- 生成AIで絵本にしてみて見たもらいやすく
- 何を書い得てるのかよくわからないということはなくなった
MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて
三菱UFJインフォメーションテクノロジー株式会社 髙橋 博実さん
- 開発プロセスのモダナイズ
- 蛇口をひねったら当たり前に水が出るように開発環境をととのえる
- gitやVSCodeやテスト自動化しましょうとか
- 整備したツールを現場にどうやって浸透させるか
- マネジメント層に体感してもらって広めてもらうとか
- 生産性の指標
- DORA/FourKeys
- SPACE
- 生産性向上のためのメトリクス
- 目的ベースであるべき
- だけど目的を満たすデータがないことも多い
- データとして使えるように残すことを意識しておくことが大事
- 人手じゃなくて自動でとる
- 目的ベースであるべき
- メトリクスの可視化
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ
株式会社ログラス 飯田 意己さん
- 開発組織
- 1チームから始まって事業拡大にともないチーム数も増大
- ドメインが複雑な中で横断的な体験の整合性も必要
- FAST
- やってみて
- チームが流動的なのが特徴だがだんだん落ち着いてくる
- 各チームがある程度の品質を満たせるような構成になっているかどうか
- 中核的な機能の開発はコア開発者が入っていないと難しい
- チームのサイロ化問題
- FASTにして解消はした
- チームの流動性が落ち着いてきてからまた起き始めた
- チーム間での協働の視点は常に必要
- 開発生産性との向き合い
- 今は大規模なモノリス
- コードベースが大きくなっても変更容易性を維持できている
- 案件の規模が大きくなってリードタイムが延びてる
- データ量の増大で非機能に対する対処もある
- 仕事量の生産性は分かりやすい
- 期待付加価値の生産性の改善は難易度が高い
- 生産性指標は健康診断のようなもの
- 過去がどうだったかを見て短期的な対処は見える
- 長期的な視点を忘れないように
- 今は大規模なモノリス
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質のマネジメント
株式会社タイミー 恩田 拓也さん
https://speakerdeck.com/takuya542/sohutoueapin-zhi-woshu-zi-dezhuo-eruji-shu-shi-ye-cheng-chang-wozhi-erusisutemupin-zhi-no-manezimento
- 開発生産性とシステム品質
- 正の相関がある
- 品質が上がれば生産性も上がる
- 生産性指標
- 数値化された品質や生産性は業績評価にはしない
- 結果指標でしかない
- プロダクトが成長すると専門性によって組織が細分化し分業化されてくる
- チーム間で指標が直交し始める
- サイロ化はある程度しかたないが生産性の指標が直行しないようにする
- プラットフォームエンジニアリングチームを活用していく
- 品質のフィードバックループ
- 開発者が瀕死地のフィードバックを受ける
- 体験悪化のアラート/トリアージ/整備
- テスト設計や品質保証活動を開発者もやる
- フィードバックを楽に早く
- 試験環境を複数チーム並列に使えるように
- 非機能まで含めた試験ができる環境
- 開発者が瀕死地のフィードバックを受ける
- ボトルネックに目を向ける
- さまざままな切り口で見つけていく
- コーディング以外のフェーズも
- 必要とされているプロセス
- トイルな作業
- ユーザージャーニー軸/アーキテクチャ軸/データフロー軸
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
合同会社DMM.com 石垣 雅人さん
https://speakerdeck.com/i35_267/wu-yi-wei-nakai-fa-sheng-chan-xing-noyi-lun-karaba-kechu-sutamenoyu-zhao-jian-zhi-toojin-toai
- 無意味な開発生産性議論
- すぐに改善してという重圧
- とにかく早くという重圧
- エンジニアだけが改善を求められる重圧
- 後ろの工程の担当のため
- これらは結局小手先の対応しかされない
- 感覚に頼らない生産性の予兆検知
- 最初は健全なソフトウェアでだんだん負債が溜まってくる
- 抑制と解消が必要
- どのタイミングで問題が起きるか検知は難しい
- 感覚に頼らずに検知していく
- 検知項目
- 見積もりと実績の差分
- 開発〜リリースは原因が多様すぎる
- 障害件数と再発防止完了件数
- 投資してる開発区分
- エンゲージメントスコア
- 生産性が下がってるとスコアも低い
- 見積もりと実績の差分
- 最初は健全なソフトウェアでだんだん負債が溜まってくる
- AIによる変化
- 人の動きと非同期で成果物が出てくるようになった
- 人はガードレール的な役割
- 未来は人は問いと出口の判断
- 生産性は大幅に上がる
- 無意味な開発生産性の議論はなくなる
- 使ってるかどうかの差が大きくなる
- プロセスをAI前提に作り変える必要性
- 局所最適化ではなく
- 人の動きと非同期で成果物が出てくるようになった
ソフトウェアエンジニアリングの人類史 〜AI エージェント時代の知識創造企業〜
株式会社レクター / 日本CTO協会 広木 大地さん
- AIによって仕事は奪われるのだろうか
- 歴史上AIに限られず技術の進歩で仕事は奪われてきた
- 仕事の内容はどんな仕事も変わり続けてる
- ソフトウェアは簡単になり続けて安くなり続けてる
- ソフトウェアの複雑さは増してるがコストは下がって適応領域が増えてる
- AI時代の生産性
- マクロな幻想よりミクロな現実
