■ 環境について
いまいる会社は、できてから日が浅い、少人数のスタートアップです。
オフィスはなくフルリモートで、案件ごとに外部のパートナーと体制を組んで進めます。分業がほとんどないので、一人が受け持つ範囲がとても広い会社です。
一方で、担当している案件のクライアントは、上場企業や、業界で名前の知られた大手企業です。
業界は、出版・メディア、医療・美容、エネルギー、クラウドインフラ、旅行、教育。
コーポレートサイトのリニューアルもあれば、新しいサービスの立ち上げから入るものもあります。
このギャップが、この数年でいちばん自分を鍛えたところだと思っています。
■ マニュアルがない会社で、大手の基準に合わせる
できたばかりの会社なので、決まった型や業務マニュアルは、まだ整っていません。
一方で、求められる品質の基準は高い。
こちらの体制が小さいことは、クライアントには関係ありません。
だから、案件が決まるたびに、調べるところから始まります。
・その業界の前提（医療広告のルール、エネルギー、クラウドインフラなど）
・その領域の型（IRと開示、人的資本、ブランディング）
・進め方の標準（PMBOK、Webプロジェクトマネジメント標準）
「知らないので分かりません」が通らない相手なので、提案の場までに、話が噛み合うところまで持っていく必要がありました。
正直に書くと、間に合わせるために相当な時間を使った時期があります。
ただ、そのとき覚えたやり方は、そのつど社内のドキュメントに落としてきました。
次の案件では、そこから始められるようにするためです。
いまは、読んだ本や調べたことを手順書にする作業を、仕事の一部として組み込んでいます。
■ 具体的に、どう回してきたか
- 承認フローで詰まったので、制約のほうをドキュメントにした
ある案件で、本番環境へのリリース時に、クライアント側の承認フローが詰まりました。
誰がいつ確認するのかが決まっておらず、リリースが近づくたびに調整で時間を取られる状態でした。
やったのは、催促ではなく、環境ごとの公開制約を全部書き出して、先方と合意を取り直すことでした。
どの環境で何が確認できるのか。承認は誰が、いつまでに出すのか。
それをドキュメントにして、前提としてスケジュールを引き直しました。
以降のリリースでは、障害が出ていません。
- 追加要件を、見積の差分に翻訳した
別の案件では、進行中に要件が増えました。
そのまま受ければ予算に収まらないし、断れば必要な機能が作れない。
やったのは、追加された要件を既存の見積との「差分」として洗い出し、「どの機能を、どのフェーズで作るか」という提案に組み替えることでした。
全部を一度に作るか作らないか、ではなく、順番の話に変える。
これで、先方も社内も判断できる形になりました。
- 判断に関わる要件は、ヒアリングの前に技術側へ渡した
要件の中に、データベースの設計に触れるものが混ざっていることがあります。
それを知らずにクライアントにヒアリングすると、「できます」と言ったあとで覆ることになる。
なので、ヒアリングの前にエンジニアへ先に相談する手順を挟みました。
確認の順番を変えるだけで、仕様が決まったあとの手戻りがかなり減りました。
■ 難しかったこと
いちばん難しかったのは、判断の「答え合わせ」に時間がかかることでした。
少人数で、しかも案件ごとに組む相手が変わる環境なので、
自分の判断が合っていたかどうかは、
たいてい、あとになってからしか分かりません。
その代わりに身についたのが、「判断を残す」という習慣でした。
なぜそう決めたのか、何を見て決めたのかを書いておく。
そうすると、外れたときに「どこで外したか」を自分で追えます。
合っていたときは、次に同じ形が来たときに使えます。
■ この環境で身についたこと
ひとつ挙げるなら、「決まっていないことを、決められる形にする」という感覚です。
型が用意されている場所では、その型を正しく使うことが仕事になります。
型がない場所では、型を作ることから仕事になる。
案件の途中で状況が変わったとき、誰かが決めてくれるのを待つ、という選択肢がありませんでした。
だから、変わったときに何をどう決め直すかを、先に考える癖がつきました。
■ これから
次は、チームがある場所で、この経験を使いたいと思っています。
ひとりでやってきたことを、ひとりで続けたいわけではありません。
体制がない状態を経験したからこそ、体制がある場所で、何を整えれば人が動きやすくなるかが、少し分かるようになった気がしています。
