「問題 VS. 私たち」で考える人たち
訳者の角谷さんから献本をいただいて(ありがとうございます)から、ずっと迷っていたことがある。私は、gem戦記というサブブログを書いていて、純粋に技術的なことはそちらに書くようにしている。この本について何か書く時、そちらに書くかここに書くかをずっと悩んでいた。
アクセス数は圧倒的にこちらの方が多いので、なるべくならこちらに書きたいが、こちらは技術者でない読者も多いので、どうしたものか迷いながら読んでいた。
中身は評判通り大変よい本だと思うが、内容的にはやはりほぼソフトウエア開発の話に終始していて、これはやはり「gem戦記」向けだなと思いながら、Bruce Tate氏の本文を読み終えた。
ところが、ところがである。
「訳者あとがき」の中で、まさに「アンカテ」向きの素材を発見してしまった。
本書のアイディアを手掛りにRubyを導入するにあたっては、マネージャとの「交渉」ではないことを肝に銘じてください。「マネージャ VS. 開発者」ではなく「問題 VS. 私たち」の構図を共有することを心がけてください。(中略)
マネージャと開発者のいずれの立場にも共通することがあります。それは、相手に変化を強要することはできないということです。人が変化させられるのは自分自身だけです。そして、人は自分の速度でしか変われません。
- 「問題 VS. 私たち」
- 人は自分の速度でしか変われない
後者は、Kent Beck氏の発言なのだけど、どちらもいい言葉だと思いませんか？
ソフトウエア技術者は、コンピュータを相手にするのだから、0か1か、YesかNoか、はっきり答が出る問題を扱っているのではないあと思われがちである。しかし、実はぜんぜんそうではない。
main()
{
int i, sum=0 ;
for(i=1;i<=10;i++)
sum += i ;
printf("sum=%d\n", sum) ;
}
「このプログラムは何をするもので、何を出力するでしょうか」
これは答がはっきり出る問題で、確かにソフトウエア技術者は、こういう問題(のもっとずっと難しいもの)と格闘することはある。
しかし「次のプロジェクトで開発用の言語として、Rubyを採用すべきかJavaを採用すべきか」という問題は、簡単に答が出ない。
それは、RubyやJavaというプログラミング言語についての問題ではないからだ。それを使う技術者という「人」に関する問題である。
- 人は新しい環境に移って、新しいやり方で仕事をする時に、どのような苦痛と幸福の中にあるか
- それが苦痛になるか幸福になるかを決めるのは何か
- その幸福や苦痛を、現実的な要素で補う場合のコストの算定方法は
新しいプログラミング言語を習得することは、頭の使い方の転換を要求する。
sum = 0 ; for i in 1..10 sum += i end printf("sum=%d\n", sum) ;
たとえば、上記C言語のプログラムは、Rubyで書くとこうなる。こういうことに全く縁の無い方でも、両者のつながりというか対応関係のようなものは読み取れると思う。
しかし、Rubyでは次のように書くこともできる。
puts "sum=%d" % (1..10).inject(0) { |i, sum | i + sum }
こちらの方がRubyらしい書き方だが、上記二つのコード片は何となく理解できた方の中でも、こちらにはとまどうことが多いだろう。
この「for文」から「injectメソッド」への頭の転換は、JavaからRubyへという技術の切り替えの中では、最も些細なことの一つである。プロジェクト管理や仕事の進め方、開発者とユーザの間の打ち合わせの仕方等のマクロのレベルでは、もっと大きな頭の切り替えが必要とされる。
そして、こういう転換によって「成果物がどう変わるか」という問題は技術的な問題であり、ある程度答のある問題であるが、こういう転換を要求される技術者がどのように感じ、モチベーションにどのような変化を呼び起こすかは、人に関する問題であり、唯一の正解の無い問題である。
「JavaからRubyへ」は、ソフトウエア技術者が日常的に直面しているそういう種類の問題について、ある特定領域に絞りこんで、そのノウハウをまとめたものである。
この具体的問題のみが問題なのでなくて、ソフトウエア技術者は同じ種類の問題にたくさん取り組んでいることを、この本の「訳者あとがき」は示している思う。
- 「問題 VS. 私たち」
- 人は自分の速度でしか変われない
人の変わる速度や方向はまちまちであるから、激しい変化の中に置かれた人の集団は「あいつら VS. 私たち」というパラダイムに向かいがちである。これをいかにして「問題 VS. 私たち」という枠組みに導くか。
ソフトウエア技術者は、この難題を哲学的、抽象的に解いても金をもらえない。自分の置かれた環境の中で、具体的実践的にこの問題を解き、しかも、できたものが本当に動くかどうか、機械によって検証されてはじめて、金を稼ぐことができる。
そういう苦闘の中から生まれた知恵は、業界外の人にももっと注目されていいと私は思う。
そこでさっそく、そういうサンプルをいくつか。
以下の発言者は、私と違って、どれも筋金入りのスーパー技術者です。(本物ニセモノは「問題 VS. 私たち」パラダイムがどれだけ体に染みついているかに着目すればおおよそ識別可能で、その点私はまだまだ)
羽生さんと言えば、マジカなのですが、マジカで書かれたカードをご覧になったお客さんが「自社の業務プロセスが例外系だらけで終わっている・・・」というのを視覚的に気づけるというのが大きい、というお話。 これはホントに大きい。(中略)汚いものを取り繕うのはお化粧すればいくらでも出来ちゃうけど、汚いものをそのまま汚く見せるってホントに難しい。
「汚いものをそのまま汚く見せる」ってことに必死で頭を使うと、いいシステムができるって話。
今のSIビジネスでは、決められた金額の中でどれだけ安く作り上げることで利益を出す構造だからである。
「機能一定コスト可変」を「ディフェンシブ」、「コスト一定機能可変」を「オフェンシブ」という新語で定義している。この定義に従うと、「モニターが悪い数値を出すのでモニターを壊せ」という議論は、「ディフェンシブな議員がいいかオフェンシブな議員がいいか」と言いかえられる。
ラリー・ウォール：《（私は）金持ちです》。どれだけ持っているかではなく，どれだけ与えることができるかというのが金持ちの定義なら。
"rich" という言葉を、perlを開発した世界的プログラマーはこう定義し、「自分は持っているものは少ないけど、与えらるものが多いから、"rich man"である」と言う。
「人間は利己的に行動する」という常識が壊れているのではなくて、"rich"の定義が違う人たちが「豊か」になろうと努力し切磋琢磨しているのが、オープンソースやWeb2.0の世界。
どうも日本という地域にいると権利というのは天から授かったものという受身の姿勢が多いような気がする。仕事もそうだ。仕事というのは自ら勝ち取るものではないのか。主体的に動いてゲットするものではないのか。
「仕事術」的なエントリーでもあるけど、「欧州」という切り口に注意。「主体性」の背後には、歴史的によく吟味され定着している「権利意識」がある。
