Joe Yoderさんによる、XP祭り2014での講演資料の日本語版です。

1. 大きな泥のカタマリを 相手にするための アジャイルと努力と苦労
Copyright 2014 Joseph W. Yoder & The Refactory, Inc.
XP Matsuri–September 6th, 2014Joseph W. Yoder --www.refactory.comwww.teamsthatinnovate.com

2. 継続可能な アーキテクチャ
Copyright 2014 Joseph W. Yoder & The Refactory, Inc. Joseph W. Yoder --www.refactory.com

3. Sustaining Your ArchitectureUIUC SAGから進化した (註:UIUC=イリノイ大学アーバナ・シャンペーン校) 90年代はじめに研究したもの：オブジェク ト、フレームワーク、コンポーネント、メ タ、パターンリファクタリング、再利用、 「良い」アーキテクチャ だが、このSAGの活動で発見したのは、いろいろ な良いものの話をしてるにも関わらず、世の中で 成功しているシステムには良い内部構造なんて さっぱりないということだった

4. Sustaining Your Architecture 利己的なクラス ブライアンと僕は『利己的なクラス』とい う論文を書いた。コードの視点からソフト ウェアの再利用と進化についてだ。 対照的に、僕たちのBBoM(Big Ball of Mud=大き な泥のカタマリ)の論文では、現実には多くの コードが再利用困難(利用も)になってしまってい る点に注目している。

5. Sustaining Your Architecture 大きな泥のカタマリ 別名: Shantytown(=写真のスラム街の ような都市構造), スパゲッティコード 「大きな泥のカタマリ」は構造が行き当たり ばったりで、とりとめの ない、いいかげんな、 ガムテープと針金でつないだ、スパゲッティ コードのジャングルのこと 標準的ソフトウェアアーキテクチャ でもある。なんでやりたいことと やってることにこんなに差があるのか？ 誰もが高品質なソフトを作りたいのに、 なんで世の中BBoMだらけなのか？

6. Sustaining Your Architecture 泥はどこから来るのか? コードを書くのは人泥を作るのは人

7. Sustaining Your Architecture 泥はどこから来るのか！ やっつけコード レガシー 都市のスプロール現象 焼き畑式 厳しい締め切り 単に無視する
ソフトウェアテクトニクス (註:プレートテクトニクスから)
再構築
•ドラスティックな変化
•捨ててしまう
インクリメンタルな変化
•進化
•一歩ずつ大きくなる

8. Sustaining Your Architecture 動かし続ける、 一歩ずつ大きくなる、 やっつけコード

9. Sustaining Your ArchitectureCopy ‘n’ Paste

10. Sustaining Your Architecture サンプリング (寄せ集め) の時代 糊(Glue)の 大きなバケツ&

11. Sustaining Your Architecture その名前は

12. Sustaining Your Architecture アジャイルが助けに来た??? プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を 価値とする。すなわち、左記のことがらに価値があ ることを認めながらも、私たちは右記のことがら により価値をおく。 …『アジャイルソフトウェア開発宣言』より

13. Sustaining Your Architecture アジャイルで助かるの？ スクラム, TDD, リファクタリング, 定常的 フィードバック, テスティング, 多くの眼 で見る 人が大事!!! 技術的卓越への絶えない注力 ふりかえり! フェイス・トゥ・フェイスで話す 意欲に満ちた人びとに環境と支援を与える

14. Sustaining Your Architecture アジャイルな設計における 価値 コアの価値: デザインのシンプルさ コミュニケーション 継続的な改善 信頼とチームワーク ステークホルダのニーズを満たす 学び続ける 定常的フィードバック テスティングと確認(validation)を たっぷり

15. Sustaining Your Architecture アジャイルの神話 どんなときでもシンプルに 要求の変化にも簡単に対応できる(新しい要求で も) スクラム/TDDを使えば良い 設計・アーキテクチャになる 良いアーキテクチャは、「正しい」プラクティ スで開発するだけで勝手に発生する それだけじゃダメなときも 最後の最後に重大なアーキテクチャ変更をする “www.agilemyths.com”

16. Sustaining Your Architecture アジャイルの原則が 悪い設計の一因か？ 事前の設計をしない? 終盤でシステムの要求を変える? 常にアーキテクチャを進化させる? 一歩ずつ育てる? アーキテクチャよりプロセスを大事にする? 動くコードが成功の尺度だ！ 他にもあるはず!!!

17. Sustaining Your ArchitectureCraftsmanship?

18. Sustaining Your ArchitectureThe Quality Goes In

19. Sustaining Your Architecture 品質(Quality) 品質の定義:特別で本質的な特徴や特性、生得 の特徴や属性、優秀者の度合いや格付け、際 だった特質や個性

20. Sustaining Your Architecture 品質(誰の視点で見るか)
科学者
芸術家
エンジニア
デザイナー
重要/ つまらない
真/ 偽
クール/ クール じゃない
良い/ 悪い
Rich Gold "The Plenitude: Creativity, Innovation & Making Stuff(Simplicity: Design, Technology, Business, Life)“
Triggers and Practices –Richard Gabriel http://www.dreamsongs.com
アーキテクトが持 つ視点は、芸術家 とデザイナーとエ ンジニア
“The Four Winds of Making”…Gabriel

21. Sustaining Your Architecture“～性” 要求
アクセシビリティ
互換性
効率性
有効性
拡張性
保守性
パフォーマンス
信頼性
安全性
スケーラビリティ
機密性(セキュリティ)
安定性
サポート性
使用性
「制約」「品質属性」「サービス要求の品質」などに対応
品質は「～性」で表現され、非機能要求とも呼ばれる……
いっぽう、機能要求がどれだけ正しく実現されたかも品質である (こちらはどう計測するのか？)

22. Sustaining Your Architecture 十分であるということ 十分であるという品質 最低限の要求を満たしているか 品質には多くの対立し合うフォースがある ……オンライン受注システムとスペース シャトル制御システムとでは品質は異なり、 適用すべきパターンとソリューションも異 なる 完璧は必要十分の敵! 数値化できない品質も、敵かも

23. Sustaining Your Architecture コードの品質に意味はある？ 上質(quality)なコードを書くためのパターン、 意図を上手く伝え、理解しやすく、 読むのが快いコードを書くためのパターン。 本書は「上質」なコードのパターンである。 しかしながら…ケント・ベック曰く 「…本書はある仮定を置いているが、それは脆弱なものだ。 すなわち、コードの品質は有意義であるという前提だ。私 はこれまで、醜いコードが大金を産み出している様をたく さん見てきた。おかげで、ビジネスの成功やソフトの普及 のためによいコードが必要だとは、なかなか信じられなく なっている。 それでも私はコードの品質に意味はあると信じている」 パターンはバグがより少ないコードを書く助けになるし、修 正と拡張の役にも立つ。

24. 技術的負債
ウォード・カニンガムが作 った言葉
実装し続けるだけで、新 たな理解や学びを反映 せずにいると、積み上が っていく
長期的なコストや悪影 響があり得る

25. Sustaining Your Architecture 家を掃除する ジェントリフィケーション、リハビリ、模 様替えをすれば、泥をきれいにする役に 立つ？ リファクタリング、パターン、フレーム ワーク、コンポーネント、アジャイル、 オブジェクト指向は泥掃除の役に立つ？ 泥防止は可能か？それでアーキテクチャを きれいに保てるか？

26. Sustaining Your Architecture コードの完全な模様替え
リファクタリングで泥を除去できる？
汚れを敷物の下に隠してるだけでは？

27. Sustaining Your Architecture コードの完全な模様替え

28. Sustaining Your Architecture すでにBBoMがある どう手をつけたらいい？ 汚い部分を局所化するには？

29. Sustaining Your ArchitectureStuart Brandの 「層の分割」(Shearing Layers) 建物は多くのコンポーネントでできて いるが、それぞれは異なる時間軸で変 遷する 層: 立地、構造、表面、サービス、空間 設計、中身。それぞれの層は異なる価 値を持ち、異なる速度で 変化する 建物が適応できるのは、 速い層(サービス)が 遅い層(構造)に邪魔されないため —Stuart Brand, How Buildings Learn

30. Sustaining Your ArchitectureYoderとFooteによる ソフトウェアの層の分割 「システムを要素分解し、同じスピードで変化するもの をまとめるようにする」—Foote & Yoder, Ball of Mud, PLoPD4. •プラットフォームThe platform•インフラInfrastructure•データスキーマData schema•標準フレームワーク、コンポーネント、サービス Standard frameworks, components, services•抽象クラス、インターフェースAbstract classes and interfaces•クラスClasses•コードCode•データData
層 ゆっくり 速い

31. Sustaining Your Architecture コードの模様替え リファクタリングで泥を元に戻せる部分もある。ト レードオフもある。コスト、時間、もしかしたら テクノロジーも。 リファクタリングから良いデザイン(パターン)へ…

32. Sustaining Your Architecture リファクタリング 振る舞いを保持したまま プログラムを変更する •インスタンス変数の名前変更 •メソッドをスーパークラスへ引き上げ •メソッドをコンポーネントへ 必ず理由に基づいて実施する!!! リファクタリングはほとんどの アジャイル手法において 鍵となる、欠かせない要素!!!
TDD

33. Sustaining Your Architecture シンプルな リファクタリングの例
Object
Concrete1
Concrete2
Object
Concrete1
Concrete2
NewAbstract
空クラスを作る Borrwedfrom Don Roberts, The Refactory, Inc.

34. Sustaining Your Architecture 複雑な リファクタリングの例 困難なリファクタリングもあるが、小さなステップ を多数積み重ねれば泥退治に大きな効果を得られる
Borrowed from Don Roberts, The Refactory, Inc.
Array
Matrix
Matrix
MatrixRep
ArrayRep
rep
SparseRep
IdentityRep

35. Sustaining Your Architecture
リファクタリングは 小さなステップの積み重ねで 不吉な臭いを除去し 望ましい設計に到達する
1ステップごとに テストを実行し、 すべて動いていること を確認する!

36. Sustaining Your Architecture テスト必須 不吉な臭いがするコードを見つけたら リファクタリングしてきれいにする テストは安全な リファクタリングの鍵！

37. Sustaining Your Architecture 小さなステップで 設計を変化させる
メソッドの抽出
メソッドの移動
ポリモーフィズムによる条件記述の置き換え
テスト
テスト
テスト
名前変更
テスト
あるいは

38. Sustaining Your Architecture コードの臭い (Code Smell) コードの臭いはコードのどこかで なにかマズいことが起きている兆候。 臭いを追跡して問題を発見するケント・ベック コードの不吉な臭いはケント・ベックと マーチン・ファウラーの書いたエッセイで、 「リファクタリング 既存のコードを安全に改善する」 の3章に収録----Ward’s Wiki
Have you ever looked at a piece of code that doesn't smell very nice?

39. Sustaining Your Architecture 臭いのキツいワースト101)いい加減なレイアウト 2)デッドコード(実行されないコード) 3)投げやりな名前 4)コードのコメント 5)コードの重複 6)特性(feature)の横恋慕 7)不適切な関係 8)長すぎるメソッド、巨大なクラス 9)基本データ型への執着、長すぎるパラメータリスト 10)スイッチ文、条件による複雑化

40. Sustaining Your Architecture ダメなフォーマット
void foo(intx[], inty, intz){
if (z > y + 1)
{
inta = x[y], b = y + 1, c = z;
while (b < c)
{
if (x[b] <= a) b++; else {
intd = x[b]; x[b] = x[--c];
x[c] = d;
}
}
inte = x[--b]; x[b] = x[y];
x[y] = e; foo(x, y, b); bar(x, c, z);
}}
void bar(inti[], intj, intk)
{ return i[j] = int[k]}

41. Sustaining Your Architecture デッドコード
void foo(intx[], inty, intz) {
if (z > y + 1) {
inta = x[y], b = y + 1, c = z;
while (b < c) {
if (x[b] <= a) b++; else {
intd = x[b]; x[b] = x[--c];
return;
x[c] = d;
}
x[b] = a;
}
y = 5; // set y equal to 5
inte = x[--b]; x[b] = x[y];
x[y] = e; foo(x, y, b);
/* usedtouse bar, mightneeditagain
bar(x, c, z); */
}
void bar(inti[], intj, intk) {
/* bar method returning nothing */
if (j > k) {
return k
i[k] = i[j];
}
if (j == k) {
return i[j] = int[k]
}
}

42. Sustaining Your Architecture レイアウトを直し 不要な部分を除去しよう コードのフォーマットは一貫性を持って 標準フォーマットに合意する 一貫性を保つためツールを決める コードベース全体にツールを使う 到達しないコードを除去 無用のコメントは削除 コメントアウトしたコードは削除 到達しないコードは削除

43. Sustaining Your Architecture なげやりな名前
void foo(intx[], inty, intz)
{
if (z > y + 1)
{
inta = x[y], b = y + 1, c = z;
while (b < c)
{
if (x[b] <= a) b++; else {
intd = x[b]; x[b] = x[--c];
x[c] = d;
}
}
inte = x[--b]; x[b] = x[y];
x[y] = e; foo(x, y, b);
foo(x, c, z);
}
void quicksort(intarray[], intbegin, intend) {
if (end > begin + 1) {
intpivot = array[begin],
l = begin + 1, r = end;
while (l < r) {
if (array[l] <= pivot)
l++;
else
swap(&array[l], &array[--r]);
}
swap(&array[--l], &array[beg]);
sort(array, begin, l);
sort(array, r, end);
}
}
http://dreamsongs.com/Files/BetterScienceThroughArt.pdf

44. Sustaining Your Architecture 名前を直す 名前は意味がないといけない 標準はコミュニケーションの役に立つ ― 学んで従おう 標準プロトコル object ToString(), Equals() ArrayListContains(), Add(), AddRange() Remove(), Count, RemoveAt(), HashTableKeys, ContainsKey(), ContainsValue() 標準の名前付け規則(conventions)

45. Sustaining Your Architecture 重複したコード どんなことでも1回だけにする コードの重複はシステムの理解もメン テナンスも困難にする 変更も重複する 直す人は全コピーを変えないといけない

46. Sustaining Your Architecture コードの重複を直す どんなことでも1回だけ！ コードの重複を直す 同じメソッドをスーパークラスへ引き上げ 同じメソッドを共通のコンポーネントへ移動 長すぎるメソッドを分割
再利用
重複 するな！
DRY 原則

47. Sustaining Your Architecture
不適切な関係
クラスがお互いの実装の詳細に依存 すると……
密結合なクラス–片方を変 更すると、もう片方も変更し ないといけない
クラスの境界の定義が曖昧

48. Sustaining Your Architecture
特性の横恋慕
あるクラスが別のクラスの特性(機能 )をたくさん使うと……
特性(の一部)が間違ったクラスにいること を意味する… メソッドの移動を使う
クラスが密結合になって しまう

49. Sustaining Your Architecture スイッチ文 あちこちのメソッドに多数のスイッチ文や、 ネストした条件分岐がある double getSpeed() { switch (_type) { case EUROPEAN: return getBaseSpeed(); case AFRICAN: return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts; case NORWEGIAN_BLUE: return (_isNailed) ? 0 : getBaseSpeed(_voltage); } throw new RuntimeException("unreachable"); }

50. Sustaining Your Architecture
double getSpeed() {
switch (_type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() - getLoadFactor() *
_numberOfCoconuts;
case NORWEGIAN_BLUE:
return (_isNailed) ? 0 :
getBaseSpeed(_voltage);
}
throw new RuntimeException("unreachable");
} ポリモーフィズムによる 条件記述の置き換え スイッチ文や分岐の代わりにメソッド名で 場合分けする(ダブルディスパッチ)
フックメソッドにポリ モーフィズムやオー バーライドを使う(新し い場合にも既存コード を変更せず対応できる)

51. Sustaining Your Architecture リファクタリング: いつ使うのか？ ۔常にリファクタリングしていれば、いつ やっても安全だし比較的簡単。 ちゃんとしたテストがあればなおさら ۔バグを直すとき ۔新しい機能を追加するとき ۔リリースの直後 ۔テストのリファクタリングも必要かも!!!

52. Sustaining Your Architecture リファクタリングの戦略 拡張–リファクタリング リファクタリング–拡張 デバッグ–リファクタリング リファクタリング–デバッグ 理解するためにリファクタリング

53. Sustaining Your Architecture リファクタリングが鍵となる レバレッジポイント リファクタリングは技法として、ブルックスの「有望 な攻略」(『銀の弾などない』より)の役に立つ(註: 銀 の弾の代わりに武器として戦えそうなもの) 作らず買ってくる: インターフェースを再構築して、商 用ソフトウェアが使えるようにする ソフトウェアを育成せよ、構築するな: ソフトウェアの 育成では再構成が起きる 要求の洗練とラピッドプロトタイピング: リファクタリ ングは設計の探索を支援し、変化する顧客ニーズに対応 する役にも立つ 偉大な設計者を支援: 設計者の道具箱のツールのひとつ

54. Sustaining Your Architecture2種類のリファクタリング* デンタルフロスリファクタ リング 頻繁、小さな変化、他のプロ グラミング作業 (日々の健康管理)と一緒 根管治療リファクタリング 稀、長引く、その間プログラ マは他のことをできない(大規 模修理)
* Emerson Murphy-Hill and Andrew Black in“Refactoring Tools: Fitness for Purpose”
http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf

55. Sustaining Your Architecture 共有の知恵 「ほとんどの場合、私はリファ クタリングの時間を別に取るの に反対だ。私の考えでは、リフ ァクタリングは時間を取ってや るようなものではない。リファ クタリングはいつでもやるものだ 。小さなまとりで(in little bursts)」 —Martin Fowler
リファクタリングを日々の業務に組み込む

56. Sustaining Your Architecture アーキテクチャを持続させる
アーキテクチャを長期に渡って 維持するために、何ができるだろうか？

57. Sustaining Your Architecture 敷物の下に隠す 隠せば、他の場所をきれいにできる (ファサードや、他のラッパーパターン)

58. Sustaining Your Architecture 表玄関に敷物を 重要なコンポーネントを守る！ システムの他の場所をきれいに保つ グルーコード(Mediator)が役立つことも システムの他の部分はきれいに保てる (腐敗防止レイヤ–エリック・エヴァンス)

59. Sustaining Your Architecture 玄関で足を拭いて上がる
別名: 隠蔽して無視せよ 内部をきれいに保て
Patterns forSustaining Architecture
PLoP2012 Paper
外部システム は信頼しない
標準外のイン ターフェース
アプリケーショ ン結合サービス とアダプター間 のやりとりは信 頼できるよう設 計

60. Sustaining Your Architecture 玄関で足を拭いて上がる
フィルタリングとクレンジング(洗浄)のシーケンス。 PlaceOrderインターフェースをきれいに保つ
Protected ComponentsS1S2S3SnAdapter/ Proxy/ FaçadeFrontdoorWrapperFiltering, Cleansing, Security Checks...

61. Sustaining Your Architecture 馬車が通う道を舗装する
別名: 繰り返しのタスクを簡単にする 繰り返しのコーディングタスクを合理化
単純なサンプル、テンプレート、スクリプトを 作る
コード生成のツールを作る
既存のツールやフレームワークを見つけて導入
フレームワークやランタイム環境を作る
ドメイン固有言語を作る
Patterns for Sustaining Architecture
PLoP2012 Paper

62. Sustaining Your Architecture 馬車が通う道を 舗装する
Patterns for Sustaining Architecture
PLoP2012 Paper

63. Sustaining Your Architecture 継続的インスペクション
Asian PLoP2014 Paper

64. Sustaining Your Architecture 継続的インスペクション
Asian PLoP2014 Paper
コードの臭い検出
メトリクス(テストカバレジ、循環的複雑度、技術的負 債、大きさ、……)
アプリケーションセキュリティ チェック
アーキテクチャへの適合性
できるだけ自動化する!!!

65. Sustaining Your Architecture アーキテクチャを維持する アーキテクチャ負債を 最小限に: 必要な変更を 受け入れられるように する 難しすぎたり、時間が かかりすぎたり、面倒 だったりすることを簡 単に 最も反応できるタイミ ングで判断せよ。反応 可能な最も遅いタイミ ングではなく 学んで進化せよ
65
システムをユーザーと開発者にとって「住める」ように保つ

66. Sustaining Your Architecture 維持できる アーキテクチャ Stewardship(註:steward=世話役、管財人、執事、など) 徹底的に付き合う 注意を常に払う 小さなことでも、システム を成長・変化・適応させる のに悪影響があれば、見逃 さない

67. Sustaining Your Architecture アーキテクチャプラクティス: 技術的負債を減らす 新たな学びをコードに 反映する リファクタリング 再設計 やり直す コードをきれいにする ユニットテスト (機能性) アーキテクチャ的品質 のテスト(パフォーマ ンス、信頼性、など)
67

68. Sustaining Your Architecture アジャイルの価値が アーキテクチャプラクティスを駆動 する 行動する。アーキテクチャについて長 々と議論しない 新たな知識が獲得できるようなことを する アーキテクチャのアイデアは実証する リスクを減らす テスト可能にする 具体的な疑問に答えるような、現実的 なシナリオのプロトタイプを作る アーキテクチャをインクリメンタルに 改善する 遅らせてもいいアーキテクチャ上の判 断は、遅らせる
行動せよ！
証明して
改善せよ

69. Sustaining Your Architecture アーキテクチャに十分注意して いれば、こうなる 欠陥は局所化する インターフェースが 安定している 一貫性 開発者が新機能を 追加するのが簡単 新機能が既存のアーキテクチャ を「破壊」しない 厄介で触ると大変なので触りたくないと開発 者が思うような箇所がほとんどない 新しい機能をインクリメンタルに取り込める

70. Agile MindsetBe Agile

71. Sustaining Your Architecture 速い思考vs. 遅い思考 (『ファスト＆スロー』) 速く考える: 直感に基 づく判断、バイアス、 習慣化したパターン、 感情 遅い思考: 推論, 論理的 思考, 熟慮

72. Sustaining Your Architecture 両方に時間を使おう 遅い思考 ペア作業で選択肢を議論する、なぜこのやり 方で実装するのがいいのか？ スケッチ、落書き、設計スパイク 速い思考 直感に従う、走りながら考える コーディング・テスト・手直しを高速に回す (レッド/グリーン)

73. Sustaining Your Architecture 品質に関するシナリオとテストを アジャイルプロセスに当てはめる
プロダクト ビジョン、 ロード マップ
ステークホル ダに提供
機能の 受入テスト
バックログを
管理し、
実現する
スプリント計画
スプリント実行
毎日のレビュー
フィードバックを取り込む
重要な品質 シナリオを定める
品質シナ リオも含 む
関連する 品質タス クを含め る
品質の
テスト

74. Sustaining Your Architecture
要求の Envisioning(日/週単位/...)
アーキテクチャ のEnvisioning(日/週単位/…)
イテレーション0: Envisioning
イテレーションモデ リング(時間単位)
モデルストーミン グ(分単位)
高速TDD(時間単位)
イテレーションN:開発
すこしモデリングしてたく さんコーディングする、ど の品質を「スプリント」に 含めるか考える
概念モデリング
どんな品質が重要か？ テスト駆動開発は 品質を含むべき

75. Sustaining Your Architecture 品質を向上する他の手法 Steve McConnellhttp://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
1つの手法では平均40%！
手法を組み合わ せれば90％以上 の品質が！

76. Sustaining Your Architecture 泥沼を干上がらせる スパゲティコードのジャングルから 脱出することは可能だ むしろ土地を改造することも可能だ。 魔法があるわけではない。大切なのは、 長期的にアーキテクチャにコミットし、 あなたの領域において品質のよいものを 育て、改善していくのだ。(Refactoring)! ベストプラクティスのパターンが 役に立つよ!!!

77. Sustaining Your Architecture 銀の弾丸 銀の弾などない …フレッド・ブルックス 銀の散弾ならあるかも …有望な攻略 よい設計 フレームワーク パターン アーキテクチャ プロセス/ 組織 ツールとサポート リファクタリング Good People ***

78. Sustaining Your Architecture 希望はまだある!!! テスティング(TDD), リファクタリング, 定常的 フィードバック, パターン, 多くの眼で見る, … Good People!!! 技術的卓越への絶えない注力! ふりかえり! フェイス・トゥ・フェイスで話す 努力と苦労！(Diligence and Hard Work) 意欲に満ちた人びとに環境と支援を与える ところで、泥のせいでアジャイルがあるのかも ……

79. ItTakesaVillage(註:人が育つのは村全体あってこそ、のような諺)

80. DōmoArigatōgozaimashita!!!
joe@refactory.com
Twitter: @metayoda