実績で一番多いのはおそらくプロジェクトマネージャーだと思う。

お仕事で依頼される以外でも、自分がサービスを立ち上げる場合は必ず自分がプロジェクトマネージャーになるので、多分プロジェクトマネージャーをしている件数は一番多い。

プロジェクトマネージャーの立場でやることは、自分なりの手法が結構確立できていると思っていて、それが実はスクラムの手法と同じだったりして、そんな似ている要素もちょっとまとめてみたいと思う。

基本スタンスはアジャイル

もうこれは本当に明確にしているけど、ウォーターフォールは絶対やらない。なぜなら間違いなく失敗するやり方だから。

これに関しては、やらない理由、失敗する背景、状況、原因について色々書けるけど、膨大になるのでリクエストが多かったら書こうかな。

で、失敗しないためにアジャイル開発のスタンスを取る。

アジャイル開発というと「開発」という単語がつくので、開発手法のように理解されがちだけど、「失敗を避けるために素早く対応しながら開発する(プロジェクトを進める)」という考え方・スタイルと捉えている。

アジャイル開発を行うにはアジャイルなプロジェクトの進行が必要なので、単語としてはないけれど「アジャイルプロジェクトマネジメント」を行うことになる。

一番大事なのは、失敗せずに(もしくは盛大な失敗を避けて)目的に沿ったシステムができあがることなので、失敗の要素を生み出さないもしくは失敗の要素に早く気づいて対応できる進行の仕組みにしている。

スクラムの要素

結構、プロジェクトマネージャーとして「スクラムマスター求む」のような案件が最近ちらほら見られる。 プロジェクトマネジメントの具体的手法として、スクラムが定着してきたのは嬉しいところ。

スクラムについては、スクラムガイドを読んだり、本を読んだりして学んだ。

自分がやる時に必ず採用しているスプリントの要素としては、

• プロダクトバックログ
• スプリント
• スプリントバックログ
• スプリントレビュー
• スプリントレトロスペクティブ
• デイリースクラム

って感じで、ほぼ全て入っているかな。

スクラムの独自用語になっているけど、内容は他の言い方で理解されている単語と同じだったりするので、プロジェクト内では以下の言い方にしている。

• やることリスト = プロダクトバックログ
• マイルストーン = スプリント
• タスク(or タスクリスト) = スプリントバックログ
• レビュー = スプリントレビュー
• ポストモーテム = スプリントレトロスペクティブ
• 朝会 = デイリースクラム

プロジェクトの基本ルール

メンバーが、プロダクトオーナー、エンジニア、デザイナー、プランナー(仕様や要件を決める人)と揃ってプロジェクトスタートする時に、キックオフミーティングでやるのはプロジェクトの基本ルールを決めて全員同意してもらうこと。

細かくはプロジェクトの状況によるけど、だいたい以下の感じかな。

• マイルストーンは3週間〜4週間間隔で日程を決める 変更はしない
• レビューの日はマイルストーンの最終日に行う 変更はしない
• エンジニアはテストコードを書いて、パスしたものをコミット・プルリクエストを送る。常にテストにパスした状態を保つこと
• プランナーとデザイナーはエンジニアがタスクに取り掛かる1つ前のマイルストーンで、その分の仕様書、UIデザイン画の資料を完成させる(エンジニアの待ちが発生しないように)
• すべての作業はタスク管理ツールを用いて、自分の担当するタスクを明示する
• 各自のコミュニケーションはメッセージングアプリで行い、他のメンバーに公開されている場所にて行う。1対1のコミュニケーションで隠さない
• 定例ミーティングは週1回。1時間以内で終わらす

今は対面せずにオンラインだけで完成まで行けてしまうので、むしろオンラインツールにすべてを残して、言った言わないをなくしたり、タスクの進捗具合をドライに測れたりできる。

基本ルールの効果

実際防げた事象としては、

• タスクの進捗が確認できないので、担当者にメッセージングアプリで確認したところ、(おそらくやっていないことがテキストログに残るのを嫌がって)個別のミーティングを提案されたが、ルール通りメッセージングアプリ内でコミュニケーションするようにして、遅延が発覚。担当者変更

• 初回のレビューの場で多くの未達が発覚。定例ミーティングでは報告なし。2回目のレビューでも遅延。プロジェクトから外れる

• プロジェクトが全体的に遅延し、最終マイルストーン分を実装せずリリース。最終マイルストーン分は付加的な機能なので、サービスのメインには影響なし

• テストがパスしていない状況を放置していたことが発覚。担当していた開発会社を外す

という感じで、期限最終日に初めて気付くのではなくて、最長でも1マイルストーン(3〜4週間)程度の期間で気づけて対処できる。

自分のサービスを作る時はメンバーの質がある程度担保できているし、自分自身がプロダクトオーナー兼プランナー兼デザイナー兼エンジニアなので、こういう事は起きないけど。

すでに開発会社含めメンバー構成が決まっていて、さぁ、マネジメントよろしくお願いします。と言われて入ってみると、メンバーのパフォーマンス・アウトプットの質や開発会社の不誠実な行動などが実際あったりして、そういうものに早めに気づけて対応というか是正がしやすかった。

やっぱりプロジェクトマネジメントは経験が成否を決める

困った状況になってしまっているプロジェクトを見てみると、未経験のプロジェクトマネージャーを置いているケースが本当に多い。 というより、困った状況になっているプロジェクトのプロジェクトマネージャーはほぼ間違いなく未経験者。

スキルアップのためとか職位が高めだからとか理由で、そのポジションに居るのかもしれないけど、だったらシステム開発で完成まで携わった経験のある人や外部のプロにアドバイザーで付いてもらうなりサポートの仕組みを入れないと間違いなく失敗する。

多分、経験のない人は自分が何にコミットして具体的に今何をしなくてはいけないのかがわかっていないのではないかと思う。そうなると、結局自分では何もせずに外注頼りというか開発会社頼りになって、思ってもいないものができあがってくる。

優れたエンジニアは質問力に優れているので、ある程度プロジェクト進行に対してプラスの効果はあるけど、メインのタスクではない。

マネジメントがしっかりできていないと、どうでも良くなるし、メンバーが不安・不審に思ってしまう。

プロジェクトマネージャーはちゃんと経験があって、今までリリース・運営までいった具体的なサービスをいくつか挙げられる人が良いと思う。それまでには失敗の経験もあるだろうし、その経験が失敗しないためのその人なりのやり方を持つことになっているだろうし。

ということで、プロジェクトマネージャーはプロジェクトの成否を決める、それだけ奥深くって投資価値はあるポジションですよ。というお話でした。

ということでお仕事募集中です

プロジェクトマネージャーはこんな感じでやってきました。

もしご相談あればコンタクトフォームからいつでもご連絡ください。