『エクストリームプログラミング』の感想

みなさんこんにちは、小畑です。

『エクストリームプログラミング』を読んだ感想を書きます。

全体の感想としては、肯定的です。可能な範囲で、本書のプラクティスをすぐに実践したいと考えています。

ただ、一人のSESエンジニアとしては実践できることには限界があるのも事実です。

次回、開発初期段階のプロジェクトにアサインする時のために、今読めて良かった一冊だと思っています。そして、まだまだソフトウェア開発の歴史について知らないことが多く、これからの改善活動に役立つ情報を深堀していきたいと、モチベーションが高まりました。

関連ワード：アジャイル、スクラム、ケント＝ベック

実現可能性について

この本で書かれていることは、一人のプログラマーが即座に実行できることもあるとともに、チームとして実現できることについても多数書かれています。

例えばペアプログラミングは一人でするものではないけれど、誰かにペアプログラミングを提案してみることはできるかもしれません。

ウォーターフォール開発で進めている仕事にアサインされたとしても、テストファースト思考を頭に入れながらプログラミングはすることができるし、次の単体試験フェーズを意識しながら作業することも一人で実現できることだと思います。もちろんウォーターフォール開発案件をアジャイル開発に切り替えることは一人ではできませんが。

もちろん開発の初期段階にアサインする機会があれば、『エクストリームプログラミング』について熱弁することは十分可能です。テストファーストで開発を進めることが初期段階からチーム全体で共有できていれば、その後の継続的インテグレーションも実現可能な確率が高まります。

私のプログラミング経験の中では、大きくレガシーな案件ほど実現可能性は低くなる傾向にあると考えていますが、それは日本国内においてはウォーターフォール開発がまだまだ根強いことや、プロジェクトを管理する立場と製造する側での大きな壁があることが原因の一つであると思います。

エクストリームプログラミングの批判的な意見の多くは、プロジェクトを管理する立場からのものが多いように想像しています。というのも、開発期間を延ばすことを推奨する内容については賛成できるところが多いのですが、それはプログラマにとってであり、ステークホルダーからの理解が得られる可能性は低いように思います。

反対にモダンで先進的な取り組みを行っているプロジェクトでは、エクストリームプログラミングの思想が自然と根付いていることもあります。

これはプログラマにとって、とても素晴らしいアイデアが詰まっており、一度でも実践し良い成果に結びつく体験ができれば、次回も同じストレスのない開発環境を構築するべきだと考えるのは当たり前のことかもしれませんね。

ただ本書でも書かれている通り、常に高い意識レベルでの改善活動が必要なため、人の入れ替わりが激しい現場では、当初構築されたストレスのない環境でも、次第に良くない環境へと変わっていってしまうこともあるので注意が必要だと感じています。

日本とアメリカの違いについて

私はアメリカの開発環境に憧れがあるので、個人的でちょっと偏っていると思われる情報についても触れておきます。

それと本書の中盤ではアメリカのプログラマーに向けて、無駄ばかりで不必要なソフトウェアを量産しており、これを改善するためには、利用者との対話が必要だということも書かれています。

つまりは、私は日本とアメリカのソフトウェア開発文化には大きな違いがあるということを感じています。

たまたまニューヨークに住んでいるアメリカ人の友達ができたので、その友人からアメリカのソフトウェア開発事情について教えてもらいましたが、そこでも大きな違いを感じています。

まず大きな違いは、プログラマはプロジェクトマネジャーの下で働いているようなイメージではないことと、プロジェクトにアサインされてユニットテストが存在しないプロジェクトはなかったというところです。

私の感覚的にはユニットテストがあるプロジェクトのほうが少ない感覚でした。

ユニットテストがあるプロジェクトに当たればラッキーだ！くらいに考えていたのですが、ユニットテストを書くことは常識で、テストの内プロジェクトはありえないというレベルに私は受け取りました。

確かに本書が書かれたのは2015年で、それよりももっと前にオブジェクト指向はあったようですし、それにともなってテスト駆動開発の認識も高まっていたことを考えると、数十年前からテストファーストな思想があったのにも関わらず、テストを作らないプロジェクトが多いのはなぜなのか、とても疑問です。

日本のものづくりのレベルは上がっていないとよく耳にしますが、まさにソフトウェア開発においてもアメリカから比べるととても低いレベルで止まっているのかもしれないと感じました。

それはある意味ビジネスチャンスで、周りが取り入れられていない素晴らしい技術が目の前に転がってきたようなものです。これを使わない手はありませんね。

これまでの開発経験と紐づいた

この本で一番の収穫だったのが、単にウォーターフォールとアジャイルとざっくりと区別していたものをより解像度高くこれらを区別できるようになりました。

これによって、はっきりとこれはレガシーなウォーターフォール。こっちはモダン（モダンと言っても数十年前からある技術）なアジャイル。と認識できるようになりました。

さらには、アジャイルで進めている時に、「最初は週次デプロイだったのに最近はデプロイに時間がかかっているけど、これは良くないような気がする。。。」と感覚的だったものに対してハッキリと、「このままじゃダメだ！」と考えられるようになったと思います。

改善活動の方向性がはっきりと見え、自身をもって先に進められるようになったと感じています。

全てを一度に実施することはとても難しいことなので、まずは自分が一人でもできることから始め、それが少しずつ誰かに伝わり、可能であれば文化として波及していけるように努めていきます。

関連書籍：『オブジェクト指向でなぜつくるのか』