公認会計士、プロダクトマネージャーになる
こんにちは！「マネーフォワード クラウド連結会計（以降“クラウド連結会計”）」のプロダクトマネージャーをしている、HORIと申します。
先日、クラウド連結会計のプロダクトビジョンを紹介させていただきましたが、「で、あなたは何者？」と思われた方や、「公認会計士がプロダクトマネージャー？」という興味を持ってくださる方もいるかもしれないと思いましたので、自分がここに至るまでのストーリーを綴ってみます。
なお、今回書く範囲は「公認会計士受験生時代」からに絞りました。「なぜ、公認会計士を目指したのか」はまた別の記事にしようと思います。
公認会計士受験生時代
公認会計士受験生時代（当時の用語では公認会計士２次試験）の話を少しだけしておくと、そんなに順風満帆に合格したわけではなく、自信満々で試験に臨んだ年に、まさかの本番大コケをして、落ちるという経験をしました。
そのため、次の一年は「絶対に落ちられないというプレッシャー」→「絶対に落ちないためにはどうするべきか」を研究して（結局は基本の強化でしかないのですが）、ようやく合格したという経験をしています。
結果的には１年遠回りしましたが、その１年で素晴らしい友人を作れたりもしたので、今では、「あの時、落ちてよかったな」と思っています。（ただ、合格後数年は定期的に不合格になる夢を見ましたが）
なお、パソコンでレジュメを作ったり（自分の手書きの字が汚くてノートをとっても読めないとう問題があった）とか、受験生時代のころから便利であればITを取り入れるというスタンスではありました。（プログラムを書くような理系ではなく文系人間です）
専門学校講師時代
当時の公認会計士業界の採用ルーティーンは、夏の試験～秋の合格発表～初冬に監査法人入社で、それまでは試験を受けた受験生は遊びと勉強半々くらいで待つというスタイルが一般的でした。
ただ、自分の合格した年は監査法人が採用を大幅に絞っていたという事情と、上記の通り「崖っぷち」だったので、自分は「合格発表前から稼ぐ」方法を模索しました。
幸い、専門学校の会計士講座の講師職に採用していただき、１年半ほど講師の経験をしてから、監査法人に入るというキャリアになりました。
ということで、実はここでも回り道をしていますが、この結果、自分は専門学校講師の同期人脈と、監査法人時代の同期人脈と２つの同期人脈を持てることになり、今となってはいい選択だったなと思っています。
ちなみに、講師時代のスキルでプロダクトマネージャーに活かせているな と思うのは「あるべき姿のロジックの組み立て、説明」、「数値サンプルデータの作成」、「人前でしゃべるスキル」など結構あります。ビジネスマナーについても、先輩講師に「余計な失点をしない。自分のため。」という真髄を教えていただきました。
どんな仕事でも真剣に向き合っていれば、プロダクトマネージャーの仕事に生きるスキルになっていくと思います（プロダクトマネージャーはプロダクトの成功のためになんでもする人なので、色々なスキルが役に立ちます）
監査法人時代
いわゆる４大監査法人の一つに入り、ごく普通の監査法人の新人キャリアを歩み、残高確認状の回収や、証憑突合、棚卸立ち合い、現金実査、開示チェック等の監査業務を経験しました（一つ一つ掘り下げると色々な記事が書けそうですが、それはまた別の機会に）。
特徴的だったところを挙げるとすると、数年間採用を絞っていた反動で先輩方の層が薄く、割と早めに多くの企業のインチャージ（主査）を経験できたことと、日本を代表するようなグループ企業での監査（日本基準＋米国基準の並行開示あり）を経験できたことと、内部統制黎明期で内部統制監査の先行適用を経験したことあたりかな、と思います。
なお、監査法人時代の仕事でプロダクトマネージャーにつながっているなと思うのは①インチャージ業務、と②内部統制監査の経験 なのでその2つを掘り下げて書いてみます
インチャージ業務
社内研修か何かだったと思うので、出典はわからないのですが、確かインチャージのあるべき姿が「監査を成功に導くためになんでもする人」だった覚えがあります。プロダクトマネージャーと変わらないですね。立場とか必要なスキルが違うだけです。
そして、インチャージ業務に必要なスキルは極論「段取り」スキルでした。監査繁忙期に人が足りないのは目に見えているので、いかに閑散期に貯金を作れるように準備できるか、重要なリソースを獲得するためにいかに根回しできるか、がポイントでした。会計のテクニカルな論点は全員会計士の世界なので、自分でやらなくてもできる人だらけなので。
ちなみに、自分はワーカホリックタイプではなく、「いかにプライベートを充実させるか」を考えて頑張るタイプ（これについては別記事でナレッジ集作成しました）なので、どうやったら早くラクに終われるかに知恵を集中していたと思います。それがこの後の内部統制監査での工夫、ひいては転職につながります。
内部統制監査
時はエンロン事件直後の2000年代、出来上がった数値を見る財務諸表監査だけでは財務報告の信頼性は担保できないとなり、内部統制監査が始まりました。
業界としては、まずは海外企業から先行で始まり、日本はその後で、という話だったのですが、自分の担当しているクライアントが米国上場基準を満たす必要があり、日本企業がまだ対応していない時期に内部統制監査に先行で取り組むことになりました。
受験生時代に何も勉強していない内部統制監査に、就職したらいきなり放り込まれるという構図。しかもクライアント様のセリフと心の声は「先生、教えてください！（なんもわからないので、全部教えて。経験年数なんて聞いてない。そして「問題ない」って言って早く帰って。）」という状況。
就職2年目に内部統制監査に単身出張で放り込まれた時は我ながら良く乗り切ったなと思います。
当時、チーム内で監査調書をWordで作るかExcelでつくるかが議論になりました。今考えると、？？？な議論（他の選択肢？）でしたが、当時は死活問題でした。Wordで作るヒトとExcelで作るヒトがいて、バラバラで収集がついてませんでした。グループ各社で同じ手続きをしてきているはずなのに報告内容の比較分析、集約ができないのです。結論として、「その後の集約を考えてExcelでやる。体裁整えるのはExcelでも不可能ではない。Excelで頑張れ」に決定されました。
この決定に従って、各メンバーが全国各地でExcel調書を大量生産する業務が始まるのですが、内部統制監査は文書の記述が多く、監査調書を作成するたびにクライアントの業務だとかコントロールの文章をコピーして貼り付けるという業務が必要になりました。
Excelなので印刷時のレイアウトなどが崩れやすく、報告用のシートに転記したりとこれまた転記、転記、コピペ、コピペを繰り返す状態でした。（当時は監査調書の電子化も進んでおらず、監査調書は印刷して出力が必要でした）
と、そんな感じでコピペ、コピペに追われ「忙しい、忙しい」と仕事に明け暮れていたのですが、とある日、嫁（理系）にぼそっと「それ、人間がやる仕事じゃなくない？」と言われた時に、「ん？確かに？」となり、「じゃ、何使えばできそう？」という話をして、Excelのマクロ（VBA）を教わりました。
そこから、自分がラクになりたい一心で、必要な転記業務は全てボタン一つで実行できる監査調書作成マクロを作り上げました。作成は1ヶ月程度だったと思います
この監査調書作成マクロは当時は劇的に監査の業務効率を改善したと自負しています。自分のクライアント限定での使い道ではあるのですが、親会社だけで50近い業務プロセスがあり、それに加えて主要子会社でも同じ監査があったので、繰り返しの利用回数が非常に多く、人によってバラバラになりがちだった監査手続の均一化にもつながりました。上司にも、同僚にも部下にも感謝され、クライアントにも感謝されました。
なお、このマクロ作成後1年くらいで自分は退職するのですが、ソースコード1行1行に目的とかを書いておいたおかげか、8年ほどメンテナンスしながら使われたみたいです。（さすがに監査調書電子化になって不要に）
そして、当時の上司が理解のある上司で、マクロ作成代を残業代に乗せて支払ってくれました（笑）。とはいえ、10万円程度です。
この時に「関係者全員に感謝されて、その対価でお金をもらう」という経験をしたことで、「システムを作る」という仕事に興味を持ち、システム業界への転職をすることになりました。
（転職先自体は他にもいろいろ検討したのですが、やっぱりこの体験からシステム業界に惹かれてしまいました。監査の仕事は頑張ってもあまり喜ばれないことが多かったりするので・・・）
パッケージベンダー時代
システムの仕事に興味を持ったものの、プログラムを書くような理系スキルが強いわけではないので、会計スキルを活かすために「会計システムを作っているパッケージベンダー」に転職しました。
足かけ10年以上も在籍したので、一通りの仕事は体験しましたが、主だった経験を列挙してみると
連結パッケージ用テンプレート開発
IFRS対応の上流要件定義（主に包括利益対応）
連結決算業務のアウトソース事業立ち上げ
管理連結用プロダクトの企画・開発
管理連結プロジェクトのコンサルタント／PM
グローバル連結プロジェクトのコンサルタント／PM
IPO支援での初めて連結決算業務支援／PM
色々な仕事やりましたが、いわゆるプロジェクトマネージャー（PM）業務が一番多かったと思います、多くの期間で管理職も兼任していましたが、ほぼ常にプレイイングマネージャー状態だったと思います。
PM業務
理想のPMの定義がこれまた「プロジェクトの成功のためになんでもする人」だったと思います（笑）。
ただ、PMの場合はプロジェクトの目的の確認が一番重要でした。それこそ、プロジェクト始める前に「何を目的にプロジェクトを始めるのか」が最も重要。
なので「提案書の最初の1枚に魂を込める」のが自分が一番意識していた内容でした。課題一覧表とかスケジュールもよく作りましたが、結局は「目的あってこそ」の業務なので、目的を外さないことが一番重要だったと思います。
PMをしつつ、ユーザーの課題解決方法を考えると「新プロダクト作りたい」 となったことも何回もあったのですが、システム構成やターゲットユーザー、エンジニアリソース、投資回収期間の問題などがあり、新プロダクト開発へのハードルは非常に高かったです。
プロダクトマネージャーになる
近年のクラウドプロダクトは、「ドメイン知識のあるメンバーと、デザイナー、エンジニアをうまく融合してプロダクトを創っていく」という意識が高いのと、「ニッチな業務領域で最適なサービスを提供していくため、規模は小さく始める」という傾向にあるため、ドメイン知識を強みに持つヒトがプロダクトマネージャーとして活躍できる環境が整ってきていると思います。
自分はその機運に恵まれ、プロダクトマネージャー未経験ながら、一つのプロダクトの０→１のフェーズを任せていただけました。
幸いデザイナー、エンジニアの組織的なサポートに恵まれて、自分で画面デザインそのものやプログラムに手を出すこともなく、プロダクトリリースを迎えられました。（役割分担として最適な方法を選択した結果ではあります）
まだまだ不足機能だらけでやらなければいけないことは山積の状態ですが、プロダクトマネージャー未経験でも０→１のプロダクトをリリースするところまでたどり着けたということ自体が、上記の仮説を立証していると思っています。
自分としては、１つのプロダクトをリリースしてようやくプロダクトマネージャー1年生になれたと思っています。これからも様々な課題があがってきますし、目標はもっと先にはありますが、「プロダクトの成功のためになんでもする」というマインドを持って頑張っていこうと思っています。
最後に
「マネーフォワード クラウド連結会計」チームでは、一緒に未来を作ってゆくメンバーを募集しています。共感された方、我こそは！という方、気になった方は、ぜひエントリーをお願いいたします。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？