アジャイル勉強会なんかをやってみました

社内でアジャイル勉強会なんかをやってみました。

まあ実践したことがあるのはテスト駆動開発と計画法少しくらいで、
大体は本を何冊か読んだことをまとめただけですが。
何冊か読んだことを俯瞰して書いたあたりが良かったですかね。

とりあえず評価は良かったらしいです。

せっかく業務外作業として行ったので、
ブログにも資料公開してみます。

貼り付けられるかと思ったらできなかったのでリンクで。
本音で考えるアジャイル講座

「リーン開発の本質」を読んで

アジャイル開発手法の一つ、リーン開発を解説した本。
日本とのトヨタ式生産方式をもとにしてあるそうで。
有名なムリ・ムラ・ムダを省くかをプログラム開発にあてはめたものになります。

日本の工場の方式をもとにしているだけあって。
規律を重視するなど、XPなんかの自由な感じとは雰囲気が違います。

しかしよく見てみると、XPとかと共通なことがかなり書いてある。
単に宣伝する想定対象が違っているということなのですかね。
実際、XPの人たちとはお互い認め合っているようです。

XPのように楽しさを重視しない分、ちょっとつまらなそうですが。
的確に無駄を省いていくという分、まじめに考える人にはかえって評判がいいかもしれませんね。

従来の管理手法からアジャイルに直接行くより、
トヨタ方式経由でリーンを学んだほうが、
雰囲気もあってますし移行しやすいでしょう。

日本人にはこっちのほうが向いているかもしれませんね。

「Smalltalkで学ぶオブジェクト指向プログラミングの本質」を読んで

オブジェクト指向そのものと、それを実現する言語Smalltalkを作り出したアラン・ケイの言葉に、
「オブジェクト指向(Object-Oriented)という言葉は私が作った。そのとき、C++ を想定していなかったことは確かだ」
というものがあります。

つまり、C++や、そのオブジェクト指向を受けついたC#やJavaにはない本質的な要素を、
Smalltalkは持っているということになります。

また、最近はやりのObjective-CなんかはSmalltalkの直系の言語であるため、
その要素を理解しなければ理解しきれないでしょう。

なので。
Smalltalkの本質を書いた本を読んでみたいと思っていたため、
この本を買って読んでみました。

最初の２０ページにきっちり書いてありました。
なるほど。
世の中のものはすべてオブジェクトだというからには、
世の中のものすべてとは何か、という哲学的な話から始めなくてはならないのですねえ。
３０年前からこういう心掛けでやってきたからこそ、
Smalltalkはオブジェクト指向プログラミングを引っ張ってくることができたのですね。
C++は使っている人は多いですが、あまり全体を引っ張ってはいないようですし。

と、最初の２０ページは大変素晴らしかったのですが。
その後は今一つ。

どうも最初の２０ページは書いている人が違うっぽいのですが。
本体部分をほとんど書いている人はSmalltalkに精通したプログラマーで、
最初の部分はその弟子が書いたという感じらしい。

メインで書いているのはマニアックなプログラマーらしく、
なんか低レベルなハードウェアに近い部分にこだわって書いていますし。

最後のほうになぞ、言語のセマンティクスについて、
自分は実装の中身を見たからこちらのほうが良いとか書いてありました。
実装方法に依存して呼び方を変えるというのは、
Smalltalkの理想に照らし合わせてどうなのでしょうか。

低レベルな部分にこだわるのは情報隠ぺいができてないという点を考えると、
Smalltalkの説明としてはあまりよろしくないような。

他Smalltalkの優れているところについていろいろ書いているのですが、
あまり客観的な根拠になっていない部分が多い。
根拠のない自慢としか受け取られない文章になっています。

まあ日頃Smalltalkが認められないことに対するうっぷんがたまっているのかもしれませんけどね。
どういう事情があれそれを文面に出してしまうと、書籍としては質は下がりますね。

Smalltalkが30年前に言語としてこういうことが実現できていたのは確かにすごいのですが、
内容を見たところ、これだらすでに良い部分は大体はほかの言語に取り入れられてしまっています。
Smalltalkが、ほかの言語の良いところなんか存在するわけがない、
と何も取り入れないのであるならば、これから学ぶ価値はなさそうです。

それがSmalltalkの性質なのか、この本の性質なのかは何とも言えませんけれど。


とはいえまあ。
文章の端々に、思想が感じられる部分は多々あり。
日ごろからこの人の薫陶を受けている弟子が、
もうちょっと一般受けしやすいようにまとめたのが、
最初の２０ページなのかもしれませんけれど。

最初の２０ページは結構素晴らしかったですが。
それ以外は、ほかの参考書読んだほうがいいかもしれませんね。
技術力があるだけでは良い本は書けない、ということの見本になっているかもしれません。

「間違いだらけのソフトウェアアーキテクト」を読んで

内容的には、アーキテクチャの基礎知識について、ざっとまとめた本です。

どちらかというと堅実な内容ですね。
アジャイルとか新しいことについてはある程度は取り入れようとしつつも、
盲信する輩の言うことについては眉に唾をつけて聞いている感じです。

基本的なことが手堅くまとまっていてよいのではないですかね。
現場を見てきた人間にしかわからないような素の意見も混ざっていて、
それなりに役に立ちます。

内容的にはそんなものなのですけれど、
この本を特徴づけているのはその文章です。
アーキテクチャに関する架空の講義を、
会話形式で書いてあります。

内容は漫画的といおうか。
まあギャグを交えて面白く書いてあります。
聴衆には無能な管理職とかアジャイル教の教祖とか出てきてまして、
本音を書きやすい構成にもなっています。

技術書は読みにくく書くことで価値が高まる、
と信じているかのような技術書が多い中、こういう姿勢は評価できますね。

CP

Windows8のCP版が出たのでインストールしてみました。
日本語版もきっちりと出ているようですねえ。

なんか普通に使えそうなので普通に使ってみようと思います。

DPでは荒削りなところもありましたが、
きっちり実用レベルでMetroがものになっていますね。

「プログラマが知るべき97のこと」を読んで

優秀なプログラマーが、大切だと思っていることをが、97+10ほどのっている本。日本語化に際して、日本人のものを10追加したようです。

一つ当たりだいたい２ページ程度。これを一人１～３個ほど書いてあります。
一つ一つは短く、また何十人もで書いているので、内容はバラバラなのですが、
これがなかなか素晴らしい本に出来上がっています。

自分が特に大事に思っていることを１～３個、２ページずつ書けと言われたら。
その人が本当に本当に大事だと思っていることのみが書かれることになります。

実際、非常に大事だと思われること、大変役に立つ提言が目白押しです。
低レベルから高レベルまでのプログラム技術や、
アジャイルなどの開発手法、チーム内での人間関係まで。
それも単純な提言ではなく、奥が深いものばかりです。

一度は読んでおくべき本ですね。

「More Joel on Software」を読んで

「Joel on Software」の続編。
これも数年ぶりに読み返してみました。

相変わらず、プログラムから販売戦略から会社経営まで、
論理的でわかりやすい話がたくさん載っています。

ただ、プログラムについて言えば、
ちょっと論旨に強引なところが見えるような。
プログラムから遠ざかって、頑固になってきたのか、
それとも紛糾しないような議論は使い果たしてしまったのでしょうか。

たとえば、
例外機構で確実に実行されないかどうかの話をするのに、
finallyの話を置いておくというのは、
著者の頭の中には理屈があるのかもしれませんが、
少なくとも読んでいる方にはまったく意味が分からないのですが。

販売戦略などの話については、
前作にもましてためになる話となっております。
クーポンなどの値引きの本当の意味とか、
まったく目からうろこが落ちる思いですね。

「Joel on Software」を読んで

人気ブログの書籍化。
数年ぶりに読み返してみました。

著者は非常に優秀なプログラマーにして、経営的な思考も得意という人間らしいです。
そのため、技術的な解説が論理的で技術者にわかりやすいのはもちろんのこと、
採用戦略や販売戦略も論理的に分かりやすく解説してあり、
大変ためになります。

しかし、この本の最大の魅力は、
論理的だったりためになったりすることよりむしろ、
そのユーモアにあふれた文体でしょう。
翻訳も大変うまく、その辺の雰囲気を再現しているようです。
読んでいて大変面白く、気軽に読むことができます。

作者はプログラマーとしてのキャリアをマイクロソフトで始めたそうです。
大卒でマイクロソフトに入って、いきなりVBAの仕様書を書きあげたとか。
なので、方法論はマイクロソフトから学んだものが多く、マイクロソフト的ではあります。

マイクロソフトはあちこちで悪く言う人がいますが、
少なくともあそこと同じだけの開発力を持つ会社がほとんどないのは、確かでしょう。

ただしその方法論が、最近流行のアジャイルなどと比較して、
官僚的に思える部分があることも確かで、その辺で引っ掛かる部分もあります。

ただ、そういうものを採用する条件などが論理的にちゃんと示されていることが多いので、
きちんと読んでいれば、安心して読み進めることができます。

たとえば、数十カ国のさまざまな環境で何万人もの人が使うパッケージソフト開発では、
テスト駆動開発による回帰テストでは全然足りなすぎる、という主張がなされていますが。
その状況下では確かにそうでしょう。

また、膨大な仕様書を書くことを推奨していることも、最近は一見古臭いように見えますが。

著者が書くべきと言っている仕様書は、
コードと不一致があることが絶対にないよう常に完璧にメンテナンスがされ、
その上誰も読まないということには絶対にならないよう、
ジョークも交え雑誌のように面白く読みやすい仕様書、
という条件を満たすものであるようです。

大卒で入社していきなりVBAの仕様書５００ページを完璧に書き上げ、
さらに人気ブロガーとして大活躍をしているような人が社長をやっていて、
その上採用に惜しみなくお金を使っている会社であるなら、
その条件を満たすための人材は集まっているのでしょう。
その状態なら、確かに仕様書は大変役に立ち、書く価値のあるものです。

ただ、もしそういう会社ではなく、条件を満たすことができないのなら。
別の対策を打つ必要があるでしょうね。アジャイルとか。

ということなので、一見古くて官僚主義的でマイクロソフト的に見えることでも、
著者はちゃんとそれを考慮した上で論理的に勧めているので安心です。

大変わかりやすくためになる本です。
一度は読んでおくべきですね。

「Gitによるバージョン管理」を読んで

私はそもそもCUIそのものに慣れていないので、この本の対象読者ではないのかもしれませんが。
ちょっと難しく感じましたね。

全体的に、まず実際の業務を想定して物語式に操作を説明してから、
機能の本格的な説明に入るという構成なのですが。

どういう状況で扱うかもわからないのに機能を説明しても意味がない、ということなのでしょうけど、
機能説明で初めて用語の意味が分かるようになっているので。
結局、何をやっているのかよくわからないということに。
物語部分でもうちょっと何をやっているかの説明もいるんじゃないでしょうかねえ。

とはいえ、そういっているうちにGitの基本的な使い方の流れは何とかわかるようになってきました。
これで実際に使ってみれば、やり方がわかるものなのかもしれません。