道の真ん中をきれいにするプロジェクトマネジメント

2021/1/30開催の「オンラインJBUG広島#7 × Agile Japan」にて登壇した時の資料です。

登壇アーカイブはこちらです。
https://www.facebook.com/watch/?v=3958433044187965

Transcript

1. 中野 ヤスオ（ARI） @yasuoyasuo 道の真ん中をきれいにする プロジェクトマネジメント 2021.1.30 JBUG広島#7 × Agile Japan
2. Copyright ©A.R.I. All Rights reserved. 2 自己紹介 中野 康雄（なかのやすお） 兵庫県宝塚市出身 S49年生 ＡＲアドバンストテクノロジ株式会社(ARI) 取締役執行役員（コンサル/技術部門統括） 《これまでのキャリア》 • SE&ITコンサル＆PM（9年） • 新卒教育＆経営企画（1年） • ECモールサービスPdM/EM（2年） • マネジメントコーチ起業（2年） を経て現職9年目 昨年Qiitaで投稿した記事がおかげ様で2020年LGTM獲得No1に  Backlogworld2021運営  最近少し痩せました（5か月でマイナス12kg）  Twitter/note/Qiita/speakerdeck：@yasuoyasuo • ユーザー企業とパートナー企業 • 現場（ＳＥ、ＰＭ）と経営者 • 営業とデリバリー ITを軸に様々な立場を経験させていただいた
3. Copyright ©A.R.I. All Rights reserved. 3 ＡＲアドバンストテクノロジ（ARI）のご紹介 創業12年目の独立系SIer 社員数427名、国内3拠点 （渋谷、大阪、名古屋） 仮想化、音声、クラウド基盤、 アプリケーションへと領域拡大 近年はAI（自然言語）、 デザインやコンサルティングも拡充 Biz Tech Creative 三位一体提供型の 次世代ファームを目指し奮闘中 ARI で検索！ ※2021年1月現在
4. Copyright ©A.R.I. All Rights reserved. 4 仲間を絶賛募集中 ARI人事 で検索！
5. Copyright ©A.R.I. All Rights reserved. 江戸下町はなぜ 道の真ん中がきれいなのか？ それは お互いが真ん中より向こうまで 掃き合うから 江戸小話
6. Copyright ©A.R.I. All Rights reserved. 6 今日お伝えしたいこと 対象： • チームでシステム開発や制作に関わるすべての方々  自サ/SI、規模の大小、使用方法論なども問わない 結論： • システム開発の難しさはステークホルダー間での合意形成にある • うまくいっていないPJは「チームのOS」が機能していない場合 が多い • 「チームのOS」を整えるのがマネージャーの役割 • メンバーを含む各ステークホルダーも、人任せにせず、 自ら道の真ん中を超えていこう
7. Copyright ©A.R.I. All Rights reserved. 7 アジェンダ 1. システム開発における悲劇は「道の真ん中が汚れること」 2. なぜ道の真ん中が汚れてしまうのか？ 3. 道の真ん中をきれいにするにはどうすればよいのか？ 4. 最後に
8. Copyright ©A.R.I. All Rights reserved. 8 “相手に全神経を集中させ、じっくり耳を傾け、 相手が言いそうなことを先まわりして考えず、 質問を通して問題の核心に迫れ” （通称“1兆ドルコーチ”ことビル・キャンベル） 1. システム開発における悲劇は 「道の真ん中が汚れること」
9. Copyright ©A.R.I. All Rights reserved. 9 そもそもシステム開発とはどういう作業なのか？ シ ス テ ム 開 発 の 時 間 軸 要件 人間の 世界 システムの 世界 設計 実装（ソフトウェア/基盤） 要求 要望 仕様 要件 1.要望要求から要件に選別する 2.要件に対する仕様を記述する 3.仕様を満たすように設計する 4.設計通りに実装する 5.仕様＆要件の実現を確認する 関係者内 整理 QCD制約踏まえた 要求精査
10. Copyright ©A.R.I. All Rights reserved. 10 システム開発は難易度の高い要素を複数併せ持つプロセス シ ス テ ム 開 発 の 時 間 軸 要件 人間の 世界 システムの 世界 氏名を表示できたらいいな その他多くの要望 各ページに氏名を表示できること 各ページのヘッダ部分に 「◦◦[半角スペース]••」と表示する。 ◦◦は姓、••は名を表す。 関係者内 整理 QCD制約踏まえた 要求精査 各ページに氏名を表示したい コミュニケーションが必要でありながら 対象が万人にとって取扱いにくい 設計 実装（コード） 要求 要望 仕様 要件 • あったらいいなだよね？目的は？本当に必要？ • 個人の意見？みんなの意見？ • 要求の優先順位は？ • 予算や納期踏まえて今回どれやる？ • ページのどこ？ • どんな風に表示するの？ 参考： https://qiita.com/digdagdag/items/2808205d89344ab8a3a1 イメージ 言語化難しい 非エンジニア は見えない あいまい 調整が必要
11. Copyright ©A.R.I. All Rights reserved. 11 プロジェクトのトラブルの原因 図引用元： » システム開発が遅れる真因、プロジェクト1700件を斬る | 日経クロステック（xTECH） https://xtech.nikkei.com/atcl/nxt/column/18/00177/022100002/ 実際にトラブルの原因は コミュニケーションや 組織内/間の合意形成に 起因するものが多い
12. Copyright ©A.R.I. All Rights reserved. 12 コミュニケーションや合意形成の問題の例  当初合意した内容から仕様がふくらむ  「どうせならついでにこれもやって」  運用担当や現場を巻き込めていない  「今回はトップダウンで改革だ」  機能同士、サブシステム同士が繋がらない  「うちは悪くない」「だから言いましたよね？」 ほんの一例：
13. Copyright ©A.R.I. All Rights reserved. 13 さらに難易度を高める要素が関係者の多様さ 最終的に目指しているものは同 じだが、皆役割が違う 役割が違うから、価値観も 優先順位も違って当たり前 インフラ エンジニア アプリ エンジニア デザイナー システム 担当者 経営者 業務部門 担当者 情シス部門 担当者 システムの ゴール 業務成果 費用対効果 機能・要件 UIデザイン アプリ ケーション インフラ 基盤 システム 利便性 社内ITの 最適化/運用
14. Copyright ©A.R.I. All Rights reserved. 14 関係者が多い分、コミュニケーションも複雑に 引用：独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC）. SEC BOOKS 共通フレーム2013（電子版） 会社をまたいで 調整が必要なことも多い クラウ ドベン ダ テスト ベンダ 脆弱性 診断 業者
15. Copyright ©A.R.I. All Rights reserved. 15 みんなが自分のことだけ考えたら それぞれ自分の範囲だけを考え 始めたらうまくいくわけがない インフラ エンジニア アプリ エンジニア デザイナー システム 担当者 経営者 業務部門 担当者 情シス部門 担当者 業務成果 費用対効果 機能・要件 UIデザイン アプリ ケーション インフラ 基盤 システム 利便性 社内ITの 最適化/運用 分断
16. Copyright ©A.R.I. All Rights reserved. 16 結局何が問題なのか？ 個人の道徳心/親切心や ホスピタリティの問題ではない （してはいけない）
17. Copyright ©A.R.I. All Rights reserved. 17 結局何が問題なのか？ （あらゆるものごとに対する期待の） 合意形成効率が悪い状態が続く • そもそも期待を合意しようとしていない • 合意しようとしてるが、時間がかかる • 合意レベルが不十分、または誤って認識されている 各自が他と関わることが面倒になり 関心の輪を小さくしていく
18. Copyright ©A.R.I. All Rights reserved. 18 結局何が問題なのか？ 自分 関心の輪 (ほぼ自分の都合しか考えていない状態） 関心の輪 （周りと自分が見えている状態） PM・営業・管理部門 他社パートナーさんなど お客様
19. Copyright ©A.R.I. All Rights reserved. 19 2. なぜ道の真ん中が汚れてしまうのか？ “マネジャーは肩書きがつくる。リーダーは人がつくる。” （ビル・キャンベル）
20. Copyright ©A.R.I. All Rights reserved. 20 なぜ道の真ん中が汚れるのか？ 見えないものへの本質的な不安 お互いの理解不足からくる不信 ビルドトラップを生みやすい業界商流構造 PMへの押し付け、孤立
21. Copyright ©A.R.I. All Rights reserved. 21 意外とエンジニアに知られていない・わすれがちなこと • 「情シス」の立ち位置や立場の強さは会社それぞれ • 「情シス」は自社の業務とシステムのことを何でも知っているわけではない • 「情シス」のメンバーはみんなエンジニアになりたかったわけではない • 「情シス」のメンバーはみんなITの専門家というわけではない • 顧客担当者はシステム化の目的を１００％理解しているわけではない • PJにアサインされている担当者の時間はいつでも抑えられるわけではない • J-SOXやISO、各種ポリシーなど無条件に守るべき制約が結構ある • お客様も当然組織の一員。保身もするし評価も気にするのは当たり前 その人にとっての「当たり前」は会社や職業が違えば自ずと違ってくる
22. Copyright ©A.R.I. All Rights reserved. 22 人間が持つ見えないものへの本質的な恐れや不安 出典：広木大地 『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』（技術評論社、2018年） 原典：P. Kruchten, R. L. Nord and I. Ozkaya, "Technical Debt: From Metaphor to Theory and Practice," in IEEE Software, vol. 29, no. 6, pp. 18-21, Nov.-Dec. 2012, doi: 10.1109/MS.2012.167. 新機能 アーキテクチャ バグ 技術的負債 プ ラ ス の 価 値 マ イ ナ ス の 価 値 見える 見えない マスコミの煽りたてもあり 非エンジニアの方にとって 不安にならざるを得ない
23. Copyright ©A.R.I. All Rights reserved. 23 ビルドトラップとは？ 書籍「プロダクトマネジメント」で メリッサ・ペリ氏が提唱した言葉 機能をリリースすることや、 自称ナイスアイデアを作ることに集中し その機能が生み出す アウトカム（成果） について考えていない状態 ≒アウトカムではなく、アウトプットに 意識が集中してしまっている状態
24. Copyright ©A.R.I. All Rights reserved. 24 リソース、アウトプット、アウトカムの関係 努力 かけた時間 やった問題集 作ったノート 模試の成績 志望校の合格 リソース アウトプット How What アウトカム Why アウトカムを無視してこの範囲に注力してしまう ＝ビルドトラップ アウトプットまでが遠い/ アウトカムが見えにくい場合 ビルドトラップにハマりやすい 例：受験生
25. Copyright ©A.R.I. All Rights reserved. 25 日本における多くの商用システム開発の実行体制 https://www.atmarkit.co.jp/ait/articles/1908/14/news006.html 内製化が叫ばれるが 多くの開発現場の現実
26. Copyright ©A.R.I. All Rights reserved. 26 システム開発におけるビルドトラップ 努力 かけた時間 受験生 やった問題集 作ったノート 模試の成績 志望校の合格 システム開発 技術 稼働時間 システム 作業報告書 事業成果 顧客満足 ユーザーの課題解決 リソース アウトプット How What アウトカム Why アウトプット（What）どころか、リソース（How）自体が目的になるケースも
27. Copyright ©A.R.I. All Rights reserved. うまくいってないのは 私の責任・・・ 27 PMへの押し付け、孤立 PM 顧客 メンバー 自社 「顧客や経営の言いなり！」 「人も期間も足りない！」 「当初予算と体制でやれ！」 「支援ほしけりゃ詳しく報告しろ！」 「遅延の対策は？」 「会社やメンバーを動かすのがPMの仕事！」 うまくいっていないSI-PJによくある構図 人の良い優しい人ほどスケープゴートにされ 責任を背負い込む結果に。 自分で何とかしようとこだわり過ぎることで 結果更に関係者同士の溝が広がることも。
28. Copyright ©A.R.I. All Rights reserved. 28 3．道の真ん中をきれいにするには どうすればよいのか？ “人を助けよ 時間や人脈などの資源を、人のために惜しみなく使え。” （ビル・キャンベル）
29. Copyright ©A.R.I. All Rights reserved. 29 プロジェクトをコンピューターシステムに例えると 各参画メンバーやステークホルダの ソフト/ハードスキルや経験値 合意形成の生産性を高める チームとしての行動指針・原理原則 ウォーターホール、Scrumなど 各種プロジェクト進行アプローチや具体的方法論 成果物 HW OS F/W Code 問題があるPJは F/WやHWの問題が 指摘されがちだが 真因はこのOSがバグっている ことが多い 各ステークホルダの性能を 最大限に引き出すOSへ アップデートすべき 内容 レイヤー
30. Copyright ©A.R.I. All Rights reserved. 30 道の真ん中をきれいにする「チームのOS」とは？  「異文化」を知り受け入れる  「意思決定ルール」を明確にする  「見えないもの」を可視化する  「与党」を増やす  「変更」に備える  「のりしろ」を設計する  「約束」を尊重する  「問題」を前向きに解決する  「最悪」に備える  「目標」を明確化する
31. Copyright ©A.R.I. All Rights reserved. 31 「異文化」を知り受け入れる • 自発的に相手を知る努力をする • 相手の組織や文化を知る • 業界とそのお約束ごとを知る • 勝手に期待し過ぎない • 立場や役職に勝手に期待を抱かない • 明確にリクエストする • 自分と違う価値観を拒否しない • 何が違うかを可視化するのも手（Appendix参照） まず自分からはじめよう 自分を知ろうと努力してくれる人に、人は心を開きやすい
32. Copyright ©A.R.I. All Rights reserved. 32 例：システムビジネスのお作法を抑えておく
33. Copyright ©A.R.I. All Rights reserved. 33 「意思決定ルール」を明確にする • 意思決定ルールとは？ • まずそのチームの意思決定者は誰かを決めて合意する • メンバーは、自身が思う最適なアイデアを全力で提案する • 各アイデアの人気投票をしてもよいが、最後は意思決定者が決定する • NGルール • 一度意思決定したら、メンバーは結果を正しくする方向に全力を尽くす • もしうまくいかなければ、また別の意思決定をしてもよい • たとえば、昼飯を選ぶ際、「カレー屋に行ってから、やっぱりラーメン食 べたかった」というのはなし チームの意思決定のルールが明確になっていると 自分の管轄外のことでも積極的に提案しやすい
34. Copyright ©A.R.I. All Rights reserved. 34 「見えないもの」を可視化する • 議事録、議事メモは必ずとる • 言った「つもり」、合意した「つもり」、理解してもらっている「つもり」は厳禁 • 本当の効果は安心感（いざという時に立ち戻れる場所がある） • チケット管理システムを使う • 迷ったらBacklogがおすすめ • チャットやチケットには既読段階でリアクションする • 他者への関心を表現する • 前向きな雰囲気を意図的に作る 安心と関心を見える化しよう
35. Copyright ©A.R.I. All Rights reserved. 35 例：議事録・議事メモの書き方のおすすめ教材 （無料で読めます）
36. Copyright ©A.R.I. All Rights reserved. 36 「与党」を増やす • 所有感の原則を知る • 人は、所有感のない事柄に対して、問題が起こった時に自発的に助けようとしない（自分の子供と他人の子供） • カギとなる会議には所有感を持たせたい面子を必ずアサインする • キックオフの人選にこだわる • 現場部門からアンバサダーを選定してもらう • 業務のヒアリングにエンジニアメンバーも同席してもらう（嫌がるけど） • 会社や契約形態という垣根をとりはらう • 正社員とパートナーさんを区分けするのは、道徳倫理ではなく経済合理性の上で得策ではない • コンプライアンスには逆らえないが、性悪説にならざるを得ないとしたら、パートナー選定時点で間違っている • コミュニケーションの黄金律は「自分がそうしてもらいたいように振る舞う」 • コミュニケーションの回数と頻度を増やす • ステアリングコミティの有効活用 • プロジェクト状況レポートの定期発信 当事者意識は勝手には生まれない 当事者意識を意図的に生むような仕掛けを考えよう
37. Copyright ©A.R.I. All Rights reserved. 37 「変更」に備える • 要件とは絶対的ではなく相対的なもの（ある時点のスナップショット） • 要件定義とは、要件という「正解」を顧客から聞き出す作業だと思ってい るとしたら大きな誤解。誰かが正解を持っているわけでもない。 • 色々な変更を記録管理する仕組みを用意する • 一番大切なのはスコープの変更の管理 • ベースラインの確定と変更要求を審議するプロセスの明確化 • 投資稟議の際は、追加修正も含めて予算を考えておく • 要求の前提となる仮説の変化も記録しておく。 変更管理は変更を抑制するためではなく 安心して変更できるようにするための仕組みであることを知ろう
38. Copyright ©A.R.I. All Rights reserved. 38 例：変更管理を知ろう こちらのnoteを 是非ご覧いただきたい
39. Copyright ©A.R.I. All Rights reserved. 39 「のりしろ」を設計する • 体制の「のりしろ」 • マネジメントが楽をするだけの組織のシンプル化は必ず部分最適を生む • 「横断チーム」や「兼任」をうまく活用する • 工程の「のりしろ」 • 工程と工程の間に計画準備フェーズを設ける （短期間でも良い） • コミュニケーションの「のりしろ」 • 情報提供は過剰気味に行い、発信側の判断で絞り過ぎない 「余裕」は「余剰」ではなく、チームを円滑に回し品質を高めるための 「必要コスト」だと捉えよう 計 画 準 備 B工程 A工程
40. Copyright ©A.R.I. All Rights reserved. 40 例：マトリックス組織の有用性 こちらのnoteも 是非ご覧いただきたい
41. Copyright ©A.R.I. All Rights reserved. 41 「約束」を尊重する • 目標とは「約束」である • 大きな「約束」を守るために、まず小さな「約束を」守る • 小さな約束を守れなければ大きな約束も守れない • 課題、ToDo、ルール、会議の開始終了時間 • 約束の前では上司も部下もない • 約束の遵守について、役職や立場を超えて率直にフィードバック・コミュ ニケーションしてもよいことを合意する • 誰にでも忖度せずリクエストできる権利と断る権利を合わせて認める コミットメントの文化を作ろう
42. Copyright ©A.R.I. All Rights reserved. 42 「問題」を前向きに解決する • 問題＝目標ー現実 • 問題を忌み嫌わない（問題と仲良くなる） • 問題は目標達成にむけて前進中であることの証 • チームに問題解決の仕組み（問題を受け付け解決する）を導入する • 問題を整理し解決するためだけの会議を定期的に開催する • 必要最小限の人数で招集し、意思決定者を明確化しておく • 解決策を議論して対策を決め、タスク化して約束を尊重する • 正しいレビューの文化を定着させる 安心して問題を投げこめ、日常的に解決される仕組みを作ろう
43. Copyright ©A.R.I. All Rights reserved. 43 例：レビューの共通土台としておすすめの教材 こちらのQiitaも 是非ご覧いただきたい
44. Copyright ©A.R.I. All Rights reserved. 44 「最悪」に備える • 平たく言えば「リスク管理」 • しっかり機能せるのは意外に大変 • 重く運用せず、リスク管理を日常化する • 多くのチームではリスク管理プロセスはオーバーヘッドになりがち。 • 「今チームに起こったら一番困ることは何か？」という問いを全員が日常 的に持つようにする • 自分で解決できるならそれでOK。解決できないことは上司に相談する。 • 日報・週報にコーナーを設ける リスク管理は仰々しくせず、日常に織り込もう
45. Copyright ©A.R.I. All Rights reserved. 45 「目標」を明確化する • 全ステークホルダーにとってぶれない目標を言語化する • 日付と達成したかどうかがわかる事柄、ワクワクするフレーズも • 例「2021年8月31日までにECサイトをオープンして月商1000万、メン バーが各自の知り合いから使いやすかったよというコメントを聞けるよう にする！」 • 所有感を大切にする • 最後は意思決定者が決めるが、その目標を生み出す場にいたか 意見をだせたかどうかが、所有感の醸成に非常に重要 全員が共有できる「北極星」を定めよう
46. Copyright ©A.R.I. All Rights reserved. 46 例：オンラインでインセプションデッキを作る byCacoo 最終稿を無理に決めなくてよい みんなが自分の意見を言える場 みんなの考えを知ることができる場
47. Copyright ©A.R.I. All Rights reserved. 47 第三者の基準を参考にするのも良し 日本CTO協会のDxCriteriaの「チーム」の項目は チームのOSを考える上で大変参考になるので 一読をおすすめしたい ご参考紹介（僭越ながら自身の記事です） https://qiita.com/yasuoyasuo/items/94e66f2151a31c2aec11
48. Copyright ©A.R.I. All Rights reserved. 48 4．最後に “あらゆるマネジャーの最優先課題は、 部下のしあわせと成功だ” （ビル・キャンベル）
49. Copyright ©A.R.I. All Rights reserved. 49 システム開発に関わる全ステークホルダーの理想像 “我々は、技術的な経験もさることながら、 チームとして活動できる能力、そして誰 とでも仲良くなれる資質、また、必要な 時は指導力を発揮し、場合によっては誰 かに従う能力のある人を探しています。“ 宇宙飛行という究極のPJでは 全員が日常的に リーダーシップとフォロワーシップを 同時に発揮することが求められる
50. Copyright ©A.R.I. All Rights reserved. 50 ひとりひとりの勝負所 チームの成功のために 自分が正しいことをしないのを 人（上司や部下）や環境のせいにしない
51. Copyright ©A.R.I. All Rights reserved. 51 私が考えるマネージャの理想像 あらゆるマネジャーの最優先事項は 部下の幸せと成功である ビル・キャンベルはアメフトのコーチ出身であ りながら、有能なプロ経営者であり、シリコン バレーの数多くのリーダー達にとってのコーチ であり、メンター的存在。 生み出した価値は1兆ドル以上 信頼関係が築かれたチームを作る
52. Copyright ©A.R.I. All Rights reserved. 52 マネージャーの勝負所 当事者意識の欠如を 個人の道徳心/親切心や ホスピタリティの問題にしたら マネージャーとしては負け
53. Copyright ©A.R.I. All Rights reserved. 53 マネージャーの役割はチームのOSをインストールすること みんなが安心して 「越境」できる状態を 実現する インフラ エンジニア アプリ エンジニア デザイナー システム 担当者 経営者 業務部門 担当者 情シス部門 担当者 業務成果 費用対効果 機能・要件 UIデザイン アプリ ケーション インフラ 基盤 システム 利便性 社内ITの 最適化/運用 チームのOS inside チームのOSを 整える
54. Copyright ©A.R.I. All Rights reserved. 54 個人的な野望 幸せなエンジニアを 一人でも多く増やしたい 道の真ん中をきれにするための チームのOSをもっと洗練させ 広げていきたい
55. Copyright ©A.R.I. All Rights reserved. 55 まとめ  システム開発の難しさはステークホルダー間での合意形成 にある  うまくいっていないPJは「チームのOS」が機能していない 場合が多い  「チームのOS」を整えるのがマネージャーの役割  メンバーを含む各ステークホルダーも、人任せにせず、 自ら道の真ん中を超えていこう
56. Copyright ©A.R.I. All Rights reserved. 中野 ヤスオ（ARI） @yasuoyasuo 道の真ん中をきれいにする プロジェクトマネジメント 2021.1.30 JBUG広島#7 × Agile Japan ＜完＞ ご感想などTwitterにてコメントいただけると幸いです
57. Copyright ©A.R.I. All Rights reserved. 57 社風や個人の価値観の可視化 https://plus.alc.co.jp/2018/01/meyer/ ビジネスコミュニ ケーションに 文化の違いがどう影 響するかを分析して 可視化したもの カルチャーマップ キックオフで 各自自分で点数付け て並べたら 意外に盛り上がった