【働き方紹介 Vol.4】ゼロベースでシステムを作り上げる。サービス開発エンジニアのリアルな1日を公開！

最先端のITアウトソーシングソリューションを提供するIIJエンジニアリング。その安定したサービスは、多様なバックグラウンドを持ち、専門性を追求する様々な職種のメンバーによって支えられています。そんな当社でのリアルな働き方を職種ごとに紹介する本シリーズ。

第4弾となる今回の記事では、サービス開発本部にてシステムの設計・開発・テストまでを一貫して手がけるエンジニアに密着しました。多くの方が気になる具体的な1日のタイムスケジュールから、仕事のやりがい、ワークライフバランスのリアルまで、詳しくお届けします。

インタビュイー紹介

T.H さん / サービス開発本部開発部開発課

大学でインターネット領域を学んだ後、同業他社でのソフトウェア開発を経て2022年に中途入社。自社サービス開発業務を経て、現在はSI（受託開発）業務のメンバーとして、Webシステムの設計からコーディング、テストまで幅広い工程を担当。日々技術を磨きながらサブリーダーとしても活躍中。

サービス開発メンバーのスケジュール

開発業務は数日〜数週間にまたがって同じ工程を担当することが多いため、日によって注力する領域が異なります。本記事では、開発業務を「設計」「コーディング」「テスト」の3つの領域に切り分け、それぞれに注力した1日の具体的なスケジュールを紹介していきます。

▼サービス開発の業務内容についてはこちら！

【業務内容紹介】「作ってから」が始まり。上流から運用・改善まで一気通貫で挑む、サービス開発業務とその魅力を解説します！ | 業務内容・働き方紹介

IIJエンジニアリングは、ITインフラの運用保守やサポートセンター運営のみならず、自社サービスの開発やSI開発など、上流から一貫したシステム開発も手がけています。そういったサービス開発において、...

https://www.wantedly.com/companies/company_7290761/post_articles/1080601

設計に注力する1日のスケジュール

まずは、お客様の要望をシステムに落とし込む「設計」に集中する日のスケジュールをご紹介します。

10:00｜出社・タスク確認

当社の開発チームでは、フレックスタイム制を導入しているため、ラッシュ時を避けて10時前頃にゆったりと出社することも。出社後はまず、今日やるべき作業内容を確認し、1日のゴールを設定します。

10:30｜技術調査とドキュメント作成

システムを作る上で必要な技術要素を調べ、チームのメンバーが見られる社内サイトに記載していきます。解釈が一意になり、誰が読んでも誤解が生じないよう明確に記載することを大切にしています。文章だけでは伝わりにくい複雑な仕様には、図や表を積極的に交えながら分かりやすいドキュメントを作成します。

12:00｜ランチ休憩

お昼休憩はしっかり休んでリフレッシュすることで、午後からの集中力を高めます。

14:00｜ドキュメント作成とブラッシュアップ

午後も引き続き技術調査とドキュメント作成を進めます。設計書には、アプリケーションなどに追加したい機能を実現するために必要なプログラムの修正や設定変更について記載していきます。その際に、想定通りの機能を実現できるか、予め自身のコンピュータ上で開発用のアプリケーションに対しプログラム修正・設定変更を行い、簡単に動作確認を行います。

本質的なサービスを開発するために、「Webシステムを使う人が本当に求めているものは何か」というユーザー視点を常に忘れないように意識します。

ドキュメントがある程度形になった段階で、上長へレビューを依頼。チェックを受ける際は、チャットでのやり取りもありますが、複雑な仕様については直接席へ行って会話ベースで相談し、効率よく完成度を高めていきます。

19:00｜退勤

区切りの良いところで作業を終え、退勤します。余裕のある時期であれば残業は少なく、19時から20時の間には退社しています。

コーディングに注力する1日のスケジュール

設計書が完成した後は、実際にプログラムを記述していく「コーディング」の工程に入ります。集中力が求められるこのフェーズの1日を見ていきましょう。

10:00｜出社・仕様の再確認

出社後、まずは設計書をじっくり読み込むことから始めます。いきなり手を動かすのではなく、30分程度かけて「今日どういうものを作るか」の仕様を頭の中で確実に再認識させます。

10:30｜コーディング開始

仕様の確認を終えたら、プログラミング（コーディング）に移ります。実装を進める中で少しでも不明点や迷いが生じた場合は、独断で進めずベテランメンバーの力も借りながら着実に作り込んでいきます。

12:00｜ランチ休憩

作業の区切りをつけて、1時間の休憩をとります。

13:00｜定例ミーティング

毎週火曜日の午後は、開発課全体の定例会議へ出席します。Hさんはサブリーダーとして、自身の担当プロジェクトの進捗を報告。他のベテランメンバーの実践的な報告から高度な技術や新たな知見を吸収する貴重なインプットの場となっています。

14:30｜コーディング

会議終了後は再びコーディングに従事。単にソースコードを書くだけでなく、プログラムを実行するサーバーやシステム全体を見据えた実装を常に意識して作業を進めます。ソフトウェアエンジニアとしての広い目線を持つことが、バグのない高品質なシステム開発に繋がります。

19:00｜退勤

その日の目標としていた実装箇所まで完了したタイミングで退勤します。

テストに注力する1日のスケジュール

プログラムが完成したら、最後に品質を担保するための「テスト」を行います。ここでは、設計通りにシステムが動くかを細かく検証していく1日を紹介します。

10:00｜出社・設計書と成果物の確認

出社後、まずは設計書の内容と実際に出来上がったシステムを見比べ、相違がないかを念入りに確認します。

10:30｜テスト項目の作成

システムが正しく動作するかをチェックするための「テスト項目」を作成します。「これくらいで大丈夫だろう」と妥協したり、思い込みで判断したりせず、あらゆる異常系のパターンを想定して細心の注意を払います。網羅的に確認する必要があるため、この項目作成だけでも半日から1日かかることがあります。

12:00｜ランチ休憩

テスト項目の作成が一段落したところで、お昼休憩をとります。

13:00｜テストプログラムの作成と実施

作成したテスト項目に基づき、テストを自動化・効率化するための専用プログラムを記述し、実際にテストを動かして問題がないか、バグが潜んでいないかを徹底的に検証していきます。ここでは、仕様通りに動くかを確認するだけでなく、「お客様が実際に使う時に使いづらくないか」「作った後の運用に支障はないか」というユーザー目線と運用目線を常に持ちながら確認し、不具合があれば迅速に修正対応を行います。

19:00｜退勤

無事にすべてのテストがクリアできたら、この日の業務は終了です。オンオフのメリハリをつけて帰宅します。

あえて「ゼロ」から作ることで得られる面白さと成長

ここからは、Hさんが感じているIIJエンジニアリングでの開発事業のやりがいや難しさ、働き方に対して感じていることなどについてさらに深くお聞きします。

ーーIIJエンジニアリングに入社を決めた理由を教えてください。

自身の技術力をゼロベースから高められる環境に惹かれたからです。前職でも開発を行っていましたが、最近はAWSなどのクラウドサービスを使えば、土台を自分で準備しなくてもシステムが動いてしまうことが多いんです。

しかし当社では、OSなどの下の階層からしっかりと触れ、ゼロからシステムを作り上げる機会があり、そのための環境も整っています。根幹から仕組みを理解し、実際に手を動かして開発できる点と、日本のインターネット黎明期を切り拓いてきたIIJグループとしての、確かな技術基盤と歴史への信頼感が決め手になりました。

ーー入社後の印象についてはいかがですか？

周囲にいる先輩やベテランエンジニアの方々は、インフラやOSといった技術的な根本原理をしっかりと理解されています。その技術力の高さには、入社当初本当に驚かされましたね。

レベルが非常に高いため、周囲についていくための苦労や大変さはもちろんあります。それでも、日々の業務を通じて多くの刺激を受ける毎日です。入社前と比較しても、自分自身の技術力は確実に良い方向へ伸びていると実感できるようになりました。

ーー技術力以外に以前と変わったことなどはありますか？

私たちの部署は「システムを作って引き渡して終わり」ではなく、リリース後の運用やその後の改善プロセスまで一気通貫で手がけています。自分たちが作ったシステムを自分たちで長く運用していくからこそ、使う側の視点に立ち、「どう設計すれば使いやすく、その後の運用を効率化できるか」を常に当事者として深く考える習慣が身につきました。

ーー業務における面白さややりがいは、どんなところにありますか。

やはり、複雑に組み合わさっているIT技術を自分でしっかり読み込み、実際に手を動かして理解できた瞬間に最も楽しさを感じます。ゼロからシステムを作ることで、クラウドの裏側にあるシステムの挙動が深く理解できるようになりました。

また、「中長期のシステム稼働だとクラウドよりもオンプレミスの方が安い場合がある」など、ビジネスや費用の構造も含めた新しい発見があることに、技術者として大きな面白みを見出しています。

ーーゼロベース開発ならではの難しさには、どのように向き合っていますか？

技術的な仕組みは非常に難解であり、人から説明されてもすぐには理解できないことも多く、本質的な理解を得るには大きな苦労が伴います。そのため、知識をただインプットするだけでなく、実際に手を動かしてプログラムを動かしてみるという検証努力を大切にしています。

また、理解を深めるための対策として、自分で調べたことをアウトプットすることも意識するようになりました。開発チーム専用の「知識共有Wiki」というWikipediaのようなナレッジベースが社内にあるため、そこに自身の学んだ内容を書き残してアウトプットしています。これによって組織へのナレッジ共有と、自分自身の確実な理解への落とし込みを両立させています。