エンジニアによるプロジェクトマネジメントについてのキャッチアップ（怪文書）

アジャイル開発

アジャイル開発の概要

アジャイル開発、エッセンスとしては要件定義->設計->開発->テストと過程が続いていくが、本当にある工程が満足いく品質で確認事項や抜け漏れもなく終わったといえるためには、成果物を後工程で実際に使ってみる他ない。そのため、ウォーターフォール開発のように各工程を一回ずつしかやらないのではなく、アジャイルのようにちょっと成果物ができたらすぐ後工程に回すというのを１週間おきくらいに繰り返すのが良いという理論。

アジャイル開発がうまくできない時

アジャイル開発の数々のセレモニー（ミーティング）をただ形式的にこなせばいいというわけではないと思っている。本質を理解していない凡人がただ形式だけ真似しても、本質が抜け落ちてしまい何の意味もない、ということは世の中のあらゆる分野でよくあることだと思う。

ガチガチのウォーターフォール開発でどうしてもそれを変えられないという状況もあると思っている。ただ、アジャイル開発の本質の一つは上記概要に記載したことだと思っている。そのため、アジャイル開発のエッセンスを取り入れることはできる。成果物がちょっとキリのいいところまでできたら、すぐ後工程の人など他の人に見せてフィードバックをもらい、抜け漏れを洗い出して直すことが必要である。これを短いスパンで繰り返しやると良い。そうすればアジャイル開発のエッセンスは満たせていると思う。

実際エンジニアの立場でそのようにやってみた。バグの数が半分~1/3くらいになり、かなり品質が良くできた。フィードバックをもらう時間を後回しにせず、キリのいいところまでできたらすぐCIで自動でビルド・デプロイし、PMなどに見てもらったりした。あるいは自分でユーザーの立場に立って、成果物を触って違和感がないかチェックしたり、設計書・テスト項目書と照らし合わせて抜け漏れがないかいちいちチェックしてみたりした。その場その場でチェックをすぐにやっていくということである。

参考文献

• アジャイルサムライ−達人開発者への道−, Jonathan Rasmusson, オーム社, 2011

PMBOK

概要

プロジェクト管理に必要な知識や分野などをもれなく洗い出したもの。

ライフサイクル

要件定義、設計、開発、テスト、公開、譲渡　など。これらはプロジェクトによって柔軟に変えられる。例えばプロジェクトによっては「実現性調査」という過程があるかもしれない。またプロジェクトによっては「開発・公開」だけで終わるかもしれない。他方下記の5プロセス群については、それほど変えることをPMBOKとしては想定していない。

参考 Project Management Simplified: Learn The Fundamentals of PMI's Framework

5プロセス群 (5 Process Groups)

• 立上げプロセス群 (Initiating)
• 計画プロセス群 (Planning)
• 実行プロセス群 (Executing)
• 監視・コントロール・プロセス群 (Monitoring and Controlling)
• 終結プロセス群 (Closing)

10 知識エリア (Knowledge Areas)

• 統合マネジメント (Integration Management)
  • 他の知識エリアやプロセスグループなどの特定、調査、調整など。
• スコープマネジメント (Scope Management)
  • 一番重要なこと。プロジェクトで何をやり、何をやらないかを、なるべく後戻りや認識違いが発生しない粒度まで洗い出し、関係者と合意しておく必要あり。これがうまくできていないと他の全てが崩壊する・できないこととなる。
  • WBS、WBSディクショナリの作成がキーポイントとなる。
    • 全ての作業が、容易に見積・コントロール可能なくらいまで細かく分解・洗い出しできているかが重要となる。
    • 実際の作業者など、知識豊富な人にレビューしてもらう必要があると思われる。
  • ただビジネスはその時々に応じて変化していくものであって、いくら完璧にスコープを決めたとしても後から変えなければいけないことも必ずあることには注意。
    • スコープ外の要求をされた場合、スコープで合意していないからといって杓子定規に断るとあまり良くないかもしれない。一旦検討するふりをして、やはりダメだったなどと理由をつけたり、後ろにずらしたり、代替案を提案するなどが考えられる。
• スケジュールマネジメント (Schedule Management)
  • ガントチャートまたはバーンダウンチャートなどを用いる。
  • ガントチャートは、ある項目を後ろにずらすと、他の項目全ても後ろにずらさなければなら、ずめんどくさい場合もあるため注意。また、作業者の作業スピード（ベロシティ）といった要素は見える化されないという欠点もある。
  • バーンダウンチャートでは上記の欠点はなく、作業者の作業スピード（ベロシティ）が線の傾き具合により明確化されるので、想定通りのスピードが出ているかすぐわかるので、指標としてスケジュールの管理がしやすいか。
  • ただ、「作業スピードをスケジュール管理の指標にしています」というのを大々的に言ってしまうと、作業者がその指標が悪化しないように立ち回り、やるべきことをやらなかったり言うべきことを言わないようにするなどの現象が起きることもある。そのため、何を指標にしているかは大々的に言わず、マネージャーの心の中だけとしておくのが良いかと思われる。
• コストマネジメント (Cost Management)
• 品質マネジメント (Quality Management)
• リソースマネジメント (Resource Management)
  • 人員などのリソース管理
    -人のアサインについて、ある期間アサインし、その後アサインから外し、しばらくしてまたアサインするというように間を開けてしまうのはあまりよろしくない。なぜなら、その中途半端な間の期間にその人は別の仕事を見つけないと手が空いてしまうことになるが、その中途半端な期間をちょうど埋めるだけの他のプロジェクトがあるとは限らないからである。
• コミュニケーションマネジメント (Communications Management)
  • コミュニケーションのやり方について、会話・メール・電話・SNSなど複数のチャンネルがあるとどこで何を話しているのかよくわからなくなることが多い（特に、客との会話）。そのため、Backlogなど容易に管理できるツールでのみコミュニケーションを図ることとすると良い。そして、そのことをプロジェクト開始時に所与のものとして合意しておくとよい。
• リスクマネジメント (Risk Management)
  • 悪いことは必ず起こり、良いことは起こらないぐらいの想定でいるのが良い。
  • 起きるかもしれない悪いことについて、自分に知識がないと全く思いつくことができないかもしれない。そのため、その分野の有識者に話を聞き、人を巻き込むことが特に重要となる。
• 調達マネジメント (Procurement Management)
  • 必要な物資や人員の調達。時間がかかることが多いため、「ちょっと進みが悪いかな？」と感じたくらいのところで、もう調達の準備を始めるくらいでちょうど良いかもしれない。
• ステークホルダーマネジメント (Stakeholder Management)
  • 対人のコミュニケーションとして、人にはいろいろ性格や価値観があり、その人に合わせた言動をして気に入られると良い。
    • 人情味のある人 -> 適当などうでもいい雑談などを挟むと良い。
    • 経営層など数字にこだわる人 -> 数字や、ビジネス状のインパクトなどを話してあげると良い。
    • エリートなど成果にこだわる人 -> 余計な話はせず、ひたすら成果を上げて認められると良い。
    • 人種・性別・国籍・政治・宗教・身体障害マイノリティ -> それらについての話題には触れない。が、配慮が必要な場合、配慮を求められたときは可能な限り柔軟に配慮してあげると良い

参考 プロジェクトマネジメントの教室

制約理論（Theory of Constraints）

1. 仕事が他の人や組織・部署と繋がって行われている
2. それぞれの人や組織の能力は一緒ではなく、早い遅いのばらつきがある

• この場合、全体の成果（スループット）を決めるのは、一番弱い人や組織ということになる。他がいくら早くても、一番弱い部分が遅ければ一番弱い部分に合わせた成果しか出ないため。

  • 例えば、設計やテストが１ヶ月で終わるとしても、開発が２ヶ月かかってしまう場合、設計やテストをいくら頑張っても絶対に２ヶ月は全体でかかってしまうということになる。そのため、一番弱い部分（ボトルネック）に資源を集中しすることが全体として最適な結果となる。

• 各部署が自分自身の作業だけを手を休めずやり続けているとすると、非常に非効率ということになる。理由は、そうするとボトルネックである人や部署（仕事が遅い人や部署）にどんどんやるべき作業が積み上がっていき、全体として非効率になってしまうからである。

  • そのためボトルネックでない人や部署はある程度自分の作業は余裕を持って終わらしておき、ボトルネックの人や部署を手伝ったり支援したりすると良い。
  • あるいは、ボトルネックの人や部署がこなせる量に合わせて、全体の作業の量や進行スケジュールなどを調整するような仕組みにすると良い。
  • あるいは、各部署の作業の順番を入れ替えたり、あるいは同時並行的にできるような場合は、ボトルネックの部分で作業を止めないで、他の作業を進めたり、同時並行的に進めたりすることで緩和できる。
    • 開発が遅いため全部開発が終わっていないが、開発が終わっている部分だけでも先にテストを始める、というようなことがこれに該当する。
    • この点、ガチガチのウォーターフォール開発は要件定義 -> 設計 -> 開発 -> テスト　の工程を順番に一回ずつやるだけで、柔軟に順番を変えたり、同時に並行したり、一部分だけやって何度もサイクルを回すというようなことを許容しないので、この点非常に非効率ということになる。
    • アジャイル開発のように、開発が終わった部分からすぐテストを始める、というようなやり方だと、テスト工程の人が手が空いて暇になるということがなくなるため、全体的に効率が良くなる。

• 仕事の需要や、各人の成果にはどうしてもバラツキがあるため、需要に合わせた最小限の体制しか積んでいないと、わずかな需要やパフォーマンスの変化によって容易に崩壊する体制となってしまう。

  • 世の中には何事もばらつきや変動があるということを踏まえれば、ある程度ゆとりを持った体制にしておく必要がある。
  • ちょっと誰かが育休などを取っただけで他の人が限界を超えてしまうなどという体勢はゆとりがないと言える。普段は何をしてるかよくわからず半分遊んでいるようにも見える、というような人が昭和の時代はいたかと思う。理想論ではあるかもしれないが、そのような暇な人を抱えておくぐらい余裕を持っておくと、いざという時にも対応ができる。

参考文献

ザ・ゴール コミック版, エリヤフ・ゴールドラット, ダイヤモンド社, 2014

NLPコミュニケーション

安心安全なコミュニケーション

• 人は、本能的には、正確なコミュニケーションを求めているわけではない。 安心安全なコミニケーションを求めている。そのためただ用件や事実などを正確に伝えれば、コミニケーションがうまくいくわけではない。 相手に安心感を抱かせるようなコミニケーションをすることで、自分の用事などが相手に受け入れてもらえやすくなる。あるいは自分の主張などを受け入れてもらいやすい状態を作れる。そのような手法がNLPコミュニケーションである。
  • 相手が同意する=「はい」と言ってもらえるようなことを会話の中に盛り込んでおく。すなわち、相手を肯定するようなメッセージである。すると相手は安心できる。すると、その後の要求などを気持ちよく受け入れてもらいやすくなる。
    • 例 ✖️「（いきなり声をかけて）これ間違ってるから治しといて。（相手「...はい」）」
      • ↑事実を伝えているだけなので、正確性という意味では問題のないコミュニケーションである。しかし相手の都合を聞くなどの配慮もなくいきなりお願いしている + 相手に「間違っている」というメッセージを投げかけている。　すると相手は本能的には受け入れ難くなる。
    • ◯ 「お疲れ様です。（相手「はい」）いつも作業ありがとうございます。（相手「はい」）助かってます。（相手「はい」）今ちょっといいですか。（相手「はい」）これをこのように修正することは可能でしょうか。（相手「はい、わかりました。」）」

ネガティブに考えられていることの思い込みの打破

• ネガティブに考えられていることの思い込みの打破
  • 人は、本能的には、安全を重視する。そのため何らかの既存のネガティブな経験から思い込みを作りあげ、そこから出ることを嫌う傾向がある。それがあまりにネガティブだと困り物である。自分、他人のそのような思い込みを崩す方法はいくつかある。
    • （ネガティブな思い込みに対して）なぜそうなるのか？ なぜそのように思ったのか？ を問う。 <- 思い込みの成立過程を追うことで、その思い込みがいつでも当てはまるわけではないことがわかるかもしれない。
    • （ネガティブな思い込みに対して）もしその思い込みから外れるようなことをしたら何が起こるのか？ を問う。 <- その思い込みから外れたところで大したことがない、または対処法があるとわかり、大した思い込みではないと気付けるかもしれない。
    • (ネガティブな思い込みに対して）その思い込みは本当にいつも、誰にでも、どこでも、どんな状況でも当てはまるのか？ を問う。<- その思い込みがいつでも当てはまるわけではないことがわかるかもしれない。

問題状況の言語化は「名詞」ではなく「動詞」で

• 問題状況の言語化は「名詞」ではなく「動詞」で

  • 問題を「名詞」で捉えるとそれがあたかも重大で動かし難い問題かのように誤解してしまう傾向がある。「動詞」で言い直すと、それの解決策があることに気づきやすくなる。
  • 例: 名詞で捉えた場合: 「部下との意思疎通の問題」がある
  • 動詞で捉えた場合: 「主にA君が私と話すときに気を使いすぎてあまり意見を言ってくれていない」<- A君にリラックスしてもらうにはどうするか、など解決策が容易に思いつきやすい。

• 参考文献: マンガでやさしくわかるNLPコミュニケーション, 山崎啓支, 日本能率協会マネジメントセンター, 2013

イシューから始めよ

問題と思えるものであっても初心者のうちはたいして問題のないものを問題と思ってしまうことが多い。有識者に聞いたり、情報を集めるなどすると、多くの問題と思えるものは実際大した意味を持たなかったり、自明に解決されたりする場合が多い。有識者に聞くなどして、本当に役に立つ度合い（イシュー度）を高めて、問題に取り組むことがおすすめされる。

ものすごい根性や体力がある場合、イシュー度の高いものの見極めをせずとも数をこなしまくって成果を上げることも不可能ではないかもしれない。しかしその場合、イシュー度の高いものの見極めができないため、部下の育成はできないので、上司として大成しない。

参考文献

イシューからはじめよ-知的生産の「シンプルな本質」,安宅和人, 英治出版, 2018