プロジェクトを推進する際、特に気をつけていること（マネジメント編）
さて、今回は私がプロジェクトを推進する際、特に気をつけていることについて記載したい。
はじめに
最近、プロジェクトを推進するうえで取り組んでいることについてリクエストがあったので、私が最近特に重視している点を大まかに記載する。あまり色々なことに取り組むと失敗するのでポイントを絞っているが、真に優れたPMは常に全方位に気を配るもの。そういう点ではまだまだ未熟なので、今後も経験を積んでいきたい。
ドキュメント関係
文言を統一する
同一、または似たような意味を複数の言葉で書かない。
例）
・パラメタ値、設定値、値
・サーバー、マシン、VM、PC、コンピュータ
・システム、機能、サービス、コンポーネント
指示や許可は明確に記載する
IT業界の慣例であるRFCの書き方を参考にしている。
例）
・～すること（MUST）
・～してもよい（MAY）
構成要素は全て書き出す
原則としてMECEになるように。例外がある場合は明記する。例えば、対象外となる要素は対象外と記載する。
例えば設定項目が3000箇所あったら、最初にそれら全てをリストアップする。
ドキュメントの受領者と協議のうえ、省略することが妥当と判断された場合のみ、省略することを明記して代替とする。
インプットの構成要素と紐付くように記載する
例えば項目や機能など。言葉で説明するのが難しいが、インプットの資料（RFPや機能仕様書等）に記載があるにもかかわらず、それを受けて作成した資料に記載が無いということはあり得ない。対象外となる要素は対象外と記載する。
可能であれば、インプットの章立てに合わせて順番に記載する。
文書構造は可能な限り面揃えする
できればテンプレート化する。（生産性向上＆誤記防止）
例えば章立て、ヘッダ/フッタ、インデント、箇条書きなど。
対人関係
チームの心理的安全性を確保する
リスク対策＆生産性向上のため。
例）
・ゴネ得、泣き寝入りはさせない。
・自身が至らないことを棚に上げて、相手に無理強いはさせない。
・理不尽には理論を持って毅然と立ち向かう。
・上位者にマウントを取られそうになったら、技術力と理論で対抗する。
総じてめちゃめちゃ勉強して、できることは全てやる。当然しんどいが、プロジェクトの主導権を奪われるよりはマシ。
チームのバランスを考慮する
メンバーの組み合わせや動き、パフォーマンスを見て、どこで介入するか、権限を与えて支援するかの役回りを変える。
チームメンバーは人間であり、個々の特性がある。それを最大限引き出すのがPMの役割と考える。
意義を唱える時は代案をセットにする
これはメンバーのモチベーションを削がないように、かつ状況に介入すべきと判断した場合に行う。余裕のある状況で教育目的であれば、あえて答えを示さないという判断も必要。
ロジックと感情論を使い分ける
大抵の人間は感情で動くが、優れた技術者は合理性が全てに優先する。誰を相手にしているのか？を常に意識すること。
まとめ
以上、私がプロジェクトを推進する際、特に気をつけていることについて簡単に記載した。今回はドキュメントと人について取り上げたが、次回は技術者として、開発を行う際に気をつけていることについて記載したい。