テストカテゴリの出し方（機能編）をみきおさんから教えてもらった

Twitterでワイノワイノやってたら、みきおさんからテストカテゴリの出し方を教えてもらった。

みきおさんのテストカテゴリの機能側導出の手順。 ソースはこちらを参照のこと。 http://togetter.com/li/684105

みきおさんがまとめたアーキテクチャー入りの方はこちら http://togetter.com/li/684589

機能を実現するプログラムを単純に入力、処理、出力とみなします。
入力に関するテストすべき観点は、「入力データチェック」「ボタン操作」
になるでしょう。処理に関する観点は「計算」、出力に関する観点は
「表示」になります。

この取り掛かりはマインドマップ本や、HAYST法のラルフチャートと同じだと思う。 まずは3つに分けてそこからブレイクダウンするということ。
シナリオを書いているときも同じ思考かもしれない。

これでだいぶテストカテゴリが洗い出されますが、これだけだと、
p.10のテストカテゴリには不十分です。何が足りないかというと、
「処理」のところです。単純に入力されたデータを演算して出力す
るのではなく、蓄積された値を使うことがあります。
そこで、処理で蓄積された値を扱う場合のカテゴリである「登録、
更新、削除」が現れます。これまでの説明で、論理的機能構造の
入力、変換（処理）、出力、蓄積が現れています。ですから、
p.10のテストカテゴリは機能モデルから導いていることになります。

これはモデルによって変わるんだと思う。 例えば、コマンドラインでの計算プログラムだと蓄積された値は無いかもしれない。 でもメモリは必ずあるので、この機能モデルの蓄積がファイルまたはDBか、メモリを含むか道考えるかで違うんだろうな～

あるテスト対象の場合、入力、処理－蓄積、出力という機能モデルには
馴染まないものもあるかもしれません。この場合は、別のモデルを
設定すれば良いことになります。
あと、機能モデルはプログラム・スケルトンを用いた
構造化プログラミングっぽいので、クラス図に慣れていると
違和感を持つかもしれませんね。

なるほど。ちょっと納得です。

テスト対象によって、テストカテゴリ名称が変わることはあると思います。
「ボタン」が「リンク」に変わったりとか。さらに、組織の文化も
反映すると思います。エラー発生時のメッセージ確認を重点的にやる組織ならば、
「エラー処理」のようなカテゴリを追加するかも。
「エラー処理」ではなく、状態遷移に関するテストを重視するのであれば、
「状態遷移」というカテゴリを持ってくるかもしれません。
まぁ、公開されているゆもつよマトリクスを分析した結果なので、
非公開のものには当てはまらないものがあるかもしれません。

エラー処理はともかく状態遷移は機能モデルからは出ないと思う。 組織（または個人）の経験として持っておくべきなのか。。。

2014/06/25 追記
どうやらやはり状態遷移は機能モデルから導出するらしい。 また機能モデルは対象のソフトウェアに依らないが、 状態遷移だったり、エラー処理だったり意図を持ってテストカテゴリを導出するとのこと。 状態遷移や非同期処理、排他などは機能モデルのサポートから出るみたい。

http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf のP7

f:id:nemorine:20140625224941p:plain

テストカテゴリの出し方（機能編）を考えてみた

WACATEに参加して、ゆもつよメソッドについて以下の理解が足りないということが分かった。
少し考えてみないとダメだね。。。でもそれが分かったことも収穫だった！

  • テストカテゴリの出し方（機能/非機能両方）
  • テストタイプの網羅性とテストカテゴリの網羅性
  • テストカテゴリの数と粒度
【そもそもテストカテゴリとは？】
既に選択したテストタイプに対して、どのようなテストケース条件で
変化を与えるべきかを考えたものがテストカテゴリになります。
(ソフトウェアテストPRESS Vol.10 P20)

JaSSTのサトミ塾の例。 http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf P10のデジカメの例を考えてみる。

上記資料でもテストPressのVol.10でも機能モデルから出しているのですが、、、 自分の結論は機能モデルは"無理"です。 この機能モデルを常に上手く出せる気がしないっす。。。 (1) (2)

ってことで自分が考えた結果は、データ中心のシナリオから出すのがいいと思いました。

デジカメの例で考えてみると･･･

【写真を撮るときのシナリオ】
1. ユーザーがシャッターボタンを押して、
2. 写真のデータが、SDカード内部に保存される。
3. そのときにJpegに変換される。
4. 保存されたデータはSDカード内部から読み出されて、
5. 液晶ディスプレイに表示される。

ここから動詞を抜き出すと以下のような感じ

  • ボタンを押す
  • データの保存
  • データの変換
  • データの読み出し
  • ディスプレイへの表示
【写真を見るときのシナリオ】
1. ユーザーが再生ボタンを押して、
2. 写真のデータがSDカードから読み出されて、
3. 液晶ディスプレイに表示される
4. ユーザーは進むボタン/戻るボタンを押し、
5. 写真のデータがSDカードから読み出されて、
6. 液晶ディスプレイに表示される

ここから動詞を抜き出すと以下のような感じ

  • ボタンを押す
  • データの読み出し
  • ディスプレイへの表示

エラー系だとフォーマットが違いますって出て表示できないこともあるので、それを考えると実は読み出した後にフォーマットのチェックをしている模様。するともう1つカテゴリがでるかな。

シナリオを何個か書き出してあげると大体の機能のテストカテゴリは出すことができそう。
自分は結構スッキリしました（笑

機能モデルに近いクラス図からも出す方法も考えたんだけど、 クラスというより、もう1つ上の概念、レイヤーとかパッケージとかそれくらいになる気がする。 でもその場合は例えばチェックとかそういうのって、クラスだったり、メソッドだったりのレベルだと思うので、レイヤーとかとは粒度が違うので出にくい感じがしてるんだよなー

あとは感覚的にはマインドマップ本のテスト対象分析のやり方でも出せるような気がしている。 簡単なアプリから考えてみるともう少し分かる気がする。

※考え方とか間違っていたら指摘ください♪

(*1) どうやら機能モデルはシステムによってそんなに変わらないらしい。 http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf のP7

(*2) みきおさんから以下のコメントを頂きました。 機能モデルはプログラム・スケルトンを用いた構造化プログラミングっぽいので、クラス図に慣れていると違和感を持つかもしれませんね。

DevLOVE仙台 泥臭い受託開発を語る

時間が取れたので、急遽参加！
そして、参加して良かった！！超楽しかった！！
今回は話聞きながら少しまとめれたので、ブログが楽チン♪
次回もこのスタイルで行きたいなぁ…

DevSen 炎上プロジェクトの経験を前向きに学ぶ(村上さん)

炎上あるある

  • 要件がコロコロ変わる
  • メビウスレビュー
  • 赤字覚悟の案件受注

できる人に仕事が集中して人がおかしくなってしまう。 できない人はおかしくならないｗ

炎上の原因

  • コスト度外視で納期だけ

対策は？

  • プロジェクトマネージメントの強化
  • PMP
  • ISO

でもダメだった。。。
結局、工数が増える/品質が劣る/管理作業も増える

自分たちの問題点を直視しないで、借りてきた解決策を導入するとこうなるよね。。。

やっと気づいた思考パータン

  • 積み重ねの概念がない　＞ 昨日と今日に連続性がない
  • 悪いのは自分以外の何か ＞　だから謝らないし、自信満々
  • 対策は他から持ってきたものばかり ＞ 自分では考えてない

話せば分かると思ってたけど、分かり合えない。。。
ただし、ジャイアン（＝自身満々の人）の数は少ない

真の対策は？

  • 仲間を増やす
  • コネクションを使って、情報を通していく
  • 情報は聞かれたものだけ報告していく
  • そしてジャイアンを無力化する
  • 上手く行ったらチームみんなに感謝をする
以前、村上さんとお話したときの情報を少し…
「情報はプロジェクトの血と同じ。滞っていると死んでしまう。
そのために、キーマンを飲みに誘い情報を引き出す。
そして、小さくてもいいのでやってみる。
楽しそうにやっていると人が集まってくる。そうやって仲間を増やしていく。」

DevKan 受託だからと言って受け身である必要はない（大友さん）

スライド

SlideShare

下請けから見て誰がお客さんか？

  • 元請けのA社が満足する必要がある
  • 誰が何のために必要なのか
    →これは本当にドメインを知ってる人じゃないと答えられない

受け身じゃないポイント① 本当の要求を持っているユーザーまで自ら辿り着く

「念のため」という言葉を上手く使い確認を行う

受け身じゃないポイント② ユーザーが予算獲得などで作成したコンセプト資料を必ず手に入れる

コンセプト資料を手に入れたら要求仕様書を作成する。

受け身じゃないポイント③ たとえ不要と言われても、要求には「なぜなら〜」を書く

なぜなら〜、〜だからだを書くことでチームの意識が揃ってくる。
これがないと、メンバー同士が憶測で喧嘩を始めることもある。

派生開発でいう理由に当たるところだと思う。
レビュー時も要求だけよりも「なぜ」という理由が書いてあった方が納得しやすい。

受け身じゃないポイント④ チームが形成される仕組みを積極的に組み入れる

いっぱい話せる仕組みを取り入れる。朝ミ、夕ミ、ランチミーティング、飲み会など。

受け身じゃないポイント⑤ 良いプロダクトを作る機会では社外もチームととらえ積極的に会話する

普段からどうでもいいことを話してないのに、大事なときだけ話せるわけがない。
お金と瑕疵以外で話して、チームとしての一体感を持つ。

要注意

会話の量は仕組みで増やすことができるが、 会話の質は個人に依存するので、要注意。

最後の会話の質は個人に依存するっていうのは本当に分かる。
お互いに尊敬の念がないとダメになることが多い。
ただどうやって尊敬の念を作っていくかは…　まだ答えがない。
半谷さんの発表のように、激論をすることでお互いを強敵（とも）と
呼べるようになればいいのかな…

DevSen 「泥臭くない」受託開発なんてない。あるいはTDD/DDDのすすめ（井上さん）

泥臭い受託開発とは？

受託開発で顧客が求めているシステムは全て異なる！
Why / What / Howを常に探求し続ける必要がある。
レベルの違いはあるかも知れないけど、全ての現場が泥臭いことをしているはず。

SIer時代で楽しかったこと

かなり早い時代からのXP。 顧客にとっていいものを作れたことが楽しかった。

2001年からテストファーストをやっていたとは…
時代がやっと井上さんに追いつきましたね（笑

悩み

  • ほとんど中間管理職
  • システムのWhyとWhatに注意を払う人が居なかった
  • 決定したことをそのままやることが重要
  • 技術力が評価されない
  • 周りを変えるのは難しい
  • 誰のための仕事か分からない。
  • ドキュメントとコードが一致しない。
  • チーム全体に覇気がない

TDD/DDD

自分が良いと思っているTDDでプログラミングしたプロジェクトはバグ０。
１サイクル目は捨てる前提！！

１サイクル目は捨てるっていうのがグッと来た。
そもそもソフトウェアに試作とかという工程がないのがおかしい。
DDD勉強会in仙台参加しなきゃ！

DevKan 「私がモテないのはどう考えても受託開発が悪い！」なんてことはない（横田さん）

よこたまさた ＠mesodash

最近はSonicGardenやGildWorksのビジネスモデルのように情熱系受託開発が多い

受託開発あるあるチェック

  • 要件定義が長引き開発の費用や時間が大幅に減った
  • 作ったものが期待するレスポンスで動かない（作り直し）
  • 外注したら絶望的な品質の何かが届いた（作り直し）
  • そういえば今日はメールとExcelのみ
  • お客さんからモーニングコールがかかってきた

終わらない開発

  • なぜやそもそもを十分に把握せずに対処してしまった。
  • チームのスキルを無視した技術の採用
  • 個人の力技で解決

受託から自社製品へ

  • 仕様を自分たちで決められる
  • 自分たちが考えた機能をお客さんにイイネしてもらえる

でも売れなかった…
中途半端な状態で逃げられなどしない。

どうすればプロジェクトが上手くいくか

  • プロジェクトは未知の領域
  • 技術は前提

やるべきことはしっかりやらないといけない

  • 見積もりはしっかり
  • 真の要求をとる

チームが上手く機能すれば、プロジェクトは劇的に良くなると実感する。
上手く機能させるためには仕組み作りも必要である。

受託開発のいいところ

  • 色んな技術を取得できるチャンスがある
  • お客さんと直に接することが出来る
  • お客さんの望んでいるものに対して、自分たちの最高を届ける
横田さんはどれくらいモテないのか、気になって仕方なかった…

まとめ

  • 経営上の課題を解決する
  • お客さんとしっかり向き合って、信頼関係を作る
  • 現場が正しいと思うことを出来るような組織にする
開発者の良い面を引き出すのが、良いマネージメントなのかもしれない…

サービス企業も結構色々あるんですよ（半谷さん）

日々の仕事

Hadooop Cluster（2PB）使って、本社からの仕事を仙台、大阪で受けている。

今の問題

  • ビジネス側と開発側に隔たりがある
  • 東京と地方との隔たり

地方で成果を出すべく、ガシガシ頑張った結果、東京から見直された。
転機は東京チームと激論を交わしたこと。そして飲みにいくようになった。お互いに理解が深まって態度が軟化して来た。

心の友よ！状態になった！！（向こうが本当に思っているかどうかは分からないｗ）

楽しくやることが重要。あと酒。酒があれば大抵大丈夫。

楽しくやることって重要だよね。自分もそれを一番に心がけている。
同じことをやるにしても楽しくやってるかやっていないかで伸びに雲泥の差がある。

ダイアログ

自分が入ったのはチーム４：要求を引き出す工夫

要求を引き出す工夫

  • 趣味を一緒にやって、時間を共有する
  • 情報を独自に集めて提案する
  • キワキワのところを質問する
  • 実際に形のあるものを見せると意見が出てくる
  • 要求よりも問題を明確にするように意識する

困った人対策

  • なるべくその人をたてながら、最後は仲間に居れる
  • 周りを巻き込んで動かざるを得ない状況にする

チーム形成のコミュニケーション

  • アニメの話
  • 朝会
  • 飲み会
  • お土産作戦
  • 趣味の話 ＞ 人を知る
  • 自分のキャラを立てる（メンバー）
  • 褒める（サスガっすｗ ← 大阪で大流行？）

受け身にならないようにやっていること

  • 〜でいいですか？より〜でいいですよね？という話し方
  • 興味がないことには興味を持っていくこと
  • クオリティ感覚を持つ
  • 定時になったら自分の時間として使う
  • 自分が会社を動かしていく視点を持つ
  • プロジェクトとビジネスの情報を公開する ＞ 視野が狭いと受け身になる

自分のまとめ

やっぱり困っているところは結構同じだよな〜って再認識した。
Whyをキチンと取っていくのが重要であるということ。
そしてチームメンバーには感謝の念で接することですね。
ビアバッシュもここに書けない楽しい話が沢山あって良かったです♪

アジャイル開発と結婚式のビデオ

会社の後輩であり、アジャイル札幌代表であり、尊敬している友人の1人でもある鈴木こと、あつーしから結婚式のプロフィールビデオを頼まれた。

AtsushiAzusaWeddingVideo from Noriyuki Nemoto on Vimeo.

短い作成期間の中で、心配を掛けないように、いいものができるように作っていったところ、最後になってこれってアジャイルのスタイルと似ているかもと思ったので記しておく。

聞き取り

どういう感じがいいのか、食事をしながら聞き取る。このとき新婦のアズとは初対面。お互いに人見知りじゃないので沢山話すことが出来た感じ。 本題のプロフィールビデオに入ったけど、アツーシとアズに明確なイメージはない。この時、iPadに入っていた自分が以前作成した再現形式のビデオを見せたところ、気に入ってくれたので今回も再現形式のビデオを作ることになった。

後は彼らの出会いから結婚に至るまでを事細かに聞いていく(笑
昼間からビールを飲みながら、幸せな二人との話はとっても楽しかったなぁ。

◇学んだこと

相手の想像をかきたてるものがあった方が話が早い。
昼のビールはやっぱり旨いっ！！

撮影

実際の撮影のときは、二人のキューピットである上司の協力も得ながら撮影した。ここで活躍したのは一緒に撮影に付き合ってくれたいづいづ。この人はめっちゃ絵がうまくて、自分がイメージしたTシャツを何も見ずにその場で作ってくれた。ビデオの中に出てくる「勝つ！！」って書いてあるTシャツはいづいづの手書き。凄いよなぁ〜ほんとに。

◇学んだこと

最速でものを作る場合は圧倒的なスキルが重要である

編集に使ったアプリ

さて、素材が出来たのでここから編集作業に入った。 今回の編集ソフトはMacのFINAL CUT PROをチョイス！触るのが始めてだったので先ずは簡単な動画を作成してみる。

◇学んだこと

知らない道具は先に使えるようにしておくことで、不安を取り除く
Macの動画編集ソフトはWindowsに比べて圧倒的に安い！！

気をつけた事１

自分が一番気をつけたのは相手が不安にならないこと、最後にドンデン返しがないようにすること、そしてやっぱり二人が喜んでくれるものを作ることだった。
今回のビデオは5パートで作成した。
　1 予告編
　2 あつーしの生い立ち
　3 あずの生い立ち
　4 二人の出会い(再現)
　5 二人の写真

2週間と短い期間だったので、基本は毎日メールとリリースをした。一つのパートが毎日出来ていくので、安心したんじゃないかと思う。その日にリリースできないときは予定をメールするようにして、無駄な不安を生じさせないようにした。
字幕などは最初につけずに、後でつけるからということにして全体をリリースしていった。

◇学んだこと

相手が不安にならないようにすることが重要と考えた。それには細かいリリースが一番。

気をつけた事２

ソフトウェアほどではないが、どうしても変更を行うと音と映像がずれたりと影響がでる。逆に言うと音や映像のズレなどに気をつけていれば、その他の不具合は気にしなくてもよいというのは楽だった。ただたまにFinalCutの特性か、ある特定の部分で変更がされないことがあったりしたが、それに関してはFinalCut自体を再起動することで直った。

毎日のリリースで気になった事

ここで気になったのは、要求元の二人からあまりリクエストが入らなかったこと。一応、会社の先輩後輩でもあるので、言いたいことが言えないんじゃないかと不安になる。最後の方にはリクエストあったので、このときに初めて満足してくれてたんだなと分かって一安心。

◇学んだこと

最初に良い関係を構築しておかないと、満足しているのか、遠慮しているのかわからないことがある。

最終リリースと当日の上映

１週間前になんとかリリースして、二人はとっても喜んでくれた。そして結婚式当日、自分は参加者としてみんなの声を直接聞く事ができた。ワイワイ賑やかだった会場が静まりかえり、みんながビデオを見てくれるのがとっても嬉しかったのを覚えている＾＾
評判も良くて３次会まで話題に困らなかった（笑

◇学んだこと

実際に見てくれた人の生の声聞けるってとっても嬉しいし、幸せだと思う。

感想

今回のビデオ作成はチーム開発という部分は少なかったものの、振り返ってみるとかなり自分のイメージしているアジャイル開発に近いと思った。
作りたいアイディアや想いも重要だけれども、作れる技術や道具というのはベースとして絶対に必要である、普段から意識してそのベース上げる努力が必要だと思う。
その上に相手を不安にさせない方法＋相手とイメージの共有に力を注ぐことで、手戻りを最小限に留め、磨き上げの時間を多く取る事ができるんじゃないかな〜と思った。
アジャイルな方法で実施しようと思ったわけじゃないけど、アジャイルについて勉強したり考えたりする機会が多いので、そういうのが少し出てきたんじゃないかな〜って思っている。

BPP(ベストポジションペーパー賞)

6/22、23とソフトウェアテスト好きが集まるWACATEという合宿形式のワークショップに参加してきた。今回で4回目なんだけど、いつも本当に楽しいんだよね！！参加するたびに、何か一つは悩みが解決する気がしてる。

今回はこの大好きなワークショップでベストポジションペーパー賞という素晴らしい賞をいただいちゃいました！！ ポジションペーパーというのは自己紹介＆参加表明のペーパーで、WACATE申し込みのときに一緒に提出するもの。 いつも参加者は合宿の間に全員分のポジションペーパーを読んで投票するんだけど、50名分だと読むのが結構大変なんだよね。 なので、見たときににホッとしてもらえるかな～と思って、今回は手書きの絵にしてみたのが良かったのかなと。

もしかしたらとは思ったけど、実際に頂くとめっちゃ嬉しい｡ﾟ(○ﾉω`o)ﾟ 嬉し過ぎて元々は白黒なんだけど、絵に色付けして公開してみた（笑

「やってみようぜ！」

f:id:nemorine:20130625000026p:plain

共生（ともいき）のデザイン読了

AgileJapanの基調講演で講演した枡野俊明さんの本。僧侶であり、庭園デザイナーでもある枡野さんの話が面白過ぎて、なんと講演中にAmazonから購入してみた。 世の中凄いね（笑

枡野さんは禅の教えを庭園のデザインに取り入れている。 平均プロジェクト期間が3年半というだけあって、短期の視点ではないモノ作りの姿勢が見える。

以下心に残ったところを書いておく。

「仮組み」こそ命

本当に大切なのは、場で感じる「感覚」。それをきちんと再現するために、石組みにしても数奇屋にしても、仮組みとは本来欠かせないプロセスなのです。

実際にやってみないと分からないっていうのは確かにそうだと思う。 なので素振り重要なんだね。

「こうしてやろう」と思わない

デザインは見せてはいけません。 その下で、その裏で、いかに緻密な計算があろうと、それを訪れる人に感じさせないようにするのが一番大事なのです。

Before/Afterの人に教えたい言葉（笑 ちょっとあれはやり過ぎな感じがする。

訪れる人のこころをデザインする

庭園をデザインするとき、大きく三つ、考えることがあります。それは、
「そこをどういう状況で使う（訪れる）のか」
「誰が使う（訪れる）のか」
「どういう心の状態でそこを使う人が訪れるのか」
の三つです。

以前「飲み会の割り勘アプリ」を考えたことがあったが、その場合にどういう心の状態、体の状態というのを意識した。ペルソナ＋心と体の状態みたいなイメージで考えた。 誰がというところまでは結構考えるのだが、そこからもう一歩となるとなかなか出来ないなぁと感じている。

「自我」よりも「仏性」を

禅が入ってくる前から「山川草木悉皆成仏」という言葉がありました。草も木も山も川も皆、心がある、これを仏教では「仏性」があると言うのです。

他の宗教を批判するつもりはないけど、日本のアミニズム～八百万の神という考えはとてもいいなぁと思ってる

「無常」をデザインする

日本は「とどまらないこと」が美しいのです。モノが変化していくことが美しい。つまり、この「無常」をデザインすることが、大切なのです。

なんか枡野さんの本でこれが一番響く。 無常をデザイン。たぶん昔から日本では行われていたことなんだろうなぁ。

「簡素」、素朴で単純な中の豊かさ

何事も足していくことはたやすいことですが、引いていくということは、大変勇気のいることです。これを行うには余程の経験と、それに基づく自信がなければ、容易にできません。

これは本当に難しいよね。 沢山足していった方が安心なんだろうなぁって思う。 100個機能つけたけど、これでミートしなかったら仕方ないわ、っていう感じかな。 すると言い訳のための機能ということなのだろうか・・・

排除しない

十人十色、さまざまなクセや違った志向があるからこそ、お互いに引き立てあえて、お互いが存在します。一人で存在しているわけではありません。

禅の梅の木の話

禅的な発想では、縁は風のように、全員に平等にくるものです。しかし、そこでその縁を受けて花を咲かせられるかは、日頃の精進次第ということになります。原因がなく、縁だけきても、原因がないから因縁が結べないままです。

準備重要！素振り重要！

世界に敏感になる

たとえばお店などに入って居心地が悪かったら、なぜこの空間は居心地が悪いのか、どうしたら良くなるのか、考えるようにといいます。 世界に敏感になって、頭の中でそれを自分で言語化するということをやり続けない限り、何かを伝えるための澄んだ心を保つことは、困難なのです。

判断は後に残さない

その場その場で全て解決し、後に積み残さない。 その判断はたとえ誤りであったとしても、「残さないようにする」ことのほうが、大事だと思います。

これは半分賛成半分反対かな。 条件が出揃う見込みあるなら待つこともあり。出揃う見込みないなら待つことなく判断をするのが良いと思う。実際は色々な局面で意味も無く判断を延ばしてしまうことが多々あるので、早く判断できるようにしないとと思った。

アジャイルジャパン仙台に参加して②

◇Keynote 2：「柔軟心 (にゅうなんしん) と庭園デザインにおけるユーザーエクスペリエンス」

枡野 俊明(ますの しゅんみょう) 氏

枡野さんが実際にデザインされている庭

枡野さんは住職でありながら、庭園デザイナーでもある。 自分の特技、好きなことを通して社会に貢献できないか？と考え、庭園デザインをやり始めた。 門外漢の自分が話すことでキッカケが生まれるかもしれないということで、お話をしてくれた。パワーポイントを一切使わない講演は久しぶりだった。


挨拶

最初は挨拶から。

声に出して自らの気持ちを表現することはいい。 自分が気持ちよくなるためには相手を気持ちよくさせる。
『禅とデザイン』
長いスパンでの仕事が多く、1つのプロジェクトは平均3年半。最長で8年。


日本人の美意識と世界の動き

日ごろ日本の美しさ、日本人が得意とする美意識。 それを如何に現代にあわせこむか。根底に流れている価値観、美意識は何百年も変わっていない。

近年は物の豊かさ、情報の速さ、量の多さが人を豊かにすると信じられているが、 必ずしもそうではないかもしれない。常に追われていく、執着心が生まれる＝それが現実でもある。 一方で、心の豊かさが重要視されてきている。これはワールドワイドな動き。

日本人が昔から持っていた全てのモノに霊性を認めるアミニズムはこれからの世界に必要なものなのかもしれない。


禅と哲学

人間の中には宇宙を持っている。それに出会うのが禅の目指すもの。 考え方は限りなく、哲学に近い。

論理を証明していくのが哲学。 禅は日々に適応していく。すなわち"行（ぎょう）"になる。 "行"を修めるので修行という。 取り組む姿勢が、皆さんの手助けになるはず。

禅ちょっと気になってきたー


枡野さんの仕事の仕方

クライアントの要求の中には言葉にならない奥に潜んでいる部分は必ずあるので、どうやってそれを引き出していくかを考える。

斜面があったとき、西洋は造成して平らにしてから作りこむ。 日本は斜面をどう生かすか？風、光、木の陰がどう変化するのか？。 そしてそれがどのように人に影響を及ぼすかを考える。

地心（じごころ）を限りなく聞き取る＋クライアントの要求の両方を聞くことが重要である。クライアントからの要求にこだわり過ぎない＝柔軟心。

庭園に配置する石、木も同じ。それらが最大限に引き出せる方法を自分の中の美意識、価値観に基づいて変更する。変化したときは３手、５手、７手先を読む。

作りながら、さらにいいものを作り上げていく。 計画ありきではなく、使う方に一番喜んでもらうもの。

これはまさにアジャイル開発宣言の『計画にしたがうよりも、変化への対応を』に近い考え方だと思う。 石や木を最大限に引き出せる方法というのはチーム作りの考えと同じだと感じた。 ここでテンション上がってしまって、枡野さんの著書「共生（ともいき）のデザイン」を注文してしまった。 共生のデザインには仮組みという概念が書かれていて、これがプロトタイプに近いものであると思った。


完全を越えた不完全の美

妥協をゆるす。 ユーザーの要望に十分応えられているかを確認すること。 機能は同じでも、老人が使うか、子供が使うかで求められるものが違う。

『簡素の美。これ以上そぎ落とせないのが良いデザイン。』

・ヨーロッパは完全な美
・日本は完全を越えた不完全の美

完全性に人間性が入り込む余地を残すのが世代を超えていくデザインであること。 アジャイル→フラジャイルとすることで、日本的なもの作りができるのではないかと。

常に移ろうものが世の中の真理である。

簡素の美のデザインについては佐藤可士和さんも同じことを言っていた。 自分はそれまでデザインは足し算だと思っていたので、びっくりした記憶がある。


自分の感想

アジャイル×お坊さんってどんな感じなのか想像もつかなかったセッションだったのだが、終わってみると心に刺さる良い話だった。特に初めて聞いたであろうアジャイルという単語から、フラジャイルへのつなげ方は素晴らしいなぁと思った。