twitterは時間的意味的な切れ目が無いブログ。
twitterは時間的意味的な切れ目が無いブログ。
tweetはブログよりはるかに小さい粒度なので、そこに含まれる意味はブログエントリより少ない。だが、全体として見たときにはtweetの積み重ねの方が生々しい個が見える。変遷というプロセスが含まれるからだと思う。
ブログでは欠落しやすい細かい感情の変遷がつぶやきとして記録されている。
熊猫の巣。
センゲの会で得たもの。
センゲの会で得たもの。
確かにふりかえりのP→Tが部分最適になるような気は私もしていた。ただ、K→Tは @kkd しか発想できない。その発想無かった。
『出現する未来』を読んで、これが自分がしたかったことか、これが自分やってきたことか、と気づいた。
学習する組織を存分に話したり聞けたりしたので、とても心地良い時間だった。
このテーマで人が集まれる、世界ってスゴイ。
世界は滅びる。それを救うのはUCDだ。 ～AgileUXの会に参加して～
AgileUXの会で得たもの。
ユーザエクスペリエンス、世界広すぎ。利用者が使い初めてから使い終わるまでの全て。気軽にUXなんか言えない。
ユーザエクスペリエンスを無視し続けたとき、いつか世界は滅びる。
高齢社会におけるユーザビリティの考慮欠如の負担はほかの世代が背負うことになる。経済的損失を含め、世界は立ち行かなくなる。
世界は滅びる。それを救うのはUCDだ。
ビジネスとITの連続性と、ユーザが手に入れる経験価値
2年先、3年先といった、システムの稼動を遠い将来においていた頃は、ビジネスとITは非連続の関係にあったのではないか。しかし、ITという手段が、ビジネスの継続・発展の上で重視されはじめると、システムのカットオーバーは、1年先、半年先と、短期間化するようになった。これは、ビジネスとITの関係が連続的なものになってきたと捉えることができる。ITの利用が、ビジネスの側に新しい付加価値を設ける、あるいは、逆にビジネスの側から、新しいサービスを始めるための実現手段として、ITへの要求が高まる。このやり取りに要する時間は短くなっていく、いや、短くなることが要求されていく。
ビジネスとITが非連続な関係にあった頃は、ソフトウェア開発そのものに対する関心は低く、ソフトウェアは期日どおりに用意され、モノとして用に足りれば良かった。ソフトウェア開発は外部に発注され、SIerはモノを作ることだけ考えていれば良かった。ユーザが出す要求に対してソフトウェア仕様を早期に固定化する。計画固定型の開発で変更は盛り込まない（非連続のため、そもそも要求が安定している）。
ところが、ビジネスとITの関係に連続性が求められるようになると、開発側はこの変化に対応できず、ソフトウェアの開発プロジェクトは苦境に陥りはじめる。一方、ユーザが連続性を追求して行けば、ソフトウェア開発は内製化へ進んでいくようになる。
SIerは、連続性の時代で、何ができるのだろうか。ビジネスボリュームを担保できる、保守開発という権益を手放すときを迎えたのかもしれない。むしろ、ユーザの内製化を支援する立ち位置を取り、Sierの新たな価値を提供するべきではないか。内製化が進んだとしても、高度・複雑化するシステム構築の世界で、開発ベンダが不要になることはない。ソフトウェア開発という行為そのものを顧客と共有し、内製のための教育をサービスとして提供する。顧客はソフトウェア開発という行為の中で”学習”という経験価値を手に入れることができる。これを実現する手段として、アジャイルな開発がある。
ヒトの受容力の限界
他人とコンテキストを共有するとき、ロジックが完璧でも通じない場合がある。尺としてどうしても必要な時間があると感じる。理屈を越えて。
ロジカルには解決できないものがある。
これは人間の受容力に制約があるということだろうか。
私は、お互いのメンタルモデルを理解する時間が必要なんだと理解している。一方的に、ではなくて。お互いに、必要。
一方だけが相手のものの見方を理解したとして、コンテキストの共有はやはり上手くいかない。
30代は、むしろこれからが始まりですよ。
http://mixi.jp/view_diary.pl?id=1248987843&owner_id=121272
30、31も30代なわけですで、私の世代からの感想。 新卒をバブル不況下で粘り強く過ごした世代が、30とか31とかになって ぼつぼつと会社の中で、発言できる立場になりつつあります。 会社のアングラではない部分でも、自分の考えを述べ、それが聞き入れられる 状況になってきた感があります。 というわけで、30代は、むしろこれからが始まりですよ。
5人がちょうど良い理由
8.1のワークショップで、棚橋さんが面白いことを言っていた。
小集団で活動をする場合、7人8人は多いが、4人だと少なすぎる。5人6人がちょうど良い。
7人8人だと意見がまとまらず、先に進めにくい。
しかし、少なければよいというものでもなく、4人だと、コンフリクトの発生が抑えられ、アイデアが育たないという。さまざまな考えを持っている人々が、対象をたたくことによって、それは洗練されていく。
よって、適度なコンフリクトがおきる、5人6人がよいそうだ。
類似するデザイン製作とソフトウェア開発
デザイン製作会社の方に、その仕事の内容を聞いた。ユーザヒアリングに基づいて、ラフなデザインを起こす。この過程で、やはりKJ法によるユーザの分析やペルソナの作成を行うそうだ。サイトのイメージをあわせたのち、見積りを行う。見積りは確定料金。その後、HTMLのWebサイトを作成し、ユーザに収める。ユーザテストとして、ユーザに実際に画面を使ってもらう。そのフィードバックに基づき、手直しを行う。このユーザとのやり取りが増えれば増えるほど、デザイン製作会社側はコストを持ち出す必要がある。よって、契約上、このやりとりを何回まで、という縛りを入れる場合もあるようだ。
この仕事の進め方は、まさにソフトウェア開発と同じである。デザインとソフトウェア開発。作るターゲットは異なるが、今のところ、見積りや契約の考え方も含めて、仕事の進め方は同じとみてよいだろう。
同時に、それはお互いの世界において、どこまで変化を受け入れられるか、という同じ課題を抱えていることになる。
ユーザはユーザビリティに対価を払うか
SIにおいて、ユーザビリティの分析に対して、ユーザは対価を払ってくれるだろうか。その可能性はいまのところ低いと。ユーザビリティの検討のために、ペルソナを作るにして、ペルソナを作れば、必ず、ドンピシャなユーザビリティが手に入るという保証はない。ペルソナはユーザからみれば架空の存在である。その架空の存在に基づき作るユーザビリティが正しいといえるのか。そういった、ユーザが持つ疑念に対して、われわれが説明し、納得を得ることができなければ、ユーザは対価を払うことはないだろう。
われわれは、ユーザビリティの検討のためのプロセス、ロジックを周到に準備しておく必要がある。迅速な作業の提供。方法は、実際に検証しておく必要がある。
そうでなければ、いつまでも、ユーザビリティは置き去りとなり、結果としてユーザの満足を高めることはできないだろう。
8.1ワークショップでやったこと
8.1デザイン思考のワークショップを開催した。私は一応、主催者の1人で、場所を提供した。いろいろと課題のある会場となったわけだけれども（もう、自社でイベントを開催したくない。いろいろと制約が面倒すぎる）。
最初にワークモデルを作る。これが難しい。今まで書いたことが無いため、どういう基準で書けばよいか分からない。棚橋さんがその後のブログで書いているが、とにかく手を動かして、作りながら直しながら進めばよかったのだ、と。その進め方については、確かにそう思う。ただ、それと同時に、進め方についてはチームで合意を取っておく必要があると感じた。つまり、「我々はこれから、試行錯誤しながらこのワークモデルを作る」ということをだ。コンテキストが共通でない、初めての人同士が集まって出来たチームでは、この合意形成が最初に必要。これが無いために、フラストレーションを貯めながら、様子を見るという状況が続いた。
ワークモデルの次は、KJ法。
これが、想像以上に困難な作業だった。”似たもの同士を集める”という作業が、また、基準があるようで無く、なかなか手が動かない。グルーピング化は時間がかかり、参加者はかなり消耗した。
KJ法で、ユーザの行動や考えを整理し、ペルソナを作る。ペルソナ作りは、参加者によって、内容を膨らませるステップなので、意見さえ出れば、前に進められる。このあたりから、チームの作業は少しずつ、うまく動き出した。
最後に、ペルソナに基づきシナリオを作る。ここでサイトを利用するユーザの行動（プロセス）、ユーザ要求、機能を検討する。この作業が、私はもっとも気持ちよく進められた。
その後、参加者が一様に感想として残していることだが、デザインのワークは想像以上に体力と頭を消耗する。時間もかかった。
地豆の男
id:daisuke_mと1年ぶりに飲んだ。id:imai78といい、何か、そういうタイミングなんだろうと思う。
お金で買えない”豊かさ”を手に入れられるのが、OSSの開発だと、彼は言う。それは、DevLOVEのコンセプトと通じるところがあると感じてる。つまり、”開発は楽しい”ということと。彼は、地豆の開発をライフワークとしている。いきいきと自分のOSSのことを語る。
面白いことを言っていた。エンジニアという職種は奇妙だという。
例えば、薬剤師は、どれだけ調剤が好きだとしても、自宅で薬の配合をすることは困難である。薬代や調合器具をそろえるのに、コストがかかりすぎる。しかし、エンジニアは違う。OSでさえフリーで手に入る。自分の努力次第で、いくらでもスキルを伸ばすことができる。趣味でやっていることが実業でやっていることを凌駕する可能性のある世界。そんな世界は、ITだけだという。
彼らしい、面白い視点だと思う。
僕らは、自分たちの恵まれた環境を生かしきれていないのかもしれない。
願う、未来は、自分たちの中に既にある。
お客様や、チームメンバーと対話して気づいたこと。
それは、お互い、より良い結果を生みたいと思っていること。そのために、本当に良いやりかたがあるなら、それを選択したいと思っているということ。そう思うのはもちろん当然なのだが、往々にして、自分たちは限定的な選択肢から手段を選んでいる。今までどおりのやりかたで失敗を繰り返す。身を守るために、従来の手段を取っているが、それは身を守っていることにはなっていない。しかし、他の手段を選ぶことはできない。さまざまな理由から。それは本当だろうか？
牽制しあう世界から、一歩出ることができたとき、今までに無い未来が出現する。
自分たちが望む未来。
お客様、開発側、それぞれが望む未来。
願う、未来は、自分たちの中に既にある。
それを見いだし、言葉にし、カタチにする。
それによって、お互いが未来について語ることができる。自分たちの未来を作るのは、自分たち自身だ。
何かを成し遂げるための原動力は、熱（苦し）さ。
仕事のチームのふりかえりを行う。
ふりかえりの後に、次の仕事のために、お互いの価値観や目標を確認したいと思っていた。
これをするには、モードを変える必要がある。場所でモードを変えることができることを知っている。今回は、オフィスの会議室ではなくて、井の頭公園をふりかえりの場所にした。井の頭公園の木陰にあるカフェで、話す。半日、話をした。
個々人が大切にしていることや、目標について、話す。私は、ひとつひとつメモを取っていたが、出来上がったものを見て、少し驚いた。これが、もう、すでにチームの目標や価値観になると思ったから。
つまり、共感できるものがそこにある。
わくわくすような世界を楽しそうに語る、チームの仲間を見て、熱い気持ちがわきおこった。
何年もソフトウェア開発を繰り返しやってきて、それでいて、断言できる。我々の開発は、もっと楽しくなる。
手段としての”ポジションパワー”は必要だが、それはあくまで、道具。何かを成し遂げるための原動力は、熱い感情だと、私は信じている。
DevLOVE CI勉強会の所感
7/29 DevLOVE CI勉強会「たとえ世界が終わろうとも、僕はビルドをケイゾクする」を開催した。
・さぼてんさんと、浅草橋さんの話。受付でうろうろしていたため（おそらく落ち着いてなかった）、さぼてんさんの話をあまり聞くことができなかった。あとで動画を確認することにする。
・浅草橋さんの話を聞いたのは久しぶりだったが、いつ聞いても面白い。明らかに”目的”より”手段”を楽しんでいる。浅草橋さんこそ、開発の楽しさを行為によって表現している人だと思う。
・kiyotakaさんが大阪から来たと聞いて、衝撃を受けた。DevLOVE関西ではお力を借りたい。
・imaiさんと1年ぶりにあった。かなり、印象が変わったように思う。今後はもう少し会いたい。
・t_wadaさんや、t_yanoさんに来ていただいたことは、運営として、これ以上嬉しいことはない。
・テスト祭りで話していただいた、goyokiさんや、川西さん。久々にきていただいた方々。初めてきていただいた方々（今回多かった）。感謝の言葉しか出ない。
・CIに対する私の意見。安定した世界があるからこそ、変えられる。安定した世界は、CIで維持する。
チームの世界に持ち込みたいもの（価値観型、目標型の議論もその１つ）
7/28 アジャイルチームWGのキックオフを開催した。キックオフというよりは、顔合わせの位置づけ。メンバーがもう少し集まる日を、次は設定したい。 “価値観型”、”目標型”の話は興味深かった。bash0C7は、私にとって、刺激を与えてくれる大切な存在だと、感じている。 価値観型とは、”理由”を重視するタイプだという。目標型は、”到達点”を重視する。価値観型は、よりプロセスを、目標型は、より成果を、それぞれ重視すると言っても良いだろう。 このどちらか一方が良いとか、そういう話ではない。両方の要素が必要で、この間でバランスを取るべきなのだ。価値観が共感されずに、設定された目標は、腹に落ちない。これは、会社の経営理念と、現場の目標設定の間の関係に言える。 今回は、チームというよりは、より大きな単位、組織についての対話が多かったが、それで良い。 私が今回、チームWGに持ち込みたい議論は、”アジャイル”だけではなく、”学習する組織”。これまで組織の中で行ってきた、変革（といえば大げさ）の動きは、チームの世界でも相通じるものだと感じている。 チームと組織、それぞれの世界で行うこと、起きることを、うまく適用していきたい。
