プロジェクトマネジメントの勘所〜補講編〜

本記事は [DMMグループ Advent Calendar 2020](https://qiita.com/advent-calendar/2020/dmm) の21日目です。

#自己紹介
[わたし](https://inside.dmm.com/entry/2020/08/06/yondemasu07)は、合同会社DMM.comで電子書籍事業と同人事業のエンジニアリングマネジメントに携わっています。
エンジニアリングマネージャー(EM)の担当領域は、所属会社やその時々の状況や個人のスキルによって違いがあると思います。昨年時点の自分自身は[去年のアドベントカレンダー記事](https://qiita.com/umerin/items/63bb45ab027c5de4012c)の通りで、現在においても主要な領域はピープルマネジメントなのですが、間接的にでもプロジェクトマネジメントに関わる機会は常日頃から存在している状況です。

#はじめに
本記事では、先月11/26に開催されたDevLead by DMM Group#1で登壇発表した内容を、要点のみ文字で読みたい方に向けて書き起こし、パネルディスカッションを含めお伝えし切れなかった点を補足するものとなっております。
もしお時間に余裕があり、DMMの組織の現状についてご興味を持って頂けている方は[YouTubeのアーカイブ](https://www.youtube.com/watch?v=muVDu1jNwBQ&t=4389s)を先に視聴頂けるとより理解が深まると思いますので、ご覧ください。
また、以降の本文は、発表資料を傍に見ながら読み進めて頂けますとイメージしやすいと思いますので、[DevLead by DMM Group #1を開催しました！〜プロダクト開発におけるリーダーシップの形〜](https://inside.dmm.com/entry/2020/12/15/devlead-1)の2番目「プロジェクトマネジメントの勘所- DevOpsとアジャイル：電子書籍/同人事業の開発運用 -」の11枚目のスライド（結論）からご参照ください。

#発表内容
## プロジェクトマネジメントの勘所：結論
全体像・繋がりを意識しながら、その時々の状況に対して、ペースが間に合っているか、当初考えていた期間・方法にムリが無いかを、関わる全員が考え続ける。

## プロジェクトマネジメントの4つの勘所
### 1.目的とゴールの設定
・必ず明確にする
・常に関わる全員が意識する
・「◯◯を完成させる」はNG
・手段に言及しすぎない
・自らが起案する場合、意思決定者と合意する

### 2.クリティカルパス
・概念を理解し、ボトルネックとなる部分の見極めに使う
・並行して進められる数を把握する
・その中で最長の経路がどういう軌跡を辿るのかを考える
　⇒このためにタスク間の関連性を明確化し紐づける
・待ちが発生する可能性を把握する
・全ての細かいタスクを洗い出すのは無理なので、必ず最長となる経路は変動することを認識し備える
・不明確な部分（何らかの調査や実装結果が無いと判断できない）が多い経路ほどブレが大きい

### 3.マイルストーン
・直列の仕事の進捗確認
・並列の仕事の同期（合流）地点
・プロジェクト期間が3週間を超えるなら必ず設ける
・短い期間で終わるものでも中間地点の確認は重要
・最低でも1つ、多くても3つまでが望ましい

### 4.リスケジュール
・遅延しているから単純に期間を延ばすという話しでは無い
　⇒なぜその状況が起きたかの原因と対処
・選択する手段の変更も視野に入れる

見直す時期
・当初は分からなかった部分が判明
・決まっていなかった部分が決定
・プロジェクトに関わる体制や状況の少なくない変化

## まとめ
特定の職種・役職・役割に限定せず、全員が当事者意識を持って、プロジェクトの勘所を押さえましょう！

## Q&A
Q1. (DevOpsの)プラクティスと(電子書籍/同人事業の組織の)状況(を)マッピングしていると思うのですが、◯/△/×は明確な達成基準があるのでしょうか？それともメンバーとの会話による感覚値的な部分でしょうか？
※資料8枚目のスライド（電子書籍/同人事業の開発運用）に対する質問

A1. 結論から申しますと、感覚的な部分が大きいです。
ただ、感覚を合わせるためにどういう風なツールや考え方を使っているかというものの1つに、弊社のCTO松本も入っている日本CTO協会の出している[DX Criteria](https://cto-a.github.io/dxcriteria/)というものを一部活用したりですとか、あとは全体の規模、モニタリングのところで言うとオンプレミスとクラウドがそれぞれ例えば50%ずつ使っているとしたら、オンプレミスだけモニタリングがしっかり出来ているから半分の△だよねなど、そういった形で考えている達成基準というところになります。

Q2. 3週間かかるものはスプリントバックログだけではなく、マイルストーンを作成していく、3週間という期間の勘所を聞きたいです

A2. この3週間という期間の意味というのが、スクラムをベースとした時にだいたい1スプリントの期間を2週間〜1ヶ月というのが推奨される期間だと思うんですけど、それの中間地点というのが、色んなものを考えた時にしっくりくるなというところだったので、3週間に置いています。
これを超えると、どうしても最初の出だしが（3週間の内の始めの1週間）、スタートが結構遅いんですよね。そこを、最初の週で20%しか進んでない。杓子定規に35%まで進んでたらオンスケ（予定通り）なのか？ということって難しいと思うんです。
だからこそ、ここだけは外せないよね（合流地点になる、どこかで分岐する）というところがしっかり守れていないと、このあと1人しかやっていなかったものを2つに分けて並行してやっていくことでスピードアップ出来るというような目論見が全て崩れてしまう。
そういった意味合いで、マイルストーンという考え方は重要だなと考えている次第です。

#パネルディスカッション
Q1. リーダーシップで一番大事にしていることは？

A1. 一番は、当事者意識ですね。
当事者意識の持ち方は人それぞれあると思いますが、僕の場合は、何か施策などがあった時に自分もそれをやりたくなるということを一番大事にしています。自分がやりたいと、周りにも広めていくことが出来る。その影響の輪が広がっていくことで、皆んなの心にも火が点いて、加速していく形になれる。

Q1-2. コロナ前と後、人のマネジメントで変化したことがありますか？

A1-2. コロナ前の六本木オフィスに居た頃は、誰がどれだけ発言しているかなどは周りを見れば分かったが、それが一切見えなくなった。
コロナ後は意識的に時間を設けて各朝会（Zoomなど）に様子を見に入るようにしている。
また、チームの中のルールを明確に文書化することを心がけた。
Web会議のカメラについてもずっとOFFだと体調面の変化などが掴みづらいため、1日に1回でも良いからONにするように変えていった。

Q2. DMMで求められるリーダーシップの形は？

A2. 事業間・関連部署（プラットフォーム、インフラなど）との連携において、それぞれの部署単体でやりたいことがあるが、それらを擦り合わせていく作業がどうしても常日頃ずっと発生し続ける。自分達がやりたいことだけやっていても、全社的に（DMMグループ的にも）うまくいかないので、全体最適を考えながらどう折り合いをつけていくかが問われている。

Q3. リーダーの責務はどこまで？
・Human Management
・Product Management
・Project Management
・Tech Management(TechLead)

A3. 4つの責務は負っているが、割合としてはHuman Managementが6割くらい（比重、時間の使い方の意味で）。それ以外は、グループリーダーやチームリーダーなど他メンバに移譲していっている。
どうしても間違ってはいけない部分のみ要所要所でコミュニケーションを密にとる形。

Q5. 意思決定の勘所。選択の連続の中で、何を軸に実行していますか？

A5. （※アーカイブには無い部分） "同じ情報があれば同じ判断を下せるもの"は、他メンバに決定を委ねるようにし、リスクを取る判断が必要なものは自分自身が決めて推進するようにしています。

#おわりに
DMMでは[毎日、採用中](https://dmm-corp.com/recruit/)です。

特に現在、[電子書籍事業](https://dmm-corp.com/recruit/691)・[同人事業](https://dmm-corp.com/recruit/333)で新しい仲間を募集しています。
少しでもご興味を持って頂けましたら、ご応募お願いします。

#参考資料
* [アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)
* [アジャイルソフトウェアの12の原則](https://agilemanifesto.org/iso/ja/principles.html)
* [スクラムガイド 2020年11月](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)

#参考書籍
* [Clean Agile　基本に立ち戻れ](https://www.amazon.co.jp/gp/product/B08KRHDS84/ref=dbs_a_def_rwt_bibl_vppi_i0)
* [カンバン仕事術](https://www.amazon.co.jp/gp/product/487311764X/ref=dbs_a_def_rwt_bibl_vppi_i1)
* [The DevOps ハンドブック 理論・原則・実践のすべて](https://www.amazon.co.jp/gp/product/B073PRMWR5/ref=dbs_a_def_rwt_bibl_vppi_i4)
* （クリティカルパス：PERT）[計画の科学](https://www.amazon.co.jp/gp/product/B00GHHYPR4/ref=dbs_a_def_rwt_bibl_vppi_i0)