【現場経験者が語る】アジャイル開発って実際どう？筆者が感じたリアルな実態

「アジャイル開発ってよく聞くけど、実際の現場ってどんな感じなんだろう？」

未経験からエンジニア転職を考えている人や、新卒でIT業界を目指している人なら、一度はこんな疑問を持ったことがあるのではないでしょうか。

スクラム、スプリント、マイクロサービス…。

言葉だけを見ると、正直よくわからないですよね。

この記事では、筆者が実際に参画したアジャイル開発（大規模プロジェクト）の現場経験をもとに、

• アジャイル開発の仕事内容
• 良かった点・大変だった点
• 未経験者が参画したときのリアルな感覚

を、できるだけ噛み砕いてお伝えします。

「現場に出たら何をするのか」を具体的にイメージできる内容になっています。
※あくまで筆者の体験談のため、すべてのアジャイル開発がこの記事内容に当てはまるとは限りません。参考にして頂けましたら幸いです。

アジャイル開発とは？

アジャイル開発とは、短い期間（スプリント）で設計・開発・テストを繰り返しながら進めていく開発手法です。

ウォーターフォール開発のように、

• 最初にすべてを決めきる
• 後戻りはほぼしない

というやり方とは異なり、

• 状況に応じて要件や設計を見直す
• 小さく作って、動かして、改善する

というのが特徴です。

今回筆者が参画したのは、

大規模プロジェクト × アジャイル開発 × マイクロサービス構成

という、比較的モダンな現場でした。

筆者が参画したアジャイル開発案件の概要

まずは、どんな現場だったのかを整理します。

プロジェクトの規模と目的

• 大規模システムのリプレイス案件
• 現行システム → 新システムへのマイグレーション
• 基本ミッション
  
  →「今までと全く同じように動く新システムを作る」

つまり、

• 新機能をどんどん追加する案件ではなく
• 現行踏襲＋一部仕様変更が差し込まれる

という、意外と難易度の高い内容でした。

作業範囲

• 詳細設計
• 実装（開発）
• 単体テスト

いわゆる「下流工程」がメインです。

開発スタイル

• マイクロサービス単位で設計・開発
• サービスごとに担当が割り振られる
• アジャイル（スプリント単位）で進行

1つの巨大なシステムではなく、

「小さなサービスの集合体」を作っていくイメージです。

実際にやっていたこと

① マイクロサービスの設計

まずは担当するマイクロサービスについて、

• 入力（I：Input）
• 出力（O：Output）
• 中で何をしているか（処理内容）

を設計書に落とし込みます。

この時点では、

• 現行システムの仕様を読み解く
• 「なぜこの処理があるのか」を理解する

という作業が多く、コードを書くよりも構造を理解する力が求められました。

② 実装（開発）

設計が固まったら、実装に入ります。

• 設計書どおりにコードを書く
• 他サービスとの連携を意識する
• 想定外のデータが来た場合の考慮

ここでは、
「設計をちゃんと理解していないと書けない」
という場面が多く、設計の重要性を強く実感しました。

③ 単体テスト

実装が終わったら、単体テストです。

• 正常系
• 異常系
• 境界値

などを洗い出し、

「このサービス単体で正しく動くか」を確認します。地味ですが重要な工程です。

アジャイル開発のメリット（現場で感じたこと）

要件・設計の見直しを経験できる

アジャイルでは、

• 要件定義に立ち返る
• 設計を修正する

ということが珍しくありません。

はじめのうちは、「決まったものを作るだけ」になりがちですが、

• なぜこの仕様なのか
• 本当にこの設計でいいのか

を考える機会があり、エンジニアとしての視点が鍛えられました。

設計〜開発〜テストまで一貫して担当できる

マイクロサービス単位で任されるため、

• 設計
• 実装
• 単体テスト

を一気通貫で経験できます。

「一部分だけ永遠に実装する」といったことが少なく、仕事の全体像が掴みやすかったです。

アジャイル開発のデメリット（正直しんどかった点）

要件変更＝作り直しになることがある

要件定義から見直しが入ると、

• 途中まで作ったものが無駄になる
• 設計からやり直し

ということも普通に起こります。

精神的には、

「今までの作業、何だったんだろう…」

となることもしばしば・・・（笑）

同じような作業の繰り返しになりやすい

マイクロサービスの数が膨大なため、

• 基本構造は似ている
• やることも似ている

という状態になりやすいです。

また、大規模プロジェクトだったため期間も長く、なかなか終わりが見えないのも正直な感想でした。

筆者が「やりやすい」と感じた理由

実はこの案件、筆者にとってはじめての参画案件でした。

それでも「やりやすかった」と感じた理由があります。

途中参画でも入りやすい

マイクロサービス単位で作業が分かれているため、

• 途中から入っても
• 担当サービスに集中すればOK

現在ウォーターフォール開発の案件に参画しているのですが、ウォーターフォール開発と比べると

キャッチアップしやすいと感じました。

段階的に任せてもらえた

最初は、

• 実装
• 単体テスト

が中心でしたが、慣れてくると設計も任せてもらえるようになりました。

「いきなり全部やれ」
ではないのが、未経験者にはありがたかったです。

スプリントレビューの経験ができた

特に印象に残っているのが、スプリントレビューです。

• 担当したマイクロサービスについて説明
• I/Oや処理内容を言語化
• テスト観点の説明
• フィードバックをもらう

この過程で、

• 自分の理解不足に気づく
• 他人に説明できるレベルまで理解する

という経験ができ、技術理解が深まりました。

未経験者が知っておくべき「現場のリアル」

アジャイル開発は、

• 華やか
• 自由
• 早い

というイメージを持たれがちですが、

• 地道
• 試行錯誤の連続
• やり直しも多い

というのがリアルだなと感じました。

ただし、

• 成長スピードは速い
• 学べることは多い

というのも事実です。

アジャイル開発で成長しよう！

アジャイル開発は、

• 変化を楽しめる人
• 考えることが好きな人
• 自分で改善したい人

に向いています。
はじめての案件でいきなりアジャイル開発でしたが、意外とやりやすかったです。

未経験からエンジニアを目指す人にとっても、「現場でどう成長していくのか」を知る一歩として、今回のリアルな話が参考になれば嬉しいです！

これからエンジニアを目指す方は、ぜひ「現場のリアル」を知ったうえで、一歩を踏み出してみてください！
弊社では一緒に頑張れる仲間を募集しています。未経験でももちろんOK！（筆者も未経験でした😊）
まずは完全無料のオンラインでできるプログラミングスクール「ZeroCode」試してみませんか？