Ryo5smileの技術ブログ

学んだこと

【12月4週目】達人プログラマーを読んで【2/2】

達人プログラマー ―熟達に向けたあなたの旅― 第2版

前回の続きです。今回も個人的に重要だと思ったTipsを紹介していきます。

個人的に響いたTips

爬虫類脳に耳を傾ける

ここで述べられている爬虫類脳というのは「自分自身の本能」のことで、コーディング中などで行き詰まった時などにモチベーションが下がることがありますが、それは自分の本音に沿っていないことをしているからだそう。そんな時は、散歩に出たり昼食をとったりしてぼんやり自分の思考と向き合ってみるのが良いと書かれています。 自分も結構考えが煮詰まっている時は一度散歩したりすることで、一回思考を整理できるので作業に取りかかりやすくなるなと感じています。エラーの解決策が移動中にふっと湧き上がったりする経験を何度もしたので、あえて集中しない時間を取るというのが必須級レベルで重要だと感じています。

早めにリファクタリングすること、そしてこまめにリファクタリングすること

例えば自分がコードを書いているときに「この変数名はあまり適切ではないな」と思ったときに、「一つの処理を完了させてから見直そう」と適切な変数名を考えることを後回しにしてしまいがちです。その結果どうなるかというと、そのことを忘れてしまい変数名は不適切なままpushされてしまいます。そのためリファクタリングは早めに取り掛かるように心がけたいです。もしくは、コーディング中にその都度Todoリストにリファクタリングする箇所を具体的に記しておいて、リファクタリングする時間を決めて、その時間にまとめてやるといった方法も考えられます。 リファクタリングをする時間とコードを書く時間を同時にしない理由は、マルチタスクになるからです。マルチタスクとは複数の作業をこまめに切り替えて行うことで、人間は作業を切り替えると前の作業の脳へのリソースが残っており、それによって作業効率がかなり落ちてしまいます。そのため、コーディングとリファクタリングは区別して行う必要があると考えます。

プログラマーの仕事は、自分自身が欲しているものを自らで気づいてもらえるように支援すること

ユーザーが求めていることを把握するためにはあらゆる問いが必要である。ユーザーの希望通りの機能を作ったとしてそれがベストだとは限らないということです。例えば自分がものづくりのエンジニアだとして、顧客に「一番早い馬車を作ってくれ」と依頼が来たとします。そこで顧客の依頼通りに世の中で一番早い馬車を作ってしまうのではなく、顧客がそれを通して解決したい課題を深掘りする必要があります。それは馬車を使う理由を考えることで見えてきます。顧客は馬車にただ乗りたいのではなく、早く目的地につく手段を欲しているの可能性があります。そのため、必ずしも馬車を作る必要はなくて自動車を作るという選択肢も出てきます。このように、「それを欲している本当の理由は何か?」と問う必要があります。そのため言われた通り作るのではなく、その目的をしっかりを理解することがプログラマーとして大事になってくると考えています。

読みきった感想

テスト駆動開発アジャイルなど結構専門的な知識を必要とするTipsがあり、一回読んだだけでは飲み込めない内容もあったのですがその中でもプログラマーとしての考え方や姿勢など参考になる部分が多くて読み応えのある本だと感じました。これまで技術的な部分を深掘りすることが多かったのですが、こういったソフトスキル面での本はあまり読んでこなかった分新たな発見が多くてサクサク読めました。定期的に見直すことで、どのくらい実践できているかを確認できるので今後も読み直していこうと思います。

【12月2週目】達人プログラマーを読んで【1/2】

達人プログラマー ―熟達に向けたあなたの旅― 第2版

達人プログラマーを読みました。この本はプログラマーとして熟達していくために必要なTipsがまとめられている本です。

個人的に響いたTips

本書にはありがたいTipsが100個ありますが、その中でも自分に特に響いたTips7つを紹介します。

割れた窓を放置しない

割れ窓理論という犯罪心理学の用語をソフトウェア開発に置き換えて書かれています。 割れ窓理論というのは、ざっくりいうと「割れた窓を放置すると、誰も注意を払っていないとみなされ、やがて他も窓も壊される」という意味です。 ソフトウェア開発における割れた窓は、悪い設計や質の低いコードなどを指しており、読みにくいコードや必要のない処理をそのままにしておくと、どんなにクリーンで機能的なシステムだったとしてもあっという間に腐敗したものになるということです。 こうなる理由は「他人が質の悪いコードを書いているから、自分も適当に書けば良い」と考えるようになりやすくなるからです。 そのため、割れた窓を見つけた際には早い段階で指摘し修正する必要があります。自分の書いたコードでもリファクタリングやコードレビューを依頼することで最小限に止める必要があります。

変化の触媒たれ

ポルトガルの「石のスープ」という民話をもとに、自分が変化の触媒(現状を変化させるためにチームメンバーを導く存在)になるための方法をざっくり示しています。 組織が変わるのを待つのではなく、自分から変化を起こして組織を変えるというマインドセットが大事だと考えています。

見聞きした物事を批判的な目で分析すること

一般的には「批判的」というと悪いイメージがあるかもしれません。批判的なヤツは場の空気をしらけさせるので、周囲に嫌われるリスクは高いでしょう。しかし、批判的な考え方は物事を多面的に観察するという側面を持っており、その物事の正当性や信頼性を見極めるのに適しています。逆に批判的に物事を考えることをしないと、思考停止になり思考の偏りやばらつきが起きてしまい、正確な意思決定はできなくなります。 そのため、常に「問い」を自分の中で持っておくことが重要だと思いました。

最終決定などというものは存在しない

ソフトウェア開発は常に変更がつきものです。作っておしまいなシステムは存在しないので、変更に柔軟なコードを書くことが求められます。IT業界では次々に便利なツールやライブラリが生まれています。こういったものを素早く柔軟に対応するには変化に強くなければいけません。例えば、一枚岩のようなモノシリックな構成から、複数の機能を独立させてそれを組み合わせるマイクロサービスに変えることでより柔軟なソフトウェア開発ができるようになります。

ということで今回はここまでです。次回も重要だと感じたTipsを紹介していきます。

【11月4週目】プロダクト・レッド・グロース【1/2】

PLG プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ

前回の続きです。前回は「プロダクト主導で新規ユーザーを獲得する企業が伸びているよ!」って話を押さえましたので、今回は最後に「正しい戦略を選択するためのフレームワーク」について見ていきましょう。フリーミアムとフリートライアルの選択を間違うと、成長力が弱くなるどころか利益も減ってしまう可能性があるので、正しく見極めて戦略を立てていこうというのが本書の肝であります。というわけで著者のウェス・ブッシュさんが考案した「MOATフレームワーク」を見ていきましょう!

最適な戦略を選択するためのMOATフレームワーク

M:マーケット戦略

自社の戦略はドミナント型戦略?それともディスラプティブ型戦略?または差別化型戦略か?

フリーミアムもフリートライアルもそれぞれのマーケット戦略によって相性があるので、今のマーケット戦略にマッチしたものを選んでいきましょう。

ドミナント戦略

ドミナント型戦略は、競合他社と比較して、サービスのレベルが高く、かつ安い価格で提供できる場合に最適な戦略です。ドミナント型戦略では、フリーミアム、フリートライアルいずれも、伝統的なセールスモデルと比べると効果があります。

差別化戦略

差別化型戦略では、競合他社よりも優れた特定の機能を、高い価格設定で提供することが求められます。ユーザーを問わない画一的なプロダクトとはなりません。差別化型戦略は、フリートライアルやデモとの相性が良いんですが、その市場規模の限界とプロダクトの複雑性から、フリーミアムモデルだとうまくいかない場合が多いです。

ディスラプティブ戦略

ディスラプティブ型戦略は、特定の市場では、既存のサービスが過剰だと感じている顧客を対象とされます。ディスラプティブ型戦略にはフリーミアムモデルが適しています。価格を低く抑えることで、既存ソリューションを使っている見込み顧客を惹きつけられます。

ということで、ざっとマーケット戦略との相性をまとめてみるとこんな感じですね。

フリーミアム フリートライアル
ドミナント戦略 ○ 
差別化戦略 ×
ディスラプティブ戦略 ×

O:オーシャン状況

自社のビジネスはレッド・オーシャンか、ブルー・オーシャンか?

ブルー・オーシャン

ビジネスがブルー・オーシャンにあり、新たなニーズを生み出しているなら、プロダクトを理解してもらうまで時間を要するので、セールスやマーケティング主導型のGTM戦略を取り入れる企業がほとんどです。

レッド・オーシャン

レッド・オーシャンでは、見込み顧客はプロダクトの活用方法・価値を理解しているので、PLGモデルが優位性を持ちます。

A:オーディエンス

自社のマーケティング戦略は、トップダウン型か、ボトムアップ型か?

プロダクト価格は以前と比べかなり安価になり、マネジメント層がすべてのプロダクトの購買判断を下すかわりに、現場の従業員が同等の意思決定権を持つようになりました。ボトムアップ型の販売戦略においては、導入の早さとプロダクトのシンプルさが求められます。この場合、フリートライアルかフリーミアムモデルが機能する場合が多いです。

T:タイム・トゥ・バリュー

自社のプロダクトは、どれくらい早くユーザーにプロダクト価値を示すことができるか?

プロダクトの価値を素早くユーザーに訴求できないのであれば、PLG戦略は適しません。

まとめ

ここまで、フリーミアムかフリートライアルかを見極める4つの判断要素を見てきましたが、個人的にこのMOATの中で特に気になったのが最後のTです。いろんなサービスが溢れている中でユーザーは価値の高いと思ったものを使いたいわけですが、使い始めて価値を感じるまで長くは待ってはくれません。そのためいかに早くそのサービスの価値を感じてもらうかが肝心であり、他の要素が優れていてもこのタイム・トゥー・バリューがなければ「もっと使いたい!」と思ってくれなくなりトライアルで解約といったケースが増えると考えています。

このプロダクトの最大の価値はなんなのか?その価値を最も早く顧客に感じてもらえるか?といった問いを持ち続けて実装していくことが、PLGを行う上で重要だと考えています。

【11月2週目】プロダクト・レッド・グロース【1/2】

PLG プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ

プロダクト・レッド・グロース」という本を読みました。著者のウェス・ブッシュさんはビジネスコンサルタントとして活動する傍ら、学長として日々生徒に本著のメインテーマであるPLGを使っていかにSaasビジネスで成長の火種をつけるか?ってことを教えているらしいです。当ブログでは普段プログラムの技術に焦点を当てた内容を書いていますが、おすすめされていて読んでみたら重要な内容だと感じたため備忘録。

続きを読む

【10月4週目】Webを支える技術を読んで【2/2】

前回5smile-ryo.hatenablog.com

の続きです。 前回をざっくりまとめると、「私たちが普段インターネットで明日の天気や、Youtubeで動画を見たりできるのはインターネットという世界中に張り巡らされている情報網がWebによってやり取りされているからですよ〜」といったそもそもWebとはというところから、Webを支える技術は3つあってそのうちの1つHTTPについて取り上げました。今回は残りの2つであるURIとHTMLについて書いていきます。

REST

URIを説明する上で必要となってくるのがRESTの概念であります。URIに入る前にサクッとRESTとは何かを見ていきます。

RESTというのはWebのシステム設計原則のことで REpresentational State Transfer の略でレストと読まれます。Web上のリソース(テキストや画像やWebページなど)にアクセスする際の基本的な考え方で、特定の情報源(URI)に対してHTTPを使って情報をやり取りすることなどが定められています。

URI

URIはUniform Resource Identifer の略で直訳すると「統一リソース識別子」です。わかりやすくいうとそれぞれのリソースの所在地が決められている場所のことをいいます。

https://5smile-ryo.hatenablog.com/entry/2021/10/18/092457

例えば前回の記事を見たい場合は上のアドレスにアクセスします。これは前回のブログ記事というリソースの所在地にHTTPリクエストを送り返ってきたレスポンスを記事として表示しています。

まとめると

・リソースとは、Web上の情報である

・世界中のリソースはそれぞれURIで所在地が存在している

URIという所在地にHTTPで情報をやり取りしている

ということになります。

URIの構文

URIがどんなものかわかったところで、URIを構成する要素を見ていきます。

https://5smile-ryo.hatenablog.com/entry/2021/10/18/092457

こちらのURIは次のような3つの要素で構成されています。

httpsURIスキーム

5smile-ryo.hatenablog.com : ホスト名

/entry/2021/10/18/092457 : パス

URIの先頭にはURIスキームというもので始まります。URIスキームというのはそのURIが利用するプロトコルを表します。この例の場合はhttpsでアクセスできることを表しています。

次にホスト名が来ます。ホスト名は〇〇.comや〇〇.jpのようなDNSを使った名前、もしくはIPアドレスで示されます。

最後に階層を表すパスがきます。パスはそのホストの中でリソースがどこにあるかを表しています。ちなみにリソースは必ず他の情報と被ることのない一意である特徴を持っています。

このようにURIはホストとパスを組み合わせることで世界中の他のリソースと重複しないようにできています。なので全く同じのドメイン名は存在しないということになります。そして先ほどのRESTは一意のリソースを指定してHTTPで情報をやり取りしているわけです。

HTML

プログラミング者がまず初めに学習するのがこのHTMLで、私も最初はHTMLから学習を始めました。そんなエンジニア人生で一番付き合いの長いHTMLですが、今回はあえて復習したかったので取り上げました。

HTMLは Hypertext Markup Language の略で構造化された文書を表現するコンピュータ言語です。構造化された文書というのは、文章の中に見出しがあったり、そのページのタイトルを表したりする要素が枝分かれ形式で構成されている文書になります。例えば以下のコードのようにインデントで階層的になっているのが特徴です。拡張子は.htmlです。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Ryo blog</title>
  </head>
  <body>
    <h1>見出し<h1>
  </body>
</html>

そして<h1>見出し<h1>のように文字を囲んでいるのがタグになります。HTMLではさまざまなタグを使い分けることによってそのページの骨組みを表すことができます。例えば<a>タグはリンクを表していて、<img>タグは画像を表します。他にも多くのタグが存在するのでこちらなどで見てみるのも良いでしょう。

まとめ

Web業界では新しい技術が次々に生まれていますが、基本的にはHTTP、URI、HTMLといった技術の上に成り立っているものなのでWeb業界で働く上では必ず身につけておきたい知識です。ベースの知識があることで、新しい技術にもキャッチアップしやすくなると思います。新しい技術を学ぶことも大事ですが、こういったベースの知識の学習を怠らずにしていきたいです。

【10月2週目】Webを支える技術を読んで【1/2】

Webを支える技術 ―― HTTP,URI,HTML,そしてREST WEB+DB PRESS plus

Webを支える技術を読みました。今まではコーディングの技術や言語の知識を深める学習が多かったのですが、「そもそもWebてどういう風に動いているの?」という疑問に駆り立てられこの本を購入しました。HTTPなどの用語をなんとなく知っているから脱却し聞かれても説明できるレベルへとステップアップして、その知識を血肉にしていきたいと思います。Webで扱われる技術は進歩が早いイメージがありますが、HTTPなどのWebシステムの技術は数十年変わっていないほど完成度が高いらしく、今後もこのあたりの技術が使われていくと思うので優先的に知識に入れておきたいです。

続きを読む

【9月4週目】オブジェクト指向設計実践ガイドを読んで【2/2】

第5章 ダックタイピング

ダックタイピングとは以下のフレーズで語られることが多いかと思います。
"If it walks like a duck and quacks like a duck, it must be a duck" (もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルに違いない) この言葉を初めて目にしたとき「そんなの当たり前じゃないか」となって呆気に取られた記憶があります。
これの言葉をもっとプログラミング的に言い換えると、「オブジェクトがアヒルのように歩き、アヒルのように鳴くメソッドを実装しているなら、そのオブジェクトはアヒルであるに違いない」となります。ダックタイピングはどのようなクラスとも結びつかないインターフェイスのことをいい、クラスへの依存度を上げないというメリットがあるので、変更にかかるコストを下げることができます。

ダックタイピングを理解する

先ほどは「どのようなクラスとも紐づかないインターフェイス」ということを理解しましたが、その理解はまだふわっとしたままです。もう少し掘り下げて理解を深めます。

まとめ

さいごに、本書を通して学んだテクニック的なメモを残しておきます。※本書の引用でなく、僕なりにまとめた文章なのであしからず。

・複数の責任(処理)を持つオブジェクトは簡単に再利用できなくなってしまうため、クラスもメソッドも単一責任にするのが基本。単一責任かを確かめるには、そのクラスを一言で説明してみる(説明できたら単一責任)。

・依存は少ないに越したことはないが、ゼロにすることはできない。不必要な依存は排除し、依存は隔離(一か所にまとめる)する。

・依存を隔離する手段として、ラッパークラス・ラッパーメソッドがある。依存箇所をラッパーメソッドで包み、そのラッパーメソッドを参照するようにしてやれば、依存先のクラスの仕様が変わったとしても、依存箇所はその一か所で済む。外部オブジェクトへの依存だけでなく、インスタンス変数など様々な個所から参照されうるものは、ラッパーメソッドで包んでおけば変更に強くなる。

・AがBに依存するか、BがAに依存するか、コントロールできる場合は、変更されづらく、依存されている数が少ない方のオブジェクトに依存させる。依存方向を意識する。

・パブリックインターフェースとメッセージが、アプリケーションを構成する。シーケンス図を用いてオブジェクト間でやり取りされるメッセージを図示することで、必要なオブジェクトを洗い出すことができる。

・ダックタイピングを使いこなすことで、よりインターフェースを柔軟にでき、クラスへの依存を排除できる。ダックタイピングは具象的な存在でないため、理解しづらいという難点はある。テストコードをしっかり書いて明文化すること。他人が書いたダックタイプを破壊しないように、ダックタイピングの概念を理解しておくこと。