はじめまして。大谷木です。
2021年10月にアトラエに入社し、現在、Wevox事業部でプロジェクトマネージャー（PM）兼バックエンドエンジニアをしております。
突然ですが、今、あなたが参画しているプロジェクトは順調ですか？
私は先日まで、Wevox カスタムサーベイのリニューアルプロジェクトのPMを担当していましたが、正直な話、終始何のトラブルもなくとはいきませんでした。
prtimes.jp
このプロジェクトには途中から参画したのですが、参画当初、実際に発生していたのは、
- 進捗が思わしくない、スケジュールがずるずる伸びていく
- 次にどういったタスクに着手すべきかわからない
と言った問題でした。
ただ、こういった問題はこのプロジェクト特有の問題ではなく、私自身過去何度もそういった場面に出くわしていることからも、よくある問題であると考えています。
今日はこういったあるあるを回避するために、私がPMを担当する時に大事にしている5つのポイントについて書きたいと思います。
PMを担当する時に大事にしている5つのポイント
1. プロジェクトのゴールを明確にする
プロジェクトを進めていく中で、こんな問題に直面したことはありませんでしょうか？
- 何を達成したら良いのかわからない
- 進捗が思わしくない、スケジュールがずるずる伸びていく
- これって今やるべきことなの？
こういった問題に直面する一つの要因として考えられるのは、「プロジェクトのゴールが定まっていない。あるいは、ゴールが明確でないためにmust/want要件の区別ができない」ケースです。
プロジェクトに携わっていると、プロジェクト開始〜終了まで、もっとこうした方がいいのではないか、ああした方がいいのではないかと様々な要件が上がってくると思います。
上がってくる要件全てを叶えようとするとなかなかプロジェクトは終息しません。
そもそも、全ての要件を叶えることが果たしてみんなが望んでいることなのでしょうか？
中には最低限の要件で良いから早くリリースして欲しいという人もいるのではないでしょうか？
プロジェクトのゴールが明確でないと、「各要件に対してmust/wantの判断が困難＝全ての要件を叶えざるを得ない状況」になってしまい、結果、上記のような問題に直面する可能性が高くなります。
もし、今携わっているプロジェクトのゴールが明確でないなと思った方は、関係者と話し、早めに設定することをお勧めします。
2. 設計書はしっかりと作る
Photo by Firmbee.com on Unsplash
小規模プロジェクトの場合は設計書を作っている期間で実際に動作するものができてしまうので、わざわざ設計書を作らないといったケースをたまに見かけます。
それが悪いといったわけではありませんが、私はどんなに小規模なプロジェクトでも以下の目的のために設計書を用意するようにしています。
- 実装の手戻りを防ぐ
- テストの材料にする
- 不具合っぽいものが見つかった時に、仕様としてあえて意図してこう実装しているのか、それともバグなのか判断できるようにする
- エンジニア以外の人でも仕様が把握できるようにする（＝ソースコードを読まなくても仕様がわかる）
ただし、何でもかんでも設計書に起こすのかというと、そういったわけではありません。
何でもかんでも設計書に起こしていたら、なかなか実装に入れないのも事実です。
あくまで私の意見ではありますが、以下3つを最低限作るようにしています。
- ユーザーストーリー
- 画面仕様書
- API設計書
では、なぜこれらの設計書を作るようにしているか。
私は、プロジェクトに途中から参画することが経験的に多いのですが、時々、設計書が存在しておらず、仕様を把握するためには、ソースコードを読んだり、動くものを触ってみたり、人に聞くしかないといったケースがあります。
正直、困ります（笑）
特に困るのが、上にも記載していますが、
「不具合っぽいものが見つかった時に、これは仕様（あえて意図してこう実装しているのか）なのか？それともバグなのかわからない」ケースです。
この場合、設計・実装した人を見つけてヒアリングするのですが、時々、数年前に設計・実装したからわからないと言われてしまうこともあったりします。
自身が関わっているプロジェクトでは、未来でこういった事態を引き起こしたくないので、設計書をしっかりと作るようにしています。
3. テストは必要十分。無理のない範囲で実施する
時々、テストが目的になっているのではないかというプロジェクトを見かけます。
テストはあくまで、品質の良いものを出すための手段です。
やりすぎもやらなさすぎも良くないので、私は、最低限のテストは実施しつつ、それ以外のテストについてはプロジェクトメンバーのレベルや状況に合わせて決めるようにしています。
私が言う最低限のテストというのは、「ユーザーストーリー」を満たしているのかを指しています。
ユーザーストーリーというのは言い換えれば要求事項ですので、これを満たしているか否かをテストすることは必須であると考えています。
それ以外のテストについてどういう状況でどう判断したかについては、過去に2つ両極端なプロジェクトに関わったことがあるので、それを例に紹介したいと思います。
[設計書やテスト項目書が存在しないが、大きな不具合や致命的な問題が頻発していない]
補足：このプロジェクトには、初期リリース完了後、サービスとして拡張、改善している時に参画しました。
このプロジェクトに参画した時にポイントとしたのは、上記にもあるとおり、「今まで設計書やテスト項目書をほとんど用意していないにもかかわらず大きな不具合や致命的な問題が発生してしていない」という点です。言い換えれば、これは、一人一人が自身の責任範囲（≒単体レベル）においては品質担保しようと心がけており、懸念部分があるとすれば結合部分以降なのではないかと考えました。
そのため、実際にサービスの拡張・改善した際は、単体レベルのテストは各自の判断に任せ、結合以降はしっかりと項目書を作ってより品質を上げるようにし、結果、リリース後も特に大きな問題は発生することはありませんでした。
[設計書の通り開発が終わったとのことだが、プログラムが起動しない]
補足：このプロジェクトには、これから結合して初期リリースというタイミングで参画しました。
開発は終わってこれから結合というタイミングだったため、結合テスト項目書を私の方で用意しテストを実施したのですが、そもそもプログラムが起動せず......非常に驚いたことを数年たった今でも鮮明に覚えています。
まずは状況の整理をと思い、単体テストの結果を教えて欲しいと開発者に聞いたところ、単体テストは実施していない結合テストでテストするつもりだったと言われたので、これは、メソッド単位でも動作が怪しいと思い、メソッド単位で意図したものになっているかレビュー、改修、テストを実施するように舵を切り、なんとかリリースまでこじつけました。
このように、関わるメンバーや状況に応じて必要なレベルは変わって来ます。
最低限のテストは実施しつつどこまでテストを行うかは状況に応じて臨機応変に判断する必要があると考えます。
4. タスクを見える化する
あなたが参画しているプロジェクトではタスクは見える化されていますでしょうか。
見える化は、カンバンボードやWBSを準備、メンテナンスするためにある程度コストがかかりますが、
「PMに聞かなくても、何がどこまで終わっているのか、今何をすべきか、あと何をしなければならないのかがわかる」
状況を生み出すことができます。
これにより、指示待ちやAタスクが終わらないとBタスクに着手できないといったことを最小限にすることができますので、コストをかけてでもやる価値のあるものだと私は考えています。
タスクを見える化する際によく私が用いるのは以下2つです。
カンバンボードは最近はmondayのカンバンビューをよく利用します。
サブアイテムがカンバンビューに出てこないのが少し残念ではありますが、アイテムのカラム追加の自由度が高く、WBSビューなど様々なビューやアプリが用意されており便利です。
カンバンボードを提供しているツールの大多数は数ユーザーであれば無料で使えますので、是非色々試し、自分に合ったツールを見つけ、見える化を進めていただければと思います。
5. 独りよがりにならない
例え話をしたいと思います。
あなたはA社から依頼されているシステムを開発しているエンジニアです。
ある日、PMが、
「今日A社さんと打ち合わせしてきたんだけど、Xっていう機能もあった方が良いですねって話になったからXの機能開発を追加で受注してきたからよろしく！！ 費用は追加で〇〇いただけるようになって、期日も2週間伸びているから。」
と言ってきました。
あなたはどう思うでしょうか。
一見すると、A社さんは機能追加の要望が叶いますし、あなたの会社は売り上げが上がるしwin-winのようにも見えます。
ただ、このXが2週間では到底実装できない機能だったらどうでしょうか。
このシステムについて一番詳しいのは恐らくPMではなく現場のエンジニアです。
「話が上がったときに一旦持ち帰って見積りさせてよ・・・」とあなたは思うことでしょう。
PMと聞くと、何やら強い権限を持っているかのようにも見受けられますが、
PMはあくまで、「プロジェクトの計画・遂行に責任を負う管理者。また、そのような職位や職能（IT用語辞典より）」です。プロジェクトはPMのものではなく、プロジェクトに関わっている全ての人のものなのです。
上記は極端な例ではありますが、もしあなたがPMを担うことになったら、独りよがりにならず、プロジェクトに参画しているみんなで意見を出し合い、みんなで作り上げていっていただけたらと思います。
最後に
今回は、私がPMを担当する時に大事にしている5つのポイントについて書かせていただきました。
読んでいる人の中には、当たり前のことしか書いていないじゃないかと思う人もいらっしゃるかと思います。
ただ、過去に数多くのプロジェクトに参画して来ましたが、割とその当たり前が当たり前にできていないために上手くいっていないといったプロジェクトも実際に見て来ています。
当たり前だからといって蔑ろにせず、当たり前だからこそ大事にしていただければと思います。
