1. CO, Strategist, SOという三段レイヤで情報をまとめてエスカレする
2. 20220517
2.1. メモ
2.1.1. 我々の課題感
2.1.1.1. 木村さん
2.1.1.1.1. 福井さんと同意見
2.1.1.1.2. プロジェクトKDX
2.1.1.2. まとめると...
2.1.1.2.1. KDXを一つのプロジェクトとして考えたときのプロジェクト管理という観点
2.1.1.2.2. プロジェクト管理において信用を得るには
2.1.1.2.3. 報告は定期的に必要であるが、頻度は信頼の大きさに反比例する
2.1.1.2.4. あと、報告書がどういうプロセスで作成・更新されているのかの開示も信頼を受ける上で必要
2.1.1.2.5. つまりこの報告書の作成および更新のプロセスの一つがRoBであり、この観点でのRoBをまとめることが、この会議体で決めることのゴールである
3. 20220510
3.1. メモ
3.1.1. 取り除く
3.1.1.1. co会
3.1.1.2. 取締役会
3.1.1.2.1. 法律系
3.1.1.3. サービスの状況報告会
3.1.1.4. ConnectedDay グループ内の対外的なKDXのサービス群の説明会
3.1.1.5. QBR
3.1.1.5.1. 株主向け
3.1.1.5.2. 株主向けは除く
3.1.1.6. 部課長会
3.1.1.7. プロジェクトの状況報告会
3.1.1.8. 企画開発会議
3.1.1.9. 人事評価会議
3.1.1.9.1. 人事系
3.1.1.10. co合宿
3.1.1.11. サービス別の月単位の予実報告会
3.1.1.11.1. 被ってる
3.1.1.12. プロダクトポートフォリオ単位でのロードマップ検討会
3.1.1.13. 人事委員会
3.1.1.13.1. 人事系
3.1.1.14. 全社集会
3.1.1.14.1. BBQとか
3.1.1.15. DX作戦会議
3.1.1.16. 衛生管理委員会
3.1.1.16.1. 法律系
3.1.1.17. プロダクトポートフォリオ間でのロードマップのキャリブレーション
3.1.1.17.1. 被ってる
3.1.1.18. kadへの経営報告会
3.1.1.19. 株主総会
3.1.1.19.1. 法律系
3.1.1.20. 来期予算検討会
3.1.1.21. コンプライアンス委員会
3.1.1.21.1. 法律系
3.1.1.22. 入社時の研修
3.1.1.22.1. 人事系
3.1.1.23. 採用状況の報告会
3.1.1.24. 諸規定の定期的な見直し
3.1.1.24.1. 法律系
3.1.1.25. 離職状況の報告会
3.1.1.26. 従業員の稼働状況の報告会
3.1.1.26.1. 残業
3.1.1.26.2. 労務系
3.1.1.27. BCP委員会
3.1.1.27.1. 言語化むずい
3.1.1.28. newface cafe
3.1.1.28.1. 懇親系
3.1.1.29. 個別カジュアルランチ会
3.1.1.29.1. 無理やり普段とは違うスキルチーム(EUCとアプリとか)で組むような小規模プロジェクトでの交流
3.1.1.30. スキルアップの研修の状況報告会
3.1.1.30.1. 人事系
3.1.1.31. 投資評価会
3.1.1.31.1. 言語化むずい
3.1.1.32. 全社系の会議の棚卸し
3.1.1.33. 経営Topと現場との対話会
3.1.1.33.1. 問題起こしまくってる工場にいって、彼らの声をtopが居酒屋とかで聞くみたいな
3.1.1.33.2. 基本的に現場->Topという流れ
3.1.1.33.3. 懇親系
3.1.1.34. 試用期間が切れるときの採用継続判定会
3.1.1.34.1. 人事系
3.1.1.35. 案件のクリスタライズ会
3.1.1.36. 案件の優先順位検討会
3.1.1.36.1. 要求の優先順位決め
3.1.1.36.2. 実現可能性を考慮したアサイン
3.1.1.36.3. 差し込みの話
3.1.2. 残ったやつの共通点・課題感
3.1.2.1. 中村
3.1.2.1.1. ロードマップの作成・更新に必要な会議体
3.1.2.2. 福井
3.1.2.2.1. 会社の無計画ぶりに不安を感じている
3.1.2.3. 木嶋
3.1.2.3.1. の共通点は中長期的な会社の部門横断的な方針
3.1.2.3.2. の共通点は実際の具体的な案件
3.1.2.4. 外所
3.1.2.4.1. 人事系の事務作業が期間短めで急に降ってくる不安
3.1.2.4.2. 会議の目的がそれぞれで定まってない不安
4. 20220419
4.1. メモ
4.1.1. 木村さんより
4.1.1.1. メンバからの報告が部課長に伝わるパスがない問題
4.1.2. RoBそもそも何が必要なんだっけ？
4.1.2.1. co会
4.1.2.2. 取締役会
4.1.2.3. サービスの状況報告会
4.1.2.4. ConnectedDay
4.1.2.5. 執行役員会議
4.1.2.6. QBR
4.1.2.6.1. 株主向けも
4.1.2.7. 部課長会
4.1.2.8. プロジェクトの状況報告会
4.1.2.9. 企画開発会議
4.1.2.10. 人事評価会議
4.1.2.11. co合宿
4.1.2.12. サービス別の月単位の予実報告会
4.1.2.13. プロダクトポートフォリオ単位でのロードマップ検討会
4.1.2.14. 人事委員会
4.1.2.15. 全社集会
4.1.2.15.1. BBQとか
4.1.2.16. DX作戦会議
4.1.2.17. 衛生管理委員会
4.1.2.18. プロダクトポートフォリオ間でのロードマップのキャリブレーション
4.1.2.19. kadへの経営報告会
4.1.2.20. 株主総会
4.1.2.21. 来期予算検討会
4.1.2.22. コンプライアンス委員会
4.1.2.23. 入社時の研修
4.1.2.24. 採用状況の報告会
4.1.2.25. 諸規定の定期的な見直し
4.1.2.26. 離職状況の報告会
4.1.2.27. 従業員の稼働状況の報告会
4.1.2.27.1. 残業
4.1.2.27.2. 労務系
4.1.2.28. BCP委員会
4.1.2.29. newface cafe
4.1.2.30. 個別カジュアルランチ会
4.1.2.30.1. 無理やり普段とは違うスキルチーム(EUCとアプリとか)で組むような小規模プロジェクトでの交流
4.1.2.31. スキルアップの研修の状況報告会
4.1.2.32. 投資評価会
4.1.2.33. 全社系の会議の棚卸し
4.1.2.34. 経営Topと現場との対話会
4.1.2.34.1. 問題起こしまくってる工場にいって、彼らの声をtopが居酒屋とかで聞くみたいな
4.1.2.34.2. 基本的に現場->Topという流れ
4.1.2.35. 試用期間が切れるときの採用継続判定会
4.1.2.36. 案件のクリスタライズ会
4.1.2.37. 案件の優先順位検討会
4.1.2.37.1. 要求の優先順位決め
4.1.2.37.2. 実現可能性を考慮したアサイン
5. 20220412
5.1. メモ
5.1.1. DX作戦会議の立ち位置byDXアーキ局
5.1.1.1. システム開発、KDXの運用負荷が高くなるものは企画開発会議に上程するというルール
5.1.1.2. 扱ってるもの
5.1.1.2.1. デジ戦から来てるものを扱っている
5.1.1.2.2. DXアーキ局が直受けしているのもある
5.1.2. WeeklySyncの報告について
5.1.2.1. 木村さんから
5.1.2.1.1. 問題をいうのは勇気がいるかも
5.1.2.1.2. U字型で伝わるよねぇ
5.1.2.1.3. 人事は採用のファネル分析とかしてるんだから言えばいいのにね
5.1.2.1.4. 成功したことは先頭に書かなくても、なんなら書かなくてもいいんじゃないか？
5.1.2.2. 木嶋さんから
5.1.2.2.1. 問題を後で報告するほうがギルティだよね
5.1.2.2.2. IBMでも最後にHelpRequieredはあったよ
5.1.2.2.3. 日本人は言いづらいのかもね
5.1.2.2.4. soft面(カルチャー)は難しいからhard面(テンプレ)でbindしちゃえばいいんじゃね？
5.1.2.3. 福井さんから
5.1.2.3.1. 予実の状況を知りたい気がする
5.1.2.3.2. みんなトラブル書いてなさすぎるけど、ほんとか？と思ってしまう
5.1.2.4. 中村さんから
5.1.2.4.1. N/Aばっかりだとなにしてるのかなぁと思ってしまう...
5.1.2.5. 今後三神がやろうとしてること
5.1.2.5.1. 事務的Updateを「プロダクトポートフォリオの状況報告」にする
5.1.2.5.2. プロダクトポートフォリオの中に「課題と解決策」を入れる
5.1.2.5.3. (昔からやってること)今日から1週間のアクションプランはなくしている
5.1.2.5.4. 成功したことに関しては
5.1.3. RoBそもそも何が必要なんだっけ？
5.1.3.1. これは話してない
6. 20220405
6.1. メモ
6.1.1. 三神からのEnglabの2名からのFB
6.1.1.1. QBRなくなると悲しい
6.1.1.1.1. QBRは有ったとしても仕事に影響はなかった(つまりなくなっても影響はない)
6.1.1.1.2. 他部署のやっていることをしり、自分の立ち位置を何となく分かるとかそういう帰属意識に貢献していた模様
6.1.2. 企画開発会議, DX作戦会議について
6.1.2.1. そもそも違いは何？
6.1.2.1.1. DX作戦会議は三神はしらない
6.1.2.1.2. 企画開発会議は新規物？
7. 20220329
7.1. メモ
7.1.1. 4/15のQBRの骨子
7.1.1.1. QBRについてby塚本
7.1.1.1.1. CO合宿は経営課題を話す場所
7.1.1.1.2. 会社は事業運営で成り立っているので経営課題で事業に影響あるものはstrategistに相談して手伝ってもらう
7.1.1.2. QBRいらないんじゃ？説
7.1.1.2.1. 触れてもらえないチームはモチベさがる
7.1.1.2.2. 種類が異なる組織間でそもそも連携のひつようが薄い
7.1.1.2.3. そもそも各務さんに対するレビュー会だった
7.1.1.3. QBR必要説
7.1.1.3.1. 合宿で経営課題を話すのでそれをstrategistに共有して腹落ちしてもらう
7.1.1.3.2. 業務を回す上では必要ない
7.1.1.3.3. エンゲージメントを高める
7.1.1.3.4. 今回に関しては安本体制の質疑応答もありかも？
7.1.1.4. 木村さんから
7.1.1.4.1. 各務さんと話してたのはCO間ポテンヒットがあるから拾いたい
8. 20220316
8.1. メモ
8.1.1. weeklysync
8.1.1.1. 三神
8.1.1.1.1. プロダクトポートフォリオ単位で報告
8.1.1.2. 木村
8.1.1.2.1. 更にこれを評価に結び付けられるといいねという意見
8.1.1.2.2. トラブルの報告
8.1.1.3. 普通に集約の場は必要だよね
8.1.1.4. strategistレベルで解決できない問題を言う機会も必要だよね
8.1.2. リソースの空き状況と優先度のバランスでの実施判断についてどこで意思決定するか？
8.1.2.1. 案件の種類
8.1.2.1.1. インフラ開発
8.1.2.1.2. アプリケーション開発
8.1.2.1.3. データ系
8.1.2.1.4. システム導入
8.1.2.1.5. EUC系
8.1.2.2. 種類をまたいでの案件は基本的に存在しない
8.1.2.2.1. つまりこの種類をまたいでの人材の融通は効かない
8.1.3. 結論
8.1.3.1. weeklysync
8.1.3.1.1. 目的
8.1.3.1.2. 方法
8.1.4. 次回
8.1.4.1. 課題(依頼)のクリスタライズおよび実施するしないの判断について
8.1.4.2. 他の議題があればそれも尊重
9. 20220308
9.1. メモ
9.1.1. シミュレーションしよう
9.1.2. 今日話したこと
9.1.2.1. 対象会議
9.1.2.1.1. 池村さんのやつを見て塚本さんが書いてきて当てはまらないのが↓だった。
9.1.2.1.2. 企画開発会議
9.1.2.1.3. WeeklySync
9.1.2.2. 必要なこと
9.1.2.2.1. 1. 企画クリスタライズ 2. 企画開発確認会 1. KDXの依頼の番人 3. 優先順位決め会と担当割り当て 4. ウィーシン（リスク洗い出し）
9.1.2.3. 宿題
9.1.2.3.1. クリスタライズをどうするか？
9.1.2.3.2. 優先順位ぎめをどうするか？
9.1.2.3.3. 雑談
9.1.2.4. 前提
9.1.2.4.1. 基幹は一旦無視(外れ値なので)
10. 20220301
10.1. メモ
10.1.1. 株主に対してどのようなレポートをしたいか？
10.1.1.1. 注力案件毎の人月のバブル表示
10.1.1.2. ネットワークとか基幹がエンジニアを出してくれないと事業側に言われている問題
10.1.1.2.1. 注力案件はもちろんだけど、他のプロジェクトも粒が大きく、
10.1.1.3. サービス別の財務的なレポートができる
10.1.1.4. サービス別の労働時間を可視化できる
10.1.1.5. kadからの無茶な要求に対して防御できる
10.1.1.5.1. 優先順位の組み換えをkadのタスクとして正しく転嫁できる
10.1.1.5.2. kdxとしての思いを示す手段としてサービス毎のロードマップを使う
10.1.1.6. 採用予定の人数および人物像および目的
10.1.1.6.1. これは期首予定を立てるときに特に重要
10.1.1.7. KDXのロードマップの進捗状況
10.1.1.7.1. リスクがあるなら特にそれについて
10.1.1.7.2. 企画開発案件も？
10.1.1.8. CF?
10.1.1.8.1. 子会社だから必要ないかも？
10.1.1.8.2. 足りなくなったら予算外でお金くれてるのが実態
10.1.1.9. 詳細化されたBSがほしいのでは？
10.1.1.9.1. kadが投資した金額に対する資産の状態
10.1.1.10. いわゆる情シスはコストを下げ続けられてしまう
10.1.1.10.1. 中期的にはkadの売上貢献をしめさないといけないのでは
10.1.1.11. できるものに関しては定量で伝えていく
10.1.1.11.1. できないものは定性で
10.1.2. 株主が期待しているレポートは？
10.1.2.1. 不明
10.1.2.2. せめてbynameだと？
10.1.2.2.1. 木村さん的には松原さん(さらには夏野さん、橋場さん、安本さん)
10.1.2.3. ドラフト持ってかないと何も言ってくれなさそう
10.1.2.4. 報告してほしいリスク案件があるかを聞いてみる？
11. 20220222
11.1. メモ
11.1.1. 案件単位でのリクープを見るときにサービスカットだと課題がありそう
11.1.1.1. 複数のサービスから価値提供を受けて成り立つ案件
11.1.1.1.1. IDSへのダッシュボード作成依頼
11.1.2. プロジェクトとプライスポリシー(顧客)毎用の観点も必要かも
11.1.2.1. 例
11.1.2.1.1. 1
11.1.2.1.2. 2
11.1.2.2. 4段目候補
11.1.2.2.1. 社外の一般的な取引
11.1.2.2.2. 社内の取引(配賦用)
11.1.2.2.3. 注力案件
11.1.2.2.4. (できればなくしたい)共通費
11.1.2.2.5. 出た議論
11.1.3. 主要人物のリソースバランスを示すのはどうか
11.1.4. 三神の困りごと
11.1.4.1. ネットワークとか基幹がエンジニアを出してくれないと事業側に言われている問題
11.1.4.1.1. 注力案件はもちろんだけど、他のプロジェクトも粒が大きく、
11.1.5. 注力案件の状況の可視化を第一歩
12. 20220215
12.1. メモ
12.1.1. プロフィットコードと集約の単位の目処は立ちそう
12.1.1.1. やること
12.1.1.1.1. 構成サービス単位でプロフィットコードを整理整頓
12.1.1.1.2. 今の工数割合の手入力は維持
12.1.1.1.3. ↑で出した割合に人毎に勤務時間をかけて実時間として計算
12.1.1.1.4. 配賦運用がグレー
12.1.1.2. 前提
12.1.1.2.1. プロフィットコードの過去との連続性は破壊する
12.1.1.2.2. 1人が160時間(20日x8h)前提の人月になってしまっているが、それを正しい時間と給与に変換する
12.1.2. kadへのレポートについて
12.1.2.1. ポートフォリオ単位での工数のバブルとか
12.1.2.2. サービス別の財務的なレポートができる
12.1.2.3. サービス別の労働時間を可視化できる
12.1.2.4. kadからの無茶な要求に対して防御できる
12.1.2.4.1. 優先順位の組み換えをkadのタスクとして正しく転嫁できる
12.1.2.4.2. kdxとしての思いを示す手段としてサービス毎のロードマップを使う
13. 最終的な報告先は株主であるkad
13.1. ここを目指して報告のミスコミを減らすこととその過程のムリムラムダを減らすことがRoBの命題とする
13.2. 具体的にはプロダクトポートフォリオ単位での管理会計的な報告を行う(プライスポリシーの順応性)
13.2.1. プロフィットコードと集約の単位の連動性の担保も課題
14. 集約の単位
14.1. CO
14.1.1. プロダクトポートフォリオ単位
14.2. Strategist
14.2.1. サービス単位
14.3. SO
14.3.1. 構成サービス単位