株式会社マネーフォワード
Group Management Solution本部
プロダクト戦略部部長
1979年9月4日生まれ（44歳）
千葉県出身
・
埼玉県在住
早稲田大学政治経済学部卒
人と関わることに抵抗がなく相手への共感能力も高い。
仕事に対して誠実に取り組むため周囲からは頼りにされている。
しかし想定していないイレギュラーな事態に直面すると、動揺したり不安になったりすることも。
業務に対してはこだわりを持って取り組むことが多く、従来のやり方や形式を重んじる傾向がある。
持ち前のプロ意識で目の前の課題を着実に解決していく力強さを持ち合わせている。
会計士受験生時代
満を持して試験に臨んだ年に、本番大コケをして落ちるという経験をしました。そのため、次の一年は「絶対に落ちないためにはどうするべきか」を研究して（結局は基本の強化でしかないのですが）、ようやく合格できました。
当時としては「１年遠回りしたな」という感じでしたが、その１年で素晴らしい友人を作れたりもしたので、今では「あの時、落ちてよかったな」と思っています。
また、自分の字が汚く読みずらかったので、この1年の間に手書きノートをパソコンでレジュメ化したことが、この後の専門学校での講師生活に役立ちました。
専門学校講師時代
私の合格年次は監査法人就職不況の時期で、中堅監査法人でも書類選考でかなりの数が落とされてしまうような時期でした。また予定より受験生期間が長引いたことにより金銭的にも厳しかったので、合格発表を待たずに大原簿記学校での講師として勤務を始めました。
講師としては簿記論、監査論を担当しました。通常、監査論のような理論科目の講師を新人がやることは少なかった時代なのですが、受験生時代のレジュメを使うことができたので比較的スムーズに講師生活に馴染めたと思っています。
監査法人時代
監査法人の就職事情も解消したころに、あずさ監査法人に入所しました。講師生活を挟んでいますので、合格年次はズレていたのですが、同期仲間が欲しかったので新人として入所させてもらいました。
この時の同期仲間とは、今でも家族合同でスキーやキャンプに行ったりするので、いい選択だったなと思っています。
監査法人キャリアは次の章で詳述するので、細かいところは割愛しますが、SEC上場基準での複数会計基準対応の監査、大企業でのグループ監査、内部統制監査などを経験しました。
連結会計システムのパッケージベンダー時代
内部統制監査の立上げ時期に監査調書作成業務をラクにするためのExcelマクロを作った経験（次章にて詳述）から、IT業界に興味を持つようになり、監査法人からのネクストキャリアは連結会計システムのパッケージベンダーである株式会社DIVAを選択しました。
当時は東証２部に上場したばかりの会社でしたので、ややベンチャーチャレンジ的な要素もあったと思います。そこから１0年以上在籍して一通りの仕事は体験しましたが、主だった経験を下記に列挙してみます。
連結パッケージ用テンプレート開発
主力システムのIFRS対応の上流要件定義（主に包括利益対応）
連結決算業務のアウトソースビジネス立上げ
管理連結用プロダクトの企画・開発・コンサルタント
各種のグローバル連結プロジェクト
IPO支援での初めて連結決算業務支援
こんな感じで色々やりましたが、いわゆるプロジェクトマネージャー（PM）業務が一番多かったと思います。
多くの期間で管理職も兼任していましたが、ほぼ常にプレイイングマネージャー状態で現場に出続けていた感覚です。
クラウド会計システムのプロダクトマネージャー時代（現職）
DIVA社でもそれなりに色々チャレンジはさせて頂いていましたが、「成長企業向けのクラウドプロダクトを作りたい」と思うようになり、株式会社マネーフォワードにお世話になることにしました。
これまで積み上げてきたキャリアの結果、連結会計に関しては、監査、内部統制構築支援、システム開発、システム導入、活用コンサルタント、連結決算代行、IPO支援とあらゆるポジションからの関与経験を持っている状態になっていましたので、この経験を活かして、連結会計のクラウドプロダクトの０→１をプロダクトマネージャーとして担当しました。
クラウドプロダクトならではの作り方へのアジャストや、営業手法の切り替えなどの壁を乗り越えながらではありますが、2022年の12月のリリース以降、順調にユーザー企業を増やしており、ユーザー様を集めたリリース1周年記念イベントを開催するところまで来られました。
なお、このプロダクト（クラウド連結会計）では「グループ経営で未来を創る、やさしい連結会計」というプロダクトビジョンのもとに、成長企業で孤独に連結業務を行っている会計士の方々を孤独から解放することを目指していたりもします。
ですので、この記事の読者の方や、ご友人に「連結会計業務を抱えているなぁ」という会計士の方がいれば、お気軽にご相談をお願いいたします。
監査法人時代の最初はごく普通の新人キャリアを歩み、残高確認状の回収や、証憑突合、棚卸立ち合い、現金実査、開示チェック等の監査業務を経験しました。
特徴的だったところを挙げるとすると、数年間採用を絞っていた反動で先輩方の層が薄く、割と早めに多くの企業のインチャージ（主査）を経験できたことと、日本を代表するようなグループ企業での監査（日本基準＋米国基準の並行開示あり）を経験できたことと、内部統制黎明期で内部統制監査の先行適用を経験したことあたりかな、と思います。
監査法人時代の仕事でその後のキャリアにつながっているなと感じるのは①インチャージ業務、と②内部統制監査の経験 なのでその2つを掘り下げて書いてみます。
インチャージ業務
インチャージ業務で磨いたスキルは極論「段取り」スキルでした。監査繁忙期に人が足りないのは目に見えているので、いかに閑散期に貯金を作れるように準備できるか、重要なリソースを獲得するためにいかに根回しできるか、がポイントでした。会計のテクニカルな論点は自分でやらなくてもできる人がいくらでもいるので。
ちなみに、私はワーカホリックタイプではなく、「いかにプライベートを充実させるか」を考えるタイプでしたので、どうやったら早くラクに終われるかに知恵を集中していたと思います。それがこの後の内部統制監査での工夫やキャリア選択につながっていきました。
内部統制監査の経験
エンロン事件直後の2000年代、出来上がった数値を見る財務諸表監査だけでは財務報告の信頼性は担保できないとなり、内部統制監査が始まりました。
業界としては、まずは海外企業から先行で始まり、日本はその後で、という話だったのですが、自分の担当しているクライアントが米国上場基準を満たす必要があり、日本企業がまだ対応していない時期に内部統制監査に先行で取り組むことになりました。
受験生時代に何も勉強していない内部統制監査に、就職したらいきなり放り込まれるという構図。しかもクライアント様のセリフと心の声は「先生、教えてください！（なんもわからないので、全部教えて。経験年数なんて聞いてない。そして「問題ない」って言って早く帰って。）」という状況。
就職2年目に内部統制監査に単身出張で放り込まれた時は我ながら良く乗り切ったなと思います。
この時、チーム内で監査調書をWordで作るかExcelで作るかが一大議論になりました。今考えるとカオスな議論（他の選択肢？）でしたが、当時は死活問題でした。Wordで作るヒトとExcelで作るヒトがいて、バラバラで収集がついていなかったのです。
グループ各社で同じ手続きをしてきているはずなのに報告内容、形式がバラバラで比較分析、集約もできず、クライアントからも苦情を言われていました。
この時、危機感を現場メンバー（調書をつくるスタッフレベル）で議論した結果「その後の集約を考えてExcelでやる。報告様式に体裁整えるのはExcelでも不可能ではない。Excelで頑張る」に決定されました。
この決定に従って、各メンバーが全国各地でExcel監査調書を大量生産する業務が始まるのですが、内部統制監査は文書の記述が多く、監査調書を作成するたびにクライアントの業務だとかコントロールの文章をコピーして貼り付けるという作業が大量に必要になりました。
Excelなので印刷時のレイアウトなどが崩れやすく、報告用のシートに転記したりとこれまた転記、転記、コピペ、コピペを繰り返す状態でした。（当時は監査調書の電子化も進んでおらず、監査調書は印刷して出力が必要でした）
と、そんな感じでコピペ、コピペに追われ「忙しい、忙しい」と仕事に明け暮れていたのですが、とある日、嫁（理系）にぼそっと「それ、人間がやる仕事じゃなくない？」と言われた時に、「ん？確かに？」となり、「じゃ、何使えばできそう？」という話をして、Excelのマクロ（VBA）を教わりました。
そこから、自分がラクになりたい一心で、必要な転記業務は全てボタン一つで実行できる監査調書作成マクロを作り上げました。作成は1ヶ月程度だったと思います。
この監査調書作成マクロ、当時は劇的に業務効率を改善したと自負しています。担当クライアント限定での使い道ではあるのですが、親会社だけで50近い業務プロセスがあり、それに加えて主要子会社でも同じ監査があったので、繰り返しの利用回数が非常に多く、人によってバラバラになりがちだった監査手続の均一化にもつながりました。上司にも、同僚にも部下にも感謝され、クライアントにも感謝されました。
なお、このマクロ作成後1年くらいで自分は退職するのですが、ソースコード1行1行に目的等を書いておいたおかげか、8年ほどメンテナンスしながら使われたみたいです。（さすがに監査調書電子化になって不要に）そして、当時の上司が理解のある上司で、マクロ作成代を残業代に乗せて支払ってくれました（十万円程度ですが）。
この時に「関係者全員に感謝されて、その対価でお金をもらう」という経験をしたことで、「システムを作る」という仕事に興味を持ち、システム業界への転身をすることになりました。
転職先自体は他にもいろいろ検討したのですが、やっぱりこの体験からシステム業界に惹かれてしまいました。
クラウドプロダクト業界におけるプロダクトマネージャーの仕事はかなり多岐にわたります。というのもプロダクトマネージャーの位置づけ自体が「プロダクトの成功のためになんでもする人」になっているので、できそうなことはなんでもやるというスタイルになります。ある意味、ベンチャー企業の立上げに似たような業務範囲になると思って頂いたほうがイメージしやすいかと思っています。
とはいえ、大きく分けるとプロダクト企画、プロダクト開発、マーケティング、営業、導入支援、運用支援となるかと思いますので、それぞれの内容を下記に列挙してみます。
プロダクト企画
時代背景、市場の状況、自社の状況、競合他社の状況を大局的に分析して、作るべきプロダクトの戦略を決定します。
この戦略を元に必要なリソースを獲得したうえでプロダクトの機能開発に進みます。ベンチャー企業だと投資家向けに説明するような内容を社内で説明するようなイメージになります。
プロダクト開発
エンジニアからプロダクトマネージャーになった人の中には、プログラム書くところまで自分でやるような方もいますが、私の場合は業務のスペシャリストとしてプロダクトマネージャーをやっているケースですので、プログラムや詳細設計には手を出しません。
私のような場合は、ユーザー業務をどのようにシステムで実現していくかを細かく分解してエンジニアに伝えていくことと、できあがった機能を繰り返しテストすることが仕事になります。
いわゆるアジャイル開発やスクラム開発といった開発手法を前提に「限りある工数を如何に有効な機能開発につなげるか」を様々な方法で検討、その決定に従って機能を開発をリードしていきます。
この際、エンジニアの方々に機能が必要な背景やこだわって欲しいポイントをいかにうまく伝えられるか、が重要なポイントになるので、色々な工夫が必要になります。
マーケティング
せっかく作り上げたプロダクトも市場に認知されなければ意味がありませんので、プロダクトの提供価値や特徴をターゲットユーザーに届けていくような活動が必要となります。一番わかりやすいところで言うと、セミナーの登壇になります。とはいえ、毎回同じセミナーをやっても認知は拡大できませんので、共催セミナーを実施してくれるパートナーを探したり、最新の機能の特徴を生かしたセミナーを企画したりします。
営業
興味を持ってくれたお客様に、会社紹介、プロダクト紹介をしつつ、お客様の課題をヒアリングして、プロダクトを利用した課題解決方法を提案します。お客様が購入を意思決定するためには、「自分たちの課題を解決できる」ということにしっかりとした納得感が必要なのは、クラウドプロダクトでも変わりません。
特に連結会計のプロダクトは操作担当者（経理メンバー）と購入意思決定者（グループ全体のCxO）が違うことが多く、機能だけに終始した営業ではうまく結果に結びつかないことが多いです。
お客様のグループ全体を俯瞰的に捉えた課題解決方法を提示する意識で営業活動を行う必要があります。
導入支援
プロダクトの導入を決めてくれたお客様向けにプロダクトの初期設定を行ったり、使い方の説明など行います。
かなりの部分が事前準備されているツール、ヘルプページでカバーできるようにしてはありますが、やはりお客様の満足感を上げていくためにはきめ細かいサポートが必要で、時に親会社側の課題だけでなく、子会社様側からの困りごとを聞いて課題の解決方法を提示するような動きも必要となります。
運用支援
導入支援完了後はお客様での運用となりますが、システムへのQAや困り事がヘルプページやメールで寄せられてきますので、困りごとの解決方法をその都度検討していきます。
メール等でのQAに限らず、機能開発でカバーする場合や、場合によっては他のプロダクトや他のサービス提供会社（コンサルタント、アウトソーサー、外部ツール提供会社等）を紹介するなど、様々な方法でお客様の課題を解消していきます。また、そういった動きを自分だけでなく、チームとして動けるように組織に働きかけていくようなことも必要となります。
