ジャーニーマン( @beajourneyman )と申します。システムインテグレーターでCOBOLプログラマ、SE、PMなどを経て、現在はコンテンツマーケティング(オウンドメディア/SNS)を担当しています。まだ運用を始めて半年に満たない駆け出しマーケターです。
こちらは Backlog Advent Calendar 2017 の23日目の記事です。
この記事の背景
nulabさんの プロジェクト管理ツール Backlogの User Group JBUG (東京#3) でお話しさせていただいたLT(Lighting Talk)のテーマを深堀りします。
スライドはこちらです。
LTでお話ししたテーマ、プロジェクトマネジメントで大事にしていること、それは以下の2つです。
- プロジェクトの"文化"
- プロジェクトのメジャメント
今回はLTさせていただいた中の"文化"についてまとめています。もう一つのメジャメントは、機会があれば改めて整理してみようと思います。
プロジェクトは生き物
かねがね、プロジェクトは"生き物"だと思っています。
システムインテグレーターのPMは、ヒエラルキーのはっきりした組織の長という性格があります。今でこそアジャイルが浸透しサーバントリーダーシップが注目されていますが、いわゆるウォーターフォール型のプロジェクトにおけるPMは、ヒエラルキーの頂点に立つプロジェクトの絶対的な責任者です。プロジェクトの成功のために組織とぶつかることも少なくありません。
さて、そんな背景を踏まえて、なぜ"生き物"なのでしょうか？ 今まで何度かエンドユーザーさんダイレクトの請負案件(いわゆるプライム案件)をいただき担当しました。案件ごとの組織は、お客様は無論、ほとんどのメンバーが初めて一緒に仕事をする方々になることは珍しくありません。"生き物"のイメージに繋がると感じる3つの特徴がプロジェクトにはあります。
- 永続的でない一時的な組織が行う
- 必ず開始と終了がある(有期性)
- 1人のリーダ(PM)とメンバーの方々で構成される
というものです。項番1.から補足すると、一過性があり都度性格が異なる、人生のように有限である、脳のような司令塔がいる、何となくですが、人間のような"人格"を持っていると捉え、組織に落とし込んだものを"文化"と考えています。"人格"は自分の中で思考する時のイメージ、"文化"はメンバーの方とも共有するプロジェクトの共有認識です。
"文化"の前にある文書
請負案件のスタートは、いわゆるコンペを経る戦場です。プロジェクトの要求事項に繋がる情報を求めるRFI(情報提供依頼書)、提供情報を元に選別(スクリーニング)された先により具体的な提案を依頼するRFP(提案依頼書)、受注者側の提案内容を発注者側で精査しプロジェクトを任せる先を決定します。
非常に厳格な選定プロセスを経て、プロジェクトが発足する初期の段階に作成するのが「プロジェクト憲章」です。国家に憲法があるようにプロジェクトには憲章がある、これから行う数々のタスク、産み出す成果物(アウトプット)の礎になる文書、ヒエラルキーの頂点に位置します。
プロジェクト憲章とは： プロジェクトを立ち上げる際に策定される、プロジェクトの目的や条件、内容などを明確に定義した文書。そのプロジェクトの目的や目標、範囲や成果物の定義、前提条件、制約条件、想定されるリスク、期間やコストの見積もりなどが含まれる。
IT用語辞典 e-word.jp 調べ
プロジェクト憲章を抜け漏れなく作ったらプロジェクトは上手く行くでしょうか？ 10年余り携わった経験から得たモノは、文書よりも"文化"がより重要であるということです。本記事で"文化"についてまとめていくにあたり、ベースとなるプロジェクト文書があることを頭の片隅にとどめておいていただければと思います。
大事なのはリーダーの振る舞い
ご自身が携わられたプロジェクトを思い出してください。構築したシステムやサービスを思い出す前に「誰々さんのプロジェクト」とイメージしたモノはありませんか？ スタートアップのサービスであれば、実際はCTOの方がプロジェクト推進されているケースもあると思います。初期のアーキテクチャの実装からサービスのグロースまで一貫して携わられている場合も多く、PMの肩書きでなくてもこのテーマのリーダーです。リーダーの具体像がイメージできたとしましょう、その方が常々メンバーに伝えていることがありませんせんか？ それが正に"文化"のエッセンスです。
例えば「チケットが発行されていないタスクはやらない。」「プロジェクトWBSに記載がないことはやらない。」など、リーダーの言葉の背景には多くの場合、明確な意思が存在しています。何故そんなことを口が酸っぱくなるほど繰り返し言うのか？ 答えは簡単です。このケースであれば事実を捉えるためです。それが担保されて初めて正しい判断ができるからです(成功する失敗するという次元の話しではありません)。
感覚的ではありますが、リーダーの日々の振る舞いは、プロジェクトの"人格"に繋がっています。抽象的な話しが続きましたが、プロジェクトという一過性の組織における"文化"について次段で述べます。
"文化"は習慣を成す
引き続き「"事実"を正しく把握するために常にタスク化をすること」を例に考えてみます。メンバーの立場から言えば、些細なことも都度都度チケットを切るのはかなり手間かもしれません。一方、検索できないモノやコトを、リーダーや他のメンバーが把握するのは手間の問題ではなく、ほぼ不可能です。把握できないモノやコトは、サポートすることも、フォローすることも、リアクション(Backlogには複数付けられる"スター"機能があり、とても好きです)することも、極めて難しくなります。メンバー視点でも、チケットを切らないことの方が手間がかかることよりマイナス面が多いことは明らかではないでしょうか？
プロジェクトの"文化"となるために必要なことは、常にメンバーの方一人一人がこの意味を体感できるようになるまで根気よく繰り返すことです。日々の進捗のように目に見えるモノとしてではなく、メンバーの方の振る舞いに現れながらゆっくりと浸透していきます。個人の経験ですが、"文化"の浸透には、概ね2ヶ月程度を要します。プロジェクトの"人格"の視点であれば、外部から見たときに、あのプロジェクトはこんなリーダーとメンバーが進めている、と理解が広まる期間とも呼応します。これは、「評価経済」と言われ始めている今の時代、とても重要な要素だと思います。
他の言葉で表現するなら"習慣化"するといえます。繰り返し伝える労力は軽減し、メンバーの方々の間で高い再現性を持って実行されてる状態です。メンバーの方皆さんが、リーダーとしての振る舞いを体現しているプロジェクト、それが目指すイメージです。
ウォーターフォールで言えばフェーズが進むごと、スタートアップで言えば投資ステージが進むごと、メンバーがどんどん増えていく中でも、時には立ち上げたリーダーがプロジェクトを離れても、"文化"が継承され、"人格"が遺伝し、プロジェクトはあるべき方向に自走していくでしょう。
自分がPMを務めるにあたり、大事にしていること、"文化"についてお話ししました。皆さんのプロジェクトにとって少しでも参考になれば幸いです。
最後に
ご自身のプロジェクトに"文化"はありますか？ もしはっきりとイメージでできないのであれば、本記事でご紹介した視点で、プロジェクトにとって良いと感じることをご自身で実践し広めてみては如何でしょうか？ メンバーの方であれば、リーダーに提案されては如何でしょうか？ "文化"の種は、個々人のプロジェクトに掛ける思いです。
取り止めなく書いてきましたが、皆さんのプロジェクトの成功をお祈りして筆をおきます。