Tweet
Tweet

Slide 1

Slide 1 text

測って見直す開発習慣 可視化を進めて私たちに起きた変化 2024/01/13 PHPカンファレンス北海道 2024

Slide 2

Slide 2 text

2 ● Hiroki Inoue ● Software Engineer ● Engineering Manager @ WHITEPLUS, Inc. About Me

Slide 3

Slide 3 text

3 トーク概要 このトークは、開発生産性、保守性を可視化し、私たちの活動やシステムの状態を顧みる試みを綴った 経験談です。どのように可視化に取り組み、どのような習慣、体験が得られたかを共有します。 https://fortee.jp/phpcon-hokkaido-2024/proposal/b2b9f4cf-3117-4d70-bd71-46b8d55a7bb9

Slide 4

Slide 4 text

4 1. 可視化に取り組むか検討している方 2. 可視化の運用を試行錯誤している方 3. 可視化に悩めるチームを手助けし、エンジニアリングプロセスの発展に関わりたい方 誰向けのトーク？

Slide 5

Slide 5 text

5 アジェンダ はじめに どのように可視化を進めたか 01 02 可視化により分かること 習慣の変化 03 04 体験の変化 05 まとめ 06

Slide 6

Slide 6 text

6 ● わかりにくかった事 ● 発見した事 ● 役に立った？立たない？ etc. フィードバックを是非お願いしますmm

Slide 7

Slide 7 text

7 はじめに ～このトークのスタンス～

Slide 8

Slide 8 text

8 ● アウトプットとアウトカム、両方大事で両立できる。 ○ このトークにおける”生産性”はアウトプットを指す。 ○ 広木大地さんによる定義におけるレベル2, 3の生産性はスコープ外。[1] 生産性の意図するところ 1. 大規模言語モデル時代の開発生産性（hirokidaichi）

Slide 9

Slide 9 text

9 ● 測る？ or 測らない？ ○ 測る ● 何を測る？（Four Keys or SPACE or その他） ○ Four Keys ● どうやって測る？（Saas or OSS or 自作） ○ Saas 生産性評価方法の現状

Slide 10

Slide 10 text

10 ● 計測、評価、改善活動は5名程度のチームごとに行っている。 ● 生産性、保守性向上を主導するチームがあるのではなく、開発チーム内で行っている。 ○ 可視化を主導するのはEMの役割の一つ。 ○ 数値を見るだけでなく開発プロセスに参加し、定性的な情報も体感している。 ○ 数値はチームの皆が見る。 ○ 改善活動はチームで、あるいはエンジニア組織全体で実行する。 前提

Slide 11

Slide 11 text

11 ● 数値の単純比較に価値はないと考える。[1] ○ 重要なのは数値そのものではなく、背景を読み取ること。 注意事項 1. チームのアジリティを上げよう！否、〇〇を上げよう！開発生産性の可視化に取り組んでみてわかったこと、わからないこと（119頁）

Slide 12

Slide 12 text

12 ● Four Keysの限界 ○ レベル2, 3の生産性は測れない。 ○ PRに反映されない仕事の生産性は測れない。 ■ 仕様調査 ■ ドキュメント作成 ■ ミーティング etc. 注意事項

Slide 13

Slide 13 text

13 ● ノイズの問題（計測ツールの仕様による部分もある） ○ 非稼働日（特に連休）により計測値が悪化する。 ○ 調査のため作成し閉じたPR（成果有）と開発を中止したPR（成果無）が見分けられない。 ○ 自動生成されるコードなどにより変更行数が顕著に大きくなる。 ○ （そもそも運営の是非があるが）隙間時間に進める開発はリードタイムが長くなる。 ○ かといって除外すると、貢献がPR数に反映されない。 ○ GitHubでラベルの付与漏れによる分析対象の誤り。 注意事項

Slide 14

Slide 14 text

14 ● 測る？ or 測らない？ ○ 測る ● 何を測る？ ○ コードベースの規模 ○ 循環的複雑度 ● どうやって測る？ ○ OSS 保守性評価方法の現状

Slide 15

Slide 15 text

15 どのように可視化を進めたか

Slide 16

Slide 16 text

16 生産性の計測

Slide 17

Slide 17 text

17 ● Findy Team+を利用。 ● GitHubやJiraに蓄積されたPR等の情報を活用。 ● PHP等の言語に依存せず、適用可能。 Four Keys[1] 1. https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

Slide 18

Slide 18 text

18 ● デプロイの頻度 … 組織による正常な本番環境へのリリースの頻度 ● 変更のリードタイム … commit から本番環境稼働までの所要時間 ● 変更障害率 … デプロイが原因で本番環境で障害が発生する割合（%） ● サービス復元時間 … 組織が本番環境での障害から回復するのにかかる時間 1. デプロイの頻度, 変更のリードタイム, 変更障害率, サービス復元時間。 State of DevOps 2021では運用パフォーマンス指標である「信頼性」が5つめのメトリクスとして追加された。 Four Keys[1]

Slide 19

Slide 19 text

19 余談

Slide 20

Slide 20 text

20 Four Keysが含意するものに差異がありうる。例えば、 ● デプロイの頻度 … 計測の都合によるカウント方法の差異 ● 変更のリードタイム … commitするタイミングの差異 … 計算方法の差異 … PRの難易度の差異 … 製品特性による開発プロセスの差異 Four Keys

Slide 21

Slide 21 text

21 Four Keysが含意するものに差異がありうる。例えば、 ● デプロイの頻度 … 計測の都合によるカウント方法の差異 ● 変更のリードタイム … commitするタイミングの差異 … 計算方法の差異 … PRの難易度の差異 … 製品特性による開発プロセスの差異 ⇒比較したい場合コンテクストの違いに注意する必要がある。 Four Keys

Slide 22

Slide 22 text

22 ● Four Keysすべてを追いかけない。 ● ガチガチに目標を固め過ぎない。 スモールスタート

Slide 23

Slide 23 text

23 ● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう ● 変更のリードタイム ● 変更障害率 ● サービス復元時間 スモールスタート

Slide 24

Slide 24 text

24 ● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう ● 変更のリードタイム ← 更に分解できる ● 変更障害率 ● サービス復元時間 スモールスタート

Slide 25

Slide 25 text

25 ● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう ● 変更のリードタイム ← 更に分解できる ○ 開発する ○ レビューする ○ 修正を完了する ○ マージする ● 変更障害率 ● サービス復元時間 スモールスタート

Slide 26

Slide 26 text

26 ● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう ● 変更のリードタイム ← 更に分解できる ○ 開発する ○ レビューする ←取り組みやすい ○ 修正を完了する ○ マージする ● 変更障害率 ← 課題感がないのでスコープアウト ● サービス復元時間 ← 課題感がないのでスコープアウト スモールスタート

Slide 27

Slide 27 text

27 ● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう ● 変更のリードタイム ← 更に分解できる ○ 開発する ○ レビューする ← ここからやってみよう ○ 修正を完了する ○ マージする ● 変更障害率 ← 課題感がないのでスコープアウト ● サービス復元時間 ← 課題感がないのでスコープアウト スモールスタート

Slide 28

Slide 28 text

28 ● レビューの早さについては最初から具体的目標を持ち、その他は観察することからはじめた。 ● 徐々に見る観点を増やした。 ○ レビューの早さ、修正の早さ、開発の早さ、PRサイズ、アクティビティ量、デプロイ頻度... スモールスタート

Slide 29

Slide 29 text

29 レビューの着手が早くなった。 みんな偉い👏 しばらく試してみると…

Slide 30

Slide 30 text

30 レビューの着手が早くなった。 みんな偉い👏 そして修正を完了するまでの（レビュー〜アプルーブまでの）時間等にも目を向け始める。 しばらく試してみると…

Slide 31

Slide 31 text

31 ● デプロイの頻度 ● 変更のリードタイム ○ 開発する ← ここもやってみよう ○ レビューする ← ここからやってみよう ○ 修正を完了する ← ここもやってみよう ○ マージする ● 変更障害率 ● サービス復元時間 次のステップ

Slide 32

Slide 32 text

32 ステップバイステップで 無理なく 着実に 変化を続けたい

Slide 33

Slide 33 text

33 保守性の計測

Slide 34

Slide 34 text

34 ● phpmetrics/PhpMetricsを使用。 ● 複雑さ等も計測できる[1]が、コード行数、クラス数に絞って観察。 ● 小まめに実行する必要性に乏しく手動で計測。 コードベースの規模 1. PhpMetrics－Main metrics

Slide 35

Slide 35 text

35 ● terryyin/lizardを使用。 ● GitHub Actionsに組み込み、閾値を超えた場合にコメントを生成。 ● 修正を強制はしない。 ○ 自身の設計をふりかえるきっかけに。 ○ 古いコードベースの課題を見える化。 循環的複雑度

Slide 36

Slide 36 text

36 よい習慣をつくる 慣性をうみだしたい

Slide 37

Slide 37 text

37 可視化により分かること

Slide 38

Slide 38 text

38 1. ボトルネック 2. 変化 3. （副次的なものとして）のびしろ 生産性に関して分かること

Slide 39

Slide 39 text

39 1. ボトルネック 開発する レビューを始める 修正を完了する マージする

Slide 40

Slide 40 text

40 開発する レビューを始める 修正を完了する マージする 1. ボトルネック

Slide 41

Slide 41 text

41 PR数の推移 1. ボトルネック

Slide 42

Slide 42 text

42 ＋ PR数の推移 1. ボトルネック

Slide 43

Slide 43 text

43 ＋ PR数の推移 開発外業務が増加 1. ボトルネック

Slide 44

Slide 44 text

44 2. 変化 ● よくなっているのか ● 停滞しているのか ● 悪くなっているのか

Slide 45

Slide 45 text

45 2. 変化

Slide 46

Slide 46 text

46 2. 変化 オンボーディング 順調な立ち上がり

Slide 47

Slide 47 text

47 2. 変化 オンボーディング 順調な立ち上がり 下降しているが なぜ？

Slide 48

Slide 48 text

48 2. 変化 オンボーディング 順調な立ち上がり 担当ドメイン変更 開発外タスク増 レビュー負荷増

Slide 49

Slide 49 text

49 ● 環境 ○ 開発プロセス ○ 既存システムの保守性 ○ 開発・運用環境[1] ○ 開発外業務[2]の多寡 ● 人 ○ ドメイン知識 ○ 技術力 ○ モチベーション 3. （副次的なものとして）のびしろ 1. CI/CD、型付け、静的解析、フィーチャートグル、ChatOps、オブザーバビリティといった類の話。 2. コードの生成に直接的につながらない業務。間接業務、見積り、照会、障害対応等。

Slide 50

Slide 50 text

50 余談

Slide 51

Slide 51 text

51 ● 不要コードの削除 ● リファクタリング ● DDDによる整理 ● 静的解析の更なる活用（レベル上げ、カスタムルール、ツール追加） 保守性を高める

Slide 52

Slide 52 text

52 ● GitHub Copilot導入 ● ChatGPT導入 ● ビルド時間の短縮 ● 循環的複雑度の計測 開発・運用環境を改善する

Slide 53

Slide 53 text

53 ● ドキュメントやツールに働かせる。 ● 業務の交通整理を行う。 ● 設計（障害耐性、復旧容易性、理解容易性）改善を目指す。 ● 開発外業務の多くをEMが巻き取りつつ、一部負荷を平準化しつつメンバーに渡す。 開発外業務をスリムにする

Slide 54

Slide 54 text

54 ● 現場見学 ● インプット、アウトプットの機会提供 ● ナレッジ共有の機会提供 ● ペアプロ ● レビュー ● ディスカッション ● 勉強会 ● ドキュメント整備 人を支援する

Slide 55

Slide 55 text

55 ● コードベースの規模の変化を定量的に把握できる。 ● 設計を見直すべきか否かの判断材料になる。 ⇒人の判断は時に不安定、不正確、不揃い。数値化することで認識、同期の精度を上げられる。 保守性に関して分かること

Slide 56

Slide 56 text

56 ● 個々の施策の良し悪しやインパクトの大きさ ○ 整備したドキュメント、勉強会は有効なのか？ ○ コードベースの規模の削減がどれほど効いているのか？ ● 保守性と生産性の関連性 ● のびしろの比重 わからないこと

Slide 57

Slide 57 text

57 ● グラフに表れない情報は別途収集する必要がある。 ○ メンバー数 ○ 稼働日数 ○ 開発外業務量（PRに反映されないアクティビティ量） ○ 難易度 ○ 新規開発 or 改修（資産や負債の有無） ○ 技術スタック など （直接的には）わからないこと

Slide 58

Slide 58 text

58 習慣の変化

Slide 59

Slide 59 text

59 1. スクラムイベント 2. 対策策定 3. 開発プロセス 4. 情報収集 5. 目標管理 変化した習慣

Slide 60

Slide 60 text

60 ● レトロスペクティブの際に数値を確認する。 ○ ふりかえりの焦点を絞れる。 ○ 発言を引き出せる。 ● 推奨するプラクティスも毎週繰り返し確認する。 1. スクラムイベント

Slide 61

Slide 61 text

● 体感の答え合わせができる。 ○ レビューを迅速に行っている感覚があり、数値がそれを裏付けていた。 ○ 新規参画者のパフォーマンスが右肩上がりなのを確認できた。 ● 体感と異なることもあり、それが発見である。 ○ 自覚していなかったがPRを小さくできる余地があった。 ● 数値を踏まえて振り返りや1on1を行うようになった。 ○ 変更のリードタイムが長引いた要因を、工程の内訳を踏まえて振り返れた。 61 1. スクラムイベント － 例えばふりかえりがどうなったか

Slide 62

Slide 62 text

62 ● 数値の下降あるいは停滞が、次なる施策の必要性を示唆する。 ● ボトルネックを特定することで対策の候補が決まる。（次頁） 2. 対策策定

Slide 63

Slide 63 text

63 …………………………… ☟変更のリードタイムが長期化する要因例 ● 開発する … 担当者のスキル、要件の精度、システムの理解容易性、影響範囲 ● レビューする … 意識・習慣（仕事の優先順位づけ）、業務量、レビューしやすさ ● 修正を完了する … 開発する同様の要因＋認識違い、指摘の流儀、レビュアー数 ● マージする … デプロイの仕組み、デプロイを阻む要素、QA体制 2. 対策策定 － 例えば変更のリードタイムを改善したい時

Slide 64

Slide 64 text

64 …………………………… ☟変更のリードタイムが長期化する要因例 ● 開発する … 担当者のスキル、要件の精度、システムの理解容易性、影響範囲 ● レビューする … 意識・習慣（仕事の優先順位づけ）、業務量、レビューしやすさ ● 修正を完了する … 開発する同様の要因＋認識違い、指摘の流儀、レビュアー数 ● マージする … デプロイの仕組み、デプロイを阻む要素、QA体制 2. 対策策定 － 例えば変更のリードタイムを改善したい時

Slide 65

Slide 65 text

65 ● レビュー文化 ○ 極力レビュー優先 ○ レビューしやすいPR ○ レビューに至るまでのコミュニケーション ■ 要所を相談してから進める。 ■ モブ設計により大きな認識のズレを無くしておく。 ■ レビューをスムーズにする前提知識を事前に周知する。 ○ レビューにおけるコミュニケーション ■ 指摘のトーンや背景を伝える。 ■ 参考資料やサンプルコードを示す。 ■ 適宜口頭で説明する。 3. 開発プロセス

Slide 66

Slide 66 text

66 3. 開発プロセス ● レビュー分担の最適化 ○ ナレッジ共有の役割を終えたレビュアーをアンアサイン ○ ボトルネックなっているレビュアーの業務調整やアンアサイン ○ レビュアーの分散化 品質保証 ナレッジ 共有

Slide 67

Slide 67 text

67 ● PRサイズを小さく 段階的に浸透させた ○ 啓蒙 ○ 具体的な方法を紹介 ○ ローカライズと自分事化 ○ 目標を具体化 ○ レビューやふりかえりで相互フィードバック 3. 開発プロセス

Slide 68

Slide 68 text

68 ● PRサイズを小さく 段階的に浸透させた ○ 啓蒙 ○ 具体的な方法を紹介 ○ ローカライズと自分事化 ○ 目標を具体化 ○ レビューやふりかえりで相互フィードバック ● 注意事項 ○ レビューが増えるので 早く行うこととセットで取り組まないと結局詰まる。 3. 開発プロセス

Slide 69

Slide 69 text

69 ● 3ペア ○ ペアプロ ○ ペア（モブ）設計 ○ ペア調査 3. 開発プロセス

Slide 70

Slide 70 text

70 ● 開発における迷いを減らす ○ ガイドライン ○ 雛形 ○ ADR ○ オンデマンドの支援 3. 開発プロセス

Slide 71

Slide 71 text

71 ● 生産性向上の観点から他社事例、ベストプラクティスを収集 ○ イベント参加 ○ （Saasを利用している場合）CSのサポート ● チーム間交流 ○ 数値の差異がディスカッションの契機になる。 ○ 他チームを観察し、プラクティスを取り入れる。 4. 情報収集

Slide 72

Slide 72 text

72 人によると思われるが ● 目標が立てやすくなる。 ● 目標に対する進捗がわかりやすくなる。 ● アクションを起こしやすくなる。 5. 目標管理

Slide 73

Slide 73 text

73 人によると思われるが ● 目標が立てやすくなる。 ● 目標に対する進捗がわかりやすくなる。 ● アクションを起こしやすくなる。 ● 注意事項 ○ 点で目標を立てるのは控えたい。環境要因によるブレがあるため。 ○ 幅をもたせたり背景を考慮する必要がある。 ○ 定量的なら白黒はっきりできると思いきやそうでもない。 5. 目標管理

Slide 74

Slide 74 text

74 ● 規模や循環的複雑度のモニタリングによる習慣の変化は見られなかった。 ● 規模のモニタリングによりコード掃除の手応えを感じることや ● 循環的複雑度のモニタリングにより複雑なコードが増殖してないことを確認できはした。 ちなみに保守性の可視化については…

Slide 75

Slide 75 text

75 ● 新規作成したコードが検知されるのは稀。既存コードが検知されることはある。 ● 検知が修正につながらないケース ○ 所謂レガシーの場合リファクタのハードルが高い。 ○ リファクタの旨みが乏しいドメインの場合優先度が上がらない。 ○ 具体的にどこをどう直せばよいかわからない。 循環的複雑度モニタリングの経過

Slide 76

Slide 76 text

76 ● 新規作成したコードが検知されるのは稀。既存コードが検知されることはある。 ● 検知が修正につながらないケース ○ 所謂レガシーの場合リファクタのハードルが高い。 ○ リファクタの旨みが乏しいドメインの場合優先度が上がらない。 ○ 具体的にどこをどう直せばよいかわからない。 ● そもそも費用対効果の高いところからリファクタしたいので、ランダムに見つかったそれを反射的 に修正しようとはならない。 循環的複雑度モニタリングの経過

Slide 77

Slide 77 text

77 ● 新規作成したコードが検知されるのは稀。既存コードが検知されることはある。 ● 検知が修正につながらないケース ○ 所謂レガシーの場合リファクタのハードルが高い。 ○ リファクタの旨みが乏しいドメインの場合優先度が上がらない。 ○ 具体的にどこをどう直せばよいかわからない。 ● そもそも費用対効果の高いところからリファクタしたいので、ランダムに見つかったそれを反射的 に修正しようとはならない。 ● 複雑なコードが増殖していないことや既存コードののびしろが確認できた。 循環的複雑度モニタリングの経過

Slide 78

Slide 78 text

78 体験の変化

Slide 79

Slide 79 text

79 測るだけで何かが起きるわけではもちろんない。 数値が見えることで何らかの慣性が生じる。それを活かすも流すも私たち次第。 大前提

Slide 80

Slide 80 text

80 体感アンケート結果 ● 自分の行動の改善案を考えやすくなった（レビューの速度やPRの大きさなど） ● 「目標を立てやすくなった（数値で明確になった）」のが一番だと思っています ● 自身の目標としても数値化されていることで、計測して改善までのプロセスが組みやすくなっていると感じます ● Pull Request を小さくしてレビュー&マージを迅速に行うという共通意識がチームに定着しつつあり、リリースを素早くすることに活かせてきている ● リアルタイムで目標の数値に近づいているor遠のいている状態が把握できるため、個人的な振り返りがやりやすくなった ● オープンからマージまでの時間が分かりやすくなり意識するようになった ● PRを細かく出すことにより、レビューがしやすくなった。また出す方でも大きなPRを作らないですむので負担感が減った ● 自分の行動が数値化されて改善点を探しやすい ● どのPRで実装が詰まったのかを明確にキャッチできている ● そこからナレッジ化やチームでの問題解消などに取り組めている ● チームのレビュー速度が上がり、直列になっているタスクを着手するまでの待ち時間が減った ● 自分がレビューについて躊躇していることを伝えるきっかけになった ● 自分の体感よりも「時間がかかっていたPR」や「早かったPR」を知ることができ、前者の問題点や後者の再現性を考えるきっかけになった （アンケート結果ではないが会話の中で拾ったこととしては） ● ガイドライン等の整備により開発における迷いが減った。 ● ビルド時間の短縮により迅速にデプロイできるようになった。開発環境の起動待ちの煩わしさが減った。

Slide 81

Slide 81 text

81 ● 内省しやすくなった。 ○ うまくいったことを確認したり、失敗したことに気づける。 ○ 裏付けがあることで、体感に自信が持てるようになる。 ○ 自覚してないことに気づけるようになる。 ○ 数値が根拠となりフィードバックを受け入れられやすくなる。 ○ 数値として見えることが自律的な改善活動のトリガーになる。 ● 目標を立てやすくなった。 ● プロセスを見直した部分の負担（感）が軽減した。 体感まとめ

Slide 82

Slide 82 text

82 ● レビューがスムーズになった。 ● 変更のリードタイムが短縮された。 ● デプロイ頻度が上がった。 結果として

Slide 83

Slide 83 text

83 ● チーム間交流のタッチポイントが増えた。 ● 開発プロセスや体験をよくする慣性が生まれた。 ● ボトルネックや変化に気づきやすくなった。 ● 発言を引き出す効果がある。 ● 数値の評価に関して負担感がある。 ○ ノイズの排除 ○ 定性情報の収集 運営サイドの視点から

Slide 84

Slide 84 text

84 ● チーム間交流のタッチポイントが増えた。 ● 開発プロセスや体験をよくする慣性が生まれた。 ● ボトルネックや変化に気づきやすくなった。 ● 発言を引き出す効果がある。 ● 数値の評価に関して負担感がある。 ○ ノイズの排除 ○ 定性情報の収集 運営サイドの視点から

Slide 85

Slide 85 text

85 ● チーム間交流のタッチポイントが増えた。 ● 開発プロセスや体験をよくする慣性が生まれた。 ● ボトルネックや変化に気づきやすくなった。 ● 発言を引き出す効果がある。 ● 数値の評価に関して負担感がある。 ○ ノイズの排除 ○ 定性情報の収集 運営サイドの視点から

Slide 86

Slide 86 text

86 ● チーム間交流のタッチポイントが増えた。 ● 開発プロセスや体験をよくする慣性が生まれた。 ● ボトルネックや変化に気づきやすくなった。 ● 発言を引き出す効果がある。 ● 数値の評価に関して負担感がある。 ○ ノイズの排除 ○ 定性情報の収集 運営サイドの視点から

Slide 87

Slide 87 text

87 ● チーム間交流のタッチポイントが増えた。 ● 開発プロセスや体験をよくする慣性が生まれた。 ● ボトルネックや変化に気づきやすくなった。 ● 発言を引き出す効果がある。 ● 数値の評価に関して負担感がある。 ○ ノイズの排除 ○ 定性情報の収集 運営サイドの視点から

Slide 88

Slide 88 text

88 まとめ

Slide 89

Slide 89 text

89 ● Four Keysを用いた生産性可視化をステップバイステップで進めた。 ● 開発習慣や体感に変化があった。 ● 生産性向上に繋げるべく保守性向上も目指している。 ● 保守性可視化の仕組みづくりにもトライしており、のびしろだらけ。 ● 可視化は組織のオブザーバビリティを高めるのに役立つが、いくつかの注意点がある。 ○ Four Keysで測れるものは限られている。 ○ 定量的なら白黒はっきりできると思いきやそうでもない。 ○ 測るだけは何も起きない。改善活動のリソースも必要。 ○ 計測値を比較する際にはコンテクストを合わせる必要がある。 ○ 計測値の評価にも労力がかかる。

Slide 90

Slide 90 text

ご清聴ありがとうございました

Slide 91

Slide 91 text

91 ● わかりにくかった事 ● 発見した事 ● 役に立った？立たない？ etc. フィードバックを是非お願いしますmm