SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 Summer レポート(PR)

アジャイル開発だからこそできた! 基幹システム刷新プロジェクト【デブサミ2022夏】

【B-5】基幹システムの刷新をアジャイル開発で取り組んだ時の課題や成果

  • このエントリーをはてなブックマークに追加

 企業の基幹システムや大規模システムになると「開発モデルはウォーターフォールで決まり」と反射的に答える方は少なくないだろう。すべてが予定通り進むと決まっているなら、ウォーターフォールを選ぶのが最も良いやり方だが、システム開発において「想定外」のことが起こらないことなどほぼあり得ない。大規模システムの開発でウォーターフォールが大きな実績を残してきたことは確かだが、それは何年前の話だろうか。株式会社SHIFTの丸山佳紀氏は、ある企業の基幹システムの刷新にアジャイル開発で取り組んでいる。その経験から、アジャイル開発だからこそ得られたメリットなどについて語ってくれた。

  • このエントリーをはてなブックマークに追加

株式会社SHIFT サービス&テクノロジー本部 技術統括部 DevOps推進部 DevOps推進3グループ 丸山佳紀氏
株式会社SHIFT サービス&テクノロジー本部 技術統括部 DevOps推進部 DevOps推進3グループ 丸山佳紀氏

ウォーターフォールではなく、アジャイルだからこそできたこと

 SHIFTの丸山氏はアジャイル開発だからこそのメリットを、現在携わっているプロジェクトを例に話してくれた。そのプロジェクトは、ある会社が長年使用してきた基幹システムの刷新プロジェクトだ。「会社の成長とともに必要になった機能を追加してきたが、データモデルや処理が複雑になり、現在の業務に合わない機能も多くなった。現在となっては無駄な手順も多くなってしまった。メンテナンスもしにくくなっているので刷新したい」という内容で依頼を受けたという。

 このプロジェクトに丸山氏が所属するSHIFTはQA(Quality Assurance)担当として参加した。メンバーは職能別にベンダーごとの得意な部分を活かした編成になっており、丸山氏が所属するQA担当のほかにはバックエンド担当、フロントエンド担当、DB担当、インフラ担当、旧システム担当がおり、それぞれ別々のベンダーが担当している。

 プロジェクト開始当初はそれぞれの担当を集めた1つのチームで作業が始まり、その後3段階のステップを踏みながら作業が本格化していったという。1ステップ目はツールの選定、環境構築、アジャイル開発をどのように進めるかの検討の時間を使い、2ステップ目は自動テストを導入してバグ検知体制を構築した。3ステップ目を迎え、テストの進め方が分かってきたところで、チームを複数に増やして開発スピードを向上させていったそうだ。

 システムは「問い合わせ」や「契約処理」などの業務単位でプロダクトを区切って開発していった。業務単位で完成したらプロダクトを順次リリースしていく形だ。このあたりはシステム全体を一気に完成させるウォーターフォールとは異なるところだ。

「問い合わせ」「契約処理」「発注処理」といった業務単位でプロダクトを区切り、完成次第順次リリースしていった
「問い合わせ」「契約処理」「発注処理」といった業務単位でプロダクトを区切り、完成次第順次リリースしていった

 スプリントは2週間に設定。とはいえ、2週間でプロダクトをリリースできるわけではない、リリースに必要な機能を少しずつ作っていき、4~12週間かけて完成させてリリースという形を採った。1回のリリースまでに複数回のスプリントを回すことになる。

 ここまで説明してきた体制を見ると、アジャイル開発で取り組むことが分かる。丸山氏は基幹システムや大規模システムにアジャイル開発は向いていないという話もよく聞くという。しかし、個人的には「そんなことはない」と思っているそうだ。

 例えば丸山氏は「ウォーターフォールで事前に綿密に予定を立てても、実際は予定通り進むことなどない」と実感しているという。今回のプロジェクトでも実際に、開発が始まってから半年がたった頃に基幹システムへの新規の機能追加依頼が経営層からやってきたと実例を挙げる。

 もしも今回のプロジェクトでウォーターフォールを採用していたとして、こんな依頼がやってきたら大騒ぎになることは間違いない。「ウォーターフォールで進めていたとしたら、ようやく設計が終わってこれから実装していこうという段階だ。新機能をどうやって実装すれば良いのかをかなり考えなければならない。そして、システム全体の開発期間が延びることになるが、それでも良いのかという問題もある。ウォーターフォールは柔軟性に欠けると言わざるを得ない」

 今回のプロジェクトでは、業務単位でプロダクトを区切って、完成次第順次リリースしていく方針を採っていたため、新機能の優先順位を考えて、プロダクト開発のすき間に新機能の開発スケジュールを差し込んで、無理なく対応できたという。丸山氏は「アジャイルなら優先度に応じて開発予定を柔軟に変更できる。どちらが優先なのかを考えられるのがアジャイルの良いところ」と語っている。

次のページ
アジャイルなら、システムによる効果が早い段階から現れる

関連リンク

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
Developers Summit 2022 Summer レポート連載記事一覧

もっと読む

この記事の著者

笹田 仁(ササダ ヒトシ)

 フリーランスのライター、編集者。IT、特にソフトウェア開発の話が好きです。 趣味はドラムを叩くこと。コロナ騒ぎでリハーサルスタジオに入りにくくなり、ちょこちょこと楽器を買うことでストレスを解消していたら、いつの間にか置き場所に困るほどになってしまいました。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16357 2022/09/21 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング