独学でプロジェクトマネージャーを1年続けるために気をつけていたこと

こんにちは。今月でプロジェクトマネジメントを主力事業にして1年が経ちました、りゅうじです。

企業に勤めたわけではなく、初回から業務提携でオフショア開発に参画していました。今思うと綱渡りはなはだしいチャレンジだったなといつもながらとはいえ痛感していました。

今回は独学でもプロジェクトマネージャーを1年間以上継続して担当できるためにやってきたことを共有しようと思います。近いうちに仕事の獲得方法についても1記事かければいいなと考えていたりします。

俯瞰で全容を知ることから

プロジェクトマネージャーをするにあたって前提といってもいいのですが、「経験したことのないプロジェクトを担当する」のが当たり前にあります。この一年で初めて経験したこととして

• 民泊系アプリ
• MAツールに予約管理システムを組み込み
• オンラインサロンのアプリ
• 音楽配信アプリ

モバイルアプリが多いですね。エンジニアをしている頃はWeb系のアプリケーション開発が多かったので、プロジェクトマネージャーをするにあたって未経験となるモバイルアプリ関連書籍から知識を実際に入れることからはじめました。

キャッチアップの濃密さ

1年のうちキャッチアップの大半は独学でやってきました。業務提携しているパートナー企業がモバイルアプリや業務システムの開発を軸に展開していましたので必然的にそういった技術本、電子書籍やUdemy講座を一切積ん読せず終わらせていくと技術も知識も山積みされました。多分1年で技術書100冊分くらいは買ってました。エンジニアやっていた頃の10倍は買い込んでいたので技術も知識も本業エンジニアやってる頃より獲得できました。実際に身銭を切ってやりきるのが1番集中できるような気がします。

1週目を読破するのに時間をかけないことをこことがけていましたので、長くても1冊30分を意識していました。理解度としては30%もあれば十分かなとういう感触です。本屋に行くと1回で30冊くらいは読み込んで1冊買うくらいのペースでいましたので1年続けると膨大な量になります。

続いてすぐに得た知識をつかって実装をしていきます。ここでは本の通りにやってしまいがちですが、設計を画面遷移から自分で立てます。自分で考えてわからない点だけ本で復習しながら進めるというやり方でなんども読み返しながら自分のものしていきました。

コミュニケーションは定性表現

国内外は関係なくコミュニケーションが上手くないなって方はだいたいが「会話に主語がなく、句読点が多い文章書きがち」です。英文になると特に長文って書いてる人も意味わからなくなりやすいんですが、日本語は気づきにくい構造だったりします。一つの会話に主語を一ついれることによって句読点が連なるのを防ぎますし、読みやすくなります。

同じ内容を繰り返し議論するようでしたら上のやり方で足りていないのかもしれません。そういう時は依頼内容を順を追って箇条書きにした方が良かったです。1から順番に1つの機能動作を書く、それでも伝わらない時は簡単な図解を書く方がスムーズです。

ここで注意点としてzoomなどの映像でコミュニケーションをとろうとすると記録に定性の情報が表現されないことが起こりますので開発がスタートするまでは特に厳に慎んだ方が良かったです。むしろこの一年間はzoomでの打ち合わせ0でやりきれたのは訂正表現としてドキュメントにテキストや図解を残すことを徹底した点が大きく作用していると考えます。

初期設計はテキストより図解

システム開発をするにあたり半年ほどはGoogleスプレッドシートを使っていました。これだと最初からおおよその要件が決まっているプロジェクトは良いのですが、一から要件を書き出さないといけないプロジェクトになると途端にやりづらくなりました。

対策として全体の抜け漏れはfigmaを使うようにしました。まずは全ての機能（と思われるもの）をリストアップします。機能が変わるたびに縦に連ねていき、横軸は機能の画面遷移です。リストアップが終わったら各機能ごとに画面遷移を完成させていくのですが、機能単位でまとめていると開発ステージに進んでもデータの動きが確認しやすくなり工数管理も設計しやすくなります。

ここまで完了してからDBやAPI設計を織り込んでいくと抜け漏れがほとんどなくなりました。

Jiraでプロジェクト進捗の管理

1年前はTrelloでプロジェクトの進捗管理をしていました。動作が軽いので使いやすかったのですが、問題としては「どの作業にどのくらい時間と工数がかかっているのか分かりづらい」ことがありました。そこで同じAtlassian社製のJira Softwareに変更しました。

Jiraではアジャイル開発を進めようとしていましたが、チームの成熟度もありアジャイルのまま導入するのは難しい状況でした。そこでスプリント=同一期間で出来上がったものを観測するやり方ではクライアントへの報告にもムラが出やすかったため、スプリント単位を開発ステージ単位で分割して達成できたかどうかを判断する形式をとりました。

最初で全てのタスクを書き出して進捗を見ていくウォーターフォール型でもJiraは運用しやすかったです。アジャイル開発できるのがチームとしてはありがたいですが予算の確保をする段階で説得材料をつくるためには設計をある程度完了させておくウォーターフォール型というのもクライアントにとって必要な要件だと思います。

プロジェクトマネージャーとして経験が浅い時はチームの対応スキルや進捗度合いを計測しやすい環境を作るのが先決だなということでJiraに変更しましたが、1年経った今でも変更の決断は良かったなと感じています。

まとめ：新しくスタートして長続きさせるには変化対応力

関わる段階に合わせて説明してきましたが、1番大事なこととして変化対応力があります。プロジェクトマネージャーとして仕事をする時は「同じプロジェクトは2度と存在しない」ということが確定しています。都度、自分が変化し続けてプロジェクトに即した対応力を作っていくことが重要で、そのためにも専門領域を勝手に自分で決めてしまわないことも同じくらい重要かもしれません。