【書評】「レガシーコードからの脱却」の9つのプラクティスは圧倒的に正しい（経験者談）

はじめに

株式会社アトラクタの原田騎郎さん（@haradakiro）から、書籍「レガシーコードからの脱却」をご恵贈いただきました。（どうもありがとうございます！）

せっかくいただいた本なので、本書を読んだ僕の感想を書いてみようと思います。

どんな本なの？

端的に言うと、「初めからレガシーコードを作りださないための9つのプラクティスを説明した本」となります。

最初にタイトルを見たときの印象は「今そこにあるレガシーコードを、どうやってイケてるコードに書き直していくのか？」を説明した本なのかなと思ったんですが、本書が主眼としているのは「そもそもレガシーコードを作らないこと」でした。

ですので、「レガシーコード改善ガイド」とは毛色が違う本だと考えた方が良さそうです。
（「レガシーコード改善ガイド」は、「今そこにあるレガシーコードを改善する方法」を解説した本です）

レガシーコード改善ガイド (Object Oriented SELECTION)

ちなみに、原著のタイトルは "Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software"です。

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

本書におけるレガシーコードの定義

「レガシーコードって何？」という人のために簡単に説明しておくと、本書におけるレガシーコードとは「修正や拡張、作業が難しいコード」（訳者まえがきより抜粋）のことです。

ポジティブかネガティブかでいうと、明らかにネガティブな意味です。
「弊社にはレガシーコードがたくさんあります」とのたまう人がいたら、その会社はちょっと大変な状況であることが疑われるので注意しましょう。

本書が提示する9つのプラクティス

本書は「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」として、以下のプラクティスを掲げています。

1. やり方より先に目的、理由、誰のためかを伝える
2. 小さなバッチで作る
3. 継続的に統合する
4. 協力しあう
5. 「CLEAN」コードを作る
6. まずテストを書く
7. テストでふるまいを明示する
8. 設計は最後に行う
9. レガシーコードをリファクタリングする

それぞれの具体的な内容についてはここには書きません。
本書を購入してご自身でチェックしてみてください😉

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

正直に言うと、あまり目新しい内容はなかった・・・が！

さて、ここから下は僕の感想です。

本書をひと通り読んだあとの感想は、「うーん、あまり目新しい内容はなかったな🤔」でした。

ネガティブですよね？disってるように聞こえますよね？？

いや、でも違うんです！

なんで目新しい内容がなかったのかというと、この本に書かれているほぼすべてのプラクティスが今僕が勤めているソニックガーデンで実践できていたからです。
そして、ソニックガーデンにはレガシーコードがありません。
かれこれソニックガーデンで7〜8年働いてきましたが、「うわー、これはないわー。まさにレガシーコードだわー」と思ったことは一度もないのです。

反対に、僕が以前勤めていた前職や前々職の会社では「勘弁してくれよ〜、まったく！」とうんざりするようなレガシーコードを何度も見てきました。
そうした職場では本書に書かれているプラクティスがほとんど実践されていませんでした。

このことから何が言えるのか？

これはつまり、「本書に書かれている内容は圧倒的に正しい」ということです。

本書で紹介されている9つのプラクティスを実践していけば、確実にレガシーコードから脱却できます。
これは僕自身の経験と照らし合わせて断言することができます。

では、どうやって実践するのか？（要検討）

本書に書かれている内容が正しいことはわかりました。
でも、もしこのブログを読んでいるみなさんが、「今の職場では全然実践できていない！なんとかしたい！」と思ったときはどうすればいいのでしょうか？

残念ながら、その答えは本書には載っていません。（もし僕が見落としているだけだったらすいません💧）

僕もSIerで働いていた経験があるので予想が付くのですが、「ウォーターフォール型かつ、多重下請けかつ、納品型の受託開発」をやっていたりすると、ビジネスモデル上の制約や会社の力関係等があるために、こうしたプラクティスを一（いち）開発者の意見で導入するのはほぼ不可能だと思います。

また、そうした開発スタイルではなくても、同僚にあまり向上心がなかったり、上司がまったく理解してくれなかったりすると、自分のやる気だけが空回りして疲弊することもよくあります。（こちらも経験あり）

じゃあ、僕自身はどうしたのかというと、今の職場を変えることは諦めて転職しました。
その転職先が今僕が働いているソニックガーデンです。
前述の通り、ソニックガーデンに入ってからは本書に書かれているような理想的な環境を手に入れることができたので、僕にとっては「転職する」という選択肢は正解だったと思います。

では、みなさんだったらどうしますか？
これはみなさん自身の宿題なので、自分の頭でよ〜く考えてみてください。

「9つのプラクティス」は転職活動するときにも役立つかもしれない

もしあなたがよりよい環境を求めて転職しようと思った場合は、本書の「9つのプラクティス」が役に立つかもしれません。
なぜなら、面接官から「何か質問はありませんか？」と聞かれたときに、9つのプラクティスで書かれていることをベースに「◯◯はどうされていますか？」とか「◯◯は実践されていますか？」と尋ねれば、その現場のレガシーコード具合が予測できそうだからです。

これから転職しようとしている方は、本書を読んで質問リストをあらかじめ作っておきましょう👍

その他の感想：翻訳が非常に読みやすい！（重要）

本書の内容とは直接関係がありませんが、本書を読んでいる最中、僕は翻訳が非常に読みやすいところに密かに感銘を受けていました。

訳書ってたまに翻訳がめちゃくちゃ読みづらいことがあるんですよね。
過去に読んだ訳書の中には、いくら翻訳を読んでも内容が頭に入ってこないので、「もはや原著を買って英語で読んだ方が良いのでは？」と思ったものもあります。

その一方で、僕自身が英語の技術書を日本語訳したことがあります。
（「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍です ↓ ）
leanpub.com

実際に翻訳をやってみると、これがめちゃくちゃ難しいんですよね〜。
英文の構造や言い回しって、日本語と大きく異なる部分が多々あるので、素直に翻訳すればするほど「読みにくい日本語」が量産されていくんです。
Everyday Railsの翻訳をするときも「翻訳臭」を消すのにすごく苦労しました。

そういった「読む側」と「翻訳する側」の両方の経験がある僕からすると、本書「レガシーコードからの脱却」の翻訳は非常に高レベルだと思います。
訳書臭がまったくしないので、すらすら読むことができました。

なので、本書を読むときはそういった翻訳の自然さ、滑らかさにも注目して読んでみてください！

まとめ

というわけで、このエントリでは書籍「レガシーコードからの脱却」の書評を書いてみました。
本書の感想は次のように大きく２つに分かれると思います。

まず、僕のように、本書を読んで「あまり新しいことが載ってないなー」と思ったそこのあなた！
あなたはきっと幸せな環境で開発ができている人です。（良かったですね😄）

反対に「へー、こんなやり方があるのか」とか「これは実践できてないな」と思ったそこのあなた！
あなたは今から何かアクションを起こすときなのかもしれません。

自分が置かれている状況を判定する「リトマス紙」として、ぜひ「レガシーコードからの脱却」を読んでみてください。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

あわせて読みたい

我田引水になってしまいますが、弊社ソニックガーデンの働き方を紹介した本がいくつか発売されています。
ソニックガーデンは受託開発をやっているのに、なぜレガシーコードが生まれないのか？
その答えを知りたい方はこちらの書籍も読んでみてください。

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

リモートチームでうまくいく

「納品」をなくせばうまくいく

Rubyプログラマが何を考え、どうやってコードを書くのか、その過程を動画にしてみました

はじめに：銀座Rails #12で登壇させてもらいました

去る2019年8月29日、銀座Rails #12で「プログラマがコードを書きながら考えること 」という発表をさせてもらいました。

ginza-rails.connpass.com

この発表では「プログラマが書き上げたコード（＝完成形）」ではなく、「そのコードをどうやって書いたのか？（＝何を考え、どんなツールやテクニックを使って、どれくらいのスピードで書いたのかという点、すなわち、コードを書く過程）」をテーマにしました。

そして、その過程をわかりやすく伝えるために、スライドだけでなく、僕がガチンコでコードを書いていく様子を動画コンテンツとして会場のみなさんにお見せしました。
これまでいろんな勉強会やイベントで発表してきましたが、動画を事前に用意して発表で使ったのはこれが初めてです。

初めての試みなので、どうなるかちょっと不安でしたが、意外と好評だったようでほっとしました。

伊藤さん(@jnchito)のコーディング実演中 (動画)

作りたい機能をこれだけサクサクコーディングできたら面白そう！というイメージが湧いてモチベーション爆上がりです😆#ginzarails

— こうだい＠Ruby on Rails勉強中 (@kodai_0122) August 29, 2019

流石、Rubymine 使いこなしてるな〜。terminalが一回も出てこん。 #ginzarails

— Yuki Minamiya(南谷 祐貴) (@yuki3738) August 29, 2019

手で確認は面倒くさいからテストコードを書く
これは習慣化していきたい。よく最後にテストコード書くので
#ginzarails

— okabeeeat (@okabeeeat) August 29, 2019

みなさんのツイートのまとめはこちらにあります。
togetter.com

また、当日使ったスライドはこちらに置いています。

動画はBOOTHで販売してみることにしました

しかし、今回の発表のメインは動画だったので、スライドだけ見てもあまり役に立ちません。
じゃあどうやって動画を公開しようかな〜？と、いろいろ検討した結果、今回はBOOTHを使って有料販売してみることにしました。

当日使用した動画は以下のページにて490円で販売しています。

jnito.booth.pm

無料のお試し版動画もあります

とはいえ、どんなものかよくわからないものにお金を払うのもみなさん不安だと思うので、無料のお試し動画も作りました。
以下のYouTube動画はBOOTHで販売している動画の前半部分を無料で公開したものです。

【お試し版】プログラマがコードを書きながら考えること 〜動画でわかるWebクローラー開発〜

このお試し動画を見て「続きを見たい！」と思った方は、ぜひBOOTHの購入ページに進んでやってください🙏

なんで有料販売にしたの？

動画を有料販売にした理由はいくつかあります。

編集作業が思っていた以上に大変だったから

動画を撮る前は「スライドを作るより、動画をぱっと撮ってぱっと見せる方がラクなのでは？」と想像していました。
ですが、実際にやってみると、発表時間内に収めるために動画を切り貼りしたり、わかりやすく伝えるためにキャプションを付けたり、なんだかんだでめちゃくちゃ時間がかかってしまいました。

iMovieでがんばって編集してました

なので、「これだけ手間ひまかけて作ったものを無料で公開するのはちょっともったいないな」と思ったのが理由のひとつです。

YouTubeの広告は質が悪い（と僕は思う）から

制作コストを回収するのであれば、広告付きのYouTube動画として公開する（＝再生回数上げて収益を得る）、という手も考えられます。
ですが、YouTubeの広告を見ていると、なんか詐欺まがいの怪しい広告をときどき見かけます。

もし、僕の動画を見た人がそういう広告に引っかかって「脳のドーピング剤」みたいなよくわからない商品を買ってしまったら僕は悲しいです。
いや、そんなものに実際に手を出す人は滅多にいないと思います。
ですが、そういう可能性がゼロではない、というのが僕の中ですごく気持ち悪いんです。

それに、そもそもYouTube広告の99.9%が自分にとって興味がない、邪魔なモノでしかない、というのもYouTube広告を避けたい理由のひとつです。
たぶん、ほとんどの人がYouTubeの広告はなくせるものならなくしたいと思っているのではないでしょうか？（なので、僕はYouTube Premiumに入って広告を出さないようにしました）

こうした理由から、YouTubeで間接的にお金をもらうよりも、僕の動画を見たいと思っている人から直接お金をいただく方が健全ではないかと考えました。
（注：これはあくまで僕自身の考え、ポリシーであって、YouTubeでお金を稼いでいる世の人々を否定するものではないので、念のため）

単純に試してみたかったから

あとは単純に、有料販売したらどれくらいの人が購入してくれるのか試してみたかったから、という理由もあります。

世間には書籍やWeb記事、YouTube動画など、プログラミングを学習するための情報がたくさんあります。
ですが、今回のように「他の誰かがガチンコでコードを書く様子を収めたコンテンツ」はほとんど見かけません。

こういったコンテンツは珍しいですし、他のプログラマの方（特に初心者さん）にとって非常に参考になるはず、と僕は信じています。
そこに対価を払ってくれる人がどれくらいいるのか見てみたい、というのも理由のひとつです。

カッコいいところだけでなく、カッコ悪いところも見せる勇気

ところで、今回の動画はべつに「俺様のプログラミング能力のスゴさを見よ！！」と自慢するために作ったわけではありません。
気持ちとしてはむしろ逆で、こんな動画を作って見せたら、みんなから「なーんだ、伊藤さんっていつもネットで偉そうなこと書いてるけど、全然大したことないやーん🤣」とバカにされるかもしれない、と心配していました。

それでも「動画にして見せる価値があるかも」と思ったのは、以下の2つの記事を読んだからです。

• 2018年の段階で私が知らないこと — Overreacted
• プログラマーの方に質問です。正直、1日8時間も集中力続かなくないですか？ - Quora

前者はReact界の有名エンジニアであるDan Abramov氏が「私はこんなこと（＝技術関連の知識）を知らない」と、「自分の知らないことリスト」を公表した記事です。

また、後者の記事ではRubyのパパことMatz氏がご自身の集中力について「私は普段だと集中力は１５分くらいしか持ちません」と公言しています。

これらの記事を読んで僕は非常に救われたというか、「すごい人はどこを切り取っても全部すごいわけじゃないんだな。まあ、そうだよな」と安堵しました。
そして、自分のすごくないところを堂々と言えるところが逆にすごいと思いました。

Matzさんのようなスーパープログラマと僕を同列に並べるのはおこがましいですが、それでも「自分のすごくないところもおおっぴらにできる勇気」みたいなところは僕も見習いたいなと思いました。

こうした思いもあって、自分がハマったり迷ったり間違ったりするところも全部動画に撮って公開してみようと考えたのでした。

まとめ

というわけで、このエントリでは銀座Railsで僕が発表した内容と、そのときに使った動画の販売ページをお知らせしました。

「伊藤さんは普段どんなことを考えて、どんなふうにコードを書いているのかなー？」と興味を持っている方がいたら、ぜひこの動画を購入して見てやってください！

【動画】プログラマがコードを書きながら考えること 〜動画でわかるWebクローラー開発〜 - 伊藤淳一 @ BOOTH - BOOTH

おまけ

ちなみに、BOOTHには「ブースト」という機能があって、これを使うと購入金額を上乗せすることができます。

BOOST↑（ブースト）機能とは何ですか？ – BOOTHヘルプセンター｜よくある質問

画像の引用元: https://booth.pixiv.help/hc/ja/articles/230690927

この機能を使って金額を上乗せしてもらえると僕が非常に喜びますので、もしよかったらよろしくお願いします😆（もちろん強制ではありません！）

あわせて読みたい：銀座Rails #12の参加レポート

銀座Rails #12に参加したみなさんが書かれた参加レポート（または開催レポート）です。（みなさん、どうもありがとうございます！）
僕の発表に関する感想もあるので、動画の内容が気になる方はこちらも参考にどうぞ。

• 銀座Rails#12@DeNA行ってきました。 - Qiita
• 銀座Railsに参加した - tanaken’s blog
• 銀座Rails#12@DeNA に参加しました。 - yrinda
• #ginzarails 「プログラマがコードを書きながら考えること 」by jnchitoさんの観察ログ - 渡り鳥の旅路
• 【イベントレポート】銀座Rails#12@DeNA - bagelee（ベーグリー）
• 銀座Rails#12@DeNAに参加しました - よしにゃんのお部屋
• 銀座Rails#12を開催しました - とにかく何か書く

声をかけてくださった銀座Railsの河野さん、スポンサーのDeNAさま、リンクアンドモチベーションさま、どうもありがとうございました！

【ポエム】ギターレッスンを受けてあらためて音楽の奥深さと面白さを実感した話

昨日は久々にギタリストの山口和也さん（@kkkzzzyyy）のギターレッスンを受けてきました。
受講したのは3時間集中コースだったんですが、例によってあっという間に3時間が過ぎていきました。

山口さんに模範演奏してもらってる写真です

今回のレッスンは演奏よりも音楽理論（と、それに関連するギターのコードフォーム等）の話がメインでした。

今まで「自称・楽器好き＆音楽好き」でやってきましたが、3時間のレッスンを通じて音楽理論に対する自分の理解がいかに狭くて浅かったか、そしていかに適当にやってきたのかを痛感しました。
いや、痛感というと苦しみの成分が多いように聞こえてしまいますが、実際は「そんな理屈になってたは全然知らんかった！へ〜、めっちゃ面白い！！」と、今まで知らなかった知識をたくさん知ることができて嬉しかった、と言う方が正しいです。

何事も学ぶことは楽しいですね。音楽にしてもプログラミングにしても。
ただ、新しい知識が多すぎて、最後の方は脳みそがクタクタになりましたが（苦笑）。

僕は「昔ミュージシャンを目指してた」ってよく言ってますが、こういう知識はあの当時（約20年前）に身に付けておきたかったです。ほんとに。
あの頃の僕にこういう知識があったら作曲やアレンジの幅が全然違ってただろうな〜と、つくづく思いました。

僕はプログラマとしては「そこそこ」に成長してきた感がありますが、それに比べたら音楽理論やギタープレイに関してはまだまだ知らないこと・できないことが山ほどあります。
でも、前向きに捉えるなら「俺、めっちゃ伸びしろあるやん！」ということなので、ちょっとずつ時間をかけてこの伸びしろを埋めていくのも楽しそうです。

僕がプログラミングにかけてきた時間と同じぐらい音楽に時間をかけたら、たぶん10年後にはプログラミングスキルと同じように「そこそこ成長した」と思えるようになるのかも？
まあプログラミングは仕事で音楽は趣味なので同じペースで時間をかけるのは無理ですけどね。

とはいえ、「昨日より成長している自分をまだまだ追求できる」ということは、「この先もまだまだ人生の楽しみがたくさん残っている」ということなので、非常に良いことなんだと思います。まる。

参考書籍

昨日のレッスンで使った山口さん執筆の教則本です。
これらの本をベースにして、ちょっと複雑なジャズ系のコードについて学びました。

イントロからエンディングまで! 完奏方式で完全制覇! “使える"ジャズ・ギター (CD2枚付) (リットーミュージック・ムック)

パワー・コードから前進! ブルースで覚える大人のコード・ワーク (CD付き) (リットーミュージック・ムック)

山口和也さんのYouTubeチャンネル

ギター好きの方は山口さんのYouTubeチャンネルも要チェックです！
毎回マニアックで面白い動画を投稿されています。
www.youtube.com