Amazon Web Services ブログ
製造業向けデモダッシュボード開発で、アジャイル開発宣言の原則の重要性を再認識した話
こんにちは。元自動車メーカ出身ですが、クルマではなく舶来バイクが好きで、休日にはいつもバイクをいじくっているソリューションアーキテクトの岩根です。
社内で「製造業のお客様に Amazon QuickSight の良さを知ってもらおう！そのために AWS Summit に展示しよう！」と有志で始めた製造業向けのデモダッシュボードを開発する中で、デモのアセットとともに、とても良い気づきがあったね！この開発体験って素敵だよね！という会話になり、ブログをしたためることにしました。
製造業向けの QuickSight ダッシュボードは、先日行われた AWS Summit Tokyo 2023 の製造/IoT ブースで展示させていただき、好評いただいたもので、有志 4 名のソリューションアーキテクトで、2 月の本格始動から、コンセプト・ユースケース策定、ユースケースの深掘り、デモダッシュボードのデベロップと、4 名それぞれの得意領域を活かして開発したものです。
今回はその開発がどのように進められたか、その中で得た学びや気づきを記事にしていきます。
DXの流れで世は内製化へのシフトが加速していますが、事業部門と IT 部門の協業は思ったより難しいものです。例えばお互いの使っている言葉や考えてることが伝わらず苦労したり…。そんなときお互い学び合う姿勢で歩み寄ってみると良いことがある！といった話としてお読みくださると幸いです。今回の事例で具体的には、以下のようなところがキーポイントになったと感じています。
- 何を目指しているのか、のコンセプトを早期に合意する
- 共通理解したものをすぐに形にして、ビジネス側の人からフィードバックを得て、改善し続ける
- 更なる共通理解のため、どんな背景でどんな課題があるのかをナラティブで表現する
- 立場を超えて自分ごととして捉え、共通の目標に向かって自ら最善を尽くす
また、この開発のストーリーを解説した動画も公開しておりますので、あわせてご覧ください。
アジャイル開発宣言の背後にある原則
いきなり、私の大好きなアジャイル開発宣言の話になりますが、アジャイルソフトウェア開発宣言には、アジャイル宣言の背後にある原則として 12 の原則が謳われています。その一節に、「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」というものがあります。今回の開発体験を振り返ったときに、まさにこの原則の重要性を体感できるものだったことに気づきました。アジャイル開発宣言は、何度読んでも新しい気づきがあって、無駄を削ぎ落として研ぎ澄まされた素晴らしい文だと改めて思いました。
開発体制
ここで本格始動からのメンバー体制を振り返ってみます。全員本業はソリューションアーキテクトであり、普段はお客様の技術的な支援をしているため、4 人のスケジュール上無理のない範囲で活動していました。組立製造業の生産技術経験者 2 名、プロセス製造業のエンジニア出身 1 名、新卒 3 年目 1 名という体制で、基本的に有志で集まったメンバーです。ここは「意欲に満ちた人々を集めてプロジェクトを構成します」に通ずるものがありますね。重要なのは、製造のドメイン知識を実務ベースで持っているメンバーと、開発が得意なメンバーの混在チームだったことです。「ビジネス側の人と開発者」が同じチームで仕事していたわけですね。開発そのものは、週 1 の定例会で方針決めや進捗の同期を取りながら、というスタイルで進めました。
実際にコンセプト決めをして活動を開始したのが 2 月中旬で、4 月の AWS Summit Tokyo に出展したので、期間は 2 ヶ月強といったところですね。
コンセプト固め
2 月中旬にコンセプト固めのためのディスカッションをしました。この際は 2 人で、たまたまお互い出社していたので対面でやろう、という話になり、そこらへんの壁にあったホワイトボードに落書きをしました。ベースの着想は「物と情報の流れ図」からヒントを得ています。ソフトウェア畑の方は、Value Stream Mapping という呼称の方がしっくりくるかもしれないですね。基本的に製造業での物と情報の流れを現状分析して、どこにボトルネックがあるのか、どう改善すれば良いのか、という活動に使われるものなのですが、「これが日次でダッシュボード化されてたら便利だよね」という会話からスタートしたのを覚えています。その上で、工場などでの「隠れ在庫」のような、なかなか把握しづらいものが実態として掴めて、なおかつそれがキャッシュフロー的にどうなのか、という金額で表現しよう、という議論になりました。改めてできあがったダッシュボードを見ると、驚くほど初期コンセプトがそのまま初志貫徹されていました。
図1: 初期コンセプトのホワイトボーディング
初期構築
コンセプトを 4 人で集まって確認したのち、製造業出身のメンバーが翌日くらいに文字通り「爆速」で絵にしてくれました (図 2)。また並行して、QuickSight のダッシュボード初期バージョンもそのまた翌日「爆速」で形にしてくれました (図 3)。議論のたたき台が整ったので、実際に製造業での改善の経験があるメンバーから、製造業ではどういうところが重視されていて、どんな課題があるのかというような、プチ勉強会のようなこともやっていました。背景の異なる 4 名が、ビジネス側のことをキャッチアップしつつ、学んだことをすぐに形にする、というサイクルがこのあたりから回り始めました。
図2: コンセプトを形にしたもの
図3: 最初のダッシュボード
課題のナラティブ化
ダッシュボードのデベロップと並行して、背景となるストーリーをナラティブとして明文化する作業も共同で進めました。もともと Amazon や AWS には古くから、チームや個人の計画を立てるための文書で、パワーポイントのプレゼンテーションを使わず、ナラティブで企画をまとめ、全員で黙読するところから会議を始める、という文化があります。それに則り、このダッシュボードで解決したい課題は何で、どういう背景があるのかというストーリーをまとめたわけです。例えば製造業のバックグラウンドがあるメンバーが過去の経験をストーリーに反映することで、方向性にブレが生じにくくなり、リアリティを持って第三者に説明することができます。AWS Summit Tokyo 展示の説明も 4 名で回していたのですが、このナラティブが一貫した背景に基づいた説明を提供することに非常に役に立ちました。
また、FAQ も作成して、このダッシュボードが「なにであって、なにでないのか」というところを明文化しました。こちらも非常に役に立ちましたね。
機械部品の組立製造を行う中堅メーカーの A 社では、近年、同社主力である W 製品のキャッシュフロー悪化が続いており、製品責任者は対応に苦慮していた。原因として、製造部品の高付加価値化が進んでおり、これまで取り扱わなかった特殊部材を使用するラインが増え、また半導体不足やレアメタル価格高騰の影響もうけ材料原価が上昇し続けているため、これまでと同量の在庫を抱えているだけでも悪化要因となってしまう状況が考えられる。さらに、各工場での在庫最適化を徹底してはいるが、世界各地の拠点がサプライチェーンを構成しており、各工程の隅々まで指導を行き渡らせることが困難な状況となっている。また、各工程やストックには適正在庫量が定められているが、ラインストップや出荷遅延を防ぐという観点から、各工程で積み上げたバッファが累積的に大きくなり、いわゆる「作りすぎの無駄」を抱えていることがわかっている。それに加えて、各工程での左記を背景にした心理的要因も手伝って、「押せ押せ」の生産になった結果、適正在庫量を超えた仕掛かり品がラインサイドやストックヤードに溢れかえっており、実態の把握も困難な状態である。このような背景から、A 社はサプライチェーン全体の在庫最適化に取り組むための方策を検討している。
仕損費に関しては、自工程完結を謳ってはいるものの、実態としては後工程で発覚する不具合も多発しており、仕損費増大の一因になっている。源流工程でのカイゼンは続けているものの、吐き出し量を優先した結果、不具合発生工程から源流改善に繋げられない事例も多く、悪さ加減を正しく可視化した上での全体最適な施策を優先度をつけて実施していくことが急務となっている。
ナラティブ化した背景ストーリー
個々人のさまざまな貢献
開発全体を通じて言えることですが、事前に役割を決めるアサイン式ではなく、各人ができることを手を挙げてやっていくサインアップ式で進めていきました。各自の時間的制約の中で、取り組みを通じてモチベーションを高めていき、だんだんチームとして強くなっていくことが実感できましたね。
- 「全体像がわかる絵を、かっこよくしたい！」みたいな課題に対して、builders.flash グラレコシリーズでおなじみのテクニカルライター米倉さんに原案を作って依頼 (図 4)
- ダッシュボードに表示するデータの準備 (これが大変！) と、ダッシュボードへの取り込み
- 例えばパレート図のような、製造観点からのダッシュボードの表現方法フィードバック (図 5)
- AWS Summit Tokyo 直前に展示内容を PR するブログ記事の投稿
- FAQ の拡充
- アーキテクチャ図の作成
- 展示関連のさまざまなミーティングへの出席
図4: 完成した絵
図5: 完成したパレート図
完成！
そんなこんなであっという間に AWS Summit Tokyo 本番となり、図 6 のようなダッシュボードを展示することができました。練り込んだナラティブとそれを具現化したダッシュボードのおかげで、「これはすぐにでもやりたい！」というポジティブなリアクションを多くの製造業のお客様からいただくことができました。さらには登録不要で QuickSight ダッシュボードをお試しいただける DemoCentral に掲載し、実際に製造業のお客様が自社の課題解決に役立てられるようなアセットとして、公開しています。
図6: 完成したダッシュボード
まとめ
アジャイル開発宣言における「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」の原則に則って、製造のビジネス的な知見のあるメンバーと、開発の知見のあるメンバーが、それぞれオーナーシップを持って、有機的に役割を持ちながら活動したことによって、週 1 の活動を 2 ヶ月というタイトなスケジュールの中、思いを形にすることができました。開発の体裁こそアジャイルの開発手法に則ったものではありませんが、ビジネス面と開発面双方の知識を備えたフルスタックなチームが自己組織化して取り組み、真に「アジャイルな状態」であったと思います。このことは開発に携わった 4 名共通の学びであったし、今後に活きる貴重な体験だったと思います。
ビジネスと IT の融合が不可欠な昨今、ひとつのモデルケースとして、少しでもご参考になれば幸いです。
図7: 開発メンバー
著者/開発者紹介
 |
岡本 晋太朗 (Shintaro Okamoto)アマゾン ウェブ サービス ジャパン合同会社 石化プラントの計装制御設計エンジニアを経て、プラントデジタルツインソリューションの構築に従事。現在は AWS Japan で製造業のお客様を中心に技術支援を行っています。趣味はコーヒー。美味しいコーヒー豆の通販サイトを探してネットの海をさまよっています。 |
| |
黒田 雄大 (Yuta Kuroda)アマゾン ウェブ サービス ジャパン合同会社 自動車部品サプライヤーの生産技術部門、情報システム部門、Smart Factory プロジェクトを経て AWS Japan に入社。エンタープライズ事業本部でソリューションアーキテクトとして東海圏の製造業のお客様を中心に技術支援しています。 |
 |
稲田 大陸 (Riku Inada @inariku)アマゾン ウェブ サービス ジャパン合同会社 2021 年 4 月に AWS Japan に入社し、筋トレが趣味なソリューションアーキテクトです。現在は製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは AWS Amplify と Amazon Location Service です。週末には美味しいお酒を求めてフラフラしています。 |
 |
岩根 義忠 (Yoshitada Iwane)アマゾン ウェブ サービス ジャパン合同会社 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 |
