開発を止めないセキュリティ体制──Visional流 DevSecOps 横断改革
ビジョナル株式会社 峯川 康太さん
株式会社アシュアード 鈴木 康弘さん
- グループのセキュリティ室
- 14名
- グループ横断のセキュリティ支援
- 10以上のプロダクトと30以上の社内システム
- 歴史の長いプロダクトから新規プロダクトまで
- 技術や体制も多様
- 開発チームの支援
- 開発を止めない仕組み
- 一方的なルールの押しつけでスピードを落とさせない
- 開発のライフサイクル全体に組み込んでいく
- 指摘するだけでなくどう対処するかを一緒に考える
fukabori.fm出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話
株式会社SHIFT 森川 知雄さん
岩瀬 義昌さん
- Shift
- 従業員1.4万人
- 毎月180人入ってくる
- SI事業をやっている
- 案件のアサイン管理が大変
- アサイン管理
- 人も案件も多いのに空きがでることがあった
- 独自エクセルでアサイン管理してた
- 管理ツールを開発
- エクセルの仕様を踏襲しようとすると細かすぎてつらい
- エクセルをなくしきれてないがWebツールと共存させている
デジタル庁におけるAI活用の最前線：内製化の推進と行政事務効率化の取組み
デジタル庁 楠 正憲さん
- 行政のAI活用におけるデジタル庁の役割
- 行政でいかにAIを推進していくか
- 最初はAIに関するルールが無いことが課題だった
- OpenAIのサム・アルトマンが総理大臣と2023/4/10にあった
- その後1ヶ月程度で行政で生成AIを使えるようにした
- 今の大臣が就任してAIの推進が加速
- アイデアソン/ハッカソン
- 生成AIの検証
- 業務への適用
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
株式会社Belong 福井 達也さん
- toB,toC,社内向けのサービスがある中で共有プラットフォームの扱い
- 対象となるユーザ属性や開発サイクルなどが違っている
- 機能の優先順位をつけるのが難しい
- EID
- Enineering Initiatives DB
- タスクチケットのようなもので期待するアウトカムを書いたもの
- 利益を生むものか
- コストを下げるものか
- ガバナンス的にやらないといけないこと
- 基準を作ってスコアリングして優先度を決定
- ICE
- Impact
- Confidence
- Ease
- ICE
なぜ「無責任な横軸」がうまくいかないのか 〜 組織の生産性にインパクトを与える振る舞いを考える
- 横軸のチーム
- 一定の規模が超えてくるとニーズが出てくる
- 100人を超える辺りで全体が見えなくなってくる
- サイロ化による問題
- 標準化/共通化
- 組織の広い範囲に対して影響を与える
- 一定の規模が超えてくるとニーズが出てくる
- 責任ある横軸
- インフラ
- セキュリティ
- 法務
- 無責任な横軸
- 抽象的なテーマ
- カルチャー
- 全社標準
- アンチパターン
- 勝手に課題を設定してべき論を押し付ける
- めんどくさそうなところを後回しにすることで後から軋轢
- 消極的で受け身なアプローチが常態化
- プラクティス
- これまでとこれからを伝える
- 建設的に異議をぶつけ合う場
- 打ち手を絶やさないための種蒔き
開発生産性再定義：安定性が生む持続的な顧客価値
株式会社メディカルフォース 畠中 翔一さん
- 安定性と顧客価値が開発生産性？
- アウトプット量の向上より安定
- 予測可能性が高い方がいい
- 一時的にギアをあげてもそれは続かない
- 長期的な視点が大切
- 安定が顧客からの信頼にもつながる
- 顧客価値
エンジニアが主体的にビジネスに貢献する〜開発現場からの変革
株式会社一休 伊藤 直也さん
ファインディ株式会社 山田 裕一朗さん
- エンジニアのビジネス貢献
- できることベースではダメ
- ユーザの現場を見て声を聞いて課題からスタートしないと
- 一次情報を自分で聞いてコンテキストも含んだ情報を得ることに価値がある
- 又聞きだと課題の本質を特定できず勘違いしてしまう
- ビジネスに貢献するエンジニア組織
- 分業するのがダメ
- マネージャー手動じゃなくてメンバーが手動する
- (前提としているエンジニアは壁を作って言われた自分のことしかやらないという前提・・？？)
- PdMとEMはエンジニアが主体的に動くことを支援する仕事
- (そんなにエンジニアが主役の組織でいいのか・・？？)
AI時代の開発生産性戦略：エンジニアは何を武器にすべきか？
ラクスル株式会社 藤門 千明さん
- 自社サービスのID基盤と決済基盤の統合
- シームレスに使えるように
- 複数サービスを一本にするので課題が多い
- PMIに必要な力
- 構造設計
- あるべき姿
- そこまでのロードマップ
- 計測の仕組み
- 協働設計
- 誰がいつどう決めるか
- ギャップをどう埋めるか
- プロセスや文化
- 判断設計
- 何を優先し何を犠牲にするか
- 関係者感で合意しておく
- 構造設計
- AIによるソフトウェア開発
- 苦手なところがPMIでの課題と似てる
- 必要な力も似てるはず
- 属人的なものを共通言語化し再定義する
- 意思決定する地下っら
- AI Agent Coding
AI時代のソフトウェア開発を考える
- Cloud Code Max
- 定額だと考え方が変わってくる
- 動かしてないと損
- Vibe Coding
- 動作確認だけで進めてコードレビューをしない
- 開発スピードが上がって負債の積み重ねスピードも上がった
- レビュー出来ない量のコード
- 発生している諸問題は昔からあるもの
- Vide CodingからAgentic Coding
- 自動化から自働化へ
- Reconciliation Loop
- 望ましい状態を宣言して評価関数も渡してそれを実現するように動いてもらう
- ガードレール技術の必要性
- テスト
- 自動化
- バージョン管理
- 包括的構成管理
- モノレポがいい
- ドキュメントもコードと距離が近いほどいい
- AI委託の場合は後からチェックできるようにしないといけない
- gitへのcommitのしかたを指定したり
- レビューの工夫
- Behavior ChangeとStructure Changeを分ける
- 前者の振る舞いの変更は不可逆なのでレビューする
- diffは小さい方がいい
- 後者の構造の変更は可逆なので仕組み化してレビュー0に
- diffは大きくてもいい
- 前者の振る舞いの変更は不可逆なのでレビューする
- Behavior ChangeとStructure Changeを分ける
