「アジャイル開発とスクラム」入門

社内勉強会の資料です。

Transcript

1. 1 ©AR Advanced Technology All Right Reserved. 「アジャイル開発とスクラム」入門 Don’t do agile, be agile. 2021年06月16日(水) TechCoE事業室 中野康雄（＠yasuoyasuo） ❞ ❝ CulTech社内勉強会
2. 2 ©AR Advanced Technology All Right Reserved. はじめに：この機会が生まれた背景  アクセルを踏むタイミングの見極め • マーケットの成熟状況 • 現有戦力との相性  いよいよ機が熟したという判断（遅すぎた？） • 足元では実際のスクラム案件増加 • 技術部隊の組織的成長 • 採用状況を踏まえ、ARIの付加価値向上と魅力付け急務  先行事例から挑戦することに • 一部部門へのスクラムマスター研修参加への打診 • 自身でドッグフーディングとしてその研修に先行参加（4/19～23） 自身の勉強不足への反省と共に、 「ARIにとってメリットがあるのでは？」という予感が 強い仮説に変わった
3. 3 ©AR Advanced Technology All Right Reserved. 新しいことへの向き合い方：まず良く知ることから始める  まずは「アジャイル開発」の本質、利点と課題を深く知ろう。  「アジャイル開発」か「ウォーターフォール」の二元論的比較や、 ある単一のプラクティスを元にした拡大解釈による総論批評は避けたい。  多くの人が共感しているこの新しい価値観を ARIとしてどうすれば最も効果的に活用できるのか？ より多くの人と共に、実践を通じ学び、考えていきたい。
4. 4 ©AR Advanced Technology All Right Reserved. 参考書籍  スクラム概論 | Fintan https://fintan.jp/?p=949  平鍋健児・野中郁次郎・及部敬雄（2021） アジャイル開発とスクラム第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開 発マネジメント 株式会社翔泳社  本資料は以下2つの資料と書籍から大幅に引用させていただいています。
5. 5 ©AR Advanced Technology All Right Reserved. 今日のアジェンダ 1. アジャイル開発とは何か？ 2. なぜアジャイルなのか？ 3. スクラムとは何か？ 4. スクラム実践に向けた課題 5. 最後に
6. 6 ©AR Advanced Technology All Right Reserved. アジャイル開発とは何か？ その思想とウォーターフォールとの違い
7. 7 ©AR Advanced Technology All Right Reserved. アジャイル開発が世界で注目を浴びた場面 Agile2007でのSalesforce.com の事例発表 https://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference 年4回のリリースが年1回に • 最初の見積が不正確で、完成期限が守れず、テスト期 間が短縮されてしまう • 開発全体の進捗が不透明で、現状が正確につかめない • 機能に対する修正や変更のフィードバックが、開発の 最後になって届く • スケジュールが遅延し、リリース日の予測が困難に アジャイル開発にシフト • 年4回のリリースへ • 技術的負債の返済 • リリース期日の遵守 • 社内アンケートで 87%が「自己組織化されている」 80%が「新しい手法がチームの生産性を上げた」
8. 8 ©AR Advanced Technology All Right Reserved. アジャイルとは？ Agile – 【形】 機敏な、敏捷な 名詞ではなく、形容詞。状態を表す。 Don’t do agile, be agile ❞ ❝ アジャイル開発を行うのが目的ではなく、アジャイルな状態にすることが重要。 その核となる考え方や原則がまとめられたものに、”アジャイルソフトウェア開発宣言”と “アジャイル宣言の背後にある原則”がある。
9. 9 ©AR Advanced Technology All Right Reserved. 2001年、当時軽量ソフトウェア開発手法と呼ばれていた分野において著名な 17名が集まり、それぞれが重視していた部分を統合し、文書にまとめたもの。 日本で特に知られているのは、以下の6名。 • Kent Beck (XPの考案者、JUnitの生みの親) • Martin Fowler (PoEAAの著者。マイクロサービスという言葉の生みの親) • Dave Thomas (達人プログラマーなどの著者。ボブおじさん) • Robert C. Martin (Clean Code, Clean Coderなどの著者) • Ken Schwaber (スクラムの生みの親) • Jeff Sutherland (スクラムの生みの親) アジャイルソフトウェア開発宣言
10. 10 ©AR Advanced Technology All Right Reserved. アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/manifesto.html 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に 自由にコピーしてよい。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
11. 11 ©AR Advanced Technology All Right Reserved. 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 http://agilemanifesto.org/iso/ja/principles.html アジャイル宣言の背後にある原則
12. 12 ©AR Advanced Technology All Right Reserved. アジャイル宣言の背後にある原則(続き) 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html
13. 13 ©AR Advanced Technology All Right Reserved. ウォーターフォールの進め方 要件定義 外部設計 内部設計 実装・単体テスト 結合テスト システムテスト 受け入れテスト おなじみのV字モデル
14. 14 ©AR Advanced Technology All Right Reserved. 時間 要件定義 実装 テスト 設計 ウォーターフォール アジャイル 設計 実装 テスト 要件 定義 設計 実装 テスト 要件 定義 設計 実装 テスト 要件 定義 設計 実装 テスト 要件 定義 アジャイルとウォーターフォールのプロセスの違い 最後に動くものができる 動くものが徐々にできあがり、成長する
15. 15 ©AR Advanced Technology All Right Reserved. 出典: Scaling Software Agility プロセス ウォーターフォール アジャイル 成功の測定 計画通りに実行出来たか。 QCDによる測定。 変化への対応。 顧客満足。 競争力向上。 マネジメント 指揮命令型 トップダウン サーバントリーダーシップ フラット 計画 範囲固定で工数を見積る。 期日固定で範囲を見積もる。 要求と設計 最初に要求を洗い出す。 要求のすべてを設計する。 継続的に要求を受け入れる。 必要なタイミングで設計を行う。 実装 全機能を同時に開発。 優先順位の高い機能から開発。 テストと品質保証 終盤に実施。 早期から継続的にテストを実施。 アジャイルとウォーターフォールのプロセスの違い
16. 16 ©AR Advanced Technology All Right Reserved. イテレーティブとインクリメンタル イテレーティブ開発は最初から価値を作る。シンプルで最低限の機能しかないが、はじめから利用者の価値を実現するのがイテ レーティブ開発。毎回のイテレーションで性能や操作性を高めて洗練させていく。 インクリメンタル開発では完成するまで価値がない。中間成果物において価値が認められない作り方がインクリメンタル開発。 ＝反復する、繰り返す ＝増加の、増分の、徐々に増加する、漸増の アジャイル開発がイテレーティブかつインクリメンタルな開発であるのは、イテレーション毎に 既存機能を磨いていくだけでなく、新たな機能追加も行うからに他ならない。 引用元： イテレーティブ開発とインクリメンタル開発の違い – プロダクト・マネジメントの要諦 The Rules of the Game of Product Management
17. 17 ©AR Advanced Technology All Right Reserved. Agile Scrum XP Kanban Lean Crystal スクラムはアジャイルに包含される。 他にもXPやLeanの流れを汲むKanbanなどがアジャイルに含まれる。 アジャイルとスクラムの関係
18. 18 ©AR Advanced Technology All Right Reserved. ハイブリッドを合わせると、 70%がスクラムを採用 VersionOne 12th Annual State of Agile Report http://stateofagile.versionone.com/ アジャイルの中でのスクラムの採用率
19. 19 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  アジャイル開発では、期間を短く区切って優先度の高い機能から 実装することを繰り返すことで、最後にならないと動くものが見 えないリスクを軽減するとともに、ユーザーや顧客のフィード バックを取り入れながら開発する。  アジャイル開発は単なる手順やプロセスではなく、「アジャイル 宣言」に述べられている価値観に根ざしている。  アジャイル開発、という手法が存在するわけではない。アジャイ ル宣言に示された価値観を持つ開発手法は複数あり、その1つが スクラムである。
20. 20 ©AR Advanced Technology All Right Reserved. なぜアジャイルなのか？ ソフトウェア開発への要求の変化と 従来手法の本質的な課題
21. 21 ©AR Advanced Technology All Right Reserved. 出せば売れる時代は”どれだけ投資してどれだけ作れるか”というシンプルな構造だった。 少々の欠陥があっても売れるので問題なかった。 何が売れるか分からない、不確実なマーケット。 “どれだけ投資してもどれだけのリターンが得られるか” 分からない。 ビジネスモデルの賞味期限が短くなってきている。 価格競争 付加価値競争 予測可能 予測困難 マーケットの激しい変化に対応していかなければならない 企業を取り巻く環境の変化
22. 22 ©AR Advanced Technology All Right Reserved. ビジネスの不確実性がITに影響を与える時代へ 引用：https://note.com/tnagasawa/n/n0a3f05160b4e
23. 23 ©AR Advanced Technology All Right Reserved. ゴール共有型 ゴール分断型 我々や我々の顧客のビジネス環境が変わっている これまで以上に「スピード」と「変化への対応」が求められる 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
24. 24 ©AR Advanced Technology All Right Reserved. 従来手法の課題：典型的なウォーターフォールの特徴 1. 最初に、綿密な計画が作成される。計画では、最終製品が注意深く検討・設計さ れ、そして詳細に文書化される。 2. 計画を実施するために必要な作業が決定され、作業は「ガントチャート」や「マ イクロソフトプロジェクト」のようなツールを使って作られる。見積は、展開さ れた詳細見積の積算となる。 3. ステークホルダーが計画を詳細にレビュー・承認した後で、チームが開発に着手 する。 4. チームメンバーは各自が担当工程を受け持ち、作業が完了すると次の工程の担当 者に成果物を手渡す。 5. 開発が完了すると、製品は一旦品質保証を担当する組織に納品される。そこで最 終顧客への納品前にテストを行う。ここでは、最初の計画・設計通りに作られて いることを保証するために、全工程を通じて計画からの「ずれ」で管理される。 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
25. 25 ©AR Advanced Technology All Right Reserved. 従来手法の課題：典型的なウォーターフォールの特徴 このアプローチには、利点と欠点が ある。 利点は、非常に論理的である、とい うことだ。作る前に十分検討し、文 書化し、計画に従い、すべてをでき るだけ体系的に管理しようとする。 しかし唯一の欠点は、このプロセス に「人間」が関与していることだ。 このために、多くの問題が起こる。 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
26. 26 ©AR Advanced Technology All Right Reserved. 従来手法の課題：人間が関与することによる問題  人の創造性を奪ってしまう • 途中でより良いやり方が見つかっても採用できない  文書によるコミュニケーションには限界がある • 文書は頭の中で考えたことの不完全なコピー • 詳細に書いた文書ほど、なかなか読まれない  悪いタイミング • 重要なひらめきほど、変更が難しい最終段階で起こる  未来を読む水晶玉はない • 競合や市場の動き、人生の変動は予期できない  仕事が楽しくない • 厳密な工程は、仕事を渡す側と受け取る側に敵対関係を生み出す傾向がある  部分最適化 • 変更を阻むプロセスからは、平凡なプロダクトしか生まれない
27. 27 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  アジャイル開発が浸透してきた背景には、ビジネスの変化の速さがある。  アジャイル開発では、ビジネスとITがゴールを共有する。  すばやくフィードバックを得ることで、無駄な機能を作ることを防ぎ、 市場投入のスピードを上げ、ビジネスの投資対効果を高める  ソフトウェア開発は人間が行う仕事であるという現実に向き合った上で、 その課題を解決したいという意図もある。
28. 28 ©AR Advanced Technology All Right Reserved. スクラムとは何か？ ソフトウェア開発への要求の変化と 従来手法の本質的な課題
29. 29 ©AR Advanced Technology All Right Reserved. 1990年代前半に件シュエーバーとジェフ・サザーランドによって開発された アジャイル開発において用いられる代表的なフレームワークの1つ  軽量  理解が容易  習得は困難 特徴 3つの責任、5つのイベント、3つの成果物が定義 （ちなみにPMBOK V6には49個のプロセスが存在する） スクラムは経験主義。 実際の経験と既知に基づく判断によって習得していく。 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スクラムの正式なルールについては、以下のスクラムガイドを参照すること 2010年に初版が作成され、現時点では2020年11月が最新版になっている スクラムの定義
30. 30 ©AR Advanced Technology All Right Reserved. スクラムの全体像 以下の3つの軸で捉えるとわかりやすい 1. 登場人物 2. イベント 3. 作成物 図引用：https://www.ogis-ri.co.jp/column/agile/agilescrum01.html
31. 31 ©AR Advanced Technology All Right Reserved. イベントと作成物 進め方自体はとてもシンプル 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
32. 32 ©AR Advanced Technology All Right Reserved. スクラムの枠組み 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
33. 33 ©AR Advanced Technology All Right Reserved. 開発者(7±2) スクラムマスター プロダクトオーナー ステークホルダー 作業依頼・説明 支援 支援 成果・質問 説明責任 要求 スクラムチーム プロダクトオーナー、開発者、スクラムマスターで構成される。 自己組織化されており、機能横断的。 ゴールを達成するための最善策を自分たちで選択する。 登場人物
34. 34 ©AR Advanced Technology All Right Reserved. • 開発チームの作業とプロダクトの価値の最大化に責任を持つ • リリース日、リリース内容を決める • プロダクトバックログの管理に責任を持つ1人の人間（複数人はだめ） • プロダクトバックログの優先順位の決定(委員会があっても構わないが、決定はPOの責任) • 開発チームへの作業依頼(PO以外が開発チームに作業依頼をしてはいけない) • 作業結果の受入・拒否 • プロダクトバックログアイテム(PBI)を明確に表現する • ゴールとミッションを達成できるようにPBIを並べ替える • 開発チームが行う作業の価値を最適化する • PBIを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す • 必要とされるレベルでPBIを開発チームに理解してもらう • コスト感覚 • ネゴシエーション力 • 説明力 • 決断力 求められる能力 • 一貫性 • 戦略性 役割 仕事 プロダクトオーナー（PO）
35. 35 ©AR Advanced Technology All Right Reserved. 開発者 • リリース可能なモノを作成する • 職能横断的に様々なスキルをもった人が製品を中心に集まり、強み を持ちより、垣根を越えて貢献し合うべく、自律性的に行動する • 自分たちの作業の管理(1番良いやり方を自分たちで考え、決める) • バックログに入っている項目を完了状態にし、製品の価値を高めて いく責任 • 生産性を向上するために努力する責任 • 製品を開発するために必要な能力 ビジネスアナリスト、プログラマー、Architect、デザイナーなど明示的な区別なし • 自律性 • チームへの貢献姿勢 求められる能力 役割 • スプリントプランニングで約束したことを実現する • 生産性向上のための行動を常に考え、行う 仕事
36. 36 ©AR Advanced Technology All Right Reserved. • スクラムの理解と成立に責任を持つ • プロダクトオーナーの支援 • 開発チームの支援 • スクラムの説明を行い、理解してもらう • 効果的なプロダクトバックログの管理方法の検討 • (必要に応じて) イベントのファシリテート • 開発チームの進捗を阻害する要因の排除 • サーバントリーダーシップ • ティーチング力 • ファシリテーション力 • コーチング力 求められる能力 役割 仕事 • スクラム以外のプロセスの理解 • 集団心理の理解 • 事実(数字)を示す スクラムマスター
37. 37 ©AR Advanced Technology All Right Reserved. スクラムを支える3本柱 透明性 (Transparency) 結果責任を持つ人に対して見える化されていること。 標準化され、見ている人が共通理解を持てること。 検査 (Inspect) 作成物や進捗を頻繁に検査し、変化を検知する。 検査を頻繁にやりすぎて作業の妨げになってはいけない。 適応 (Adapt) プロセスに不備がある場合、その構成要素を調整する。 プロセスの調整を出来る限り早く行い、逸脱を防ぐ。 経験的プロセス制御の実現は以下の3つによって支えられている。 スクラムのイベント、作成物、ロールには必ず何れかが当てはまる。
38. 38 ©AR Advanced Technology All Right Reserved. 確約 (Commitment) 個人はスクラムチームのゴールの達成を確約しなければいけない。 無理をして絶対に終わらせるということではない。 勇気 (Courage) スクラムチームのメンバーは、正しいことをする勇気を持ち、 困難な問題に取り組まなければいけない。 集中 (Focus) スクラムチーム全員がスプリントの作業とゴールに集中しなければいけない。 公開 (Openness) スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を 公開することに合意しなければいけない。 尊敬 (Respect) スクラムチームのメンバーは、お互いを能力のある独立した個人として 尊敬しなければいけない。 5つの価値基準を取り入れ、実践することで透明性・検査・適応が実現可能となる。 スクラムを支える5つの価値基準
39. 39 ©AR Advanced Technology All Right Reserved. スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。 実際の経験 知識 判断・行動 反復的かつ漸進的な手法で 予測可能性の最適化と リスクの管理を行う 判断し、行動した結果、新たな知識を獲得する 判断し、行動したことが経験になる スクラムの大前提となる考え方
40. 40 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  スクラムは、アジャイル開発の１手法である。  スクラムは、予見的プロセスではなく経験的プロセスであり、実際に やってみた結果を見ながらチームを適応させていく。  スクラムは、３つの「責任」、５つの「イベント」、３つの「作成物」 で定義された、マネジメントの枠組みである。  スクラムチームの責任は、「プロダクトオーナー」「開発者」「スクラ ムマスター」の３つで構成されている。  スクラムマスターは、トップダウンの管理的マネジメントをするのでは なく、スクラムチーム全体を支援し、チームと組織にスクラムが確立さ れることに責任を持つ。  スクラムでは、スプリントごとに機能する製品を開発し、その製品とプ ロセスの両方について「検査と適応」を繰り返す。
41. 41 ©AR Advanced Technology All Right Reserved. スクラム実践に向けた課題 導入に向けたコツと罠
42. 42 ©AR Advanced Technology All Right Reserved. アジャイルの実践に向けて 説明したこと以外でも アジャイルを実践する際は 「チーム」と「システム」 両面で様々なツールや 手法を組み合わせて 運用を継続的に最適化してく ことが大切 経験主義の原則に則り、 各チームに合うものを 各自のやり方を模索する 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
43. 43 ©AR Advanced Technology All Right Reserved. スクラムの実践において陥りやすい3つの罠  スクラムが形式的、儀式的になる • スクラムガイドはあくまでもルールブックでしかない • プレイブック（実際の運用戦略）は各チーム自身で考える  プロダクトオーナー vs 開発チームの構図に陥いる • 最新版では「開発チーム」という言葉をなくした意図 • 3つの役割に分けているのは、仕事に線をひくためではない • 計画と実行を分けないことがアジャイルの基本思想 • 「あなた vs 私」 ではなく、「問題 vs 私たち」へ  スクラムマスターがスクラム警察もしくは雑用係に陥る • スクラムを回すことが仕事になってしまう • より高次の組織的目標にコミットするような動機づけと導き • スクラムマスター同士の社内コミュニティで経験や学びを共有 これはスクラムに限った話ではない。今すぐ現場に活かせる考え方。 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
44. 44 ©AR Advanced Technology All Right Reserved. SIにおけるアジャイル実践時の契約 引用：» アジャイル開発版「情報システム・モデル取引・契約書」 ～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～：IPA 独立行政法人 情報処理推進機構 https://www.ipa.go.jp/ikc/reports/20200331_1.html 2020年3月にIPAよりモデル契約書が 提供されている。  スクラムをベース  準委任契約を前提  POはユーザー企業から選出 引用：平鍋健児;野中郁次郎;及部敬雄.アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
45. 45 ©AR Advanced Technology All Right Reserved. ここまでのまとめ  スクラムで成果を上げるためには、スクラムガイドで定義されているこ と以外に様々な手法やツールを駆使することが効果的。  文化や組織風土、契約書面など多方面な整備が必要となる  スクラムを効果的に実践するためには、スクラムチームを含む組織全体 が「コマンド─コントロール」型から「リーダーシップ─コラボレー ション」型の自律した組織に変わる必要がある。
46. 46 ©AR Advanced Technology All Right Reserved. 最後に
47. 47 ©AR Advanced Technology All Right Reserved. 今後とこれから  経験主義を前提に、小さな実践事例を増やしていきたい  会社として、現場の挑戦を後押しできる仕組みを整備していく  アジャイルを学び、社内に広げていく仲間を募りたい 協力いただける方は是非中野（康）までご連絡ください。
48. 48 ©AR Advanced Technology All Right Reserved. 「アジャイル開発とスクラム」入門 Don’t do agile, be agile. 2021年06月16日(水) TechCoE事業室 中野康雄（＠yasuoyasuo） ❞ ❝ CulTech社内勉強会 ＜完＞ 是非感想を お寄せください！
49. 49 ©AR Advanced Technology All Right Reserved. ＡＲアドバンストテクノロジ株式会社【略称：ＡＲＩ】 URL : https://ari-jp.com