AgileJapan仙台サテライト 参加レポート①
今年もやります。AgileJapan2014。 早速基調講演のレポートを書いてみましたー
予習用の水野さんのYouTube
『時を超える技術』 水野和敏氏 ―あなたと部下を最高の結果に導く極意とは?― - YouTube
ソフトウェア開発者に問う ~日本人のモノづくりの本質とは~
元日産GTR責任者:水野和敏(みずのかずとし)
企画・開発・設計・生産・販売・品質保証も 全てが一体になるのが日本の素晴らしさ。 切ってしまうから言葉でつなげるだけ仕事になる。 言葉を代理してくれるのが、メカニックであり、セールスマンである。
最初からガチンと来る。。。この人は間違いなく面白いという予感!
文化の違うところに、違う経営手法を用いるとおかしくなる。 価値観を共有できるのは実はすごいアドバンテージ。 日本語は感情を伝えるのにはとてもよい言語である。
どうしても仕様などを日本語で書くと厳密ではないと感じるけど、コミュニケーションの言語としては表現が豊かなんだろうなぁ。
レーシングチームに入ったとき、まずレースとはなんぞやをやった。 How to じゃなくて、What isだ! データ解析者を3人雇って、全てのデータを分析した。 データを見ながら、相手の監督の考えもシミュレーションする。 プロのドライバーへもデータを使い毎日フィードバック。 プロのドライバーのの凄さは1時間で0.2秒の誤差。これは瞬きとほぼ同じ時間。 実はBigDataはみんなをやる気にさせるマネジメントツール 裁量権と目標を与えるとみんなやる気になる。 未来の目標を如何に共有化するかがチームの最高の仕事。
感覚ではなく、データを見ながら目標に近づいていくというのはとてもいいこと。 ただデータだけでは動かないのでパッションとデータに基づいた目標が与えられたとき、 素晴らしい力を発揮するのだと思った。
Try&Errorと言うと聞こえがいいが、言っちゃうと壊れた&直した。 無駄なTry&Errorはしない。車はエラーすると人が死んじゃう。 人・物・金・時間が従来の半分でいい。この半分はエラーがないからできる。
かなり早い段階で意識を共有して、無駄なTryをしないっていうのは凄いなぁ。。。
普通の人がお金を使うことではなく、お金持ちがお金を使わなくなることを 不景気という。ディスカウントバリュー戦略はダメだっ。
確かに安売り戦略は全てが疲弊しちゃうよね。 最後の質問にもあったけど、HighClassとMiddleClassを狙っていくのがいいんだと思う。
GT-Rはよく見るとセダン。スナップショットがそのままカタログになる。 でもそれがいいところ。トランクがあるスーパーカー作ったっていいじゃない! タイヤがバーストしても、そのままディーラーに行けてもいいじゃない! それが日本人が作るスーパーカー、おもてなしの心。
やっぱり日本人は色々なものを取り込んで混ぜることに関しては圧倒的な才能があるんだと感じた。
技術の進歩で値段は上がりますか? iphoneは?冷蔵庫は?車は? 実は値段を下げるものじゃないですか!!
それは確かにそうかもしれない。機能をつけたら付加価値になると思うのはまやかしなのかもしれない。少なくとも数年のスパンで考えると付加価値は下がっていくと思う。
低いレベルに合わせた設計と作りをしたとき、本当にその商品は 進化しているのだろうか?誰かがOKと言ったとかで作ってないですか? 会社という枠でモノを見てるから、ニュートラルにモノを見れなくなる。 会社は実現の手段であって、目的ではない。 職業の選択:What/Why 会社の選択:How
確かに会社の居心地がいいと、自分で考えることをやめて、誰かのせいにして進んでしまうなぁ。。。色々な人から話を聞いてもが多い気がする。
夏スーパーカー乗っている人が冬SUV乗るのは幸せか? 冬も乗れるスーパーカーを作ればいいじゃない! 事実を知ったら発想が出てくる。
なるほど、モノがないときはそのコンセプトは馬鹿にされたかもしれないけど、 実はそこに真の需要があるかもしれない。。。
日本車に比べ、ドイツ車はリコールが少ない。 テストコースくらいじゃ、本当の状況を再現することはできない。 ドイツはマイスター制度があるので、モノを作ることに希望がある。
技術者が国家資格で優遇されるというのはとても良い制度だと思うなぁ。 日本でももっと能力を持った人が優遇されればモノつくりが良い方向に向かうと思う。
一番上にいるのは、現場!! 現場が造れないものを設計しても無理・無駄が起こる。 現場と設計を平行で進めていく。 現場のレベルが上がらないと設計のレベルが上がらない。
設計が言ったから、設計が言ったから・・・はダメ 水野さんのマネした言い方が面白すぎる(笑
未来は言葉ではなく画像。過去は言葉。 言葉と数字でディスカッションしても未来は生まれない。 新しいこと、未来は言葉からでない。
未来はストーリや画像で語れ!!というメッセージが熱かった!!
ってか尋常じゃなく面白かったなぁ。。。
水野さんありがとうございました。
【質問】
現場と共有するためには?
【回答】
会社からの肩書きが自分の能力だと錯覚する。
会社にもらった権限を忘れる。失敗をする可能性があるが、その失敗をリカバーするために自分は一体どうすればいいのかを真摯に考える。
【質問】 リーダーやチームで共有するべきコツ 【回答】 みんな趣味で仕事している。それは仕事ではない。 仕事は人のためのもの。キーワードは"人の喜び"、それをもって共有できる。 人のためにと思うと、共有できる。 まず初めにどんな人をどのように喜ばすかを考えなければいけない。
【質問】 水野さんの夢 【回答】 日本を象徴する最高級のフラグシップを作らないといけない。 最高級(HighClass)と廉価版(LowClass)の間のMiddleClassをどうするかが分からない。 そこをどうにかしていきたいと思っている。
【質問】 ソフトウェア技術者に一言 【回答】 どうせ人生は一度きりなので、会社に囚われずに社会に対してどうしているかを考えて欲しい。趣味や欲は捨てました。ダメで元々だと思いなさい。失敗したら社長が悪い(笑 失敗しちゃいけないと思えば思うほど、何もできなくなる。
テストカテゴリの出し方(機能編)をみきおさんから教えてもらった
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
テストカテゴリの出し方(機能編)を考えてみた
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 炎上プロジェクトの経験を前向きに学ぶ(村上さん)
炎上あるある
- 要件がコロコロ変わる
- メビウスレビュー
- 赤字覚悟の案件受注
できる人に仕事が集中して人がおかしくなってしまう。 できない人はおかしくならないw
炎上の原因
- コスト度外視で納期だけ
対策は?
- プロジェクトマネージメントの強化
- PMP
- ISO
でもダメだった。。。
結局、工数が増える/品質が劣る/管理作業も増える
自分たちの問題点を直視しないで、借りてきた解決策を導入するとこうなるよね。。。
やっと気づいた思考パータン
- 積み重ねの概念がない > 昨日と今日に連続性がない
- 悪いのは自分以外の何か > だから謝らないし、自信満々
- 対策は他から持ってきたものばかり > 自分では考えてない
話せば分かると思ってたけど、分かり合えない。。。
ただし、ジャイアン(=自身満々の人)の数は少ない
真の対策は?
- 仲間を増やす
- コネクションを使って、情報を通していく
- 情報は聞かれたものだけ報告していく
- そしてジャイアンを無力化する
- 上手く行ったらチームみんなに感謝をする
以前、村上さんとお話したときの情報を少し… 「情報はプロジェクトの血と同じ。滞っていると死んでしまう。 そのために、キーマンを飲みに誘い情報を引き出す。 そして、小さくてもいいのでやってみる。 楽しそうにやっていると人が集まってくる。そうやって仲間を増やしていく。」
DevKan 受託だからと言って受け身である必要はない(大友さん)
スライド
下請けから見て誰がお客さんか?
- 元請けのA社が満足する必要がある
- 誰が何のために必要なのか
→これは本当にドメインを知ってる人じゃないと答えられない
受け身じゃないポイント① 本当の要求を持っているユーザーまで自ら辿り着く
「念のため」という言葉を上手く使い確認を行う
受け身じゃないポイント② ユーザーが予算獲得などで作成したコンセプト資料を必ず手に入れる
コンセプト資料を手に入れたら要求仕様書を作成する。
受け身じゃないポイント③ たとえ不要と言われても、要求には「なぜなら〜」を書く
なぜなら〜、〜だからだを書くことでチームの意識が揃ってくる。
これがないと、メンバー同士が憶測で喧嘩を始めることもある。
派生開発でいう理由に当たるところだと思う。 レビュー時も要求だけよりも「なぜ」という理由が書いてあった方が納得しやすい。
受け身じゃないポイント④ チームが形成される仕組みを積極的に組み入れる
いっぱい話せる仕組みを取り入れる。朝ミ、夕ミ、ランチミーティング、飲み会など。
受け身じゃないポイント⑤ 良いプロダクトを作る機会では社外もチームととらえ積極的に会話する
普段からどうでもいいことを話してないのに、大事なときだけ話せるわけがない。
お金と瑕疵以外で話して、チームとしての一体感を持つ。
要注意
会話の量は仕組みで増やすことができるが、 会話の質は個人に依存するので、要注意。
最後の会話の質は個人に依存するっていうのは本当に分かる。 お互いに尊敬の念がないとダメになることが多い。 ただどうやって尊敬の念を作っていくかは… まだ答えがない。 半谷さんの発表のように、激論をすることでお互いを強敵(とも)と 呼べるようになればいいのかな…
DevSen 「泥臭くない」受託開発なんてない。あるいはTDD/DDDのすすめ(井上さん)
泥臭い受託開発とは?
受託開発で顧客が求めているシステムは全て異なる!
Why / What / Howを常に探求し続ける必要がある。
レベルの違いはあるかも知れないけど、全ての現場が泥臭いことをしているはず。
SIer時代で楽しかったこと
かなり早い時代からのXP。 顧客にとっていいものを作れたことが楽しかった。
2001年からテストファーストをやっていたとは… 時代がやっと井上さんに追いつきましたね(笑
悩み
- ほとんど中間管理職
- システムのWhyとWhatに注意を払う人が居なかった
- 決定したことをそのままやることが重要
- 技術力が評価されない
- 周りを変えるのは難しい
- 誰のための仕事か分からない。
- ドキュメントとコードが一致しない。
- チーム全体に覇気がない
TDD/DDD
自分が良いと思っているTDDでプログラミングしたプロジェクトはバグ0。
1サイクル目は捨てる前提!!
1サイクル目は捨てるっていうのがグッと来た。 そもそもソフトウェアに試作とかという工程がないのがおかしい。 DDD勉強会in仙台参加しなきゃ!
DevKan 「私がモテないのはどう考えても受託開発が悪い!」なんてことはない(横田さん)
よこたまさた @mesodash
最近はSonicGardenやGildWorksのビジネスモデルのように情熱系受託開発が多い
受託開発あるあるチェック
- 要件定義が長引き開発の費用や時間が大幅に減った
- 作ったものが期待するレスポンスで動かない(作り直し)
- 外注したら絶望的な品質の何かが届いた(作り直し)
- そういえば今日はメールとExcelのみ
- お客さんからモーニングコールがかかってきた
終わらない開発
- なぜやそもそもを十分に把握せずに対処してしまった。
- チームのスキルを無視した技術の採用
- 個人の力技で解決
受託から自社製品へ
- 仕様を自分たちで決められる
- 自分たちが考えた機能をお客さんにイイネしてもらえる
でも売れなかった…
中途半端な状態で逃げられなどしない。
どうすればプロジェクトが上手くいくか
- プロジェクトは未知の領域
- 技術は前提
やるべきことはしっかりやらないといけない
- 見積もりはしっかり
- 真の要求をとる
チームが上手く機能すれば、プロジェクトは劇的に良くなると実感する。
上手く機能させるためには仕組み作りも必要である。
受託開発のいいところ
- 色んな技術を取得できるチャンスがある
- お客さんと直に接することが出来る
- お客さんの望んでいるものに対して、自分たちの最高を届ける
横田さんはどれくらいモテないのか、気になって仕方なかった…
まとめ
- 経営上の課題を解決する
- お客さんとしっかり向き合って、信頼関係を作る
- 現場が正しいと思うことを出来るような組織にする
開発者の良い面を引き出すのが、良いマネージメントなのかもしれない…
サービス企業も結構色々あるんですよ(半谷さん)
日々の仕事
Hadooop Cluster(2PB)使って、本社からの仕事を仙台、大阪で受けている。
今の問題
- ビジネス側と開発側に隔たりがある
- 東京と地方との隔たり
地方で成果を出すべく、ガシガシ頑張った結果、東京から見直された。
転機は東京チームと激論を交わしたこと。そして飲みにいくようになった。お互いに理解が深まって態度が軟化して来た。
心の友よ!状態になった!!(向こうが本当に思っているかどうかは分からないw)
楽しくやることが重要。あと酒。酒があれば大抵大丈夫。
楽しくやることって重要だよね。自分もそれを一番に心がけている。 同じことをやるにしても楽しくやってるかやっていないかで伸びに雲泥の差がある。
ダイアログ
自分が入ったのはチーム4:要求を引き出す工夫
要求を引き出す工夫
- 趣味を一緒にやって、時間を共有する
- 情報を独自に集めて提案する
- キワキワのところを質問する
- 実際に形のあるものを見せると意見が出てくる
- 要求よりも問題を明確にするように意識する
困った人対策
- なるべくその人をたてながら、最後は仲間に居れる
- 周りを巻き込んで動かざるを得ない状況にする
チーム形成のコミュニケーション
- アニメの話
- 朝会
- 飲み会
- お土産作戦
- 趣味の話 > 人を知る
- 自分のキャラを立てる(メンバー)
- 褒める(サスガっすw ← 大阪で大流行?)
受け身にならないようにやっていること
- 〜でいいですか?より〜でいいですよね?という話し方
- 興味がないことには興味を持っていくこと
- クオリティ感覚を持つ
- 定時になったら自分の時間として使う
- 自分が会社を動かしていく視点を持つ
- プロジェクトとビジネスの情報を公開する > 視野が狭いと受け身になる
自分のまとめ
やっぱり困っているところは結構同じだよな〜って再認識した。
Whyをキチンと取っていくのが重要であるということ。
そしてチームメンバーには感謝の念で接することですね。
ビアバッシュもここに書けない楽しい話が沢山あって良かったです♪
アジャイル開発と結婚式のビデオ
会社の後輩であり、アジャイル札幌代表であり、尊敬している友人の1人でもある鈴木こと、あつーしから結婚式のプロフィールビデオを頼まれた。
AtsushiAzusaWeddingVideo from Noriyuki Nemoto on Vimeo.
短い作成期間の中で、心配を掛けないように、いいものができるように作っていったところ、最後になってこれってアジャイルのスタイルと似ているかもと思ったので記しておく。
聞き取り
どういう感じがいいのか、食事をしながら聞き取る。このとき新婦のアズとは初対面。お互いに人見知りじゃないので沢山話すことが出来た感じ。
本題のプロフィールビデオに入ったけど、アツーシとアズに明確なイメージはない。この時、iPadに入っていた自分が以前作成した再現形式のビデオを見せたところ、気に入ってくれたので今回も再現形式のビデオを作ることになった。
後は彼らの出会いから結婚に至るまでを事細かに聞いていく(笑
昼間からビールを飲みながら、幸せな二人との話はとっても楽しかったなぁ。
◇学んだこと
相手の想像をかきたてるものがあった方が話が早い。
昼のビールはやっぱり旨いっ!!
撮影
実際の撮影のときは、二人のキューピットである上司の協力も得ながら撮影した。ここで活躍したのは一緒に撮影に付き合ってくれたいづいづ。この人はめっちゃ絵がうまくて、自分がイメージしたTシャツを何も見ずにその場で作ってくれた。ビデオの中に出てくる「勝つ!!」って書いてあるTシャツはいづいづの手書き。凄いよなぁ〜ほんとに。
◇学んだこと
最速でものを作る場合は圧倒的なスキルが重要である
編集に使ったアプリ
さて、素材が出来たのでここから編集作業に入った。
今回の編集ソフトはMacのFINAL CUT PROをチョイス!触るのが始めてだったので先ずは簡単な動画を作成してみる。
◇学んだこと
知らない道具は先に使えるようにしておくことで、不安を取り除く
Macの動画編集ソフトはWindowsに比べて圧倒的に安い!!
気をつけた事1
自分が一番気をつけたのは相手が不安にならないこと、最後にドンデン返しがないようにすること、そしてやっぱり二人が喜んでくれるものを作ることだった。
今回のビデオは5パートで作成した。
1 予告編
2 あつーしの生い立ち
3 あずの生い立ち
4 二人の出会い(再現)
5 二人の写真
2週間と短い期間だったので、基本は毎日メールとリリースをした。一つのパートが毎日出来ていくので、安心したんじゃないかと思う。その日にリリースできないときは予定をメールするようにして、無駄な不安を生じさせないようにした。
字幕などは最初につけずに、後でつけるからということにして全体をリリースしていった。
◇学んだこと
相手が不安にならないようにすることが重要と考えた。それには細かいリリースが一番。
気をつけた事2
ソフトウェアほどではないが、どうしても変更を行うと音と映像がずれたりと影響がでる。逆に言うと音や映像のズレなどに気をつけていれば、その他の不具合は気にしなくてもよいというのは楽だった。ただたまにFinalCutの特性か、ある特定の部分で変更がされないことがあったりしたが、それに関してはFinalCut自体を再起動することで直った。
毎日のリリースで気になった事
ここで気になったのは、要求元の二人からあまりリクエストが入らなかったこと。一応、会社の先輩後輩でもあるので、言いたいことが言えないんじゃないかと不安になる。最後の方にはリクエストあったので、このときに初めて満足してくれてたんだなと分かって一安心。
◇学んだこと
最初に良い関係を構築しておかないと、満足しているのか、遠慮しているのかわからないことがある。
最終リリースと当日の上映
1週間前になんとかリリースして、二人はとっても喜んでくれた。そして結婚式当日、自分は参加者としてみんなの声を直接聞く事ができた。ワイワイ賑やかだった会場が静まりかえり、みんながビデオを見てくれるのがとっても嬉しかったのを覚えている^^
評判も良くて3次会まで話題に困らなかった(笑
◇学んだこと
実際に見てくれた人の生の声聞けるってとっても嬉しいし、幸せだと思う。
感想
今回のビデオ作成はチーム開発という部分は少なかったものの、振り返ってみるとかなり自分のイメージしているアジャイル開発に近いと思った。
作りたいアイディアや想いも重要だけれども、作れる技術や道具というのはベースとして絶対に必要である、普段から意識してそのベース上げる努力が必要だと思う。
その上に相手を不安にさせない方法+相手とイメージの共有に力を注ぐことで、手戻りを最小限に留め、磨き上げの時間を多く取る事ができるんじゃないかな〜と思った。
アジャイルな方法で実施しようと思ったわけじゃないけど、アジャイルについて勉強したり考えたりする機会が多いので、そういうのが少し出てきたんじゃないかな〜って思っている。
BPP(ベストポジションペーパー賞)
6/22、23とソフトウェアテスト好きが集まるWACATEという合宿形式のワークショップに参加してきた。今回で4回目なんだけど、いつも本当に楽しいんだよね!!参加するたびに、何か一つは悩みが解決する気がしてる。
今回はこの大好きなワークショップでベストポジションペーパー賞という素晴らしい賞をいただいちゃいました!! ポジションペーパーというのは自己紹介&参加表明のペーパーで、WACATE申し込みのときに一緒に提出するもの。 いつも参加者は合宿の間に全員分のポジションペーパーを読んで投票するんだけど、50名分だと読むのが結構大変なんだよね。 なので、見たときににホッとしてもらえるかな~と思って、今回は手書きの絵にしてみたのが良かったのかなと。
もしかしたらとは思ったけど、実際に頂くとめっちゃ嬉しい。゚(○ノω`o)゚ 嬉し過ぎて元々は白黒なんだけど、絵に色付けして公開してみた(笑
「やってみようぜ!」
共生(ともいき)のデザイン読了
AgileJapanの基調講演で講演した枡野俊明さんの本。僧侶であり、庭園デザイナーでもある枡野さんの話が面白過ぎて、なんと講演中にAmazonから購入してみた。 世の中凄いね(笑
枡野さんは禅の教えを庭園のデザインに取り入れている。 平均プロジェクト期間が3年半というだけあって、短期の視点ではないモノ作りの姿勢が見える。
以下心に残ったところを書いておく。
「仮組み」こそ命
本当に大切なのは、場で感じる「感覚」。それをきちんと再現するために、石組みにしても数奇屋にしても、仮組みとは本来欠かせないプロセスなのです。
実際にやってみないと分からないっていうのは確かにそうだと思う。 なので素振り重要なんだね。
「こうしてやろう」と思わない
デザインは見せてはいけません。 その下で、その裏で、いかに緻密な計算があろうと、それを訪れる人に感じさせないようにするのが一番大事なのです。
Before/Afterの人に教えたい言葉(笑 ちょっとあれはやり過ぎな感じがする。
訪れる人のこころをデザインする
庭園をデザインするとき、大きく三つ、考えることがあります。それは、
「そこをどういう状況で使う(訪れる)のか」
「誰が使う(訪れる)のか」
「どういう心の状態でそこを使う人が訪れるのか」
の三つです。
以前「飲み会の割り勘アプリ」を考えたことがあったが、その場合にどういう心の状態、体の状態というのを意識した。ペルソナ+心と体の状態みたいなイメージで考えた。 誰がというところまでは結構考えるのだが、そこからもう一歩となるとなかなか出来ないなぁと感じている。
「自我」よりも「仏性」を
禅が入ってくる前から「山川草木悉皆成仏」という言葉がありました。草も木も山も川も皆、心がある、これを仏教では「仏性」があると言うのです。
他の宗教を批判するつもりはないけど、日本のアミニズム~八百万の神という考えはとてもいいなぁと思ってる
「無常」をデザインする
日本は「とどまらないこと」が美しいのです。モノが変化していくことが美しい。つまり、この「無常」をデザインすることが、大切なのです。
なんか枡野さんの本でこれが一番響く。 無常をデザイン。たぶん昔から日本では行われていたことなんだろうなぁ。
「簡素」、素朴で単純な中の豊かさ
何事も足していくことはたやすいことですが、引いていくということは、大変勇気のいることです。これを行うには余程の経験と、それに基づく自信がなければ、容易にできません。
これは本当に難しいよね。 沢山足していった方が安心なんだろうなぁって思う。 100個機能つけたけど、これでミートしなかったら仕方ないわ、っていう感じかな。 すると言い訳のための機能ということなのだろうか・・・
排除しない
十人十色、さまざまなクセや違った志向があるからこそ、お互いに引き立てあえて、お互いが存在します。一人で存在しているわけではありません。
禅の梅の木の話
禅的な発想では、縁は風のように、全員に平等にくるものです。しかし、そこでその縁を受けて花を咲かせられるかは、日頃の精進次第ということになります。原因がなく、縁だけきても、原因がないから因縁が結べないままです。
準備重要!素振り重要!
世界に敏感になる
たとえばお店などに入って居心地が悪かったら、なぜこの空間は居心地が悪いのか、どうしたら良くなるのか、考えるようにといいます。 世界に敏感になって、頭の中でそれを自分で言語化するということをやり続けない限り、何かを伝えるための澄んだ心を保つことは、困難なのです。
判断は後に残さない
その場その場で全て解決し、後に積み残さない。 その判断はたとえ誤りであったとしても、「残さないようにする」ことのほうが、大事だと思います。
これは半分賛成半分反対かな。 条件が出揃う見込みあるなら待つこともあり。出揃う見込みないなら待つことなく判断をするのが良いと思う。実際は色々な局面で意味も無く判断を延ばしてしまうことが多々あるので、早く判断できるようにしないとと思った。