[Ruby] SimpleConsole の View を外部ファイルで管理して puts-less に。

by tanabe on March 31, 2007

SimpleConsole で View にいちいち puts とか print とか書くのがめんどい。余計な出力は見せないのが Unix way なのだろうけど、それにしても help とか書くときに puts が並んだのを見るとうんざりする。(ちなみにヒアドキュメントはあまり好かない。)

てことで、Rails の ActionView みたいに外部ファイルのテンプレート読み込んでやればいいんじゃない?とありがちな結論に持ってってみた。

下記のようなオフィシャルサイトのサンプルコードが、

class Controller < SimpleConsole::Controller
  params :string => {:n => :name}

  def whoami
    @name = params[:name]
  end

  # ...
end

class View < SimpleConsole::View
  def whoami
    puts "Hello, your name is " + @name
  end
end

こうなる。当然コントローラでセットしたインスタンス変数の値はテンプレートから参照可能。

class Controller < SimpleConsole::Controller
  params :string => {:n => :name}

  def whoami
    @name = params[:name]
  end

  # ...
end

require 'view_template'

class View < SimpleConsole::View
  def_view_template :whoami
end

# .. inside whoami.rview
Hello, your name is <%= @name %>

ViewTemplate Module はこんなかんじ。テンプレートファイルはとりあえず実行するファイルと同じところに置いておけば動くようになってるけど、今いちなかんじ。どんな構成にするのがいいかなぁ。あんまり大層な構成にしても SimpleConsole らしくないし。

require 'erb'
require 'simpleconsole'

module ViewTemplate
  include ERB::DefMethod
  TEMPLATE_FILE_EXTENSION = '.rview'
  TEMPLATE_METHOD_NAME_PREFIX = 'erb_'

  def def_view_template(*method_names)
    method_names.each {|name| define_view_method(name) }
  end

  def define_view_method(method_name)
    template_file_name = method_name.to_s + TEMPLATE_FILE_EXTENSION
    template_caller = TEMPLATE_METHOD_NAME_PREFIX + method_name.to_s

    module_eval %Q-
      def_erb_method("#{template_caller}", "#{template_file_name}")

      def #{method_name}
        puts #{template_caller}
      end
    -
  end
  private :define_view_method
end

SimpleConsole::View.extend ViewTemplate

SimpleConsole の以前の紹介記事はこちら

  

お客さんのホントの気持ちに迫るための一言。

by tanabe on March 30, 2007

たいていの人は自分のやり方というのを持っている。そして、大人にもなると少なからず自分が知らないことがあるというのを認めたくない。だから、システム開発をしているとこんなことがよくある。

「これこれこういう機能のものを作ってくださいよ。」
「その機能ってどんな機能なんですか?」
「うん。それはね、こんな風に動いて、あとはあんな風に動いてくれれば大丈夫です。」

そして、もし言われるがまま作ったものを見せると、きっとこういう答えが返ってくる。

「ちょっとイメージと違うなぁ。これだと○○なとき、困るんですよぉ。」

ちょっと待て。「よぉ」なんて言われてもこっちも困る。

というわけで、要件聞きに言ったのに機能の詳細に突っ込んで話しをして下さる人へはやんわりとこの言葉を使うことにしている。

「そうですよね。今その機能がなくて困っているのはたとえばどんなことなんですか?」

「このシステムを作る目的を教えてください。」というのは教科書的には正しい質問なのだろうけど、実際それだけ言っても通じないことが多い。たぶん「目的」という言葉が指す範囲が広すぎて、意図が伝わりにくいのだと思う。

そんなときも「自分が困っている問題」については皆はっきりわかっているので、そこについて質問すると知りたい内容が明確に教えてもらえる。

同じ内容を聞くのに聞き方はいくつもあると思うけど、いろいろ試してみた結果、今のところ上の質問が一番効果的。

  

そろそろ Web のような低レベルなものを意識するのは止めたら?とか。

by tanabe on March 26, 2007

Apollo とか LDR とか見ていて最近感じるのは、つくづく Web が融通の利かない低レベルレイヤで、もうその制約に従うのは止めたほうがいいんじゃない?という発想が強くなってるなというもの。

たしかに Web は単なる手段であって、手段の見せる世界ですらなかなか魅力的だったから手段が目的化していたような面があった。でも、Web のおいしい部分を頂いてしまえば、別に制約の多い世界にわざわざ留まる必要ないよねーっていう考えが強くなってきた気がする。

別にそれをもって「 Adobe は Google キラーだ。」みたいなことを殊更言いたいとも思わないし、実際 Web 自体がご破算になるとは思えないけれど、今のブラウザベースの Web の姿が 5 年後もそのままあり続けるというのはイメージしづらいなぁ。

  

Ruby の include, extend まとめ

by tanabe on March 26, 2007

この前の話の続き。

include, extend わかった。つか、自分で写した説明のとおりとしか言いようがない。

  • self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。
  • self.extend(other) とすると、 other のインスタンスメソッドを self の特異メソッドとして追加する。

Module はインスタンス化されないから、Module のインスタンスメソッドは extend するか、 include するかしないと使うことができないってだけだった。いったい何が理解できずにはまってたのか、自分でもよくわからず。。

てことで、まとめ。

  • self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。
    • 特異メソッドは実装されない
    • インスタンスメソッドは実装される。public, private, protected もそれぞれの扱いとして実装される
  • self.extend(other) とすると、 other のインスタンスメソッドを self の特異メソッドとして追加する
    • 特異メソッドは実装されない
    • private なインスタンスメソッドは特異メソッドとしては実装されない。private な呼び出しは可能。
module Foo
  def self.a # 特異メソッド
    puts "a"
  end

  def self.b # 特異メソッドからインスタンスメソッドを呼出
    d
  end

  def self.c # 特異メソッドから特異メソッドを呼出
    a
  end

  def self.c_self # 特異メソッドから特異メソッドを呼出
    self.a
  end

  def self.c_foo # 特異メソッドから特異メソッドを呼出
    Foo.a
  end

  def d # インスタンスメソッド
    puts "d"
  end

  def e # インスタンスメソッドから特異メソッドを呼出
    a
  end

  def e_self # インスタンスメソッドから特異メソッドを呼出
    self.a
  end

  def e_foo # インスタンスメソッドから特異メソッドを呼出
    Foo.a
  end

  def f # インスタンスメソッドからインスタンスメソッドを呼出
    d
  end

  def g # インスタンスメソッドから private なインスタンスメソッドを呼出
    h
  end

  def h # private なインスタンスメソッド
    puts "h"
  end
  private :h
end

class Bar
  include Foo
end

class Baz
  extend Foo
end

BarBazFoo
ClassName.method_nameすべてエラーd,e_foo,f,g は問題なく動作a,c,c_self,c_foo は問題なく動作
ClassName.new.method_named,e_foo,f,g は問題なく動作すべてエラー

インスタンス変数の動作。

module Hoge
  def self.set_value
    @hoge = "hoge"
  end

  def self.puts_value
    puts @hoge
  end
end

module Hoge
  def set_instance_value
    @hoge = "hogehoge"
  end

  def puts_instance_value
    puts @hoge
  end
end

class HogeHoge
  include Hoge
end

Hoge.set_value
Hoge.puts_value  #=> hoge

HogeHoge.new.puts_instance_value  #=> nil

ここに書くのが遅くなったから、エントリ上の日付だけ追ってると一週間これに悩んでたみたいだな。ま、いいか。

  

なぜ自分を磨くのか

by tanabe on March 20, 2007

Number の 674 号、三浦知良のインタビューから。

ーでも、一方で、サッカー選手の中には20代で早々に崩れていく人も少なくない。 「結局何かを疎かにしてるんだよね。それはやっぱりサッカーだと思う。若いときは深酒して寝不足になっても大丈夫だと思う。でもそこで練習を疎かにして辞めなきゃいけなくなった人は多いと思うんだよね。それは自分に問いかけてほしい。ほんとに自分が大切にしなきゃいけないのはサッカーのグラウンドだったと思う。
 遊んでマイナスになることもあるよ。でも、ほんとにハートが強ければグラウンドで取り戻せるものだと思う。若いときだったら。それを怠けたから辞めなきゃいけなくなったんだと思う。怪我とかいろんな要素があって辞めなきゃいけなくなった人もたくさんいるけど、怠けて辞めた人も、半分はいると思う。もっと練習やっとけばよかったって言ってる人はたくさんいる。遊んでも何してもいいと思う。ただ、その倍くらい練習すればよかったと思うし。」

やっぱりフィールドで輝いてこそだし、そのための積み重ねだよな。と。

  

Ruby の include/extend が分からなくなってきた・・・

by tanabe on March 19, 2007

FileUtils は FileUtils.mkdir といった形で利用ができる。つまり、モジュールの特異メソッドになってるのだけど、module_function を探しても見つからない。

それでもコメントに燦然と輝く "# All methods are module function." の文字。

なんだ??と思って探し回った結果。↓

extend self

そりゃ、そうだぁ。そんなやり方もあったのね。。(あれ、もしかして一般的なの?)

というわけでメモ。

  • クラスメソッド=クラスの特異メソッド。モジュールメソッド=モジュールの特異メソッド。
  • モジュール関数=モジュールの得意メソッドであり、モジュールの private メソッド。
  • self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。
  • self.extend(other) とすると、 other のインスタンスメソッドを self の特異メソッドとして追加する。
  • モジュールをクラスに extend するとモジュールのインスタンスメソッドがクラスメソッドになる。
  • include は、クラス(のインスタンス)に機能を追加。
  • extend は、ある特定のオブジェクトだけにモジュールの機能を追加したいときに使用。
  • モジュールの特異メソッドから内部の private メソッドは参照できない。(undefined local variable or method. include した場合は参照可能。extend だとダメ。)

うーん、わかってたつもりが混乱してきた。

class 内部に extend ModuleName して使うのはイレギュラーな使い方?でも、Forwardable モジュールとかでふつうに使うようなぁ。

  

ふつケル中。

by tanabe on March 16, 2007

ふつケルの読書中。おもしろいなぁ。

ちょっと高階関数とクロージャの言葉の定義の違いに混乱したので、メモ。

Martin Fowler's Bliki in Japanese "Closure"
Martin Fowler's Bliki in Japanese "CollectionClosureMethod"
まつもと直伝 プログラミングのオキテ 第5回 高階関数を分かりやすくしたブロック

  

リクナビ

by tanabe on March 14, 2007

3年くらいリクナビの職務経歴を更新していなかったので、ひさしぶりに更新してみた。

スキルマップに Ruby や Rails はないのか。あと1年したら載ってるかなぁ。

  

なぜ顧客は受入テストで仕様変更に気がつけるのか?の続きの続き

by tanabe on March 13, 2007

3/9のエントリについて、いくつか言及を頂いたので紹介。ちなみに私自身の考えはこちら

違いは何か。実ははっきりしています。「本気度」です。いつでも変更できますよ、というステータスだと、必死で詳細まで見ないのです。ここで決めたことがリリースされるのだ、となった途端に急に詳細まで考え抜くようになります。〆切重要。

もうすぐ春だよはぶにっき [仕事]仕様の確認方法

僕はもともと、ドキュメントじゃ確認できる内容には限界あるから、使ってもらって判断してもらう、ということには同意できたんだけど、使ってもらってであっても、本気度が足りないと全然フィードバックが受けられないというのも現実で。

m_pixyの読書日記 [dev][RD]お客様の本気度

いきなり真打登場という感があるのですが、「本気度」。たしかにこれはあります。なんで本気にならないんでしょうね?やっぱり締切りなんでしょうか。

一方で「本気になって仕様を検討するときに何をどう見ればわからない」というのはある気がしています。ユーザーの人は業務のプロではあるけれどシステム仕様を書くプロではないので。じゃ、誰がプロかっていうとやっぱりシステム作る人になるんじゃないかと。

ユーザーが本気になって仕様を確認したときに、動作するプログラムと紙の仕様書(ガチガチのもアジャイルなのも含めて広い意味での仕様を記した何かしらのもの)のギャップはどこに残るのか?(残らないのか?)が新たな疑問。

スタロジ流だと限りなく「残らない」に近いスタンスですね。残るけど、それは紙では実現不可能な部分という。

そうか。たしかにここまで割り切ってしまえば残りの部分(見えてないと仮定できる部分)の見通しはかなりよくなるなぁ。少し前進した感あり。ありがとうございます。

このズレが重いな。だから、ユーザを巻き込めという話になるのか。XPやなんかでも言われてるけど、このこと自体は開発方法論には関係しないはず。ただ、方法論としてユーザを巻き込むということを明示しているからアジャイルはイイ!って話になってるのかと思ったり。

m_pixyの読書日記 [dev][job]ユーザが本気になるタイミングと、開発側が本気になるタイミング

「リーンソフトウェア開発」を読んでいて私もこれを感じました。単純に開発サイクルが短いというのは強制的に巻き込む機会が増えるな、と。(厳密には「方法論としてユーザを巻き込むということを明示」の指されている話とは少し違いますが、言いたいところは近い。はず。)

最後に頂いたトラックバックから。

ぼくは「仕様決めのときになくて、顧客テストのときにある」のは「動くアプリケーション」と「それまでのコミュニケーションで培ってきた信頼関係」だと思う。受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。その上で、実際に動くアプリケーションを使って検証するから、この仕様は正しいと判断できるのだと思う。

TECH-moratorium : テクモラトリアム [SD]顧客テストにはあって、仕様決めのときにはないもの

なるほど。たしかに丸っきり初対面から始めたようなプロジェクトだと仕様決めるにしても「空気を読みつつ」みたいなところはありますね。(身に覚えあり。その態度を反省した覚えもあり。)

「受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。」の部分がちょっと理解しきれなかったのですが、仕様と実装アプリの動作にずれが出ているという内容かな。そして、それをコミュニケーションですり合せている。と。(違うかも)文脈的に「この仕様は正しいと判断できるのだと思う。」の部分に掛かる理由にもなっているはずですし、もうちょっと突っ込んで聞いてみたい内容です。

あと、「動くアプリケーション」というのはなんだかんだ言ってやっぱり強いですね。Ruby まつもとさんの「ソースがドキュメントだ。 バグも完全に記述されている」ではないですが、たしかに仕様の誤り・漏れも含めてすべて実装されているというのは強いです。あとはそれを作るのはタダじゃないというコストの問題ですか。

最後のオチとしては、

逆に、お付き合いが長かったり、そのシステムに専念できるお客さまだったり、既存システムのリプレース案件の場合は、仕様決めの段階できっちりと詰めるアプローチが有効だと思う。特に、仕様のほとんどが計算式な金融系のシステムなんかはそうだろう。重要な仕様は事前に十分に検証でき、結果的にリスクも下がると思う。

にど真ん中で当てはまる案件をやっているにも関わらず、こんな問題提起をしている自分が居たり。やっぱ単なる本人の力不足か!

  

なぜ顧客は受入テストで仕様変更に気がつけるのか?の続き

by tanabe on March 13, 2007

3/9の話の続き。

ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている(だからテストでは指摘ができる)のにそれを完全に正確に伝えられないのだろう?」というもの。(略)「顧客テストにはあって、仕様決めのときにはないものはなんだろう?」「その本質的な違いはどこにあるんだろう?」

顧客テストと仕様決めでの本質的な違いは「網羅性」なんじゃないか。そう思ってる。

仕様決めのときはお互い想定で進んでいる部分があって、要は詰めが甘い。顧客テストになると実際に動くものができているので、隅から隅まで動かせる。わかってるようでわかってない部分とか、なんとなくこれで大丈夫と思ってたような部分での問題が全部表面化するのではないか?

その視点だと Goya の UI スケッチだとか、あるいは他の宗派の同系統手法でもいいけど、手法を真似るだけじゃなくてそれによって何をやらないといけないかが明確に見えてくる気がする。

たとえば、こんなものが見落とされているはずなので重点的にチェックする。

  • 状態によって変わる動作(想定されるすべての状態について検討したか)
  • そのあり得る組み合わせとしての操作ストーリー
  • 条件が false の場合のすべての動作
  • 条件の網羅性(条件を満たさないものにはどんなものがあって、それらは本当に条件に含まれなくても正しいのか)

上記を見ると当然確認しているべきものでもあって、レベルの低い話になってしまっているのだけど、それでも実際漏れるのは「当然であるはずのところ」から抜け漏れが出てしまっている。当然のことをより意識して都度気にしながら確認できる仕組みが必要。(少なくともぼくには)

上記を考えるにあたって、顧客テストと仕様決めの時点で何が違うかを考えてみたので併せて公開しておく。

仕様決め顧客テスト
(時間軸上の)タイミング情報少ない(?)情報多い(?)
顧客の求められる役割”お客さん”最後の門番
検証物仕様書(定型ドキュメント、図、モデルなど)動作するプログラムそのもの

それぞれに少しずつ意見があって、結局網羅性に行き着いている。

  • (時間軸上の)タイミング
    本当に顧客の得られる情報量が変化しているケースは仕方がないが、そうでもないケースもよく見かける。これは仕様決めの時点では顧客は何らかの理由での細部まで調査確認をする必要がないと判断しているのでは?では、その理由は?
  • 顧客の求められる役割
    そもそもの顧客の態度自体が違う?だとすればなぜ?それは私がコントロールできる?また、仕様決め時点なりに真剣に検討しているようでも、顧客の頭の中では想定外の(望んでいる動作と違う)動きが顧客テスト時に発見されることもある。なぜ想定外の動きだったんだろう?
  • 検証物
    仕様書が「顧客の想定している使い方のケース」をすべて網羅していれば、理屈上プログラムはそれを実装しただけのはず。プログラムが顧客に見せられるものと同じものを仕様書として見せられるのでは?今仕様書からは漏れ、プログラムでは顧客が気が付けるものがあるとすれば、それは単に仕様書がそれについて正確に言及していないか、顧客がそれを見落としているのではないか?

最後の方は思考過程を丸投げしているようなエントリになってしまったけれど、「いかに仕様化するか?」というのが最近のテーマだったので良い機会だし文章にしてみた。

  

なぜ顧客は受入テストで仕様変更に気がつけるのか?

by tanabe on March 09, 2007

「リーンソフトウェア開発」P219から。

システムが、顧客の意図どおり動くことを確認するテストは「顧客テスト」という名前で呼んだ方がよい。それは、テストの目的が、顧客がシステムに期待したとおりシステムが動くことを確かめるためだからである。

そう。そのとおりだ。そして、本書ではその顧客テストを短いサイクルタイムで複数回を行うことでリスクを軽減するというアプローチを取る。

その主張も正しい。一つの解決策として非常に参考になる。

だけど、ここで一つ大きな疑問がある。顧客はなぜ「顧客テスト」をするとしっかり仕様の漏れ、ミスを発見できるんだろう?

ちょうど今日もそうだった。すでにシステムはリリース間近。まさに「顧客テスト」が行われていた。そして発覚した仕様の漏れ。

その対応自体はけっきょく事なきを得たのでここで話題にはしないけれど、不思議なのはその仕様はけして「ビジネス環境の変化」で昨日今日浮上したなんてものではなくて、当初にレビューをしている時点で分かっていて然るべき内容だった。

これは結論から言ってしまえば仕様のヒアリング漏れであり、端的には「しっかりやれ自分」てところに反省点は行き着く。それはデブサミの羽生さんの名言「仕様変更なんてないんです」を持ち出すまでもなく、そのとおり。そう考えないと前進しないし。

ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている(だからテストでは指摘ができる)のにそれを完全に正確に伝えられないのだろう?」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう?」という疑問だ。

さらに質問形式を続けると、「顧客テストにはあって、仕様決めのときにはないものはなんだろう?」「その本質的な違いはどこにあるんだろう?」

リーンソフトウェア開発で述べられている「動くものを提供する」というのもたしかに「顧客テスト」を早めるという意味で有効なサポートになりそうだ。

でも、目下抱いている疑問への直接の解答にはならないんだよな。

自分の今の仮説も明日さらすつもりだけど、まずは読んでくれた方、ご意見など頂けるととてもうれしいです。

ちなみに「仕様変更なんてないんです」の意味については、こことかこことか参照。

リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜
メアリー・ポッペンディーク トム・ポッペンディーク 平鍋 健児 高嶋 優子 佐野 建樹
日経BP社 (2004/07/23)
売り上げランキング: 59630
  

[memo] パターンのメモ。

by tanabe on March 08, 2007

net/smtp から抜粋。

def initialize( address, port = nil )
  @address = address
  @port = (port || SMTP.default_port)
  @esmtp = true
  @socket = nil
  @started = false
  @open_timeout = 30
  @read_timeout = 60
  @error_occured = false
  @debug_output = nil
end

def SMTP.start( address, port = nil,
                helo = 'localhost.localdomain',
                user = nil, secret = nil, authtype = nil,
                &block) # :yield: smtp
  new(address, port).start(helo, user, secret, authtype, &block)
end

def start( helo = 'localhost.localdomain',
           user = nil, secret = nil, authtype = nil ) # :yield: smtp
  if block_given?
    begin
      do_start(helo, user, secret, authtype)
      return yield(self)
    ensure
      do_finish
    end
  else
    do_start(helo, user, secret, authtype)
    return self
  end
end
  

きれいなコード

by tanabe on March 08, 2007

これ、わかるなぁ。私は Ruby 使い始めて、Ruby のライブラリ見たり、るびまの青木さんの添削みたりしてどんどん書き方が変わった。

最初、こういうのがきれいだと思った。

int  axe      = 3 ;
int  exe      = 4 ;
int  longname = 8 ;
long lonlon   = 1L;

が、へたなプログラムほどこういう書き方をしているのを目にして、次の書き方へ移行した。

int axe = 3;
int exe = 4;
int longnmae = 8;
long lonlon = 1L;
http://arton.no-ip.info/diary/20070222.html#p04

以前職場で教わった「きれいなコード」って全処理の構造をコメントで書いたりしてた。ある程度の処理の単位ごとに手動で項番振って「○○処理」とか「○○を××する」みたいなコメント書いて。今思うとなんともアレだけど、当時は大まじめにインデントそろえたり最初にコメント書いたりしてた。

  

リーンソフトウェア開発がとっても良書

by tanabe on March 05, 2007

リーンソフトウェア開発を読んでいる。長い間書棚の肥しにしていたのだけど、正直バカだった。すばらしい内容。

読みながら、デブサミ2007での羽生さんの講演を思い出す。「スタロジはウォーターフォール」はある意味でブラフで実は最もLeanに近いところを狙っているよなぁと思う。語義に惑わされず原義の宣言に戻れば agile でもあるし。ウォーターフォールってのは、単に「イテレーションベースでインクリメンタルな開発はしていない」っていう手法の問題だよな。

読んでて初めて気づいたけど、リーンソフトウェア開発って平鍋健児さんが共訳している。何にしてももっと早く読んでおけばよかったな。

リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜
メアリー・ポッペンディーク トム・ポッペンディーク 平鍋 健児 高嶋 優子 佐野 建樹
日経BP社 (2004/07/23)
売り上げランキング: 99757
  

すごい会議のための最高の手引書 『この「聞く技術」で道は開ける』

by tanabe on March 02, 2007

すごい会議」を購入した人にはぜひ一度読んでほしい。「すごい会議」の公式副読本はおそらく「すごい考え方」なのだろうけど、この本もぜひ加えてほしい。すごい会議はこの TIME TO THINK をプロジェクトの推進で使うためにフレームワーク化したものだと言えるから。

問題の正しい対処の仕方を知っていて、一人で実践する分にはうまく行くのに、皆にそれをやってもらおうとした途端にうまくいかなかった経験はないだろうか?

たとえばプログラムでもいい。セオリーとしてどのようにすべきか、きっとあなたは知っている。ファウラーのリファクタリングも読んだし、デマルコのデッドラインも読んだ。もちろん達人プログラマーだって読んだし、デザパタ本だって読んでいる。コードコンプリートもライティング ソリッドコードも読んだんだ。楽々ERDレッスンも読んだ。何をすべきかは知っている。

ところが、それを組織でやろうとしたときになぜだかうまくいかない。そして「やっぱり会社や組織の問題かなー」などと考えながら、角谷さんのプレゼンを羨ましげに眺めるんだ。

まぁ、大方の予想のとおり上記はほとんど自分のことなのだけど、同じような体験をされている人は多いと思う。

『この「聞く技術」で道は開ける 一番いい考えを引き出すノウハウ』という本は人を巻き込むためのアプローチを書いた本だ。人は変化することを恐れる傾向がある。これは無知や見識不足が原因ではなくて、もっと精神的な問題だ。だから、それが正しいかどうかに関わらず、あなたがやろうとしていることは支持されにくい。それは今までのやり方を変えることだから。これをいかに克服して変化を起こすのか。この本ではそれを順を追って書いている。

『この「聞く技術」で道は開ける 一番いい考えを引き出すノウハウ』はいかに全員が”考える環境”を作るかということに焦点を絞った本だ。ぼくには”考える環境”というちょっと道徳チックな響きよりも TIME TO THINK というストレートな物言いのほうがわかりやすい。

本の中では TIME TO THINK を互いに実現するために必要なことが書かれている。

  • TIME TO THINK のコンセプト
  • TIME TO THINK に必要なこと
  • TIME TO THINK に必要なことを実現するために何をすればいいのか
  • ケーススタディ
実際、300ページほどの本で書かれているのは一貫してこの TIME TO THINK についての話だけだ。それだけを懇切丁寧に書いているから、何をすべきか、してはいけないかがよく見える。

TIME TO THINK の根底に流れるものを一言で言い表すとしたら、「人は自分で考え答えを出せる、と相手の可能性を徹底的に信じぬく姿勢」だ。 自ら考え導き出した答えは自然とその人をドライブする。だから、自分はそのためのサポートに徹しよう。それが TIME TO THINK の幹になっている。

正しいことを決めてそれを発表、実行させる「御上の通達方式」はある種楽な方法だ。「正しいこと」を脳みそに汗かき考え抜く過程はしんどいが、あとは実行されなきゃ「他人が無能だった(方向性は正しかったのに!)」と言い張ればいい。まして、その考え抜く過程を手抜きして省いてしまえば、こんなに楽な方法はない。「○○が正しい(はずだ!)」という仮説を立てた時点で検証をせずに思い込みで突っ走るんだ。

でも、この方式はそれほど効果を生んでないように見える。そりゃ、皆他人から言われただけのことをやるのに120%、200%の力を出そうとはしないもの。

一方で、この本で語られる TIME TO THINK 方式は組織を動かす方法として、とても興味深い。自分で考え自分でやることを決める。誰のせいにもできない。末端のレベルでのアクションプランへコミットメントを得る方法としては、非常に効果的だ。

でも、コントロールできる立場の人にとってこんなにしんどい方法もないと思う。誰だって答えを出す力があるのと同様に、当然コントロールする立場の人だって、自分の正しいと思う答えを持っている。そしてそんな立場の人はたいてい経験もあるし自負もあって、「自分は正しい答えを知っている」という思いはきっと誰より強い。つい「御上の通達方式」へ流れたくなる。

TIME TO THINK 方式は、そんなコントロールする立場の人に我慢を強いる。ひたすら我慢を強いる。答えは相手の中から出てこないと意味がない。仮に同じ結論にたどり着くとしても、相手の中から答えが生まれるというプロセスこそがその人を動かす原動力になる。

だから、待つ。課題に対して、必要条件を満たす答えが見つかるまでとことん待つ。出てきた答えが必要条件を満たすなら、たとえ自分が知っているセオリーどおりの答えでなくても本人の中から生まれた答えを優先する。

言葉で言うのは簡単だけど、これを実行するにはとんでもない忍耐力がいると思う。有能な人ほどそうだろう。それでも一人でできない仕事をやり遂げるには知っておいて損のない考え方だ。

本書を読み終えても、一つ大きな課題がある。セオリーへの誘導はまったくすべきでないのか?

ここから先は完全に私見だが、自分で答えを出す過程では誘導すべきでないと思う。相手の人は馬鹿じゃない。たぶん誘導されたことに気づいてしまう。そのような子供扱いはすべきじゃない。

セオリーは事前に提示する。他の人が考え出したら、誘導するような真似はしない。そのセオリーが本当に力を持っていれば、きっと皆が出す答えの中にも何かしらの形を残すだろう。セオリーの提示のやり方は、「すごい会議」で語られた真実の提示の手段というのが有効かもしれない。ハワード・ゴールドマンが大橋禅太郎さんたちに対して洞察を与えるときに取ったやり方だ。質問をし、答えを言ってもらい、最後により深い洞察を持った意見を提示する。

TIME TO THINK は一緒に働く人全員を答えを出す力のあるパートナーとして尊重し、可能性を信じる。そして、その考える過程を通じて全員が課題を克服していくことにコミットしていく。精神的なところを大事にしつつも単なる理想論に終わらず、非常に実践的なマネジメント手法になっていて興味深い。

この「聞く技術」で道は開ける 一番いい考えを引き出すノウハウ
ナンシー・クライン 古賀 祥子
PHP研究所 (2007/01/27)
売り上げランキング: 12961
  

Web時代の今こそ読みたい「UNIXという考え方」

by tanabe on March 01, 2007

少し前にUNIXという考え方という本を読んだ。そして、これこそまさにプログラムするWebを理解するために読むべき本だと思った。

そしてしばらくしたところに現れたサービスが Yahoo! Pipes。自分でWebのAPIを触っているような人は発想自体への新規性は感じず、むしろ納得のサービスだったのではないだろうか。それにしても、Pipesという一部の人にはこれ以上なく直感的なネーミングは絶妙だと思った。

さて、そんなPipes(Yahoo!じゃない方の)についても触れられているUNIXという考え方。これは名著だ。しかも類著がない。(ふつリナ?そうかも。)

UNIXという考え方は、UNIXを使う人ではなくむしろUNIXを使ったことがない人に読んで欲しい。それもソフトウェアを作る人に。なぜならこの本にはUNIXの使い方ではなく、UNIXという優れたコンセプトに横たわる設計思想が書かれているからだ。

語られる思想の中心にあるのは、「小さなものを組み合わせる」ということだ。「スモール・イズ・ビューティフル」を持ち出すまでもなく、ここにあるのは引き算のデザインの美学である。そして、これが組み合わせたときのスケールを生む鍵になる。

本書の中で語られる10の定理を列挙してみよう。

  • スモール・イズ・ビューティフル
  • 一つのプログラムには一つのことをうまくやらせる
  • できるだけ早く試作を作成する
  • 効率より移植性
  • 数値データはASCIIフラットファイルに保存する
  • ソフトウェアの梃子を有効に活用する
  • シェルスクリプトを使うことで梃子の効果と移植性を高める
  • 過度の対話的インタフェースを避ける
  • すべてのプログラムをフィルタにする

これはUNIXという考え方からの抜粋だ。けしてWebという考え方の抜粋じゃない。それでも、そのように見まがうくらい今のWebアプリケーションに求められる考え方がつまっている。

「いかにスケールするか」という共通の目的に向かった設計思想が自然と似た指針を生んだのだろうが、興味深い。細かい内容の方も「拘束的プログラム」や「動かせないデータは死んだも同然」など楽しくもためになる指摘がたくさんある。

(委員会的に)正しいソフトウェアじゃなく、本当に役に立つプログラムを作りたい人はぜひ読んでほしい。

UNIXという考え方―その設計思想と哲学
Mike Gancarz 芳尾 桂
オーム社 (2001/02)
売り上げランキング: 57554