「誰でもできるけど誰もやらない仕事」をやり続けた7年間——マネーフォワード退職エンジニアが語る信頼の積み方

記事のサマリー（TL;DR）

• マネーフォワード在籍7年のエンジニアが、技術力ではなく「誰もやらない地味な仕事を拾い続けること」で技術広報→API基盤チームへのキャリア転換を実現
• 技術広報就任1年目でブログ年間投稿数を約50本→約100本（前年比200%）、投稿者数を27名→56名（前年比207%）に拡大し、半期MVPにノミネート
• 「拾う・埋める・公開する」の3型を継続することで積み上がるのは個別の実績ではなく「任せてみるか」と思われる信頼だという結論

社内で伸び悩むエンジニアが今日から使える「信頼の積み方」の実践論

この記事は、技術力が高くなくても・マネジメント志向でなくても、組織の中で信頼を獲得しキャリアを広げていく方法論として読める。日本のB2B SaaS・エンタープライズ系の開発現場では、技術的課題よりも「誰も担当しないタスク」や「情報発信の文化醸成」が放置されがちな組織が多い。

筆者が示す「誰でもできるけど誰もやらない仕事」の定義——「技術的難易度が低い・担当者不在・評価に直結しない・でも確実に誰かが困っている」——は、kintone・Salesforce・マネーフォワードなどの業務SaaS環境を持つ組織のエンジニアや情シス担当にも直接当てはまる。ドキュメントの整備、テックブログの移行、社内勉強会のファシリテーターなど、「あったほうがいいがオーナーがいない」タスクは組織規模を問わず存在する。こうしたタスクを拾い、実行し、可視化することが、次の大きな機会への地ならしになるという視点は普遍性が高い。

詳細

第1部：何を期待してマネーフォワードに入社したか

2020年1月、京都拠点にサーバーサイドエンジニアとして入社

筆者（ハンドルネーム：luccafort）は、ゲーム会社やWebの受託開発会社を経て2020年1月にマネーフォワード京都開発拠点へサーバーサイドエンジニアとして入社した。入社直前はRuby on Railsで民泊予約管理サービスの開発に携わっており、Rubyの実務経験は約1年、Goはほぼ未経験という状態だった。

入社直後に4つの目標を会社ブログで公開した。

1. Ruby/Rails力の向上（プログラミング能力の向上）
2. テックリード的な役割の構築（アーキテクチャ設計とトレードオフにおける意思決定力）
3. 京都拠点のGoエンジニア育成（ティーチング能力の向上）
4. レガシーフロントエンドのモダン化（苦手分野の克服）

「目標を立てること自体は誰でもできる。でも、それをわざわざ人が見える場所に書く人はあまりいない」——これが筆者にとって最初の「誰でもできるけど、誰もやらない仕事」だったと振り返る。

当時、筆者がマネーフォワードに期待していたこと

入社時の感想は「優秀な人が多い」。カンファレンス登壇経験者、技術的な議論で知られるエンジニア、自分が参考にしたブログの著者本人——そういった人材が揃う環境で、「大きな挑戦は技術的に優れた人が勝ち得る権利」と本気で思っていた。技術力以外で存在価値を示す方法が思いつかず、「技術力をもっと高めてからでないと挑戦できない」と考えていた。

第2部：マネーフォワードで何をやってきたか

そもそも「誰でもできるけど、誰もやらない仕事」とは何か

筆者が定義する4条件は以下の通り。

「③があるから誰も手を付けない。④があるからこそ、実行した際の貢献度は計り知れない」——この2つが同居するタスクを7年間探し続け、拾い続けた。

やってきたことを整理すると「拾う」「埋める」「公開する」の3つの型に分かれる。

1.「拾う」——誰の担当でもない仕事を引き受ける

テックブログをWordPressからはてなブログへ移行

「ブログプラットフォームの移行」は社内で何度も話題になりながら、オーナーシップを持って完遂する人がいなかった。最終的に筆者がこのプロジェクトを担当し、移行先の調査・記事インポート・過去記事すべてのリダイレクト設定を実施した。

実際にやると細かいところで何度も失敗した。サポート対象外のファイル形式、ファイルサイズの上限超過、低解像度の画像、リダイレクトパスの置換ミス——1本ずつ確認して、貼り替えて、リンクが切れていないかを検証する、派手さのない地道な作業だった。「ハイリスク・ローリターン」ではあったが、「誰かがやったほうがいい」状態で長く放置されていたため、着手からやり切るまでを完遂した。

技術広報としての活動を始めた

元々のきっかけは「発信の心理的ハードルが高すぎる」という課題意識だった。書ける人はいるのに書き出せない。個人やチーム単位での支援はあったが、成果を他チームへ展開する仕組みがなく、不定期開催になりがちで参加者が限定される悪循環があった。

技術広報が窓口となって定期的な場を用意し、取り組みを可視化したことで、2021年の実績は以下の通りになった。

この活動が評価され、半期MVP（Most Valuable Player）にノミネートされた。受賞は逃したが、「頼まれていない仕事が社内アワードの候補に挙がった」という事実が転換点になった。「プロセスをきちんと整えれば結果につながり、同僚の理解を得られる」という確信を得た瞬間だった。

2.「埋める」——空いている枠に自分から手を挙げる

得意分野以外での登壇に挑戦

Kyoto.js #22の登壇枠が空いていると知ったとき、社内に打診したが誰も手を挙げなかった。主戦場はバックエンドでフロントエンドは専門外だったが、Temporal API（当時提案中の新しいJavaScriptの日付・時刻API）について発表した。

「高度な専門性そのものがなくとも、知識をキャッチアップする力や課題を読み解く力が役に立つ場面がある」——必要だったのは、わからないことを調べて、自分の言葉で説明できるところまで持っていく作業だけだった。登壇テーマがあったから手を挙げたのではなく、手を挙げてから登壇テーマを探したという点が重要だ。

技術カンファレンスってなんですか？

マネーフォワードが初めて開催した技術カンファレンス「Money Forward Tech Day 2024」で、企画・推進の一部を担当した。最大の難題は実行そのものではなく、「どんなイベントにするか」というイメージの共有だった。カンファレンス経験の有無が参加メンバーによって異なる上、ベトナム・インドなど複数国の拠点を抱えるため、文化的前提がそれぞれ異なる。ドキュメントを何度も書き直し、イメージ図に起こし、あの手この手を繰り返して開催にこぎ着けた。

人間万事塞翁が馬

京都のRubyコミュニティ「Kyoto.rb」の読書会で、質問のハードルを下げる取り組みを導入したところ、新規参加者が発表に挑戦するという流れが生まれた。その流れの先で筆者自身が大阪Ruby会議03に登壇し、その登壇がまたKyoto.rbへの新規参加者を生む好循環が発生した。「誰かのための場をつくっていたつもりが、巡り巡って自分の機会になって返ってきた」という体験は、次の「公開する」の話にも直結する。

3.「公開する」——やったことを公開の場で宣伝し続ける

なぜ「公開する」のか

「拾う」「埋める」をやっている人は意外と多いが、「公開する」をやっている人は一番少ない。大童澄瞳『映像研には手を出すな！』の言葉を引用している。

誰も知らねえ店に、客が来るわきゃないんだ。

どれだけ「拾う・埋める」をやっていても、誰にも見えていなければ次の機会を任せる判断材料にはならない。「黙ってやっている仕事は、観測する誰かがいなければやっていないのと同じ扱いになる」というのが筆者の認識だ。

宣伝は自慢ではなく、次の相談を呼び込むための導線になる。「XXXをやっていた人」として認識されると、関連する話が向こうからやってくるようになる。

推奨する具体的なアクションは、個人の失敗を「仮説→検証→分析→考察」の順でブログにまとめること。生成AIがすぐに答えを出せる時代でも、「何を期待して・どこを誤解していて・どうすると良かったか」という学びの発信は、自分の記憶の定着という点で価値がある。

自分の知らないところで、発信は誰かに届いていた

2025年3月に企画した学生向けエンジニアMeetupでは、Go Conference 2024のスポンサー活動や、筆者が「自分の欲しいものがなかったから」という自分駆動のモチベーションで開催した前夜祭が、学生の応募動機になっていた。「発信は、届いたかどうかがすぐにはわからない。でも、届いていないわけではない」——これは覚えておいてよかったことのひとつだと筆者は言う。

積み上がったのは、実績ではなく「信頼」だった

技術広報時代の数字をまとめると以下の通り。

なお、記事執筆時点（2026年）では投稿数は落ち着いている。技術広報体制の変化、Zennなど他の発信先の普及、生成AIの登場、社内エンジニアの英語話者比率の増加など、複合的な要因が絡んでいると分析している。

2025年4月、筆者は技術広報から京都拠点のAPI基盤チーム（特に認可を担当）へ社内異動した。技術広報と基盤開発はやることがまったく違う。それでも異動が成立したのは、「積み上がっていたのが個別の実績ではなく、こいつになら任せてみるかと思ってもらえる状態だったから」だと分析する。

第3部：イメージしていたマネーフォワードと何が違ったか

挫折と苦悩。順風満帆だったわけではない

7年間で転職を2度検討した。

1度目：Goマイクロサービスをチームへティーチングするミッションで挫折。1PRに80以上のコメントがついても耐えたが、自チームへの持ち帰りで「Goの不慣れさ」と「複雑なビジネスドメイン」を同時に教えようとした結果、どっちつかずになりメンバーから不評を受けた。

2度目：技術広報として3年目に突入したとき、「来年も同じことをしている自分の姿が見えた」ことで「このままでいいのか」という疑念が湧いた。社内外のさまざまなポジション・経歴の人に相談を重ね、最終的にたどり着いたのが「どのような条件であれ、環境を変える力を持つ人材になること」という答え。そのためにはまだやれることがあると考え、マネーフォワードに残ることを決断した。

期待していたことの、答え合わせ

期待どおりだったこと：

• Ruby/Rails/Goを用いた大規模サービス構築から多様なプログラミングのエッセンスを習得
• 現在のアーキテクチャがなぜその設計になったかを考察する能力が鍛えられた
• 未知のアーキテクチャデザインを学ぶことで設計の選択肢の幅が増えた

いい意味で裏切られたこと：

• 価値を発揮するための前提だと思っていたポジションは、価値を発揮した後の結果にすぎなかった
• 価値を発揮する方法は1つではなく、どれを選択するかは自由

完全に誤解していたこと：

• 教わったメソッドを踏襲すれば理解されると思っていた→相手が何をわかっていて何がわからないかを整理する必要があった
• モダンな手法を取り入れることが目的化してしまい、本質課題の解決まで目を向けられていなかった
• わからなければ聞けばいいと思っていた→聞いてもいいが、それは自身の考えを放棄していい理由にならない

一番大きかったズレ

「機会は平等に開かれている。でも、それを掴む準備をしている人は、思ったより少なかった」

準備にどれだけ費やしたかが結果に直結する

7年かけてたどり着いた結論：

「誰でもできる仕事を、誰もやらないうちにやる」。そして、それを公開する。

難易度が低いので失敗しても損失が小さい。誰の担当でもないので誰かの領域を侵さない。確実に誰かが困っているのでやれば感謝される。公開すれば次の相談が向こうから来る。

中島敦「山月記」の「臆病な自尊心と尊大な羞恥心」を引用し、「誰でもできる仕事をやらないのも同じで、技術力や才能の問題ではなくプライドが邪魔をしているだけ」と指摘。「李徴に足りなかったのは、恥をかいても損をしない小さな挑戦の場だった。誰でもできる仕事は、まさにその練習台になる」と結ぶ。

おわりに

筆者が読者に残す、明日からできる1つのアクション：

今日やった小さな改善を、誰かが見ている場所に1行だけ書いてみてください。「ドキュメントのリンク切れを直した」でも「壊れていたテストを直した」でも構いません。

「ぼくの7年間は、その1行の積み重ねでできています」

退職は2026年9月末日を予定。記事公開時点ではまだ在籍中。