【実録】製造業のファクトリーIoTでアジャイル開発してみた：製造業のためのアジャイル開発入門（5）（1/3 ページ）

複雑性／不確実性に対応するためソフトウェア開発業界で広く採用されている「アジャイル開発」の製造業での活用法を紹介する本連載。第5回は、製造業のファクトリーIoTの開発で、どのようにアジャイル開発を導入し、活用したのかを紹介する。

[松尾俊佑（クリエーションライン），MONOist]

　こんにちは。本連載ではアジャイルとは何かの基礎から始まり、アジャイル開発導入のポイント、導入がつながる未来などについて紹介してきました。

　そこで今回は、実際に製造業の現場でアジャイル開発をしてみたメンバーがその実態を紹介してみたいと思います。

⇒連載「製造業のためのアジャイル開発入門」バックナンバー

工場をIoT化するファクトリーIoTのAPI開発

　今回紹介するプロジェクトは、ファクトリーIoT（モノのインターネット）の事例です。

　このプロジェクトは、工場をIoT化し、工場の設備に取り付けられたセンサーなどから情報をデータレイク／データマートにリアルタイムに蓄積し、稼働状況や品質情報などを必要としている部署に提供するシステムです。

　本事例で紹介するのは、その中で実際に工場から送られるデータを加工し、データレイク／データマートに格納する基盤アプリケーションの開発およびデータレイク／データマートに蓄積されたデータを取得するためのAPI開発を行うチームのお話です。

チーム構成

　プロジェクト開始当初のチーム構成は下記の体制でスタートしました。

• プロダクトオーナー（以下、PO）：1人
• スクラムマスター（以下、SM）：1人
• 開発者：5人
• アジャイルコーチ：1人

　開発者とSMは毎日プロジェクトルームに来て作業をしていました。POは週2日程度プロジェクトルームに来て、スプリントレビュー前に開発状況や作成物を確認していました。その後、スクラムチーム全員でスプリントレビュー、スプリントプランニングなどのスクラムイベントを実施します。また、アジャイルコーチは週1日、スクラムイベントに参加し、アジャイル開発の進め方などを教えてもらいました。

　このような体制で始まりましたが、現在はPO1人、開発者5人程度で落ち着いています。

アジャイル開発「守破離」の守

プロジェクト開始直後の様子

　チームメンバーはアジャイル開発経験のないメンバーばかりでした。そこで、アジャイルコーチに入ってもらった上で、アジャイル開発をスタートしました。スクラムを採用し、スプリントの期間は1週間にしました。

　最初に開発したのは下記のようなアプリケーションです（図1）。

• アプリケーションA：工場からMQTTプロトコルで送られてくるデータを受けてMQTTブローカからデータを取り出し、メッセージキューに送信する
• アプリケーションB：メッセージキューから取り出したデータを加工して再度メッセージキューに送信する
• アプリケーションC：加工されたデータをメッセージキューから取り出し、データレイク／データマートに登録する

図1　ファクトリーIoTプロジェクトで最初に開発したアプリケーション［クリックで拡大］

　MQTTブローカは「Mosquitto」、メッセージキューには「Kafka」を使用するなど、オープンソースソフトウェア（OSS）を多用しました。

　また、開発者の技術向上、成果物の品質向上を目的にモブプログラミングやTDD（テスト駆動開発）を採用しました。技術や品質の向上だけでなく、パッケージで開発した場合に比べ、はるかに短い時間で開発することもできました。

早速現れたアジャイル開発の効果

　アジャイル開発を取り入れた効果はすぐにでました。

　これまではベンダーに開発依頼をしていたため、機能の修正に2〜3カ月かかっていました。それに対して、今回の開発では1週間〜1カ月の期間で機能を修正することができました。

　このような効果が生まれたのは下記のような違いが大きな要因だと思います（図2）。

• 従来：ベンダーへの修正依頼の作成から始まり、ベンダー側と予算や開発工数、スケジュールなどの調整が入り、開発期間、テスト、受入と長期間が必要だった
• 今回：アジャイル開発で自社のチームが一体になって開発を行うことで、これらの期間を大幅に短縮、もしくは工程そのものが不要になった

図2　ベンダーによる開発とアジャイル開発の比較［クリックで拡大］

　これ以降の開発においても、ステークホルダーからの要求を次スプリントには反映し、迅速にリリースすることができています。

　また、当初これらのアプリケーションはプログラミング言語としてJavaを使って開発を行いましたが、コンテナで動かす観点からGoを使ったアプリケーション開発に切り替えました。Goでの開発経験のあるメンバーはいませんでしたが、チーム全体で学習、モブプログラミングを実施するなどして対応しました。こういった大きな技術的変化に対する対応力も、アジャイル開発ならではの柔軟性ではないかと思います。

　単純に考えるとGoで開発し直すなら、Goが得意なベンダーへ外注する手段が考えられますが、上記で紹介した通り、ベンダー開発では時間がかかり、タイムリーな開発ができません。アジャイルチームが自身で開発していくため、個々のアプリケーションを徐々にGoに変更していくこともできるため、ステークホルダーからの要求に答えながら、Goへの変更、さらにGoで開発したアプリケーションの改善も行うことができるからです。