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

by 中野康雄（ARI）

Slide 1

Slide 1 text

中野ヤスオ（ARI） @yasuoyasuo 道の真ん中をきれいにするプロジェクトマネジメント 2021.1.30 JBUG広島#7 × Agile Japan

Slide 2

Slide 2 text

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を軸に様々な立場を経験させていただいた

Slide 3

Slide 3 text

Copyright ©A.R.I. All Rights reserved. 3 ＡＲアドバンストテクノロジ（ARI）のご紹介創業12年目の独立系SIer 社員数427名、国内3拠点（渋谷、大阪、名古屋）仮想化、音声、クラウド基盤、アプリケーションへと領域拡大近年はAI（自然言語）、デザインやコンサルティングも拡充 Biz Tech Creative 三位一体提供型の次世代ファームを目指し奮闘中 ARI で検索！ ※2021年1月現在

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright ©A.R.I. All Rights reserved. 6 今日お伝えしたいこと対象： • チームでシステム開発や制作に関わるすべての方々  自サ/SI、規模の大小、使用方法論なども問わない結論： • システム開発の難しさはステークホルダー間での合意形成にある • うまくいっていないPJは「チームのOS」が機能していない場合が多い • 「チームのOS」を整えるのがマネージャーの役割 • メンバーを含む各ステークホルダーも、人任せにせず、自ら道の真ん中を超えていこう

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright ©A.R.I. All Rights reserved. 9 そもそもシステム開発とはどういう作業なのか？システム開発の時間軸要件人間の世界システムの世界設計実装（ソフトウェア/基盤）要求要望仕様要件 1.要望要求から要件に選別する 2.要件に対する仕様を記述する 3.仕様を満たすように設計する 4.設計通りに実装する 5.仕様＆要件の実現を確認する関係者内整理 QCD制約踏まえた要求精査

Slide 10

Slide 10 text

Copyright ©A.R.I. All Rights reserved. 10 システム開発は難易度の高い要素を複数併せ持つプロセスシステム開発の時間軸要件人間の世界システムの世界氏名を表示できたらいいなその他多くの要望各ページに氏名を表示できること各ページのヘッダ部分に「○○[半角スペース]●●」と表示する。 ○○は姓、●●は名を表す。関係者内整理 QCD制約踏まえた要求精査各ページに氏名を表示したいコミュニケーションが必要でありながら対象が万人にとって取扱いにくい設計実装（コード）要求要望仕様要件 • あったらいいなだよね？目的は？本当に必要？ • 個人の意見？みんなの意見？ • 要求の優先順位は？ • 予算や納期踏まえて今回どれやる？ • ページのどこ？ • どんな風に表示するの？参考： https://qiita.com/digdagdag/items/2808205d89344ab8a3a1 イメージ言語化難しい非エンジニアは見えないあいまい調整が必要

Slide 11

Slide 11 text

Copyright ©A.R.I. All Rights reserved. 11 プロジェクトのトラブルの原因図引用元： » システム開発が遅れる真因、プロジェクト1700件を斬る | 日経クロステック（xTECH） https://xtech.nikkei.com/atcl/nxt/column/18/00177/022100002/ 実際にトラブルの原因はコミュニケーションや組織内/間の合意形成に起因するものが多い

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright ©A.R.I. All Rights reserved. 13 さらに難易度を高める要素が関係者の多様さ最終的に目指しているものは同じだが、皆役割が違う役割が違うから、価値観も優先順位も違って当たり前インフラエンジニアアプリエンジニアデザイナーシステム担当者経営者業務部門担当者情シス部門担当者システムのゴール業務成果費用対効果機能・要件 UIデザインアプリケーションインフラ基盤システム利便性社内ITの最適化/運用

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright ©A.R.I. All Rights reserved. 21 意外とエンジニアに知られていない・わすれがちなこと • 「情シス」の立ち位置や立場の強さは会社それぞれ • 「情シス」は自社の業務とシステムのことを何でも知っているわけではない • 「情シス」のメンバーはみんなエンジニアになりたかったわけではない • 「情シス」のメンバーはみんなITの専門家というわけではない • 顧客担当者はシステム化の目的を１００％理解しているわけではない • PJにアサインされている担当者の時間はいつでも抑えられるわけではない • J-SOXやISO、各種ポリシーなど無条件に守るべき制約が結構ある • お客様も当然組織の一員。保身もするし評価も気にするのは当たり前その人にとっての「当たり前」は会社や職業が違えば自ずと違ってくる

Slide 22

Slide 22 text

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. 新機能アーキテクチャバグ技術的負債プラスの価値マイナスの価値見える見えないマスコミの煽りたてもあり非エンジニアの方にとって不安にならざるを得ない

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright ©A.R.I. All Rights reserved. うまくいってないのは私の責任・・・ 27 PMへの押し付け、孤立 PM 顧客メンバー自社「顧客や経営の言いなり！」「人も期間も足りない！」「当初予算と体制でやれ！」「支援ほしけりゃ詳しく報告しろ！」「遅延の対策は？」「会社やメンバーを動かすのがPMの仕事！」うまくいっていないSI-PJによくある構図人の良い優しい人ほどスケープゴートにされ責任を背負い込む結果に。自分で何とかしようとこだわり過ぎることで結果更に関係者同士の溝が広がることも。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright ©A.R.I. All Rights reserved. 29 プロジェクトをコンピューターシステムに例えると各参画メンバーやステークホルダのソフト/ハードスキルや経験値合意形成の生産性を高めるチームとしての行動指針・原理原則ウォーターホール、Scrumなど各種プロジェクト進行アプローチや具体的方法論成果物 HW OS F/W Code 問題があるPJは F/WやHWの問題が指摘されがちだが真因はこのOSがバグっていることが多い各ステークホルダの性能を最大限に引き出すOSへアップデートすべき内容レイヤー

Slide 30

Slide 30 text

Copyright ©A.R.I. All Rights reserved. 30 道の真ん中をきれいにする「チームのOS」とは？  「異文化」を知り受け入れる  「意思決定ルール」を明確にする  「見えないもの」を可視化する  「与党」を増やす  「変更」に備える  「のりしろ」を設計する  「約束」を尊重する  「問題」を前向きに解決する  「最悪」に備える  「目標」を明確化する

Slide 31

Slide 31 text

Copyright ©A.R.I. All Rights reserved. 31 「異文化」を知り受け入れる • 自発的に相手を知る努力をする • 相手の組織や文化を知る • 業界とそのお約束ごとを知る • 勝手に期待し過ぎない • 立場や役職に勝手に期待を抱かない • 明確にリクエストする • 自分と違う価値観を拒否しない • 何が違うかを可視化するのも手（Appendix参照）まず自分からはじめよう自分を知ろうと努力してくれる人に、人は心を開きやすい

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Copyright ©A.R.I. All Rights reserved. 33 「意思決定ルール」を明確にする • 意思決定ルールとは？ • まずそのチームの意思決定者は誰かを決めて合意する • メンバーは、自身が思う最適なアイデアを全力で提案する • 各アイデアの人気投票をしてもよいが、最後は意思決定者が決定する • NGルール • 一度意思決定したら、メンバーは結果を正しくする方向に全力を尽くす • もしうまくいかなければ、また別の意思決定をしてもよい • たとえば、昼飯を選ぶ際、「カレー屋に行ってから、やっぱりラーメン食べたかった」というのはなしチームの意思決定のルールが明確になっていると自分の管轄外のことでも積極的に提案しやすい

Slide 34

Slide 34 text

Copyright ©A.R.I. All Rights reserved. 34 「見えないもの」を可視化する • 議事録、議事メモは必ずとる • 言った「つもり」、合意した「つもり」、理解してもらっている「つもり」は厳禁 • 本当の効果は安心感（いざという時に立ち戻れる場所がある） • チケット管理システムを使う • 迷ったらBacklogがおすすめ • チャットやチケットには既読段階でリアクションする • 他者への関心を表現する • 前向きな雰囲気を意図的に作る安心と関心を見える化しよう

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Copyright ©A.R.I. All Rights reserved. 36 「与党」を増やす • 所有感の原則を知る • 人は、所有感のない事柄に対して、問題が起こった時に自発的に助けようとしない（自分の子供と他人の子供） • カギとなる会議には所有感を持たせたい面子を必ずアサインする • キックオフの人選にこだわる • 現場部門からアンバサダーを選定してもらう • 業務のヒアリングにエンジニアメンバーも同席してもらう（嫌がるけど） • 会社や契約形態という垣根をとりはらう • 正社員とパートナーさんを区分けするのは、道徳倫理ではなく経済合理性の上で得策ではない • コンプライアンスには逆らえないが、性悪説にならざるを得ないとしたら、パートナー選定時点で間違っている • コミュニケーションの黄金律は「自分がそうしてもらいたいように振る舞う」 • コミュニケーションの回数と頻度を増やす • ステアリングコミティの有効活用 • プロジェクト状況レポートの定期発信当事者意識は勝手には生まれない当事者意識を意図的に生むような仕掛けを考えよう

Slide 37

Slide 37 text

Copyright ©A.R.I. All Rights reserved. 37 「変更」に備える • 要件とは絶対的ではなく相対的なもの（ある時点のスナップショット） • 要件定義とは、要件という「正解」を顧客から聞き出す作業だと思っているとしたら大きな誤解。誰かが正解を持っているわけでもない。 • 色々な変更を記録管理する仕組みを用意する • 一番大切なのはスコープの変更の管理 • ベースラインの確定と変更要求を審議するプロセスの明確化 • 投資稟議の際は、追加修正も含めて予算を考えておく • 要求の前提となる仮説の変化も記録しておく。変更管理は変更を抑制するためではなく安心して変更できるようにするための仕組みであることを知ろう

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Copyright ©A.R.I. All Rights reserved. 39 「のりしろ」を設計する • 体制の「のりしろ」 • マネジメントが楽をするだけの組織のシンプル化は必ず部分最適を生む • 「横断チーム」や「兼任」をうまく活用する • 工程の「のりしろ」 • 工程と工程の間に計画準備フェーズを設ける（短期間でも良い） • コミュニケーションの「のりしろ」 • 情報提供は過剰気味に行い、発信側の判断で絞り過ぎない「余裕」は「余剰」ではなく、チームを円滑に回し品質を高めるための「必要コスト」だと捉えよう計画準備 B工程 A工程

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright ©A.R.I. All Rights reserved. 41 「約束」を尊重する • 目標とは「約束」である • 大きな「約束」を守るために、まず小さな「約束を」守る • 小さな約束を守れなければ大きな約束も守れない • 課題、ToDo、ルール、会議の開始終了時間 • 約束の前では上司も部下もない • 約束の遵守について、役職や立場を超えて率直にフィードバック・コミュニケーションしてもよいことを合意する • 誰にでも忖度せずリクエストできる権利と断る権利を合わせて認めるコミットメントの文化を作ろう

Slide 42

Slide 42 text

Copyright ©A.R.I. All Rights reserved. 42 「問題」を前向きに解決する • 問題＝目標ー現実 • 問題を忌み嫌わない（問題と仲良くなる） • 問題は目標達成にむけて前進中であることの証 • チームに問題解決の仕組み（問題を受け付け解決する）を導入する • 問題を整理し解決するためだけの会議を定期的に開催する • 必要最小限の人数で招集し、意思決定者を明確化しておく • 解決策を議論して対策を決め、タスク化して約束を尊重する • 正しいレビューの文化を定着させる安心して問題を投げこめ、日常的に解決される仕組みを作ろう

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Copyright ©A.R.I. All Rights reserved. 44 「最悪」に備える • 平たく言えば「リスク管理」 • しっかり機能せるのは意外に大変 • 重く運用せず、リスク管理を日常化する • 多くのチームではリスク管理プロセスはオーバーヘッドになりがち。 • 「今チームに起こったら一番困ることは何か？」という問いを全員が日常的に持つようにする • 自分で解決できるならそれでOK。解決できないことは上司に相談する。 • 日報・週報にコーナーを設けるリスク管理は仰々しくせず、日常に織り込もう

Slide 45

Slide 45 text

Copyright ©A.R.I. All Rights reserved. 45 「目標」を明確化する • 全ステークホルダーにとってぶれない目標を言語化する • 日付と達成したかどうかがわかる事柄、ワクワクするフレーズも • 例「2021年8月31日までにECサイトをオープンして月商1000万、メンバーが各自の知り合いから使いやすかったよというコメントを聞けるようにする！」 • 所有感を大切にする • 最後は意思決定者が決めるが、その目標を生み出す場にいたか意見をだせたかどうかが、所有感の醸成に非常に重要全員が共有できる「北極星」を定めよう

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Copyright ©A.R.I. All Rights reserved. 49 システム開発に関わる全ステークホルダーの理想像 “我々は、技術的な経験もさることながら、チームとして活動できる能力、そして誰とでも仲良くなれる資質、また、必要な時は指導力を発揮し、場合によっては誰かに従う能力のある人を探しています。“ 宇宙飛行という究極のPJでは全員が日常的にリーダーシップとフォロワーシップを同時に発揮することが求められる

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Copyright ©A.R.I. All Rights reserved. 53 マネージャーの役割はチームのOSをインストールすることみんなが安心して「越境」できる状態を実現するインフラエンジニアアプリエンジニアデザイナーシステム担当者経営者業務部門担当者情シス部門担当者業務成果費用対効果機能・要件 UIデザインアプリケーションインフラ基盤システム利便性社内ITの最適化/運用チームのOS inside チームのOSを整える