アジャイル仮想論争:スキルの問題(3)

まぁ、もういい加減机上の空論でアジャイル開発を
語るのも疲れてきた感も否めないんですが、まだしつ
こく頑張ります。

しかもさらにしつこいことにまたスキルの問題に関する
議論というか、この問題の根本に関する私の私見です。

そもそも何故アジャイル開発に参加する開発者には
一定のスキルが必要だ、ということがそんなに問題
なのでしょうか?その一定のスキルの開発者が簡単に
集められるならば、「集めりゃいいじゃん」という話で
終わるはずです。

そうならないのは、結構多くのマネージャが、
そして、標準的な手順に従えば誰でもある程度の
品質で開発ができるという妄想に取り付かれていて、
個人のスキルに依存して開発を進めることに拒否反応を
示すからだと思います。

この妄想はまた、スキルの高い開発者を育成することも
阻んでいます。そのため、ますますアジャイルな開発手法
を採用することが難しくなるという、状況を生んでいる
と思います。

世の中には比較的低スキルの、取り換え可能な開発者を
供給することによって食っている会社もあるかと思いますが、
そういう会社はもし、アジャイルな開発手法がもっと一般的
になってきたら厳しいだろうな、と思います。

気付き

今日はめずらしくごく私的な話題です。

実は私、小学4年生くらいからずっとトランペットをやっていて、
今も続けているのですが、10何年やってて今日始めて、自分の
楽器吹くフォームがおかしいことに気付きました。
風呂場の大きな鏡をみながら練習していて、マウスピースを唇に
あてる位置が右より過ぎることに気付いたのです。
鏡を見ながら左右真中の位置に唇を当ててみると、ずっと太い音が
でることが分かりました。そりゃそうですよね。いままでずっと
唇の筋肉が薄いところを使って吹いてたんだから。
いまま顔の中心だと自分で思っていたところは実はそうでは
なかった訳です。

左右対照を意識して練習を続けてるうちに、実は自分が普段から
まともにまっすぐ立ててないことにも気付きました。

無理矢理まっすぐたとうとすると凄く違和感のある感じです。
それからずっと自分がまっすぐな姿勢か気になって仕方ありません。
今も微妙に左右対照を意識しながらキーボード打ってます。

一言でいうと身体のゆがみというやつでしょうか。確かに姿勢は
悪いほうだけど。。。もしや眠りの浅さや、肩こり、疲労感などは
全てこれが原因かっっっっ!
こういうのって整体とかにいけばいいのでしょうか?

身体の問題に限らず他にも自覚はしてないけどバランスの
悪い言動をしているときがきっとあると思うとぞっとします。

こういう気付きっていうのがどういうタイミングで訪れるのかは
ほんとに謎で、そこに関しては私は神秘主義者です。

従来型の開発プロセスで満足してしまっている人達が他にも
良いやり型がある、ということを理解するにもきっと気付きが
必要なのでしょう。

と無理矢理マジメな話しにまとめたところで今日は終にします。

ブックレビュー：コーチング・バイブル

書名：コーチング・バイブル
著者：ローラ・ウィットワース、ヘンリー・キムジーハウス、フィル・サンダール
訳：CTIジャパン
発行所：東洋経済新報社
ISBN4-492-55455-6 2,500円

去年の暮れにコーチングについて勉強した時に読んだ本です。
バイブルと名乗ってるだけあって、コーチングの基本的な考え方
をひと通り知る事が出来るし、プロのコーチとは何かについて学ぶ
ことができます。

アジャイルなソフトウェア・プロジェクトではメンバが自発的に
行動することを重視するので、プロジェクトマネージャが
頭ごなしに命令するだけでは多分プロジェクトはうまく回らない
と思われます。ですから、ある程度コーチングのスキルを身に
つけるか、コーチ的な役割を果たせる人をメンバに加えるか
した方がきっと良いのでしょう。

読んでみて、自分にはコーチングの才能は一切ないのだと痛感し
ました。コーチングの根本は、「話し相手に興味をもつ」ことだと
読み取ったのですが、これが自分には意外と難しいことだと分かり
ました。それでも自分に足らないものを気付かせてくれた
という点において、この本を読んだことには意味があったと
思います。

コーチングスキルを高めるための実践的なエクササイズも
いくつか紹介されているので、それを実際にやってみても
おもしろいかもしれません。でも僕にはとてもできそうもない
エクササイズもありますが。例えば。。。

好奇心を磨くためのエクササイズ：
「喫茶店で30分ほど過ごし、周りにいるすべての人に対して
好奇心を向けてみましょう。次に、その中の一人に対して
少し時間を割いてもらえるように依頼し、実際に好奇心から
くる質問をしてみましょう」

はたからみたら完全にナンパですよね、これ。

コーチになりたいというよりもむしろコーチングを受けたいと思う、
今日この頃です。

Language Oriented Programming

随分間が空いてしまいました。
忙しかった、というよりちょっとしたモチベーション層の
障害ってところでしょうか。。

さて、去年Martin FlowerのBlogに紹介されていた記事で
取り上げられていた、Language Orient Programming(LOP)というもの、
これはいったい何だろうと呼んでみたところ、
なんのことはない、MDAとかモデル変換っぽい話でした。
これが新しい話題ではないことは著者も認めています。

簡単にいうと、DSL(Domain Specific Language)を簡単に
作れるプラットフォームがあればソフトウェア開発がもっと
楽にできるようになる、というお話でした。
現状のソフトウェア開発では頭の中にあるもやもやっと
した概念をソースコードに落とす課程に多大なる労力を費して
いますが、概念とのギャップが少ないDSLをプログラマが簡単に
作れるようになればもっと楽ができる、と。
それは確かにその通りだと思いますが、実現するのは結構
難しそうです。この記事の著者は、Meta Programming Systemという
LOPのコンセプトを実現した実装を作ったそうです。
(もちろんまだreal worldで使えるレベルには達していないと
本人も認めていますが)

とはいえ、あらゆるモデルを記述できる言語を作ってしまおう
というUML2.0のようなアプローチと比べればずっと健全だと
思います。

さて、ここでDSLとは

1. 言語の構造


2. 言語構造を操作するためのエディタ


3. 言語構造を実行可能なコードに変換するトランスレータ

の3つの部分からなると言われています。
ですから、LOPのコンセプトを具現するには

1. 言語の構造を定義するメタ構造


2. 言語構造を操作するためのエディタを簡単に作る仕組み


3. 言語構造を実行可能なコードに変換するトランスレータを簡単につくる仕組み

の3つが必要であることがわかります。

Meta Programming Systemはすべてを自前で用意しようとしてる
みたいなのですが、実は個々の要素を見てみると世の中に既にあるものも
結構あるのかと思います。

1.は多分OMGのMOF(Meta Object Facility)とかEclipse EMF
のECoreとかにあたるものでしょう。
2.はEclipse のGEFとかEMFのエディタ生成機能とかが
近いものがありますが、GEFは"簡単に"エディタを作るには
あまりにも複雑ですし、EMFが自動生成する
ツリーのエディタは逆にあまりにもシンプルすぎます。
3.はMOF QVT RFPでいわれているものと同等のもので、
まともな実装はまだ無いのでしょうが、謎のEclipse GMT
とかがこれにあたるのでしょう。
(最近全然おっかけてないのですが、どうなってるんでしょうか?)

LOPというコンセプトはこれらを統合したところに新しさが
あるといえばあるといえると思います。
確かに実現できたら素晴らしいんですけどね。。

個人的には最後にDSLの構造を実行可能コードに落とす所を
"簡単に"記述するのがかなり難しいのではと感じています。
これは、去年仕事で自分が頑張った経験に基づいているかなり
確信の持てる意見です。ここが簡単にできないと、やっぱり
普通にJavaとかのソースコードごりごり書くほうが良いって
ことになってしまいそうです。

自分でLOPの実装に取り組むなら、やっぱりEcilpse EMF+GEFを
ベースにするかな。。でもあまりにも状況が混沌としているため、
容易にはとても手が出せないですが。

でもこのような考えをもとに、数年後にとてつもない
イノベーションが起こって、みんなHappyになってると
いいな、と期待します。でも難しいんだろうな。。。