DXトレンド④ ―アジャイルその1―

テク仁(えんまん七福仁 IT技術担当)のつぶやき – その4

EnMan社にてCTOを勤めさせて頂いている石井慎一郎です。
EnMan社が、一流IT企業との開発・PMO連携、サービス事業提供、更なるアジア圏ビジネス隆盛を目指す中で、その背景にある昨今のIT技術やシステム動向について徒然なるままに認めます。

前回は、SoR、SoE、そしてSoIという言葉について、その特徴を説明しました。
特に、SoE、企業を取り巻く外部環境(個人消費者や取引先)の嗜好多様性を意識して、的確に新サービスを提供するものは、何がヒットするかを事前に予測することが難しいこともあり、実現・改修の素早い対応が求められることになります。
つまり、早期にマーケットや実業務に投入して、その評価結果を以て、次の開発計画に反映する、もしくは開発中止をも判断するような、スピード重視のサイクルが重要になります。

このような「スピード重視」を実現するために、開発プロセスも進化してきています。そのうちの1つである、アジャイル(Agile)型開発プロセスについて採り上げてみます。

【計画主導型(ウォーターフォール型)開発プロセスとアジャイル型開発プロセス】

この2つのプロセスは、自動車製造業の生産管理手法の議論がベースになっています。
自動車産業の先駆けとして、フォード・GMに代表されるライン生産方式にあります。つまり、同じ作業はまとめて対応する方が効率的であるということより、同じ作業が行われる工程をまとめて実施し、完成後に、成果物を、次のラインに引き渡すことになります。

一方、トヨタは「ムリ・ムダ・ムラ」の徹底的排除を目指して、「Just In Time」や「かんばん方式」などを含む、新たなトヨタ生産方式を確立しました。例えば、「セル生産方式」という言葉もありますが、1人または少数の作業者チームが、部品や工具を、キオスクのような作業場所で成果物の組立工程を完成まで受け持つ生産方式になります。

大量生産を目的としたライン生産方式は、以下のようなデメリットもあります。

  • 投入から完成までの仕掛り在庫は増加し、製造リードタイムが長くなる
  • ラインの整備時間が掛かるので、成果物の変更がしにくい

上記に対して、セル生産方式では、以下のようなメリットがあります。

  • 各セルが独立して異なる品目を作ることで多品種少量生産にうまく対応できる
  • セル内で組立が完結するため、工程間の仕掛り在庫が大幅に削減され、各セルが独立して生産を行うため、他のセルの遅れによる影響が発生しません。

ただし、デメリットもあって、セル生産方式は、一人あたりの作業内容が広くなるため、作業者が「多能工」になる必要があります。よって、作業者の育成には時間が掛かってしまいます。
この「多能工」というキーワードは、実はアジャイル型開発プロセスでも重要な意味を持つことには留意しておきたいところです。

【アジャイルソフトウェア開発宣言登場】

アジャイル型開発プロセスが世の中で大きな動きとなったのは、2001年にアジャイル型開発プロセスに関する有名人がスノーバードの地に会して、「アジャイルソフトウェア開発手法」と呼称を変え、さらに「アジャイルソフトウェア開発宣言」が発表されました。

「計画」よりも、

  • プロジェクトメンバ個人との対話
  • 早く動かす
  • お客さま視点重視
  • 変化を恐れない

ということが謡われました。

【アジャイル型開発プロセスの特徴】

アジャイル型開発プロセスでは、「動くプログラムを早く提供することを第一目標にする」ことが求められます。これを実現するために、反復(イテレーション)開発とテストファーストの考え方が大きな特徴になります。

 ①反復(イテレーション)

アジャイル型開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用しています。ひとつのイテレーションで、ひとつの機能を開発し、これを反復を繰り返し継続して行うことで、完成を目指します。

各々のイテレーションでは、従来の計画主導型(ウォーターフォール型)開発プロセスの計画、要求分析、設計、製造、テスト、文書化といった全ての工程を行います。そして、イテレーションの最後には、機能追加された新しいソフトウェアを動く形でリリースすることになります。

テストファースト

早期に提供する、つまり無駄な開発を極力省くためには、開発対象ソフトウェアに対して、開発する機能に対して、最初の段階でテスト項目を設定し、そのテストを通すことを第一に開発を進めるという考え方があります。これは、「テスト駆動開発」という手法におけるテストファーストの概念を取り入れたものになります。

いくら実装すべき機能の定義をしっかりしたとしても、その確認はテストを通じて行うことを鑑みると、テストは通るけれども、必要のない余計なコードも開発してしまうことは多々ありますよね。
しかし、テストを通すことのみに注力してコード開発すれば、必要最小限でのコード開発で済むということになるわけです。

勿論、開発を繰り返す中では、一部既存のコードの改修が発生する場合もありえます。
そのために、よりコードを洗練するための「リファクタリング」という技術も視野に入れる必要があります。

※リファクタリング(Refactoring)
プログラムの動作を変えずに、中の構造を整理することを指します。
まずは見た目の動きを実装し、次いで中身を洗練していくようなアプローチもよくとられることより、改めて意識しておきたい用語です。

【アジャイル型開発プロセスのチーム構成とコミュニケーション】

 まずはチーム作り

 チーム作りで心掛けるポイントは、次の2点です。

  • 利用者やお客さまからも、チームメンバーにプロダクトオーナーとして参画
  • 開発チームはメンバー内議論を通じて、最適なやり方や課題解決を図る自律性を持つ

アジャイルの代表的な手法であるスクラムでは、開発チームに「スクラムマスター」というリーダーが設定されます。スクラムマスターは、プロダクトオーナーと開発チームが正しく連携して開発を進めることを支援し、阻害要因があれば排除するミッションを負います。

※短期に動くソフトウェアを仕上げる必要があるため、開発チームメンバーの役割は、開発に係る全てのスキルが揃っている必要があります。
ただし、アジャイル型開発プロセスの場合には、コミュニケーション効率の観点から、プロジェクト全体でもMax10名までとなります。
よって一人のメンバーが複数の役割を担う「多能工」、「フルスペック要員」が必要になります。

毎日のコミュニケーション

開発中に、開発メンバー全員で毎日、進捗状況や本日やるべき項目について確認を行  うことが、短期開発にはとても重要になります。通称、「朝会」とか「毎朝ミーティング」とかも、皆さんも行ったことがあるかもしれません。

開発メンバー全員で、以下を確認します。

  • 昨日やったこと(前回からの進捗)
  • 今日やること(次回までの計画)
  • 作業を進める上で困っていること(問題点)

これは、毎日行われることより、短時間で、そしてそこで議論を行うことなく、速やかに完了することが肝要になります。その際、上記を効率的に確認するために、徹底的に可視化を行いまことも重要になります。

進捗管理には、ガントチャートを用いて進捗を確認することが多くありますが、アジャイル型開発プロセスにおいては、さらにより視覚的に分かりやすいノウハウ(プラクティスと称する)が多くあります。ここでは、1つだけ、例を挙げておきます。

※進捗の可視化…バーンダウンチャート
縦軸に作業量、横軸に期間を示しています。
今回のイテレーション内で対応する作業量の集計に対して、平準化して対応した場合を予定の直線とし、実際の対応状況をプロットしたものになります。

右図は日が経つにつれて残作業量がどれだけ減っているかを示すことになりますので、

予定に対して遅れているのか進んでいるのかが一目で分かるわけです。

さて、次回は、アジャイル型開発手法の代表的な手法としてスクラムやXPについて解説するとともに、スクラムに基づく開発の進め方を解説してみます。

この記事の執筆者

石井 慎一郎

1984年 東京大学卒、日本電気㈱入社
ソフトウェア開発研究部門 配属(18年) 、金融システム開発、SI部門(13年)、グローバルビジネス推進部門(CTO)(3年)
時代の最新ソフトウェア・アーキテクチャの研究開発経験を礎に、ビジネスの最前線への適用、大規模SIでの顧客対応、最新技術プロダクトのグローバル展開を行った貴重な経験を持つ。
2018年末 日本電気㈱退職。個人事業主にてIT領域で企画・開発支援等、幅広く活動。
2020年7月~ EnMan Corporation 取締役CTO