16
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

寒くなってきましたねー。
気がつけばもう12月10日です。
何書こうかと悩み途中まで書いたものの収集がつかなくなって急に方向転換してこの記事を書いていますw

30代半ば頃の私は、プロジェクトマネージメントの仕事が多くなってきており、周りではまだアジャイルという開発手法を実践的に行っている現場が少なく、色々を書籍を漁っていました。
当時、業務委託で来てもらっていたエンジニアに教えてもらったXPを読んだ時は衝撃を受けたのを覚えています。
そこから、海外筆者中心で色々と読んでおり、未だに影響を受けている本を紹介したいと思います。

XP(エクストリームプログラミング)

完全に私のバイブルです。

ただ、前職で色々なな人読め読めと勧めた結果、所在がわからなくなってしまった一冊で、今は手元にありません…涙
今でも読みたい本なので、まだ前職にいる人に探してもらおうと思います(なかったら買うかな)。

XPとは Extreme Programmingの事です。
直訳すると「行き過ぎたプログラミング」とか「極端なプログラミング」になりますねw
よく、 Extreme Programmingは、「開発手法の一つ」と言われがちなのですが、そうではないです。
これはあくまで、アジャイルに則った形の、極端な手法を書いてあるだけです。
そのため、本質としては、「ある問題に対して、こうやって極端にやれば解決できちゃんじゃないの?」という感じです。

わかりやすいのがペアプロで、これはレビューの時間がもったいないから「You, レビューしながらプログラミングしちゃいなよ」という感じですw
アジャイルの原則である「動く=価値のあるソフトウェアを早く継続的に提供する」に則っています。

結局、何が言いたいかというと、本書にあるプラクティスはある問題についての解決策の案でしかないこと。
だから、「銀の弾丸はない=全てに効く薬はない」と何回も言っていて、それをただ実施すればいいということではありません。
起きてる課題に対して、置かれている環境や文化の中で取捨選択を行い、その場にあった解決策を考えるということです。

この本の初版がでた際、「銀の弾丸」と思われることが多く、それぞれが持つ開発文化とミスマッチの中、この本を参考に実践しようとして挫折する人が多くいましたw
その為、否定されることも多かったのですが、初版ではこれはあくまで究極論であり、解決したかったのはこういうことだ、というのを第2版で語られています。

細かい言葉までは覚えていませんが、すごく印象的だったのが、「アジャイルが当たり前になってアジャイルという言葉が世の中からなくなればいい」的な事が書かれています。
今、メタップスでやっている事は、アジャイルの原則を元にプロダクトを作っており、それを実践している若いメンバーがアジャイルという言葉知らないということ、、、少し感動的です。
ケント・ベックさん、そういう世の中になってきましたよ。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

この本は2018年に出ているので、比較的最近ですね。
(若干どうでもいい話だけど、googlebooksでは2017年に出ていることになっているけど、本には初版は2018って書いてある!)

著者であるロバート・C・マーチンさんは、アジャイルの提唱者の一人であり、すごく有名。
多分日本版だけのサブタイトルで「アーキテクチャのルールはどれも同じである!」とありますが、そのとおりかなと思っています。
インプットがあり、データがあり、ビジネスロジックがあり、アウトプットがある流れをよりレイヤーを細分化し役割を明確にすることで、クリーンなアーキテクチャができあがる(そのまま)って話。
結構、ボイラープレートコードができるので、少しコード量(というかファイル量)が増えるので、少しなれが必要な気がするけど、kotlinでClean Architectureに則って実装した時にはめちゃくちゃスッキリ書けたのを覚えてます。
今でも、別言語での別フレームワークを使って、ソフトウェアのアーキテクチャに悩んだ時は、これを思い出して、考えたりしています。

エリック・エヴァンスのドメイン駆動設計

前述のClean Architectureと親和性の高い設計手法DDDの本。
ソフトウェアの設計は「ビジネス層に対してどうアプローチをするか」という話で様々なアプローチ方法があります。
このDDDはその根幹であるビジネス=ドメインを軸に設計をブレイクダウンしていく手法等。
複雑になるシステムを、「どう整理して設計していくか」です。
Clean Architectureと親和性の高いというのは、そのブレイクダウンしていく過程で細分化されたものの構造が、Clean Architectureのプログラム構造とよく似ているから。
あまりDDDを知らないときから、無意識にドメインというものを意識して設計していたけど、この本を読んだ時、それを言語化された感じしっくりきたのを覚えてます。
知らないで似たような事を実践している人は多いと思います。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

これも結構印象的でした。
筆者が実際に経験したプロジェクトを元に、問題とどうやって解決していったかが書かれている。
これも、前職で誰かに貸して戻ってきないやつ…。
内容は覚えていたけど、タイトル忘れたから必死にググりましたw
この手の、スクラムとかカンバンとか書かれている本は、プラクティスの説明が多く、実践としての話ではないので面白くないが
この本は、「なるほどねー」と面白く読めた。

まとめ

これ以外にも本は読んでいますが、結局はあくまで「知識」でしかない。
「開発のやり方」を教えてくれるわけではなく、「開発に対する考え方」を教えてくれていると思って読んだ方がいいと思っています。
本の通りにやったからといって、プロジェクトが成功するわけではなく、その環境によって課題や解決策が違うということ。
だから、こういった本を読むことで知識を増やし、問題に対してその場にあった解決を行うことだと思っています。
今年も、残り僅か!楽しんで開発をしましょう!

16
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?