技術の裏付けで、提案から納品・運用まで一気通貫で伴走する

私は文系新卒未経験で入社してから、IT業界、エンジニア職の特色、当社の特色を肌で感じ、「営業と開発、両方できるエンジニア」になることを目標に行動してきました。

本論ではそう考えるに至った経緯、その目標を達成するためにこの5年間の経験でどのような工夫・改善をしてきたかを振り返ります。

そして最後に、これまでを踏まえて今後どのように成長して会社に貢献していくかを述べたいと思います。

それは、案件獲得から納品まで一気通貫で行える人材になり、能動的に売上を伸ばすことで私自身の価値を高めつつ、当社の利益拡大に貢献したいと思ったからです。

入社直後、プログラミング経験がなかった私は、同期のエンジニアが経験者だったこともあり、技術スキルのスタートラインが違う現実に直面しました。研修の頃からハンドトラッキングのような新しい技術を積極的に取り入れた開発をし続ける同期を見て、埋めようのないスキルの差を突きつけられました。「同じ技術の道で競っても、彼のようなエンジニアには追いつけないのではないか」。そう痛感すると同時に、彼と肩を並べ、自分ならではの価値を発揮するための「差別化」の戦略を考え始めました。

最初に、社内の先輩方がそれぞれどのような役割で活躍しているか、注目しました。ある先輩は学生時代の数学知識、経営層や先輩は前職の建設業経験、別の先輩はデザイン。様々なスキルや経験を背景に、活躍する先輩方を見て、「技術に他のスキルを掛け合わせる」という道に気づきました。

次に、どのようなスキルと掛け合わせて、成長していくべきか考えました。そこで私が目を向けたのは、「今の当社という組織がさらに成長するために、必要になりそうな役割は何か」という視点でした。先輩方がそれぞれの専門性で現場を支えている一方で、組織全体を見渡したとき、その高い技術力を発揮するための「場」を能動的に創り出せる人材がまだ少ないのではないか。どれほど優れた技術があっても、それを活かす場所がなければ、宝の持ち腐れになってしまいます。そこで仕事を作るスキルである「営業」に着目しました。

・当社の成長を加速させる営業

当社が仕事を受注する時、基本的にお客様からの相談を待つスタンスです。一方で、相談を待つ前にお客様とのやり取りの中で、潜在的な課題を探る、解決策を提案するといった、攻めの姿勢はあまり取れていません。

元来、IT業界は大手SIerが仕事を受注し、中小IT企業に割り振っていく、多重請負構造が多い業界です。この構造の中では、下流工程になればなるほど価格競争に巻き込まれやすく、主体的な利益コントロールが難しくなります。当社を今後さらに成長させるためには、従来の待つ姿勢に加えて、お客様への積極的な提案を行い、上流工程から自社で案件を獲得する攻めの姿勢が必要であると感じました。

優秀な営業マンを中途採用すれば良いのではないか、との考えもあるかもしれません。しかし、技術を深く理解していない営業担当者が案件を獲得してきた場合、そこには「営業と開発とのコミュニケーションロス」という大きなリスクが潜んでいます。

営業がお客様の要望を鵜呑みにして「できます」と安請け合いしてしまい、いざ開発フェーズに入ると技術的な実現が困難だったり、工数が大幅に膨れ上がったりするケースは少なくありません。結果として、開発チームには大きな負荷がかかり、お客様には納期遅延や品質低下でご迷惑をかけてしまう。こうした「営業と開発の壁」によるロスは、会社の信頼と利益を大きく削り取ってしまいます。

だからこそ、技術の裏付けを持った人間が直接お客様の悩みをヒアリングし、その場で「それなら、この技術を使えば解決できます」と即答する。このスピード感と説得力こそが、信頼を勝ち取り、適正な価格で案件を受注して利益を拡大するための最大の武器になると考えました。

この「営業と開発」を掛け合わせるという成長戦略は、当社の収益構造そのものをより強固なものへ変えていくだけでなく、私の抱えていた「技術力では勝てない」という焦燥感を、「技術力を発揮できる場を、自分が作る」という高揚感に変えてくれました。だからこそ、この5年間で「営業と開発、両方できるエンジニア」になることを目標に、仕事に実直に向き合い、試行錯誤しながら、経験と実績を積み上げてきました。

営業と開発のできるエンジニアを目指すとはいっても、実務での開発が未経験の私にとって何から始めたら良いのか、右も左もわからない状態でした。「最短期間でプロジェクトの全体像を把握し、自走できる状態になること」を最初の課題に掲げました。右も左もわからない状態だからこそ、目の前の業務の「量」をこなしつつ、更に一段上の視点からプロジェクトを俯瞰することで、早期にエンジニアとしての視野を広げようと考えました。

・配属当初の課題とそれに対する目標設定

私がドキュメント生成システムに配属された時、配属から半年以内にチームメンバーが産休でプロジェクトを離れることが決まっていました。当時のドキュメント生成システムの開発メンバーは2名の体制だったため、実質的にチーフエンジニア担当していた開発業務で抜けた穴を埋める必要がある状況でした。

ドキュメント生成システムでは開発の人手が足りないときはリーダーが開発作業を手伝う形を取っていました。つまり、自分の成長が早ければ早いほど、当時のリーダーが開発作業に入る工数を減らせて、プロジェクトの利益拡大に貢献でき、逆に言えば、遅ければ遅いほど利益を圧迫してしまいます。そこで、初年度の目標として、「１年目で開発業務の担当割合を５割以上になること」を目標に設定しました。

・難易度の高い目標を達成するための２つの工夫

短期間で仕事ができるようになるために、２つの工夫をしました。

「質＜量で新しい作業を教わること」と「プロジェクトを俯瞰して理解すること」です。

質＜量で新しい作業を教わることにおいては、一つひとつの作業を完璧にこなそうとすることをやめました。ドキュメント生成システムはシステム不具合が施工やり直しに直結するため、不具合ゼロが求められますが、１つのテンプレート作成、定義書作成にかけられる時間は限られています。新人の私が自分の理解の範囲内で完璧を目指すよりは先輩に進捗を聞かれる前に、自分から細かいスパンでアウトプットを提出し、フィードバックを受ける回数を最大化させることが重要だと考えました。加えて、ドキュメント生成システムでは業務マニュアルが十二分に整備されていたため、新しい作業を教えていただく前に、予めマニュアルを読み進めておくことで予習・復習のサイクルを作りました。

プロジェクトを俯瞰して理解することにおいては、量をこなしていくことで担当業務の幅を広げることでプロジェクト全体をぼんやりと理解できるようになってきます。そこで、自分の担当した作業、まだやったことのない作業を含めたドキュメント生成システムの全体像をExcelにまとめて、プロジェクト全体を可視化しました。

プロジェクトを俯瞰すると、工数のかかる作業、技術理解が必要な作業、後工程に響く作業などが作業の強弱が見えてきます。これにより、単に先輩の指示を待つのではなく、「明後日はリンク設定にデータベースが必要なので、明日中にはデータベース作成をやっておいた方が良いでしょうか」と後工程に影響するクリティカルな作業を先回りして動けるようになったり、複雑な仕様のコマンド作成があれば「過去のPG対応で類似のものがないか」あらかじめ調べておいたり、自ら優先順位を判断して動けるようになりました。

これらの工夫をしたとはいえ、先輩方が嫌な顔一つせず、未熟な私を繰り返しフィードバックして育ててくださったおかげで、１年目で開発業務の担当割合を５割以上になる目標を達成できました。また、目標を達成できた以上に、短期間で新しい仕事に慣れる経験と優先順位を付けて作業に取り掛かる「仕事の基本」を身につけられたことは、後述のPLM新規事業プロジェクトでも大きく活きることになりました。

ドキュメント生成システムの保守対応を順調にこなせるようになるにつれて、仕事の基本は身についた反面、徐々に焦りが出てきました。なぜなら、入社前に想像していたよりもコーディング経験を積めていなかったからです。

ドキュメント生成システムでプログラミングスキルが必要になるシーンはイレギュラー対応を除くとコマンド実装か業務ツール改修のみです。その上、コマンド実装に至っては、邸内の部材数を数える、特定の条件を満たすときTrue/Falseを返すような簡単なコーディング対応がほとんどでした。営業、開発ができるようになりたい一方で、スクラッチでゼロから設計して実装、リリースする経験を積めていない現状にストレスを感じていました。

・ストレスをバネに独学で勉強

「別の仕事をしたい」とは言っても、努力をせずに現状の不平不満を言っている人に新しい仕事を任せたいと思うでしょうか。私はそうは思いません。自分の成長の機会は自分で作っていくしかないと考え、独学で勉強を始めました。主な勉強法は、C#の文法をインプットし、サンプルアプリを作るアウトプットを交互に繰り返す座学と実践のハイブリット形式の演習でした。

まず、文法のインプットのために始めたことは総ページ数680ページに及ぶ「独習C# 第３版」でした。通勤の電車内と帰宅後、休日を使って、１日最低１時間以上、3か月間かけて、書籍を３周読み込みました。書籍内で紹介されているサンプルコードは実際に自分でも書いて動作確認することで理解を深めました。このインプットのおかげで、文法が分からなくてコーディングできない状況を脱することができました。

次に、最初のアウトプットで作成したのは名刺管理アプリでした。アプリとデータベースを連携させたプログラムの書き方を学びたいと考えたため、エンタープライズ利用の多いSQL Serverを選択して作り始めました。当時はデータベースの役割が全く理解できておらず、データベースに画像ファイルそのものを保存しようとしたり、データベースに接続しないままデータを参照しようとしたりして、エラーが多発しました。エラーが出たときは安易に先輩に聞いて解決しようとせず、Web検索で分かるまで調べることを泥臭く繰り返しました。結局、完成までに３ヶ月かかってしまいましたが、自力で１からシステムを作った経験は、後にプロの設計思想を吸収するための重要な土台となりました。

次のアウトプットには勤怠管理アプリを作ろうと考えました。当社の勤怠管理では勤怠システムを使用していますが、工数入力、打刻修正がしづらいとの声を聞いていたため、社内の課題を解決して人に使ってもらえるツールを作ることで実用的なフィードバックを得たいと考えました。

そんな時、勤怠管理アプリを作っていることをグループウェア(当時利用していたグループウェアサービス)の日報に書いていたところ、社内教育委員会の先輩から日報のアプリ化をやってみないかとお誘いいただきました。社内教育委員会が要件定義、設計をフォローしてくださるとのことで、実力のある社内の先輩3名から直接上流工程を学べる、思ってもない好機に勤怠管理アプリの開発は中断し、そちらに飛びつきました。

・ゼロから要件定義、設計、開発を経験

社内教育委員会にフォローいただくとき、真っ先に痛感したのは独学で作った「自分のやりたいことだけ動けばいいアプリ」と業務で耐えうる「実用的なアプリ」の圧倒的な差でした。社内教育委員会のメンバーからは、単なる機能要件の定義だけでなく、将来的な機能拡張を見据えたユースケースの整理、データベース設計を行い、要件書や設計書を作ってから開発するウォーターフォールモデルでの開発を指導いただきました。特に、データベース設計においてはアプリの画面からどのようなデータを表示しているか考え、ホワイトボードに書き出して、そこから拡張性を考慮して正規化していく方法が非常に新鮮でした。独学では場当たり的にテーブルを作っていましたが、データの整合性や保守性に重きを置いた設計の進め方を学ぶことができました。

開発工程は社内教育委員会のメンバーが一緒に実装するわけではなく１人で進める計画だったこともあり、社内で活用事例のない、C#でマルチプラットフォームな開発が可能なフレームワーク「.NET Core(現在は.NET)」を使用した開発に挑戦しました。

当時はChatGPTのようなAIが普及しておらず、日本で普及していないフレームワークを選択してしまったために、公式ドキュメントやStack Over Flowなどの海外の情報から自分に必要な情報を読み解くしかありませんでした。その時の工夫としては、英語で検索を行うことはもちろん、断片的な情報を鵜呑みにせず、その背景にある技術原理を正しく理解するところまで時間をかけて行いました。

例えば、コメントのリアルタイム通信を実現するSignalRの実装に際しては、単にライブラリを導入するだけでなく、通信の基盤となるCookieやセッション管理、さらにはHTTPプロトコルの挙動といった周辺知識を一つずつ紐解きました。このライブラリが自分の開発において有効なのか、適合しないのかを判断するためには、こうした低レイヤの理解が不可欠でした。このように、表面的な実装方法を探す「点」の検索ではなく、技術の仕組みを構造的に捉える「面」の学習を繰り返しながら開発を進めました。

結果として、半年近い開発期間を要することとなってしまいましたが、未知のフレームワークと格闘しながら、一つ一つの技術要素を論理的に裏付けしていくプロセスは、一見遠回りに見えるものの、エンジニアとしての開発力を養う上では極めて重要な時間であったと確信しています。ゼロから要件定義、設計、開発、そしてリリースまでを一貫してやり遂げたこの大きな経験値は、住宅メーカー向け案件やPLM新規事業プロジェクトにおけるあらゆる局面において、私の課題解決能力を支える大きな指針となっています。

その頃、新施策によるプロジェクト縮小に伴い、永続的に見えていた商品対応業務が非永続的であることに気付き、危機感を募らせていました。住宅メーカー向け案件を継続するためには過去の別プロジェクトへの参画ができたように、新しい提案をしていかなければならないと考えました。しかし、日々の保守開発業務量が多く、新規提案に割くための時間的余力が物理的に不足していました。「攻めの姿勢」を具現化するためには、社員の既存業務負担を減らし、より付加価値の高い提案活動にシフトするための体制変更が必要だと考えました。

・開発業務をパートさんにも入ってもらう

その頃、関連チームではパートさんの手が空く時間が増えていることが課題になっていました。案件リーダーの間でパートさんをドキュメント生成システムの「テスターとして増員する」案が検討されていました。しかし、テスト業務の人員は不足しておらず、適切な人員配置にはならないと思い、むしろ、リソースが不足していた「開発業務の一部」を担ってもらう案を出しました。

当初はパートさんに開発業務が可能なのか疑問に思われていました。そこでドキュメント生成システムにおけるプログラミング知識の不要な作業工程を適切に説明するようにしました。例えば、テンプレート作成業務ではコーディングは行わず、カタログの画像変更や建築ルールの変更、住宅設備の仕様変更に合わせて、Excelで作成されたデザインと掲載部品を修正することが主な作業です。つまり、建築知識の理解とExcel操作が主軸であり、住宅メーカーの販売会社のハウジングアドバイザー出身でこれまでテスト業務を経験されてきたパートさんにとっては十分可能な業務であることを強調しました。結果、この案が認められ、パートの同僚を開発メンバーとして迎え入れることができました。同僚は短期間で開発業務を習得し、開発メンバーの業務負担を大幅に減らすことに繋がりました。

・新規提案への挑戦

これまでのドキュメント生成システムでは小規模な改善は継続されてきたものの、大規模な予算を確保した抜本的な機能追加や改善は行われていませんでした。これまでの改善活動は業務の合間に余裕があれば考える程度だったためです。そこで私は、新規提案を既存業務と同レベルで管理してやりきるために、WBSを策定していつまでに何をやるのか明確なマイルストーンを設定しました。さらに、進捗定例会議の後に毎週30分の時間を確保することで、新規提案の活動が進められるように仕組み作りを行いました。

提案内容の構築にあたっては、当初、現場のエンドユーザーへの直接的なヒアリングは困難であると判断し、自分たちで考案した案に費用対効果を付与し、過去のサポート対応に寄せられた要望を分析する方針で提案資料の作成に向けて進めていました。しかし、上司からの助言を受け、自社内のみで完結させた内容では提案の根拠として不十分であると再認識しました。そこで、真に価値ある提案を行うために現場の生の声を集める、顧客のいくつかの拠点を対象としたヒアリング会の実施をシステムインテグレーター（以下、SIer）に打診し、その協力を取り付けることを活動の当面のゴールとするよう方針を転換しました。

具体的な提案活動の実態として、まずブレストを実施して、フレームワークを用いながら、40件ほど案出しを行いました。これらの案の絞り込みに際しては、費用対効果の高さや過去の要望件数に基づいた分類を行い、過去の初期開発段階で計画されながらも未実装であった「過去に計画されていた連携機能」や、ユーザーの利便性に直結する「出力速度の改善」「テンプレートデザイン刷新」「営業タブレット対応」など、４つの案を抽出しました。

続く提案内容のブラッシュアップ工程では、ヒアリング会を開催する納得感を得るためのストーリー構成を重視しました。具体的には、過去10年間にわたり大規模な改善が行われていない現状を指摘した上で、最終的な顧客企業の本部への提案に向けた具体的な段取りを整理しました。特にヒアリング会の計画においては、単なる実施の打診に留まらず、我々が事前に検討した仮説としての提案を提示するとともに、システムの利用率が高い利用率の高い拠点や初期導入の起点となった拠点など、定量的な背景から選定した具体的な候補地とその選定理由を明示して、資料をまとめ上げました。

しかし、この提案活動は、極めて困難な現実に直面することとなりました。まず、提案先であるSIerの担当者が多忙を極めていたため、提案内容を説明する機会そのものが度重なる延期を余儀なくされました。加えて、現場へのヒアリング会を実現するためには、必ずSIerを経由しなければならないという組織間の構造的制約が大きな障壁となりました。最終的には、提案の意義を真剣に取り合ってもらえる関係性を構築しきれず、さらには私自身の異動が決定したことで、活動を完遂できぬまま失敗という形で終了する結果となってしまいました。

本活動を通じて得た最大の学びは、現場レベルのボトムアップの努力だけでは、組織間の壁を越える大規模な変革は困難であるという点です。マネジメントグループと連携し、SIer内部に対してトップダウンでの調整を働きかけるような、複層的なアプローチが必要であったと痛感しています。技術的な裏付けだけでなく、いかにして意思決定層を動かす戦略的な立ち回りを行うか、営業と開発を両立させるエンジニアを目指す私にとって大きな学びとなりました。

住宅メーカー向け案件を離れ、親会社の事業（以下、親会社側）に関わる新規事業、PLM新規事業プロジェクトへの異動が決まった時、これまでの努力が報われた思いと、培った全てを発揮してプロジェクトの成長に貢献したい思いが溢れ、やる気に満ち溢れていました。そんな転属後のスタートは決して良いものではありませんでした。

最初は3DEXPERIENCEの研修とE-ラーニングを受けました。研修は自社西日本事業部で3DEXPERIENCEの操作研修、自社東京本社の先輩によるカスタマイズ開発の説明が数回あり、説明資料やサンプルプログラムを頂きながら、Eラーニング(CATIA基本操作・モデリング編・アセンブリ編)も活用した事前インプットを進めました。3DEXPERIENCEの製品規模に圧倒されつつも、繰り返し資料を読む、Eラーニングを３周するなど量を確保する学習手法でインプットを進めました。

しかし、資料確認、プログラム確認、Eラーニングを繰り返すにも、２週間が経つ頃にはほとんど終わってしまいます。チームメンバーの間でも、手持無沙汰な状況にモチベーション維持が難しいという声が上がりました。

そこで、先輩の提案で案件が来ない期間を使って、チーム内勉強会を開催することになりました。勉強会の講師は私が担当し、案件で使用する想定の開発技術を学ぶ内容で実施しました。

・案件で必要な知識を予想して学習内容を考える

当時は具体的な案件情報が得られていない状況でしたが、メンバーのチームメンバー二人のスキルセットを考慮し、今後どのような知識が必要になるかを検討することから始めました。二人はコーディングの基礎は習得していましたが、実務未経験の言語やIDE（統合開発環境）での開発、およびWebアプリ特有の概念把握が、参画時の大きな障壁になると予想しました。そこで、Javaで実際に動くものを作りながら概念知識を補完する勉強会資料を準備しました。

公式ドキュメントの読解と並行してチャットアプリのクローンアプリを自作するなど、アウトプット主体のキャッチアップを先行させました。その過程で直面したのが、Java特有の「多様性」に伴う学習難易度の高さです。Microsoft製品で標準化され、学習レールがシンプルなC#環境に対し、Javaはビルドツール（Maven/Gradle）やフレームワーク（Spring Boot/Jakarta EE）、実行サーバーの選択肢が無数に存在します。歴史ある言語だからこそ、オプションが無数にある構造こそが、初学者が混乱する主因であると考えました。

勉強会の内容設計にあたっては、なるべくたくさんの内容を長時間かけてでも伝えたほうがいい、という考え方もあるかもしれません。確かに、伝えたいことは山ほどありましたが、人が一度に許容できる情報量には限りがあると思います。そのため、この勉強会においては案件に必要最低限の情報に絞り、先輩エンジニアから共有頂いたサンプルプロジェクトの構成を分析し、学習リソースを「RESTの概念」と「REST APIフレームワークJAX-RS」の二点に集約しました。具体的にはRESTの理論をJAX RSのワークショップ形式で実践しながら学ぶ、これまでの独学での学んだ手法を短期間に凝縮した形で作成しました。

その結果、チームメンバー二人からは「RESTとJAX-RSの概念理解が非常に深まった」との感想をいただくことができました。その後、実際に案件業務でREST APIの構築を行なうことがあったのは私だけでしたが、3DEXPERIENCE Web APIを利用してカスタマイズ開発するメンバーの別クライアント案件においても、VBAでAPIを呼び出す実装が行われた際に勉強会でのAPI学習が概念知識として役に立ったこともあり、チームとしての土台を作ることができたのではないかと考えています。

・初の案件配属開始、いかに自分を売り込むか

３ヶ月間の案件が開始になりました。稼働集計案件では、私とメンバーの２名での参画。使用技術は使用経験のあるC#.NETで技術難易度は高くありませんでした。しかし、初めての案件ということもあり、最初の仕事ぶりがその後の印象に直結すると考え、「いかにPMから信頼され、次もまた私を使いたいと思ってもらえるか」に心血を注ぎました。

最初は、PM視点で仕事のやりやすい人材とはどんな人物像かを考えました。PMの仕事はプロジェクトが納期通りに作業を完了し、QCDを担保するために調整をすることです。つまり、この仕事を自主的に推進してくれるメンバーになることが「次もまた私を使いたいと思ってもらえるか」に直結すると仮定しました。

これを実現するための具体的な取り組みとして、「クリティカルタスクを先回りする」「過不足のない報連相」「他メンバーのフォロー」の３つの工夫を行いました。

１つ目の工夫として、クリティカルタスクを先回りするために、ドキュメント生成システムで行ったように作業の依存関係を把握し、後続の工程や他メンバーの作業を止めてしまう可能性のあるタスク(クリティカルタスク)を最優先で完遂させました。例えば、機能テストは実装担当者以外が実施することになっていたため、他のメンバーの作業スケジュールを把握しながら、いつまでに実装完了が必要かを計算して対応しました。

２つ目は、過不足のない報連相で、PMが状況を判断するのに必要な「作業の進捗率」「完了見込み」「直面している課題」を、聞かれる前に日次報告することを徹底しました。

また、質問をしすぎてPMの手を止めすぎないように、開発ツールのセットアップやプロジェクトファイル構成、SVNの使用方法など、自己解決できる部分はなるべく自己解決し、リポジトリのURL、機能の仕様詳細、定例会議での設計変更点など、聞かなければ分からない箇所のみ質問するようにしました。

３つ目は、「他メンバーのフォロー」を行いました。自分のタスクを早期に完了させた後は、共に参画したメンバーの疑問・課題を一緒に考えたり、自社側の他メンバーのテストデータを用意したりして、チームとしての成果を最大化させるよう動きました。周囲に好影響を与える動きを心がけることで、PMから「チームの潤滑剤」として認識してもらえるよう努めました。

この結果、PMから安心して仕事を任せられるとの評価をいただくことができました。

製造業クライアント向け案件の終了後、別クライアント案件が頓挫してしまった出来事もありましたが、再び2025年2〜3月の２ヶ月間の案件が開始になりました。私とメンバーの２名での参画。使用技術はVB.NETがメインで、一部Javaを使用します。プロジェクトメンバーは自社社員のPMが１名、自社の協力会社、協力会社（以下、協力会社）のメンバーが２名の体制でスタートしました。開発案件の途中から配属されたため、最初の作業はテスト工程と次期先行開発でした。

当時、VB.NETとJavaは２人とも未経験の技術ではあったものの、VB.NETは新人研修のC#.NETの知識が流用でき、Javaも勉強会でインプットをしていたMavenプロジェクト構成だったため、技術的な課題はそれほど大きくありませんでした。共に依頼されたタスクを常に前倒しする形で進められていました。

・リモートワーク下における信頼構築の課題

私たちの作業でスケジュール遅延がなかったにも関わらず、自社側からリモートでのコミュニケーションロスを問題視され、東京での現地作業を求められました。私の家庭の事情もあり、東京での現地作業は難しかったため、出張回数を減らす方向で話を進めていただきましたが、結果的に、メンバーがプロジェクトを外され、協力会社のエンジニアが代わりに１名追加になる形になってしまいました。

当時を振り返ると、報連相をして技術的な進捗さえ守れば良いという私の認識と、親会社側が求めていた次期開発を任せられる安心感の間に大きな乖離があったのでは無いかと思います。進捗に遅れが出ないようにメンバーをフォローしていたところが、逆に私の負担になっていると誤解させてしまったこと、メンバーの進捗報告や作業見積もりの不慣れさがあったことなどが原因だったと考えており、技術面以外での必要スキルやノウハウを共有する機会が不足していたと反省しました。

・チームとしての成長に向けた取り組み

今回の件を受けて、「チーム」としての評価も重要であることに気付かされました。そこで、チームの成長の礎を作るために、ナレッジベースを構築する計画を立案しました。

STEP1ではメンバー個人の学びを蓄積・共有することで、個人の成長を加速させます。STEP2では過去の蓄積した学びをダイレクトに次案件に活かす仕組みを構築します。STEP3ではチームで難易度の高い問題を社内で解決できるような体制を整えます。

現在はSTEP1の取り組みとして、ナレッジ共有フォームと週次での情報共有会を実施しています。ナレッジ共有フォームでは共有するMicrosoft Formsを使用してナレッジを気軽に投稿できる仕組み作り、６分類に分けて投稿するフローを確立しました。

週次での情報共有会では、投稿したナレッジを対面で共有したり、プロジェクト状況もメンバー自身が自分の言葉で説明する機会を設けたりすることでメンバー個人の成長に寄与しています。

結果的に、私が他のメンバーから学ぶことも多く、別案件で話す機会が少ないメンバーともコミュニケーションが取れる副次的なメリットもあるため、今後も継続していきたい取り組みです。

・いかにして契約を１年間継続させたか

メンバーがチームを離れ、2025年8月末までの契約で次期開発がスタートしました。この限られた期間の中で、「いかにして契約を継続させていくか」を考えました。契約の継続を考えた時に注目したのは協力会社の存在です。協力会社のメンバーはなぜ、PLM新規事業プロジェクトで契約継続できているのか。特に協力会社のPMは自社のPMを抑えてプロジェクトマネジメントに貢献し、お客様との折衝まで直接担当することでそのプロジェクトの詳細を把握し、必要不可欠なポジションを築いていました。

その様子から学び、私もプロジェクトにおいて必要不可欠な存在になること、自ら契約延長を打診すること、この2つの攻めの姿勢で臨むことにしました。

プロジェクトにおいて必要不可欠な存在になるために、最初は協力会社の開発者との差別化を行いました。協力会社の開発者はCATIAのカスタマイズフレームワークのCAAやVBのコーディング経験が豊富でした。一方で、私は勉強会で培ったWebAPIの構築、活用経験においては協力会社の開発者よりも知識が豊富でした。

3DEXPERIENCEのカスタマイズにCAAを用いる方法には、いくつかのデメリットがありました。１つ目はVBでのAPI呼び出しに比べ動作が低速になりやすいこと、２つ目は挙動を安定させるための技術調査に時間がかかること、３つ目は自社社内での技術者が少なく、保守が難しくなること。そこで私は、プロジェクト開始後の技術検証で、3DEXPERIENCEの開発者ガイドをいち早く読み進め、CAAを使用しないWebAPIでの実装方法をいくつも提案しました。また、APIの呼び出し処理をVBで使用しやすいモジュールにして提供することで、他の開発者の実装からでも利用しやすい開発環境を整えました。これは単に私の得意分野を押し付けるのではなく、「開発工数の削減」と「実行速度の向上」という、お客様にとっての直接的なメリットを優先した提案であることを強調しました。その結果、「3DEXPERIENCEのAPIの相談、実装担当は自分にする」流れを作ることができ、プロジェクトに必要不可欠なポジションを確立できました。

プロジェクトでの役割を確立した後は、自ら契約延長を打診しました。具体的には、2025年8月の契約満了が近づく１ヶ月前のタイミングで、自らお客様に対して今後のロードマップに基づいた提案を行いました。単に「残らせてほしい」と伝えるのではなく、次期フェーズで予想される課題に対し、自分が構築したWebAPIモジュールをどう活用させれば工数削減に寄与できるかを定量的に示しました。

また、協力会社のPMが実践していた「お客様との直接折衝」を参考に、定例会議以外でも積極的に進捗共有や技術的なアドバイスを行い、お客様が「担当者がいなくなると開発スピードが落ちる」と実感できる状況を作り出しました。こうした「技術的な優位性」と「主体的な提案」の両面からアプローチした結果、お客様から「自分の知見は次期フェーズでも外せない」との評価をいただき、当初の予定を上回る形での契約を継続することができました。結果、案件の終了予定は25年8月だったところを2026年3月現在まで伸ばすことが出来ました。

今後の５年間で、私はPLM新規事業プロジェクトを現在の「個人の活躍」に依存するフェーズから脱却させ、住宅メーカー向け案件に並ぶ、もう一つの柱へと成長させていきたいと考えています。その具体的な到達点として、チーム体制を10名へと拡大し、プロジェクト全体で売上１億円を達成させたいです。この目標は単なる事業規模の拡大を意味するものではありません。入社以来掲げてきた「営業と開発、両方できるエンジニア」という目標を、私一人のスキルに留めず、チーム全体で体現し、当社の収益構造をより強固なものへと変革させるための挑戦です。

まず着手すべきは、10名体制への拡大を軸とした「ドメイン知識」の組織的な蓄積です。製造業の現場で信頼を勝ち取るためには、純粋な技術力以上に、顧客の業務プロセスを深く理解していることが不可欠です。まずは現在の主軸であるSES契約を通じて、大手製造業の業務フローをメンバー全員が理解し、どの案件でも活躍できるポジションを確立します。

また、この10名体制を維持しつつ、利益率の高い請負へとビジネスモデルを転換させるために、自社アセットの活用を推進します。私が実践した「共通APIモジュール」の提供のような、個人の知見をチームの資産として積み上げ、開発効率を向上させる仕組みを構築します。これにより、他社が３ヶ月要する開発を、当社であれば高品質かつ短期間で完遂できる体制を整えます。

さらに、チームの成長を支える基盤として、技術教育と並行して「プロとしての立ち振る舞い」の教育にこれまで以上にコミットします。メンバーの人員入れ替え経験の失敗を糧に、リモート環境下であっても顧客を不安にさせない能動的な情報開示や、プロジェクト全体を俯瞰した先回りのコミュニケーションを「当社の標準」として全メンバーに教育します。技術力があるからこそ提案が通り、振る舞いが良いからこそ次の仕事に繋がる。この好循環を10名全員で体現できるよう、後輩の育成に心血を注ぎます。

私がこれまでの５年間で培った「営業と開発」を掛け合わせる姿勢を組織の文化として根付かせ、会社から「チームを任せられるリーダー」として全幅の信頼を寄せられる存在になることが、次の５年間のゴールです。