はじめに

デザイン&エンジニアリング部所属、入社3年目の菅です。学生時代は情報工学を専攻し、TISに新卒入社しました。
近年IT業界では若手エンジニアが早くから挑戦できる環境が注目されていますが、実際に全工程を一貫して任される機会は決して多くありません。そんな中、私がプロジェクトを通じて感じたリアルな成長や苦労を、これから業界を目指す方にも共有したいと思います。
　私は入社2年目になると同時に新規案件に携わることになりました。開発計画としておよそ1年と短めで当初想定としてはシンプルな機能であったため、要件定義から設計・製造・テスト・リリース、そして保守運用まで、プロジェクトの全工程を一貫して担当するという貴重な経験を得ることができました。今回の記事では、私と同じチームでシステムのリリースまで携わった若手メンバー数人にもインタビューを実施し、それぞれが直面した課題や成長のリアルな声も交えてご紹介します。初めて尽くしの日々でどのように課題と向き合い、学びを得たのか。その具体的なエピソードをお伝えします。

プロジェクト概要と自分の役割

私が担当したのは、企業向けの業務効率化を目的としたITシステムの新規開発プロジェクトです。本プロジェクトでは、運用業務プロセスの効率化に関する機能の設計・実装に携わりました。
　自分の担当範囲が広かったからこそ、各工程の難しさや面白さ、そしてチーム内外とのコミュニケーションの重要性を強く実感することができました。初めての経験ばかりでしたが、プロジェクトを通じて多くの技術・業務知識を身につけることができ、エンジニアとして一回り成長できたと感じています。

想定読者

  • キャリアを歩み始めた若手のエンジニア
  • IT業界を志望する学生・就活生

役割と開発体制

  • 役割：開発担当者として、主に要件定義から設計、開発、テスト、リリース、さらに運用・保守まで、幅広い工程を担当。
  • 開発体制：開発チームは変動もあったが、主にリーダー1人、私を含む入社2年目の若手が3人、協力会社さん1人のメンバーでの体制。

全工程を担当して見えた景色

私にとって全ての工程を実務で担当するのは初めてで、どのような成果物を作ればよいか、どう進めていくべきか戸惑うことばかりでした。研修で開発の流れや成果物のサンプルは学んでいたものの、実際に自分の手で１つひとつ作成する難しさを痛感しました。手探りで試行錯誤を重ねる中で、各工程のつながりや、自分の判断がシステム全体の品質やコストに大きく影響することも身をもって学ぶことができ、部分的な担当では得られない責任感や緊張感があったと思います。リリースを迎え実際に動く画面を見た時は、一から関わったシステムが完成したという大きな達成感と自信を得ることができました。

各工程での課題と乗り越えた工夫

この章では、実際にプロジェクトを通じて私が直面した主な課題と、その都度どのような工夫で乗り越えてきたか、学んだことを工程ごとにご紹介します。

要件定義

課題1: 全くまとまらない要件

通常、新規開発のプロジェクトであればどういったものを作りたいのかお客様に要件をヒアリングするのですが、今回のプロジェクトは社内システム開発のため、お客様から直接要望を聞く機会はありませんでした。代わりにプロジェクトリーダー（PL：開発チームの進捗と品質、メンバー管理の責任者）を通じて要件をまとめたのですが、なかなかまとめることができず苦労しました。理由は、PL・プロジェクトマネージャー（PM：プロジェクト全体の計画と実行の責任者）・サービスオーナー（SO：サービスの品質、提供の責任者）間で要件について認識に齟齬があり、同じゴールのイメージを持つことが難しかったためです。関係者間の認識合わせや共通理解の重要性を実感しました。
解決策：要件をまとめる上で行ったこと
要件の具体化にあたっては、PLだけでなく、PMやSOの方々にもご参加いただき、集中検討会を実施しました。
この検討会では、業務要件について関係者が直接意見を交換し、認識のすり合わせを行うことを目的としました。また、検討会で決まりきらなかった要件については課題として整理し、今後の論点を明確にするよう努めました。多様な視点から意見交換を行い、課題点を定期的な定例で擦り合わせることでなんとか要件をまとめていくことができました。

課題2: ゴールが見えない成果物作成

通常システム開発では、システムの操作マニュアルや設計書などを成果物として作成し、お客様へ納品します。本プロジェクトのもう１つの大きな課題として、成果物を作成するにあたり、何を目的とし、何を参考にすればよいのか分からず、まずは成果物自体の目的や役割を理解するところから始める必要がありました。目的が曖昧なままでは必要な情報や観点が抜けてしまう不安があり、成果物の完成イメージを掴むこと自体が大きな課題となりました。
解決策：成果物の目的や意味を知り、チームに還元する
まず参考にした資料として、Fintanの要件定義フレームワークを参考にすることで、要件定義の進め方や、各成果物の目的、繋がりを知ることができました。そこからプロジェクト内の別のチームの成果物を参考にし、目的や繋がり、誰がどのように使うのかを意識しながら各成果物の作成に取り組みました。また、私を含めチームメンバーの多くが若手であり、成果物作成の経験が少なかったため、作成に戸惑う場面が多くありました。そこで、私が率先して必要な各成果物のサンプルを作成し、私が学んだ内容や考え方を他のメンバーに共有しました。これによって、チーム全体で成果物のイメージや記載方法を揃えることができ、要件定義資料の作成をスムーズに進めることができました。

設計・製造

課題1: 「察して」は通じない。設計書の曖昧さが品質低下を招く

バックエンドの実装をオフショア（海外への業務委託）チームにお願いしていたのですが、自分が設計書を少しでも曖昧に書いてしまうと、そのままの内容で実装されてしまうことが多くありました。今回のオフショアチームは日本語で意思疎通ができる環境が整っており、言葉の壁はありませんでしたが、「ここは察してくれるだろう」と思っていた部分も、しっかり具体的に書かないと全く意図が伝わらず、結果的に自分の設計書の書き方がそのまま成果物の品質に直結してしまう、ということを何度も実感しました。仕様の解釈や判断を相手任せにせず、伝わるように厳密に書く大切さを痛感しました。
解決策：読み手の前提知識を考慮し、曖昧さを避ける
今回設計書を作成する上で、オフショアチームの前提知識を考慮する必要がありました。業務知識がない読み手でも誤解なく仕様を理解できるよう、曖昧にされがちな部分のロジックをできる限り詳細に記載することに努めました。具体的にはどんなときに、どの処理を行うかといった判断基準や処理の条件分岐について、業務知識がない方にも内容が正しく伝わるよう、数式や論理式など、誰が読んでも解釈がぶれない表現を用いるよう心掛けました。
　これらの対応を実施することで下記のように改善されたと思います。
改善前
  • 毎日設計書に関する質問が来ており、細かい部分の説明の対応が必要となる。
  • 処理で考慮が漏れていることがあり、意図しない動作でエラーとなることがたびたび発生してしまっていた。
改善後
  • 誰にでも分かる設計書を書くことで質問対応などが減り、処理の認識齟齬によるエラーが削減された。

テスト

課題1: 原因不明のエラーでテストが全停止

結合テスト準備では、内部機能間（同じシステム内の機能連携）および外部連携（別のシステムとの機能連携）での疎通が全く上手く行かず、原因の切り分けやログ確認といった調査の方法も分からない状態だったので、むやみに試行錯誤を繰り返してもテストが進まず大きな課題となりました。
今までの工程と違い、考え方や参考資料、進め方さえ何も分からなかったため、全工程の中で一番精神的にも苦しかったです。
    解決策：どうしようもない時は人を頼る
    疎通検証が全く上手く行かず、どうしようもなかった際、リーダーに相談したところ、上長が動いてくださり、プロジェクト内の有識者を集めてくれました。そこから原因の切り分け方や調査の方法を教えていただき、疎通に関する不具合についても手助けしてもらいどうにか全て疎通させることができました。
    　1人で悩み続けて毎日憂鬱な日々だったので、この時助けていただいたことには、今でも心から感謝しています。自分ひとりでは解決できなかった問題も、周囲に相談し知恵を借りることで前に進むことができました。この経験から、困難な状況では無理に抱え込まず、早めに人を頼ることの大切さを実感しました。また、専門的な調査手順やログの見方など、実践的な知識も学ぶことができ、以降の工程では自力で原因を特定できる場面も増えました。様々な方の支えがあったからこそ乗り越えられた貴重な経験だったと感じています。

    運用・保守

    課題1: 仲間は旅立ち、これからは1人でタスク管理

    リリース後、システム開発は運用・保守フェーズに入り、それまでの工程ほどの人手は不要となったため他の若手メンバーが異動し、実務は主に私が担当する2名体制となりました。リーダーはサポートが中心のため、エンハンス対応や不具合・障害対応、引継ぎなどを限られた工数で効率よく進める必要があります。工数整理やスケジュール管理などを自分で進めるのは初めてで戸惑うことも多く、納期や障害対応との両立に苦労しました。

    解決策：培った経験が力になる

    1人で多様な業務を抱えることに最初は大きな不安がありましたが、これまでの開発プロセス全体を通じて培った技術知識やタスク管理、業務効率化の経験がここで大いに役立ちました。例えば、タスクごとに優先度を明確にし、対応期限をリスト化することで、業務全体を俯瞰できるようになりました。また、外部連携における障害対応については、以前は自分ひとりだと迷うことばかりでしたが、これまでの経験を積み重ねる中で、関係するチームに対し積極的に情報共有し、障害の原因を自分で切り分け、必要な対応策を考えることにより実際に1人で解決できるケースが増えてきました。

    これまでの開発全体の経験を通じて、限られたリソースの中でも安定した運用・保守を実現できる力が身についたと感じています。

    若手チームメンバーへのインタビュー

    最後に、私と同期であり、同じ案件で開発を行っていた若手2人の秋山さんと平林さんにインタビューを実施しました。
    2人の経歴としては以下です。
    • 秋山さん: 大学時代は情報系を専攻。研修ではJavaの基礎を学び、前のプロジェクト配属後にReactを用いたフロントエンド開発をしていた。
    • 平林さん: 大学時代は文系でITに関しては完全未経験。基礎研修および前のプロジェクト配属後にJavaでバックエンド開発をしていた。

      配属当初の期待とギャップ

      菅: 今回システム開発に参画するとなって、当初の気持ちと参画後でギャップがあれば教えてください。

      平林:  配属当初は全てが初めてだったので、学べる機会が多そうですごく楽しみでした。1年実際に開発してみて、自分が学びたいこと、やりたいことをやらせていただきました。しかし、初めての工程で知識も全くない状況でしたので、自分が思っていたよりもできないことが多く、特に要件定義では他のメンバーに頼ってばかりで落ち込むことが多々ありました。

      秋山: 私は設計工程から参画したのですが、業務がかなり立て込んでいることを聞いていたので、多少の不安がありました。実際に参加してみると、想像通り多忙な日々が続きましたが、設計自体はそこまで困難ではありませんでした。ただし、要件の変更が度重なり、手戻りによる作業の増加が続いたため、その点で苦労することが多かったです。

       

      開発現場での苦労とギャップ

      有識者が居ない中どのように実装を進めたのか

      菅: お2人は私とは別の機能をメインで担当していましたが、開発ではどんな苦労や課題がありましたか？

      秋山: 画面実装の際に私たちが適切に※省力化コンポーネントを使用できておらず、今後の保守性を考慮しこれまで作っていた実装コードを全て見直す必要が出てきました。そもそも実装メンバーはほとんど経験がない2年目2人とフロントエンドの経験はあるが省力化コンポーネントについては全く知らない協力会社さん1人で、有識者が少なかったです。

      ※省力化コンポーネント: React開発の実装量を大幅に削減するコンポーネント

      菅: お2人が担当した機能の画面は2か月で30画面以上も実装する必要がありましたよね。すごく大変な状況だったと思うのですが、省力化コンポーネントについて知見が無い中どのように実装を乗り越えたのですか？

      平林: よく出社している先輩上司とコミュニケーションを取る機会が多く、先輩にフロントエンドの実装で悩んでいると相談したところ、省力化コンポーネントを正しく使えていないことに気付けました。省力化コンポーネントの開発者の方に相談をし、省力化コンポーネントの適切な使い方を教えていただき、上手く実装に組み込めない時に助けてもらうことでなんとか乗り越えることができました。

      秋山: 平林さんが主体的に動いてくれたのに加え、チームの協力会社の方もフロントエンドの有識者だったので、行き詰まったときは皆で頼りながら解決していきました。

      菅: どうしようもない時は周りに助けてもらうことが大事だと、私も今回のプロジェクトを通して学ぶことができました。実際に省力化コンポーネントを適用してみてどうでしたか？

      秋山: Reactの知識だけでは不十分なので学習のコストはあると思いますが、コードの量がかなり削減されてその後の保守性も向上しました。

      製造フェーズでも続いた要件変更。どうすれば防げたか？

      平林: PL、PM、SOを交えて集中的にシステム要件を整理し確定したのにも関わらず、外部システムの都合に伴う要件や設計の変更が製造工程に入っても相次いで起きて手戻りが多かったのも大変でした。

      菅: なぜそのようなことが起きてしまったのですか？

      平林: 私たちはフロントエンドを開発し、グループ会社の他チーム(以降、単に他チームと表記)にバックエンドや外部システムを開発してもらっていました。そのため、画面イメージなどを他チームの方々とも会議を通じて何度も擦り合わせていました。しかし、その会議には外部システムの1つを担当している方が参加しておらず、その画面イメージが相手に上手く伝わっていなかったことが原因で設計変更が度々必要になりました。

      秋山: 私たちとしても業務知識や他チームの方々の詳細な体制、外部システムについての仕様などをしっかり理解できる労力があれば良かったなとは思います。

      菅: 忙しい時期ではありましたが、せめて他チームの体制を正確に理解し、最初から関係者全員を巻き込んで会議ができていれば今回のようなことは起こらなかったかもしれませんね。

      平林: 本当にそう思います。

      エンジニアとしての成長実感

      菅: 成長したことや、得られた学びについて教えてください。

      平林: 1つ目は様々な関係者とコミュニケーションを取る機会が多く、相手に伝える能力をかなり磨けたと思います。最初はチーム内でのコミュニケーションにも苦戦していましたが、多くの方々との会議や情報共有を通して大きな学びを得ることができました。2つ目はフロントエンドの開発について力を付けることができたことですね。次のプロジェクトでも自走して開発を進められそうです。

      菅: コミュニケーションに関して、PM、SOといった上位者の方々との会議に関しても平林さんが主体となって資料を作り、会議を進めていたところを見てものすごく成長しているなというのを私も近くで感じていました。

      秋山: 技術的な話で言うと、TISが発信している「省力化コンポーネント」という技術について触れて学んだほか、ウォーターフォール開発や初めて経験する工程にも携わり、多くのことを学べました。私がプロジェクトの上位者になった際の視点に立って課題等も多く見つけることができたので良かったです。ビジネススキル面では、今回のプロジェクトは多種多様な関係者に自分から情報を発信していく必要があったので、相手の前提知識を考慮しどのように伝えるかを考える機会が多く勉強になりました。

      未来のエンジニアへのメッセージ

      平林: 私はITに関して完全未経験で入社し、初めは右も左も分からず大変でした。その中でも、知らないことに興味を持って挑戦していくことでその分野について知ることができ、自分の大きな成長に繋がったので、どんどん新しいことに挑戦していってください。

      秋山: 私は学生の頃からITに関する知識を学んでいたのですが、そのせいか自分でやり遂げたいという思想が強く人にあまり頼らないことが多かったです。自分で抱えすぎてメンタルが参ってしまいそうなこともあったので、困ったら無理せず人に頼ってください。

      おわりに

      若手が大半を占めるチームで、多くの壁が立ちはだかるシステム開発でした。しかし、メンバーそれぞれが強みを活かし、周りに支えられながらリリースを迎えることができました。
      挑戦できる環境と、それを支えてくれる多くの人々に恵まれたおかげで、私たちは大きく成長できました。
      この記事が少しでも皆さんの参考になれば幸いです。