Mission-Street.

2020年10月〜12月に担当した案件と、2021年2月〜継続中の案件でそれぞれPMを担当している
案件を進めてみて、学びや感じたことがあったので、今回はそれをを記事にしておこうと思います
どうまとめればいいのかわからないので、多分まとまりは悪いですがご容赦いただければと思います

前回の記事からとても日が空いてしまったけど、PM業が忙しくて体力削られまくって死んでいて書く気力がなかった...

案件概要

あんまり細かく書けないのでざっくりですが一般的なRailsアプリの開発です

• 中規模
• 既存アプリのリニューアル
• 受託開発
• デザイナー1名、webデザイナー(コーダー)1名、開発2名、PM(僕)
• 2月案件スタート、9末納品予定(最後一ヶ月先方の受け入れがあるので実質8末)

案件開始時の状態

• 企画書、全体像、概念データモデルなどの資料はなし
  • 行動シナリオ作成は途中で挫折したとのこと
• 使用技術未定
• 予算、納期は決まっていた
• 見積もりするために使用した、「ざっくりこんな機能があるといいな」という機能一覧はあった
  • しかし案件開始時には既にやりたいことが変わっていたので見直しが必要だった
• あとは先方社内のMTGで仕様決めに使っていたスプレッドシートなどが存在

案件開始時を振り返ってみた感想

• まずとにかく「ざっくりこんな機能があるといいな」という機能一覧で正確な見積もりをするのは100%無理だった
  • とはいえ完璧な機能一覧とかアプリを実際に作るまで出せるもんじゃないので、開幕に超絶難しいところがやってくる
  • なるべく作るべきアプリの詳細度をあげるためにMTGなど参加できるのであれば参加して色々把握した方がいい(理想)
  • 色々把握することもできずに納期だけが決まっている状態でGO！となった場合は、とにかく情報収集して開発範囲をできるだけ早く固めた方がよい(じゃないとジェルのような仕様の変化に殺されることとなる)
• 説明だけ見ると簡単そうなので安く見積もりした結果、実際は全然軽い作業ではなかったということが頻発した(「この機能は具体的にどんなことをやりますか？」みたいな質問はしたが、当然そんな小手先な対応で詳細までわかるわけがなかった)
  • 簡単に1行で書かれている機能の中に、複数画面に渡る開発が必要な機能があった
  • ↑を安く見積もってしまった結果、予算ギリギリまで他の機能が追加されるが、実際の作業は膨らむので納期に影響が出まくった
  • これ事前にヒアリングする時間が用意されていなければ回避不能では...(正直どうすればうまくやれたのか未だにわからない)
• 僕が案件にアサインされた時点で納期は決まっていて、ざっくり資料で見積もりを出さざるを得ない状態だったので、そもそも最初の状態がよくなかったと強く思っている
  • 書籍「はじめよう！用件定義」には、企画書、全体像、使用技術、概念データモデルなどは用件定義前に揃えておくべき資料と書かれていたが、実際揃ってない状態でやってみて、これには完全に同意した
  • せめて見積もりする前、納期決める前にこのくらいの資料は欲しかったのが正直なところ
  • ただ、どれだけ事前に資料を集めても、作ってみるまで細かい部分までは予想仕切るのは難しいので、ちゃんとした資料を要求し過ぎるのは酷なのも確かだと感じた(バランスが難しい)
• なるべく開発を成功させるためには、以下の状態で案件スタートを迎えられると良さそうかと思った
  • 企画書、アプリ全体像、アプリを利用する想定のユーザー種類出し(一般ユーザー、顧客、自社の社員。など)、ユーザー毎のストーリー作成(誰が何をアプリでするのか？できると嬉しいのか？)、具体的な使用技術とバージョン、ストーリーに基づく機能一覧、概念データモデル(超簡易的なDB設計情報)
  • ↑が揃っていれば資料を元に見積もりを行う、見積もりが行えれば納期を出すことができる
  • ↑が揃っていない場合は資料作成に勤しむ、見積もりと納期はできないので進まない

要件定義開始時の状態

• 先方から情報を聞きつつ企画書っぽいもの、使用技術など、用件定義・開発を始めるに当たって必要そうな資料を作成
• 初回見積もり時に使った「ざっくりこんな機能があるといいな」のうち、既に不要になったり、別に欲しい機能が出てきていたので、それを洗い出していただき、再度見積もりを行う必要があった
• とにかく情報がなさすぎた(どんなものが欲しいのかも具体的にわからない状態)ので、先方との接点をとにかく増やしてMTGを入れまくった

要件定義開始時を振り返ってみた感想

• 僕の経験が少ないのもあると思うけど、とにかく要件定義のしようがない状態だったので、とにかく資料集め、方針決めに奔走した(MTG入れたり本読んだりした)
• 案件開始の状況にもよりそうだけど、とにかく接点増やすのは大変有効だと感じた
  • ていうか接点増やさないと詰む状況だったので、何話せばいいのかわからんけどとにかくMTG入れて話した
  • あと顔合わせまくると信頼感も出るのでおすすめ(信頼感があれば色々腹を割って話しやすくなるなどメリットも多い)

要件定義が周り出した時の状態

• UIがあればDBとかの設計もできるので、細かいことは無視してとにかくUI作りに走った
  • 最初iPadで手書きでやろうとしたけど、話しながらその場でUI作るとか無理だったので、作ってもらってそれをMTGで確認するというフローを数ヶ月繰り返した
  • 手元にある「ざっくり機能一覧」を元に、優先度が高い順にAdobe XDにUIを書いていってもらう感じ

こんな感じで動いてよかったと思ったところ

• レスポンスは早ければ早いほどいい
  • すぐに答えられる/答えられないに関わらず、問い合わせがあった場合は可能な限り即レスポンスを返す
  • 即答えられないような内容でも「今はわからない」とか「検討したい」と相手に伝えるだけでも安心感が違う
  • すぐに答えられない質問をもらう => 何も返事しないで裏で検討、相談 => 返答 というのは不安にするのでダメ。遅い
• とにかく各メンバーには、それぞれの得意なところでパフォーマンスを発揮してもらうため、余計な雑務系タスクはPMが可能な限り拾う
  • ちょっとしたPRはいちいちブランチ切り替える手間があるのでPMがやる(メンバーの集中力をなるべく切らさない)
  • ちょっとした仕様の質問は、全部PM(僕)にぶん投げてもらってPMが調整して、結果だけ伝える(先方とのやりとりに無駄な力を使って欲しくないので。敬語とかしっかり使って文書作成とかだるいよね。)
• メンバーの習熟度に応じたタスクの振り方をする
  • 経験が浅い人には「このタスクをお願いします。設計はこんな感じで、名前はこれで、〜〜〜」と細かく伝える(色々とわからないことが多く、手が止まってしまうことが考えられるので、なるべくレールを敷いてあげる)
  • プロ(ベテラン)には「この辺XXくらいまでにお願いします。資料はこれです。XXの点だけ先方の要望なので仕様通りでお願いします」だけで細かいことは全てお任せする(何も決めずに任せてしまった方が動きやすい)
• 仕様で困ったことがあればPMに聞いてくれと言う
  • メンバーがいちいち資料探しする時間がもったいない
  • PMなら全体の仕様が割と頭に入っているはずなので、聞いてもらった方が色々早い
  • その場でわからなくても、「あの辺に書いてあるはず」と当たりくらいはつけられるはずなので、やっぱり早い
• ただ、あまりPMが重い開発タスクを持たない
  • MTGとか仕様調整とか開発以外のタスクが多いので、ロックしてしまう可能性がある
  • 理想はPMがハイパー暇(何も持ってない)な状態で勝手に開発が進む状態

こんな感じで動けばよかったと思ったところ

• 複数選択できるもの(マスタが必要で中間テーブルで管理するようなもの)は早めにリストアップしてもらった方がいい
  • 作るのも消すのも結構面倒なので、なるべく後で変更ないようにした方がいい
  • 今回変更がありまくって、作ったのに消したり、やっぱり必要そうだから追加したりしてハイパーストレスだった
• どうしても開発が楽になるような仕様とかを求めてしまっていた気がするので、「ちょっと調整必要だけど、こうなってると運用が楽になりそう」みたいな視点が抜けていたように思う。これは圧倒的に反省すべき点だと思う
  • 目指すべきは「スムーズに開発できて、余裕を持って納品できること」ではなく、「リリース後にユーザーや先方に便利に使ってもらえて、売り上げをあげられる」アプリなので、明らかに改善した方がいい点は、多少工数かかってもやるべきだし、提案すべき
  • とはいえ納期との兼ね合いがあるので、「色々はい！やります！って言ったけど、納期に間に合わなかった」というのは絶対に回避しなければならない

作っておいた方がいい(よかった)資料

• スケジュール管理シート
  • 必須資料だけどとにかく作るのが難しい
  • とりあえず必要そうなのは
    • 開発するタスク一覧(githubにissue立ててリンク貼っておくとよい)
    • 各タスクに見積もりをしたポイント(結構人によるけど、1pt = 1日がわかりやすくていい)
    • 見積もりポイントの合計を、「毎週これくらいのポイント消化できるだろう」という数値で減らしたグラフ(理想線)
    • 「実際にどのくらいポイント消化できたのか」というグラフ(実績値の線)
  • 開発メンバーに入力してもらうので、なるべく迷いなく入力できるようになっていると好ましい
    • スケジュールシートの入力に工数がかかるとか本末転倒なので内容はよく考える
    • しかしあまりシンプルだと工数管理できなくなるというジレンマ
  • 未だにどんなシートにすればいい感じに使えるのかわからないので、知見がある方おしえてください
• 質疑応答シート
  • 先方と無限に仕様の質疑のやりとりをするので、それをまとめておくもの
  • 質問番号、質問内容、質問者、回答者など、必要そうなものを書いておくと良い
  • 回答が保留されて回答が空欄だらけになりがちなので、必ずMTGで全ての空欄をチェックする機会を作る
  • 歴史の改竄されると怖いのでgoogleスプレッドシートなどを推奨
• UI
  • 今回はAdobe XDを使った(見た目がわかればFigmaとかでも何でもよい)
• DB設計図
  • 今回はdraw.ioを使った(これもわかれば何でもよい)
• MTGアジェンダ
  • いわゆる議事録
  • MTGで話して決まったりしたことを書いておく
  • googleドキュメントで書く場合、1つのファイルの中に、日付を区切って書いていくのがいい気がする(検索性的な意味で)
  • 賢いからgoogleドライブの特定のディレクトリにあるドキュメントの内部まで検索してくれるけど、いちいちファイル開いたり閉じたりするの面倒だし
  • 歴史の改竄されると怖いので(ry
• 企画書
  • 開発の背景(現在の課題)、目的、使用技術、スケジュールの予定あたりを書いておく案件概要的な書
  • 先方が作っているならそれをもらってもよい(社外秘だったら↑の項目くらいは聞いてPMがまとめておく)
  • 新規メンバー受け入れ時に見せると、どんな目的があってどんなアプリを開発しているのかが一眼でわかってもらえる(ように書いておく)
  • あとMTG重ねると方向性を見失いがちなので、時々企画書を振り返っておかしな方向に向かってないかチェックするとよい
• 開発メンバー受け入れのためのesaとか
  • 前提知識0の人が入ったときに、スムーズに開発に入ってもらうための書
  • メンバーに何をやって欲しいのか、開発のルールについて(gitの運用とか)、ちょっと変わっている仕様についての説明、などなど、開発に入るに当たって知っておいて欲しいことを書いておく
  • ↑の企画書を最初に見せると「どんなことをこれからやっていくのか？」を最初に把握できるのでよい