正しいものをともに考え、正しくともにつくる

1. 正しいものをともに考え正しくともにつくる Ichitani Toshihiro 市⾕聡啓 The end of the journey is the beginning of a new journey

2. 第1部正しいものを正しくつくる

3. 市⾕聡啓 Ichitani Toshihiro https://ichitani.com/ Proﬁle Twitter https://twitter.com/papanda “越境をエナジャイズするジャーニー” What Doing

4. 講演、研修、執筆仮説検証型アジャイル開発によるプロダクトづくり仮説検証、アジャイル開発の実践⽀援 (メンタリング) DX (Digital Transformation) ⽀援

5. https://amzn.to/2TBC0oA https://amzn.to/2VQ6oOM

6. ともに考え、ともにつくるプロダクト開発の実践「チーム・ジャーニー」 2020年2⽉17⽇発刊 https://amzn.to/32Wuklp

7. われわれが挑戦していること不確実性の⾼いプロダクト開発 …は領域を選ばない Photo on VisualHunt.com

8. “誰かのために作る” という時点で不確実性と向き合うことは不可避 (“誰か" is ユーザー、顧客) Photo on VisualHunt.com

9. “SoE だから不確実性が⾼い” “SoR だから不確実性が⾼くない” という2元論で説明する時代は終わった Photo credit: Ravi_Shah on Visual hunt / CC BY

10. 10年あるいは20年近い、 “知る⼈ぞ知る” な基幹システム (なおそれを知る者はほぼいない) バックエンドにフタをしてフロントの世界だけで新しい価値を⽣み出そうの限界 (フロント(SoE)で”デキない制約”が強すぎる) Photo credit: v923z on Visual hunt / CC BY

11. ⼈知れず動くSoRを巡る調査はまさに(価値)探索ひとりでいくな危険 Photo credit: Kylie_Jaxxon on Visual Hunt / CC BY-SA

12. 今われわれが直⾯していることは⼈間が普段やっている⾏為をデジタルに置き換えようではなくてあらゆる⼿段を使ってどのようにトランスフォーミングできるのかという検証そのもの Photo credit: Kevin M. Gill on Visualhunt / CC BY

13. Photo on VisualHunt.com 保険業務 SoE SoR 本⼈認証⼦供写真共有アプリ MaaS RPA従業員満⾜度婚活介護ロボット決済 VR D2C

14. Photo on VisualHunt.com 保険業務 SoE SoR 本⼈認証⼦供写真共有アプリ MaaS RPA従業員満⾜度婚活介護ロボット決済 VR D2Cエクスペリエンスの再定義

15. “タダシイ筋道も筋書き”もない中でそれでも前に進むためには？

16. 対象となる状況や問題についての仮説を⽴て、検証し、分かったこと (学習)に基づいて、プロダクトを実装するあり⽅が求められる

17. Photo on VisualHunt 仮説検証型アジャイル開発

18. 仮説とは？仮説 = 前提 + 仮定 + 期待結果前提：昨年はある商品の売上が10%伸びた仮定：リーチしていない顧客はまだまだいるはずでさらに広告投資を50%増やすため期待結果：今年の売上は20%の伸びは期待できる

19. 前提(事実)が少ないほど、仮定の部分が多い(不確実) ゆえに仮説検証で仮定(想像)を減らし、前提(事実)を増やす前提仮定期待結果前提仮定期待結果仮説検証

20. 前提仮定期待結果データ知⾒前提(事実)を作るための根拠がデータ (定量/定性) であり、知⾒ (経験知) ゆえにデータによる理由付けが不可⽋であり、データを補う知⾒(既知の事実)が全体の速度を上げる

21. 仮説検証で「事実を増やす」とは？「情報」を増やして、「理解」を得ること (“分かった”を増やす) 前提仮定期待結果データ知⾒情報解釈理解 ☓

22. だからといって検証や調査で情報だけ増やしても、解釈を難しくて、誤った理解になりえる前提仮定期待結果データ知⾒情報解釈理解 ☓

23. 前提仮定データ知⾒情報解釈理解 ☓ ゆえに、正しい理解を得るためには、「解釈」を鍛える必要がある（すなわち学習結果を積み重ねる）期待結果これまで獲得した知識検証結果による学び

24. 検証結果による学び前提仮定データ知⾒情報解釈 ☓ 期待結果これまで獲得した知識理解仮説合意形成意思決定その上で、⽴てた仮説に基づいて意思決定のための合意形成を⾏う

25. 検証結果による学び前提仮定データ知⾒情報解釈 ☓ 期待結果これまで獲得した知識理解仮説合意形成意思決定さらに⽴てた仮説に基づいて意思決定のための合意形成を⾏うすべての箇所で誤る可能性があるゆえに仮説の⽴て⽅、検証の⽅法、学習の蓄積チーム内だけではなく関係者との合意形成について学び、練度を⾼めていきたい

26. 選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）仮説検証型アジャイル開発

27. 仮説検証の「例」

28. 仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正仮説検証1周⽬ (target : PSﬁt)

29. 仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正仮説検証1周⽬ (target : PSﬁt) 仮説検証2周⽬ (target : PSﬁt (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正

30. 仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正仮説検証1周⽬ (target : PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) プロトタイプ制作 (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の修正

31. 仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正仮説検証1周⽬ (target : PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) プロトタイプ制作 (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の修正仮説検証4周⽬ (target : PSfit (被験者に利⽤体験してもらい評価する)) MVP特定と開発 (ユーザー⾏動フロー) 利⽤体験を伴う検証 (MVP検証) 仮説の修正

32. 仮説には「構造」がある課題仮説機能仮説形態仮説本質的な課題課題の解決⼿段⼿段を利⽤可能にするかかたかたちまず解くべき問いがあり、問いに答える⼿段があり、⼿段を扱えるようにするための形がある = = = = = =

33. 仮定⽴案 (仮説キャンバス) 探索的検証 (顧客インタビュー) 仮説の修正仮説検証1周⽬ (target : PSfit) 仮説検証2周⽬ (target : PSfit (被験者にイメージを深めてもらう)) イメージ制作 (ストーリーボード等) イメージを伴う検証 (顧客インタビュー) 仮説の修正仮説検証3周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) プロトタイプ制作 (No Code Prototyping) 操作を伴う検証 (プロトタイプ検証) 仮説の修正仮説検証4周⽬ (target : PSfit (被験者に操作関与でイメージを深めてもらう)) MVP特定と開発 (ユーザー⾏動フロー) 利⽤体験を伴う検証 (MVP検証) 仮説の修正課題仮説課題仮説機能仮説課題仮説機能仮説課題仮説機能仮説形態仮説検証⽬的の度合いが異なる

34. 仮説検証5周⽬ (target : PMﬁt) UXの推敲課題仮説機能仮説形態仮説・5周⽬以降に必要となるものは4周⽬の結果に依るが、アーリーなユーザー(課題が切実なため多少の瑕疵を⼤⽬にみれる) から、ユーザーの裾野を広げる⽅向に進む必要がある。・より「伝える」ことを丁寧に⾏う必要がある。それはPRだけではなく、プロダクトの表現そのものの磨き込みである。・ユーザーを⾃分たちに宿し、利⽤体験を頭から何度も繰り返しテストし、つっかかりのない「つるつる」を⽬指す（UXの推敲）

35. 分からないことを分かるようにする分かったことに基づいて、つくる仮説検証型アジャイル開発の戦略 Photo credit: ilovepics11 on Visualhunt.com / CC BY-NC-ND

36. 問われるのはわれわれは、どこまで変化に適応できるか？早く形が⾒える、触れられる想像⼒頼みから体が使えるだから、圧倒的に学びが増える Photo credit: Ale Art on Visualhunt / CC BY-ND

37. 学びが次の不確実性を連れてくる。 Photo on VisualHunt

38. 変化を受け⽌められる余⽩をつくりながら、短いタイムボックスの中での確実性は⾼める。余⽩が無ければ変化を受け⼊れられない。いかにして無いところに余⽩を作り出すか？⻑い距離で確実なことは⾔えない。でも、短い距離でなら？成果の確度を⾼められる。 Photo credit: Arenamontanus on Visualhunt.com / CC BY

39. 余⽩の戦略全体への共通理解を統べる作戦スプリント強度を⾼める戦術プロジェクトレベル複数スプリントレベルスプリントレベル・調整の余⽩・期間の余⽩・受け⼊れの余⽩・背⾻駆動開発・状況をクリーンに保つ5つの条件 1. 受け⼊れ条件を定義している 2. ベロシティを計測し安定させている 3. 受け⼊れテストを実施している 4. 振り返りを実施しカイゼン継続 5. 実運⽤相当のデータが揃っている

40. 余⽩の戦略・調整の余⽩ユーザー⾏動フローのうち「広さをコミット深さで調整」全体の必要最⼩限の実現を⾒⽴てつつ、実際の折々では状況を踏まえて実現内容を調整する。・期間の余⽩バッファの確保。個⼈・局所のバッファではなく、プロジェクトやテーマ単位でバッファを設ける。・受け⼊れの余⽩ ICEBOXの運⽤。学びを蓄積(凍結)し、状況を⾒て棚卸 (解凍)し、PBLとの順序付けを⾏う。

41. スプリント強度を⾼める戦術・背⾻駆動開発 PBLを背⾻(利⽤体験上必要不可⽋、前提となる基本機能) とお⾁に分けて、背⾻の開発を先⾏し、開発の前提を作る

42. スプリント強度を⾼める戦術・状況をクリーンに保つ5つの条件 1. 受け⼊れ条件を定義している条件を定義しようとしてみることが⼤事。実際にはできない場合もある。どこまではっきりしていて、どこからは作って⾒てなのかの理解をチーム、関係者で揃える 2. ベロシティを計測し安定させている低すぎず、過熱しすぎず。ボトルネック事案の早期検出をチームで⾏えるようになるために、ベロシティに関⼼を持つ。 3. 受け⼊れテストを実施している条件と呼応するもの(場合によって条件そのもの)。スプリント毎の確実な実施が安定度を格段に⾼めることになる。 4. 振り返りを実施しカイゼン継続 5. 実運⽤相当のデータが揃っている

43. 全体への共通理解を統べる作戦・⾃分たちの活動に”作戦名”をつける活動 = まとまった機能群の開発、カイゼン… 距離感としてはプロジェクト＞複数スプリント＞スプリント象徴的な名前付けで⽅針を分かりやすくする (“背⾻バックログを倒し切る作戦”) 「この期間」のミッションが明確になり、何をやれば良いかが⾃明になり、優先基準もわかりやすくなる。チームの⾃律的な動きへと繋がる。

44. 全体への共通理解を統べる作戦・⾃分たちの活動に”作戦名”をつける活動 = まとまった機能群の開発、カイゼン… 距離感としてはプロジェクト＞複数スプリント＞スプリント象徴的な名前付けで⽅針を分かりやすくする (“背⾻バックログを倒し切る作戦”) 「この期間」のミッションが明確になり、何をやれば良いかが⾃明になり、優先基準もわかりやすくなる。チームの⾃律的な動きへと繋がる。このタイムボックスのことを “ジャーニー” と呼ぶ

45. ゼロからのプロダクトづくりではなく既にあるプロダクトでの仮説検証にどんな特徴があるか？

46. デュアルトラック・アジャイル検証BBB スプリント11 スプリント13 検証CCC スプリント開発スプリントと仮説検証の活動が並⾏して進む開発→検証→学習結果を開発へとサイクルさせる並⾏する2つの活動間での同期ポイント設定が必要。同期の距離が空きすぎると、プロダクトに「学習不全の負債」がたまるスプリント12スプリント10 (プロダクト) (プロダクト) (学習結果)

47. 仮説検証リードを置く仮説⽴案のリードや、検証の計画づくり、検証⼿段や環境の準備などを中⼼となって進める役割。仮説検証実施の経験が問われる。適切な練度を備えたメンターを組織内外から招聘する。チームで学ぶ機会を段階的につくるまずは仮説検証とは何かという理解からはじめて、イベントベースの検証を⾏う（いきなり定常的に、組織的に⾏うのはハードルが⾼い）例えば、“ユーザーテスト” や ”プロダクトレビュー” をイベントとして実施する。

48. “タダシイ筋道も筋書き”もない中でそれでも前に進むためには？

50. 問い続けることで⾃分たちに傾向を与えるプロダクトづくりにおいて最も誤りをおかす箇所とは⾃分たち⾃⾝の意思決定や⾏動。 Photo credit: Shandi-lee on Visualhunt.com / CC BY-NC-ND

51. 第1部完

52. https://amzn.to/2TBC0oA https://amzn.to/2VQ6oOM https://amzn.to/32Wuklp https://ichitani.com/ https://enagile.jp/

53. 第2部ともに考え、ともにつくる

54. 不確実性との戦い必要なのは「誰にも分からない」という状況下で前に進んでいくあり⽅ Photo credit: Kylie_Jaxxon on Visualhunt / CC BY-SA

55. 不確実性とは回避するべきものなのか？

56. 混沌を引き寄せるものであり、プロダクトの未来を変える可能性でもある不確実性とは、明⽇の予定調和が常に明るい未来なわけではない未来を変えるためにはシナリオ(台本)を変えられる必要がある Photo credit: occhiovivo on Visual Hunt / CC BY-NC-ND

57. つまり、不確実性を⾃ら招き寄せる分からないことを増やす Photo on VisualHunt.com

58. 不確実性を招き寄せるために多様性を⾼める Photo on VisualHunt

59. 検証結果による学び前提仮定データ知⾒情報解釈 ☓ 期待結果これまで獲得した知識理解仮説合意形成意思決定多様性多様性が解釈に幅をもたらす

60. 重奏型仮説検証

61. 重奏的仮説検証仮説の外在化第1段階プロダクトオーナー1⼈の解釈を⼀⽅的に伝える仮説キャンバスで仮説を外在化 (誰でも表明が出来る) (解釈を頭から取り出す) 仮説検証

62. われわれはなぜこの事業をやるのか？⽬的ビジョン実現⼿段優位性評価指標提案価値顕在課題潜在課題代替⼿段チャネル状況収益モデル市場規模中⻑期的に顧客にどういう状況になってもらいたいか？提案価値を実現するのに必要な⼿段とは何か？提案価値や実現⼿段の提供に貢献するリソース (資産)が何かあるか？どうなればこの事業が進捗していると判断できるのか？ (指標と基準値) われわれは顧客をどんな解決状態にするのか？ (何ができるようになるのか) 顧客が気づいている課題に何があるか？多くの顧客が気づけていない課題、解決を諦めている課題に何があるか？課題を解決するために顧客が現状取っている⼿段に何があるか？(さらに現状⼿段への不満はあるか) 状況にあげたひとたちに出会うための⼿段は何か？どのような状況にある顧客が対象なのか (課題が最も発⽣する状況とは？) どうやって儲けるのか？対象となる市場の規模感は？傾向同じ状況にある⼈が⼀致して⾏うことはあるか？仮説キャンバス (1.0)

64. Photo credit: Wendelin Jacober on Visual Hunt / CC BY "プロダクトオーナー”の⺠主化 PO⼀⼈の視座、視野からチームの視座、視野へ

65. 重奏的仮説検証仮説検証の重奏化第2段階それぞれの中に仮説を持ち、共通の理解に対して掛け合わせる・多様なメンバー=多様な解釈への期待・検証を通じての仮説⽴案が前提・仮説検証の実施リードや解釈のメンター役は必要(仮説検証リード) 仮説検証

66. 重奏的仮説検証チーム or PO を仮説検証にどうやって巻き込むか最初は誰もが半信半疑。実践していく中で、意義を⾒出して⾏く。仮説検証についてのゴールデンサークルを確認した後、段階的な取り込みを設計する。第１ジャーニー：事前学習第２ジャーニー：イベントベースの検証第３ジャーニー：継続的な検証活動

67. Photo credit: Wendelin Jacober on Visual Hunt / CC BY 意味あるものを作り出したいという意思に POや開発者という分け隔ては無い

68. 相⼿のナラティブを知ろうとする Photo credit: zxjbfcindy2019 on Visual Hunt / CC BY-NC-SA

69. どれだけ多様な⾒⽅が出せたとしてもチームが進む為には⼀つのことに合意しなければならない？

70. 合意形成とは唯⼀の解釈のみ残しその他の全て⼀切を捨て去ることを強要するものではない

71. 検証結果による学び前提仮定データ知⾒情報解釈 ☓ 期待結果これまで獲得した知識理解仮説合意形成意思決定多様性ばらばらのままの合意形成チームの合意形成個々の仮説

72. 検証結果による学び前提仮定データ知⾒情報解釈 ☓ 期待結果これまで獲得した知識理解仮説合意形成意思決定多様性チームの共通合意個々の仮説ばらばらのままの合意形成 (それぞれが仮説を持つ) 仮説を⽴てるのにハードルがあるならばまずはワンライナーから始める https://ichitani.com/2019/oneliner-canvas/

73. 多様性 ☓ 機動性プロダクトづくりに多様性を取り込む、では次に⽬指すことは？多様性によって広がる選択に最⼤限適応していく

74. Photo credit: U.S. Paciﬁc Fleet on VisualHunt.com / CC BY-NC チームの機動性を上げるとは？インプット(変化)に対して即応性をあげるただし、全体性を⾒失わずに。誰かが与えた全体性のもとに、端っこから作っていくのではなく、⾃分たち⾃⾝で舵を取る

75. 「段階」の概念を取り⼊れる (全体と微細の両⽴)

76. 「段階の設計」とは⾃分たちが到達したい地点(⽬的地)を⾒⽴て、そこにたどり着くために必要となる状態を構想すること。現実を進めた結果から分かったことに基づき、構想⾃体を変化させる (現実を構想に合わせることが⽬的ではない)。⽬的地⾃体も通過点に過ぎない。変えていく。段階の⻘写真は、当事者に⽅向性を与える。不確実性の⾼い状況では、チーム、ステークホルダーとともに「理解」と「意思決定」を共通にして歩み進むことが唯⼀の頼り。

77. ※チームの活動単位であるスプリントの⻑さはチームのリズムを作るために固定 ※多様なミッションを捉えるためジャーニーの⻑さ(スプリントの数)は可変段階(ジャーニー)を経てアウトプットされるのは、チームとプロダクトの2つ

78. Photo credit: mikecohen1872 on Visualhunt.com / CC BY チームもプロダクトも最初から完成型(理想)が⾒えるわけではない

79. ジャーニー = 段階的発展 = 進化当事者として「意思のある進化」を仕組み、その上で変化に適応していくこと

80. どのようにしてジャーニーを運⽤するのか？

81. リーン・ジャーニー・スタイル

82. リーン・ジャーニー・スタイルセットベースで選択肢を広げ、ポイントベースでアウトプットを結実させる選択肢を広げるために多様性を利⽤する段階の設計によって、経験による学びを踏まえた当事者の意思決定を着実に形にしていく変化への適応性を確保するために、ミッション、フォーメーション、チームの主義を動的に選択する

83. ⽬的地を⾒定めるジャーニー(段階)を設計するジャーニーのミッション定義チームのフォーメーションを変更ジャーニーバックログプランニングチームのファースト選択ジャーニーの遂⾏ジャーニーのふりかえりとむきなおり (ジャーニーごとの回転)

84. 少しずつ繰り返しながら形づくる (agile)

85. 繰り返し = イテレーティブ

86. 少しずつ = インクリメンタル (チームもプロダクトも)

87. 段階的に = ジャーニー最初の旅（仮説検証）次の旅（プロトタイプ）さらに次の旅（MVP）

88. 少しずつ = インクリメンタル繰り返し = イテレーティブ段階的に = ジャーニー形作る

89. リーン・ジャーニー・スタイル重奏的仮説検証ジャーニースタイルフォーメーション・パターン適者⽣存型アーキテクチャ仮説検証プロセスチームアーキ

90. ※第1ジャーニーで検証結果が期待するものでは無かったら当然、全体のジャーニーを⾒直すプロダクト・ジャーニー

91. 選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）仮説検証型アジャイル開発不確実性が⾼いプロダクトづくりでのパターン仮説検証ジャーニー MVP開発ジャーニー MVP検証ジャーニー

92. 「傾き」の問題 Photo on VisualHunt.com

93. 理想的な変化量と現実の乖離イメージ

94. 「これまで」が引き寄せる重⼒を突破できない Photo credit: Miles Cave on Visualhunt / CC BY-NC-ND

95. 厳然と存在する「変化格差」

96. 「段階」によって「なめらか」にする

97. チーム・ジャーニー ※チームの成⻑戦略を描く。⾃分たちの出発点を⾒定め、ひとたび⽬指す⽬的地までの「傾き」が急勾配にならないよう設計する。実際のところ歩みはじめてみて、傾きを調整する。⽬的地⾃体を捉え直す。

98. 「過去」をふりかえり、現在を捉え直す「未来」にむきなおり、現在を捉え直すジャーニーにむきなおりは前提

99. プロダクトやチームを越えた、⼤きな段階を迎えている

100. Digital Transformation

101. DXは、現場と経営の変⾰意思が噛み合う惑星直列的なチャンス現場でいくらアジャイルを⾔っても通じなかった時代 “トップダウンによる変⾰”が空を切り続けた時代を経て、われわれは共通の危機感の下に辿り着いた Photo credit: NASA Goddard Photo and Video on Visual hunt / CC BY

102. チーム・ジャーニー現状の全てを⼀気呵成に Transformationするのはチームも練度も⾜りない。現状の⽂脈から分断した環境を作る (たいていの場合SoEが成熟していないからできる) SoE開発を通じてチーム作りに注⼒然る後に本丸(SoR)に切り込む (「逆２項対⽴」作戦)

103. ※DXのミッションとして技術・プロセスのモダン化、新たなビジネスモデル構築全てに⼀気呵成に取り組むのではなく、局所的なSoE 構築を先⾏させて学びの⼟台作りを⾏う。 DX・ジャーニー (狙いは、ジャーニーを通じたチーム、組織の成⻑)

104. ジャーニーは重なり合う

105. このあり⽅の先にあるものとは？「われわれはどこに向かうのか」

106. ともに考え、ともにつくる固定的な役割を中⼼とした「調整」から仮説検証による学びを中⼼とした「ともに」へ Photo on VisualHunt.com

107. ともに考え、ともにつくり続けるためには？

108. お互いの関係性に意味を⾒つける「われわれはなぜここにいるのか？」 Photo on VisualHunt.com

109. ⾃分⾃⾝のミッションと役割を問い直し続ける必要がある “⾃分のナラティブを脇に置く” 『他者と働く』 Photo on VisualHunt.com

110. 私⾃⾝のジャーニーゆえに。さいごに、

111. 地⽅アトツギ国・⾃治体⼤いなる組織 (⼤企業)

112. Photo via Mars Williams via Visual hunt これまで⽇本の社会インフラをつくってきたプレイヤーこそ逆境にある

114. つまり、不確実性を⾃ら招き寄せる分からないことを増やす Photo on VisualHunt.com

116. このジャーニーは、⾃分⾃⾝の再定義の旅 Redesign Journey

117. 新たな境界でまた。会えることを。 Photo credit: digitalpimp. on Visualhunt.com / CC BY-ND

正しいものをともに考え、正しくともにつくる

Esté a ler uma amostra.

Confira estes a seguir

正しいものをともに考え、正しくともにつくる

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a 正しいものをともに考え、正しくともにつくる (20)

Mais de toshihiro ichitani (20)

Mais recentes (20)