機械猫の日記

■[agile]軽量からアジャイルへ

id:yamazaさんの日記に

なぜ「軽量言語（Lightweight Language）」というのか

という疑問が投げかけられていた。軽量という意味は何か、というような疑問だと思うんですが、ふーむ。

そういえば、同じような話をどこかで聞いたなぁ・・・あ、Agileか。笑

アジャイルも元々軽量プロセスと呼ばれていたけど、「軽量って何？」みたいな話になってアジャイルという言葉が誕生したのだった。

であれば、今言語に対しても同じことが起きるんじゃないかなぁ。

つまり、軽量言語ではなくアジャイル言語（？）に。

では、アジャイルって何か？というと、これはアジャイル宣言で明文化されていて、そのおアジャイル宣言の価値を共有するものがアジャイルなのだ（ですよね？汗）

では、今一度ここでアジャイル宣言を振り返ってみる。

　プロセスやツールよりも、個人と相互作用

　包括的なドキュメントよりも、動作するソフトウェア

　契約交渉よりも、ユーザとの協調

　計画に従うよりも、変化に対応

元々のアジャイルとは、開発手法というか、チームとしてのあり方を示したものなんやけど、じゃぁここでそれを言語に読み替えてみればどうなるかな。

プロセスやツールよりも、個人と相互作用

これは本来、言語そのものが重要なのではなく、それを使う人が大事なのだというこ。いきなり言語を否定してしまっているように見えるかもしれないけど、そうじゃなくて、言語側に読み替えればこれは、変な言語仕様を意識しなくちゃいけなかったり、やたらと使いにくいものになっていたりするのはツールに依ってしまうのは良くないということ。

つまり言語は人間に優しくなくてはいけないっということだと思う。

また、優しい言語であれば可読性も高くしやすく、他人との相互作用を促進してくれるだろう。また言語と人との相互作用というのも重要。

何をもって優しいというのかは難しいけど。。

包括的なドキュメントよりも、動作するソフトウェア

これは、すぐに陳腐化してしまって信頼性も低いドキュメント（しかも作成するコストは馬鹿にならない）に価値を置くよりも、実際のリアルなソフトウェアのほうに価値を見出しましょうという話。（決してドキュメントいらないという話ではない）

これは言語側から見れば2点あると思う。

一つは「言語は自然と可読性の高い記述になるように設計されていなくてはいけない」ということ。

もう一つは「ソースを読んだときにぱっと想像する処理内容と実際の処理内容に差があってはいけない」ということ。（これもある意味可読性の問題か）

そもそもなんでドキュメントが必要なのかというと、コードは読むには具体的すぎるし、さらには読むにはスキルがいる。というのと、角谷さんが「コードにはHowを、Testにはwhatを、コメントにはWhyを書く」と、言われていたように、コードとは別視点のドキュメントが必要になるからだ。

この別視点のドキュメントというのは、ちょっと置いておくとして、最初の「コードは読むには具体的すぎるし、さらには読むにはスキルがいる」というのは可読性が十分に高ければ、もしかしたら解決されるんじゃないかな？

十分に可読性が高い→全体を理解しやすい、あるいは処理内容が理解しやすい。また言語を知らなくても読める。

ということだと思えば、ある程度解決されているように見える。

ところでさっきちょっと置いた「別視点のドキュメント」についても、可読性の高い、良いコードはそこに意図（what／why）を反映させやすくもあるので少しは効果があるかもしれない。

つまり宣言的な記述ができる、あるいは宣言的な記述を促す言語であるほうが良いのだ。

とはいえ、完全にwhat/whyを記述できるわけではないし、やっぱり別視点のドキュメントというのは必要だろう。言語がどう進んでもドキュメント重要というのは変わらない。

契約交渉よりも、ユーザとの協調

これは言語と開発者の間の契約（言語の文法、仕様）よりもユーザとどのように協調するかという点のほうが重要であるということ。

つまり変な文法や難解な仕様で開発者を混乱させるよりは、素直で見通しのよい文法・仕様であるべきで、さらに開発者の思考を手助けして協調してくれなくてはいけないということ。やりたいことがパッと思いつくような言語のほうが重要だってこと。（ただ、言語に対する習熟というポイントもあるけど、まぁそれは今はおいておく）

計画に従うよりも、変化に対応

これも2つあるかなぁと思う。

「アプリケーション変更が行いやすい言語であること」と「言語側の仕様等の変更がしやすいこと」

アプリケーションの変更というのは、言語の責任ではなくアプリ設計などの責任に思えるかもしれない。まぁそれは確かにそうなのだが、言語側としては、変更に強いアプリ設計になるような支援をするべきだと思う。

また、「言語側の仕様などの変更がしやすいこと」ってのは、例えば言語提供するライブラリがあったとしてそれが不十分だなぁっと感じたら簡単に拡張できるほうが良い、あるいは変な仕様だなぁっと思ったら、より素直な仕様と思えるような記述が可能にしやすいほうが良いなぁということ。（仕様等を拡張しても、既存アプリなどに影響を与えづらくしなくてはいけないという問題もある）

まとめ

以上の4つのことに価値を置いている言語がアジャイルと言えるかなぁと思う。言語側に強引に焼きなおしてみると

・言語は人に優しくあるべきだ

・言語は可読性が高い記述を促さなくてはいけない

・言語仕様は見通しがよくなくてはいけない

・言語は変更に強くなくてはいけない

（これらの価値は互いに関連しあっている）

僕がRuby好きだからかもしれないけど、Rubyは上記の4つの価値にコミットしていると思う。笑

他の言語はどうでしょうか？

（追記）

というかあれですかね、システムは人が作る、ツールや言語は人が使う・コードは人が書き・人が読むという事実に価値を置くことがもっともアジャイルなんでしょうかね。