ボクココ

個人開発に関するテックブログ

宇宙のことがわかってないことをわかった

ども、@kimihom です。

最近はプログラミング関連の本ばかりを読んでいたので、このGWでは全く別の分野で興味のあった本を読んでみた。

「僕たちは、宇宙のことぜんぜんわからない この世で一番おもしろい宇宙入門」

宇宙はまったくわかっていない

「お父さん、空はなんで青いの?」

この質問にズバッと答えられるだろうか?今ならググればわかる話だが、それで解決できるようになったのはごく最近のことだ。

同じような形で、次の質問に対してはどうだろう。

「お父さん、こんなにたくさんある星の中に、宇宙人はいないの?」

回答としては、「いるかもしれないし、いないかもしれない。」という現状である。

宇宙の世界には全くわかっていないことが大量に存在する。本書では現在、どこまでがわかっていて、どこからが全くわかっていないのか。「エネルギー」、「物質」、「質量」、「空間」、「時間」、「次元」、「光」などの視点からたくさんの例を挙げてわかりやすく説明されていた。(それでも1回読んだだけでは私はほとんど理解できていない)。

その中で、IT業界の中で話には出てくる「量子」に関して興味を持った。量子テクノロジーがうまくいけば、今までの0/1の世界と比べ物にならないくらい高速なコンピュータができる?とまで聞いたことがある。また、宇宙の世界でも化学の世界である物質の理解が必要である点が面白い。宇宙のことを知るにはまず、よりミクロな世界の理解が必須なのだ。そしてそのミクロな世界もまだ謎だらけの領域である。

宇宙の世界は、わからないことだらけであることに、「答えがわかってないなんて面倒だ」と言って切り離すのか、「答えがわかってないなんてワクワクする」と思うのか。私は後者であり続けたい。

私たちが生きている間に、何か画期的な発見を1つでも多く見つけたい。少しずつ解明していく宇宙の世界にワクワクする。

終わりに

日頃のプログラミング生活の中では、「このプログラミング技術を学べば、こんなものが作れる」と既に答えのわかっていることを理解するだけな日々であった。

本書を読んで、私も一歩進んだ新しい技術に挑戦してみたいという思いをくれた。

たまには別分野の何かを読んで学んでみることで、今をより良くさせる。GWで私はそう学んだのであった。

イノベーションの作法を読んで

ども、@kimihom です。

f:id:cevid_cpp:20191211160909j:plain

オススメ本のアドベントカレンダー11日目の記事。本記事はオススメ本というよりかは最近読んだ本という感じではあるけども、せっかくなので記しておく。

オススメ本 Advent Calendar 2019 - Adventar

事前情報

SHIFT:イノベーションの作法

SHIFT:イノベーションの作法

  • 作者:濱口 秀司
  • 出版社/メーカー: ダイヤモンド社
  • 発売日: 2019/06/27
  • メディア: Kindle版

こちらの本、多くの著名な方からのレビューが既にネット上で公開されている。いい値段するけども、読んでみた。

世界的なイノベーター 初の著作! 濱口 秀司 『SHIFT:イノベーションの作法』│ダイヤモンド・オンライン

感想

本書は、とりわけ大企業に所属している方が、自社の技術を応用して全く新しい新サービスを展開しようとするような時に、特に有用な内容であった。大企業で新サービスを開発するってなると、どうしても上司・役員を説得させるというフェーズが必要になり、その説得フェーズで大抵のアイディアはボツとなってしまう。でも、イノベーションを起こすアイディアが、「最初から誰もがいいね」って思うようなものではない。ボツになるアイディアこそ、ダイヤの原石なのである。その点こそ、大企業がイノベーションを起こすことができない最大の理由の一つとなっている。

私も以前は大企業の新サービス開発事業に所属していたから、その事情はよくわかる。誰かが新しいアイディアを出したとしても、その開発の承認を得るには多大な説得フローが待っており、その中で "~~したほうがいいんじゃない?" みたいなアドバイスを聞かなければならないわけである。また、担当者がたくさんいればいるほどアイディアが出てきてしまって全部を取り込んでしまおうとする。そんで色々とファットなアイディアに包まれた新規事業が出来上がり、誰のためのサービスだかわからないものがリリースされてしまうというのはよくある話だ。

イノベーションには、「ビジネスモデル」、「テクノロジー」、「コンシューマーエクスペリエンス」の3つ全てが完璧に揃っている必要があるとのことだ。エンジニアだとテクノロジーばかり見てしまうが、例えば DELL はコンピューターをオーダーメイドで作り上げるというコンシューマーエクスペリエンスを兼ね揃えることで大成功した。また購入した時点から作成を始めるため、在庫の課題を大きくクリアした。私のようなエンジニアだと、常にテクノロジーだけでイノベーションを起こそうと躍起になりがち(パソコン開発で言えば、圧倒的な画質とかスピードとか容量などを考えがち)だが、それだけの視点ではいつまでもイノベーションを起こすことはできない。今までにないビジネスフローや顧客体験を兼ね揃えた事業を始めなければ、イノベーションと言われるレベルの大成功まではいかないのである。

そんな中、本書では日本でも(こそ)、次なるイノベーションを起こせる可能性があると書かれている。日本人の風習や思想などが発明に適しているというのである。

私が共感したのは、人が何かを学ぶ上での2種類のタイプである。

  • 教育プログラム
  • 弟子入り

「教育プログラム」は、まさに学校と同じだ。カリキュラムがあって、そのカリキュラム通りに勉強してテストを受け学べたかどうかを確認していくプロセスだ。誰もがやればできるっていう汎用性と、先生や教科書が設定したレベルに向けてさっと到達できるというメリットがある。私がこの方法の学習方法が嫌いなのは、いつまで経っても先生・教科書の内容を超えることはできないという点である。同じレベルにはなれても超えることはできない。自分から新しい発見や発明をするなんてことは2度と起きない。単に既知の事実を聞いて学んで知っていく。それだけ。そして怖いのは「この方法に慣れてしまうと、弟子入りの効率の悪さに拒絶反応を示すようになる」のである。

「弟子入り」は、日本の伝統を受け継ぐために弟子入りする。まさに日本らしい部分なんだけど、最近はすっかりその効率の悪さばかりに目がいって軽視されてしまう。でも、この方法の何が一番すごいのかというと、いつかは師匠を超えることができる可能性が非常に高いという点である。もちろん、それにはカリキュラムで学んでいくよりも膨大な時間を要する。時間をかけてじっくりと自分で自分を極めていくことで、誰もが到達できない領域にたどり着くことができるのである。イノベーション、つまり誰もが思いつかなかったようなアイディアは、そんな人からしか生まれないはずだ。

かつての日本が本当に凄かったのは、まさに職人レベルの人たちがうじゃうじゃいたからだと思う。その人しか知らない・持っていない何かを極める人たち。彼らが尊敬される価値観がかつての日本にはあったように思う。今は欧米化がどんどん進んで、とっとと金つぎ込んで儲ける手法みたいなのだけが注目されてしまっている。私はかつての職人の考え方へ戻らない限り、いつまでも日本はイノベーションを起こせず低下し続けるままだと思うのである。

終わりに

少なくとも私はかつての日本の素晴らしさ、何かを極める勇気のある職人であり続けたい。その先に、未だかつて誰も経験したことのないような発見や開発ができると信じている。

その実現には長い道のりと覚悟が必要だ。ささっとできるような短時間の成果なんて求めない。

誰かに教えてもらうのではなく、自分で自分を極めていく姿勢を持つ人が増えて、日本から本当のイノベーションが起こって欲しいと思う。イノベーションを起こせる候補の一人として、引き続き地道な成長を続けていく次第だ。

サービスの伝え方 を学ぶ

ども、@kimihom です。

f:id:cevid_cpp:20190916183126j:plain

最近は色々な Web サービスが Twitter や Facebook、Google などに広告を出している。そんな中で感じた点と、今回読んだ本について記す。

What を伝えるのは誰でもできるし、誰にも響かない

今回読んだのが以下の本だ。私はもちろん英語バージョンでね。

英語

Start with Why: How Great Leaders Inspire Everyone to Take Action (English Edition)

Start with Why: How Great Leaders Inspire Everyone to Take Action (English Edition)

日本語

WHYから始めよ!  インスパイア型リーダーはここが違う

WHYから始めよ! インスパイア型リーダーはここが違う

んで本書の中で印象に残るマーケティングメッセージについての例が印象深く残る。あなたが興味を引くメッセージはどちらだろうか、考えてみてほしい。

私達は素晴らしいコンピューターを製造しています。
美しくデザインされシンプルでユーザーフレンドリーなものです。
一ついかがでしょう?

5GB 容量の MP3 プレイヤー
私達は現状を変えることにチャレンジしています。私達は異なる考え方を信じています。
現状を変えるために私達のプロダクトを美しくシンプルでユーザーフレンドリーなものにしています。
お一ついかがでしょう?

あなたのポケットに1,000曲

「そりゃ2つ目の方でしょ」ってこれを読んだだけだとほとんどの人がそう思うことだろう。だが実際に世の中にありふれている広告メッセージはどうだろう?ほとんどが1つ目の単なる What を伝えるメッセージで広告として単に流れで流されるだけのものになっている。

What は誰でも考えられるし、誰でもお金さえ出せば広告を出せる。だからありふれているのである。Why まで考えられた広告が少ないのは、単にそこまで深く考えていないからだ。マーケティング担当者がそこまで考えてプロダクトについて伝えられないし、伝えようという熱意もそこまでないことが多い。本気でマーケティングをしようって思ってる企業はマーケティング社員を雇うことはしても最後には社長自らが真剣に考えてマーケットに向けたメッセージを作り出している。単にほとんどの企業がそこまでやってないってだけだ。

そもそも あなたのサービスに Why は存在するか?

大事なのは Why である。優れたサービスには必ず優れた Why が存在する。なぜなら、それがなければすぐにぐちゃぐちゃバラバラなサービスとなって顧客は寄りついてこないからである。単に流行ってるからだとか金儲けしたいだとかいうモチベーションの人には到達できない領域だ。

その Why を社員だけでなく、利用ユーザーまで届いていることも重要な条件である。そしてそれを裏切らないような開発やメッセージを送り続けていることが必要だ。誰かにあーだこーだ言われたとしても、No と伝えこだわり続けられるか。そうした意志の硬いサービスってのは案外少ないものである。

人が多くなればなるほど、Why の維持が難しいことは想像に容易い。社員が多くなれば、それをまともに考えずに単に給料のためだけに働く人が出てくるし、投資家などから資金を受け入れたら、Why を時間かけて考えるより金儲けして上場しろと言われる始末である(もちろんそうじゃない人もいるとフォローしておく)。それでも Why をブラさずに持ち続けて全員がそれを理解している企業こそが、顧客の期待を裏切らずに残り続ける。

ところでなぜ日本や世界でブラック企業と言われるような会社がトップを走り続けられるのか、私は疑問に思っていたことがある。私の仮説として、それは社長が社員を洗脳して Why をぶち込んでるからだ。大量の人を洗脳させて同じ考え方を染み付かせれば、ブラックでも強いチームになってしまうのである。それが嫌で辞めたいなら辞めればいい。そんな世界なのではないだろうか。

この Why が薄れてきたら、確実に企業は衰退する。会社が一つになれず、バラバラの行動を始めて顧客の期待や想像を裏切ることが発生してくるからだ。

そんな Why が浸透した企業が生み出す広告は強い。本気で寝る間も惜しんで最適なメッセージを考える。それは単なる What だけの広告ではなく、 Why が含まれた熱いメッセージなのである。

終わりに

なぜあなたは今のビジネスをやっているのか?

改めてこの議題について真剣に考えてみてほしい。そしてその考えが社内に浸透しているか。これが薄れてきて単にお金のためだとか言うようになってきたら、あとは堕落へまっしぐらである。

私は自分へ問い続ける。なぜ私は今のサービスを運営しているのか と。

Subscription Marketing を読んで感じた新しい顧客との関わり方

ども、@kimihom です。

f:id:cevid_cpp:20180716172650j:plain

今回は以下の本を読み終えたので、読書感想文を書こうと思う。

Subscription Marketing: Strategies for Nurturing Customers in a World of Churn

Subscription Marketing: Strategies for Nurturing Customers in a World of Churn

Subscription Marketing: Strategies for Nurturing Customers in a World of Churn

ちなみに日本語もあるので、英語が不得意な方はこちら。日本語になった時の「モノが売れない時代の顧客との関わり」っていうサブタイトルが中身とマッチしてないと思うんだが。これも日本流マーケティングってことなのかな。。

サブスクリプション・マーケティング――モノが売れない時代の顧客との関わり方

サブスクリプション・マーケティング――モノが売れない時代の顧客との関わり方

サブスクリプション・マーケティング――モノが売れない時代の顧客との関わり方

マーケティングは新規顧客獲得のためだけの部署ではない

SaaS 界隈では当たり前のように言われるようになってきたけど、大事なのは新規顧客獲得より既存顧客の維持(Customer Retention)である。SaaS の世界では顧客獲得(サービス利用)を始めただけでは意味がなく、顧客がサービスを使い続けることによって初めて価値を提供し利益を生み出すことができる。今まで"マーケティング"といえば、いかに目立って見込み顧客を獲得するかってところにフォーカスしていたかと思う。でも Subscription Marketing の世界ではそれらは二の次である。CM や雑誌広告に載せる企画を考えたりするみたいな旧来の新規獲得のためのマーケティング手法は Subscription Marketing の世界では優先度が低いのである。

既存顧客がもっと使い続けていきたいと思っていただけるようにすること。これは今まではカスタマーサポート等で対応してきたかもしれないが、これからは全ての部署が連携して顧客に対しての関わり方を真剣に考えなければならない。今では "カスタマーサクセス" って言葉も一般的になり始めたけど、まさに顧客のことを把握して分析し、そこから行動する顧客ファーストの視点が重要になってきている。

また、本書では無料トライアル期間での顧客との関わりについて重点が割かれていた。初めて無料トライアルを使い始めてくれた時のサービスに対する印象は今後のサービス利用に大きく関わってくる。なので最初の時点でいかにユーザーが躓かないで、快適にサービスを使い始めてくれるかに注力するのもマーケティングの重要な仕事の一つである。

Subscription Marketing の世界では、新規顧客獲得数が数値目標になることはない。いかに正しい顧客に刺さったプロモーションをし、正しく教育し、流れに乗せることができたか。総合的な視点でマーケティングを評価しなければならない。

どうやって顧客と関わっていくか

そのための方法として象徴的だったのは、動画を使ったウェビナーによる教育だった。日本ではまだほとんどの SaaS が行なっていない取り組みだ。FAQ 等を整備することはもちろんなんだけど、顧客にサービスの価値を知ってもらって使い続け、さらにそのサービスを紹介したくなるくらいにまで満足してもらうには、やはり顧客との接点を増やし、サービスの新たな価値を知ってもらう努力をしなければならない。

従来のマーケティングでは、この顧客育成の視点が決定的に抜けているように思う。とりわけ従来の作って終わりな製品の場合、説明書に載っていることが全てでわからなければサポートに問い合わせというケースで対応していたことだろう。しかし、時代は進んで SaaS のような常に進化を続けるサービスの場合、説明書は進化を続けていく。顧客は毎回アップデートされる説明書のある商品を使い続けていくのである。それは当然面倒で手間のかかることだから、いかに手軽に新しいことを知ってもらえるかっていうところにマーケティングは力を注ぐべきだろう。

そしてサービスの価値を真に理解したロイヤルカスタマーが、サービスをアップグレードしてくれ、新しいお客さんを紹介してくれるようになる。SaaS はそのような状態になって初めて利益を得ることができる。

カスタマーサクセスと密に連携する

マーケティングがメインテーマの本書でも、カスタマーサクセスについての説明が多くあった。顧客を分析してニーズを導き出すカスタマーサクセスと、顧客獲得し育成していくマーケティングとでは深い情報の連携がマストだ。

カスタマーサクセスの部署を設けていない場合は、兼務でもいいからまずは考え方から導入し始めるべきかもしれない。カスタマーサクセスに関しては以下の書籍が数少ない日本語文献としてある。

カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則

カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則

  • 作者: ニック・メータ,ダン・スタインマン,リンカーン・マーフィー,バーチャレクス・コンサルティング
  • 出版社/メーカー: 英治出版
  • 発売日: 2018/06/06
  • メディア: 単行本
  • この商品を含むブログを見る

この本も英語から翻訳されたものなので、原本を読みたい場合は以下である。

Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue

Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue

終わりに

まだ日本で SaaS やサブスクリプション型のビジネス自体が普及していないことを考えると、Subscription Marketing の考え方が普及するのには時間がかかるかもしれない。

早いうちから顧客育成に力を入れてより良い関係づくりに取り組んだ企業が、愛されるサービスとして成長し残り続けることだろう。

この記事を見つけて読んだ方は、それができるポテンシャルを秘めている。マーケティングに対する意識を変え、新しいビジネスの時代を作り出していこう。

プログラマのための SQL を読んで

ども、@kimihom です。

今回は以下の本をざっと読んだので感想を書く。760ページにもなる超大型本だ。

SQL でここまでできる

私は普段、Web アプリケーションのコードを書くエンジニアなのでデータベースの知識はそこまで深くない。よりデータベースの知識を深めようということで本書を手に取った。

本書の前半部分は SQL の一般的な教養的な感じで学ぶことができた。いきなりトランザクションの話が出てきたときはマジかよって思ったけど、そのあとは SQL の各句の詳細な解説などもあった。

一番ここで感じたのは、「NULL の扱いの難しさ」だったように思う。NULL は SQL の中で本当に特異的な存在で、実際にクエリを書くときも注意しないと意図しない結果を生むことにもなりかねない。本書でにおける NULL を扱うことで意図しない結果を生んでしまう SQL の例がたくさんあったので、やはりテーブル作る時に NOT NULL にして初期値をセットするのは大事だなと改めて感じた次第である。 例え NULL を許容するカラムがあったとしても、COALESCENULLIF などを使って丁寧なクエリを書くことを意識したい。普段 Rails を使っていると ActiveRecord で隠蔽されちゃうけども、何か困った時にはちゃんと自前でしっかりとした SQL を組み立てられるようにならないといけない。

本書の後半部分では SQL を駆使したテクニック的な側面が強かった。SQL も1つの立派なプログラミング言語であるので、複雑な問題を SQL "だけで" 解くことができたりする。当然それはそれで SQL を極めるって意味では本書の意図に適っており、学ぶことはあった。しかし、実際にそれを解くってなるとやはり私は Ruby や JavaScript などのプログラミング言語で解きたいなと思う。

グラフや木構造を SQL で扱う話もあった。当然、SQL はそのような設計で作られてはいないので、トリッキーな構造でテーブルとして管理する必要がある。でも実際 SQL でこういうデータ構造を扱うことってどのくらいあるのかと疑問に思った。最近では Neo4j などのグラフ志向データベースなどが出てきているので、適材適所なんじゃないかなと思った。そういう意味では後半はちょっと流し読み程度で読み終えた。

とは言いつつ、"SQL" は今後も廃れることのない技術の基礎として残り続けるだろう。新しい技術が出てきても SQL ベースになっていることが多く、UNIX などの OS の基礎といった同等のレベルで必要な知識だ。そういう意味で改めて一気に本書を読みきったことは、今後の Web アプリケーション構築の糧となるだろう。

集約機能の拡充

最近の SQL の潮流(?)的なものとして集約を SQL で活用できるような流れを感じる。BigQuery とかも SQL で大規模データにアクセスする感じだ。私たちが普段書いている Web アプリケーションのコードと違って、集約の SQL は複雑なクエリを書けるようになる必要がある。本書を読みたいと思った動機もそこにあった。

ただ本書は "SQL のすべて"ってことなので集約に関しての記述もその中の一部としての解説だったし、PostgreSQL に特化したって話でもないので実際に集約のみを重点的に学ぶとなると他の本の方がいいかもしれないと思った。私は以下の本をプログラマのための SQL を読む前に読んだのだけど、学ぶことが多くて良かった。大抵の Web エンジニアであれば本書を読むだけで十分な気もする。

また、集計の本格的な実例として以下の本も参考になった。特に PostgreSQL などの DB に最適化された内容で実践に即した内容なのですぐに使える知識として有意義だった。

私が直近で学んだデータベースに関してはそんなところだ。

終わりに

最近はブログ更新のアウトプットよりもこうしたインプットを重点的にやってきた。エンジニアは表面的なところ(プログラミングやフレームワークなど) を抑えたら次は裏の部分(OS, データベース, プログラミング言語そのもの) といった部分に興味というか、自分にとって必要だと感じるようになるのだろう。今回はその一環として "SQL" をテーマに深く学んできた。

次に作りたいものの大枠が見えてきたし、今回得た知識を活用して、またプログラミングをどんどんやっていきたい。

モチベーションを保ち続ける

ども、@kimihom です。

f:id:cevid_cpp:20170902185410p:plain

今回は以下の本を読んだので感想とやっていきたいことみたいなのを書いてみる。かなりいい本だったので、モチベーションに関して興味ある方はぜひ読んでみることをオススメする。

モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)

モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)

労働に対する考え方の変化

モチベーション 3.0 とあるからには、1.0, 2.0 があるわけだ。ざっくり言うと、生きるために働いてきた1.0 と大量生産のためのマニュアル化/機械化を推し進めてきたのが2.0だ。

3.0 はどんな時代背景があるのか。それは単純作業だけでまかり通っていた 2.0 から、より創造的な仕事が求められてきていることが背景にある。私たちの人間の仕事はより高度になり、より柔軟な発想が必要な仕事がこれからもどんどんと増えていく。そんな中、今の日本の企業は 2.0 的な考え方の企業が多すぎるように思う。

3.0 の特徴は、個人の意志を大切にする企業文化だ。自由な出勤時間、何でも自由に開発できる時間を設ける、一人一人の所属意識でなくオーナーシップ、上司は部下を管理しない。ここで面白い実験内容があったので本記事でも概要だけ紹介したい。

とある学生の集団を AとBに分けた。Aはその作業をすると報酬が与えられると事前に約束され、Bは特に何もアナウンスをしないで作業をしてもらった。誰でもできる頭を使わない単純作業を A, B それぞれにやらせたところ、Aははりきってその仕事をすぐに終わらせた。今度は頭を使う創造的な課題をやらせたところ、今度はBの方がAよりも早く課題をクリアすることができた。

これは、まさに人参の目の前にぶら下げた馬のような表現だ。目の前に人参しか見えない馬は、その人参のためだけに走って正しい道を選ぶことができないのである。そして人間でもこの目の前に人参がぶら下がっているのを追い続ける人たちが後を絶たない。

モチベーション3.0 はその先を見なければならない。今目の前にある利益ではなく、今努力した結果生まれる利益だ。それが続く限り、人はどんどん大きく成長し、今まで辿り着けなかった利益を得ることができるのである。

良い目標と悪い目標

目標に向かって努力するモチベーションは当然大事だ。しかし、良い目標と悪い目標があって、いとも簡単に誤解するので注意したいところである。さて、皆さんがお持ちの目標は、以下のどちらだろうか。

  1. フランス語の授業でAをとる
  2. フランス語を話せるようになる

一見、具体的で到達可能な目標だとして 1 を選びがちだ。それはそれで良いとされることもある。確かに、1 でも Aを取るという目標のためにテスト期間に頑張ってフランス語を勉強することはできる。しかし問題はそこからだ。 1 の場合、Aを取った途端に露頭に迷うことになる。もはや次の目標が見つけられないため、次のテストまではフランス語とは一切関わらないことだろう。しかし、2はあくまでテストは通過点に過ぎないので、テストが終わってもフランス語の勉強をコツコツと続けていくことだろう。この違いがやがて大きなものとなって、最終的には 2 の目標を選んだ人が成功を掴むのである。

これは企業にも同じことが言えるだろう。営業目標や利益目標などを掲げて目の前の数値だけを追い続ける人がいる。数字にとらわれて、その数字目標を達成するためなら手段を厭わないような、そんなやり方だ。それは結果的に不正を招くことになる。なぜなら数字を達成できないとわかったら、何が何でも達成させようと、"どんな手段を使ってでも" という考えに陥ってしまうからだ。 しかし、理念ベース、つまりフランス語を話せるようになるといった企業目標に向かっていればそんなことは決して起こらない。なぜなら、そのような不正をしてしまっては結局自分に返ってくることを知っているからだ。テストでカンニングしたところで、フランス語は上達しないのは当たり前だろう?フランス語を話せるようになる目標にしているのに、そんな不正をすることに全く意味はないのだ!

達成したら次の数値目標を掲げてブラック企業としてがむしゃらに働く姿勢が日本では評価されている傾向がある。しかし、もうそんな気合い論は時代遅れであることを知るべきではないだろうか。

漸近線を描く目標を考えよう

最終的にどんなに近づいても達成することのできない目標を掲げること。どんなに成長しても、まだまだ自分は成長できると信じ続けること。それが私たちをより高みへ連れていく。

それは、誰かからとやかく言われるようなものではない。自分が心から達成したいという理想の状態を見つけ、それに向けて努力を続けるのである。その努力は自ら沸き起こるモチベーション3.0なので、ずっと続くもので、他の誰よりも良い結果を生むことだろう。

それは地味で辛く険しい道でもある。それを知った上で続けることができれば、尽きることないモチベーションを持ったまま、成長し続けられる仕組みを得ることができる。

終わりに

最近、私がぼんやり考えていたことが、そのまま明文化されていたような本だった。

本当に成功している企業ってのは実はこのような社員のモチベーションを最大限に引き出す仕組みを既に活用していて、人海戦術な古来の方式を取る企業のその先を行っている。

もちろん、モチベーション2.0 のような仕事を続けるのも良いだろうけど、私はモチベーション3.0のような、主体的な行動が推奨されるような、そんな仕事を続けていきたいと思う。だからこそ、自らを磨き続けることの重要性を知り、終わることのない自分の理想に向けて努力を続けていく次第である。

大切にしたいインターネット企業の条件

ども、@kimihom です。

今回は私の好きな本を一冊紹介する。私はこの本を読むたびに号泣するのでティッシュが必須である。

日本でいちばん大切にしたい会社

日本でいちばん大切にしたい会社

従業員を最初に幸せにする

会社には色々な関係者がいる。従業員、従業員の家族、下請け企業、顧客、取引先、株主。。その全部が当然幸せになればいいことである。では、この中で、誰が一番最初に幸せにならなきゃいけないのか。好循環のループを生み出せば、最終的には全員が幸せになれる企業が作れるはずである。

本書では「従業員」こそが最重要であると説いている。会社で笑顔で働く従業員が増えれば、心から自信を持った商品を顧客に提案することができる。それがやがて企業の信頼を生み、顧客や取引先に良い影響を与え、最終的には株主に還元される。そのループの始まりはいつでも従業員である。

では従業員を満足させるために給料を上げればいいのか。いや、実際のところはそうではない。とある企業満足度アンケートによると、給与よりも働きがいやお客様との良好な関係に重きを置いている人が多いとのことである。それは最低限の給与があれば、欲求5階層説の"社会的欲求" 以上を求めているからだろう。物が溢れかえっていつでも好きなものが手に入るようになった時代において、自分が世の中に必要とされているという感覚こそが、働きがいを生む。

インターネットの世界では、どうしてもそのユーザーに使われている、必要とされている感覚ってのが味わいづらい。ログやデータベースを眺めれば、どれだけサービスが使われているかとかは把握できるけど、それは単に PC から見れる"情報"に過ぎないので、現実味を感じることができない。ここをなんとかするには、実際に使っていただいているユーザーに会ったりすることが大事な気がした。それによってユーザーから必要とされているサービスだと実感できて、従業員の心も満たされるのではないか。当然それ以外にも従業員が幸せになる何かについて考えていきたいと思った。

この"従業員を大切にする"って意味で、有名なチョークの製造企業のエピソードが本気で泣ける。この内容はぜひ本書を読んでみていただきたい。本を読んで泣くって滅多にないから初めて読んだときは衝撃だった。

日本でいま、本当に必要とされているものは何だろう?

以前のポッドキャストで、ゲーム作ってる場合じゃないという話で盛り上がったのだけど、実際に本当に日本で必要とされているものは何だろう?本書でも登場してきたキーワードが、ポッドキャストでもあったように “医療・福祉・介護” だった。その中で、義足などを製造している島根のど田舎の企業があって、オーダーが殺到する日本中から必要とされている企業だそうだ。

これはサービス開発の時にも参考になる話だと思う。以前から私の記事では、「あったらいいな」のサービスではなく「なくては困る」サービスを作ろうと書いてきた。日本の少子高齢化の中で今でも困っているものが確実にあるはずで、その課題を解決しながらも、従業員の満足度が非常に高い企業こそが日本で大切にしなければならない企業になりうるのではないだろうか。

そして素晴らしい企業はどの企業にも競合にならないような商品を試行錯誤を凝らして作り続けている。こういう企業努力って実際はあまりやられていないように思う。利益が十分に上がっている何かがあれば、それにしがみつき、ずっとそのまま流れに乗るような部署が多いのではないだろうか。

では、インターネットの世界において、どの企業にも競合にならないような商品を作るにはどうすれば良いか。それは1つのテクノロジーを極めることで見えてくることだと思う。誰だって作れるようなサービスってのはすぐさま競合が現れる。そうではなく、「今持ってるこの技術を応用すれば、あんなこともできるな」という先見の明を持ち、それを試行錯誤で作り続けることではないかと思う。そうすれば世の中に本当に必要とされるサービスを持つ企業が生まれていくのだろう。

終わりに

私自身、まだまだ目の前の事業に精一杯でその先の行動ができていない。しかしやがては本書にあった日本でいちばん大切にしたい企業と肩と並べられるようになりたいと思う。

本記事であげた特徴の企業は、会社の従業員が多かったり、給料が高かったり、上場したりするよりも立派なことだと思う。従業員/顧客/関連会社/地域社会から必要とされる企業。それこそが愛される企業の条件だ!

キッチハイク は「つながり」だ

ども、@kimihom です。

個人的に仲良くしている キッチハイク さんが本を出したとのことで読んだ感想を書く。

キッチハイク! 突撃! 世界の晩ごはん

kitchhike

この本を通じて私が特に知りたかったのは、「なぜ料理を提供してくれる人は、見ず知らずの人に料理を提供するのか」という観点だった。本書を通じて、その答えがなんとなくわかった気がした。

人はつながりを求める

本書は様々な国に訪問して現地の食事を食べ回ったバイタリティあふれる著者による、人の出会いや生活をまとめた記録だ。波乱万丈の旅の記録を時に面白く綴られていた。

その中で、料理を提供した方のいくつかの言葉が私には印象に残った。

  • 「またいつでも食べに来ていいからね」
  • 「数日でも共に暮らすと家族のように思えるんだ。今では世界中に家族がいるようなものだ」

これらの言葉こそ、無償で料理を提供する方の根底の思いなのではないかと感じた。料理を提供する方々は旅する者に喜んでご飯を提供し、会話を通じて世界のことを知ったり自国のことを知ってもらったりする。それぞれの国の文化を知るためには、その国の料理を食べることが一番わかりやすい。だからこそ、世界中の家庭料理を食べ歩くこの旅は有意義になったのだと思った。そうして料理を提供する方は “つながり"を得ている。本書に書かれた各国の物語は読んでいて心温まるものだった。今の日本ではちょっと忘れかけているような温かい気持ちだ。

本書の最後に、著者も「食卓を囲む行為は、人がつながり、絆を深める行為」であると述べている。まさにこの考えこそがキッチハイクの根幹ではないかと感じた。実際、私もキッチハイクを何度か利用し、知らない人と食卓を囲む機会を体験した。食を通じた会話は男女関係なく楽しめるし、何より美味しい料理を通じた会話は温かい気持ちになる。人の交流と食の関係は、どんな時でも相性がいいものなのかもしれない。

さて、海外ではホストファミリー的な感じで色々な人を家に迎えて食事を振舞うことで “つながり” を得ている。では今の私たちはどうなのか。そのことについてちょっと考えてみた。

現代のつながり

“人と繋がっている” って感覚は幸福を得るための一つの手段だ。

んで、この点をうまく実現した Facebook というサービスがある。人とのつながりを明確に可視化して、何か投稿をすると いいね! をもらえる。いいね!をもらえた瞬間に、人と繋がっている擬似的な感覚を得ることができる。これ自体は日本だけでなく世界中で同様に Facebook によって繋がりを得ることができているというのがまず現代の一つ大きな特徴としてあるように思う。否 そもそも、インターネットそのものが “繋がる” を満たした総合体のようなものだ。Facebook だけでなく 2ch やオンラインゲームが流行りだして、別に外に出なくても人は繋がりを得ることができた。だからこそたくさんの人が家に篭り始めてしまったのだと私は思う。今後も発達したビデオ通話や音声通話によって会わなくても会ったという感覚、繋がりを得やすくなることだろう。そうしてインターネットが人とのつながりを"広めて"いる。しかし、インターネットは人とのつながりを"深める"ことができているのだろうか?

ここでつながりを深めるには"実際に一緒に何かを体験する"ことが重要になるのではないかという仮説が浮かび上がってくる。そしてその一つの手段として一緒に料理を食べるのは良い方法だ。それなりにお値段のする飲み屋がそこら中にはあるのはその証拠だ。より深い体験のために週末に BBQ をみんなでしたがるのも同様の理由だろう。

私は新たなつながりを深める方法の一つとして キッチハイク というサービスに注目しているし応援している。

キッチハイク社について思うこと

正直、私は最初はキッチハイク社については「流行りのシェアリングエコノミーの乗っかった企業の一つ」くらいにしか思っていなかった。実際、登場したタイミングもネット業界で Airbnb が流行りだした時期と重なるから、案外この分野の人々は同じようなことを思っている方が多いかもしれない。

しかし、実際に創業者の人と会ってサービスに対する思いを聞いた時、その思いは一変した。キッチハイクは、近年の企業で稀に見る “理念ベース” の企業だ。会社として実現したい未来があってその思いを社員全員が共有している。特に創業者の2人の思いの強さは尊敬に値するほどだ。本書を読めば、著者の思いの強さのベースとなった体験について理解することができるだろう。

終わりに

キッチハイクはつながりだ。これはあくまで私の感想に過ぎないけど、緩くなりがちだった現代の"つながり"をより強めるための一つの方法だと思う。今後、キッチハイクが Facebook 以上の人との深いつながりを実現するサービスになることを期待したい。

テクノロジーが変える未来について思いを馳せる

ども、@kimihom です。

今回はこんな本を読んでみたので感想をまとめてみる。

〈インターネット〉の次に来るもの―未来を決める12の法則

〈インターネット〉の次に来るもの―未来を決める12の法則

確実にやって来るであろう未来

ネットで流れて来るニュースを眺めていると、「新しいテクノロジー/ビジネスが登場!」というようなタイトルを目にすることが多いけども、ちょっと読んでもそれらの生まれた具体的な背景までを知ることはできない。とりわけインターネット業界に精通していない方であれば、最新のテクノロジーは何があって何を目指しているのかを理解することは難しいだろう。でも、新しいテクノロジーは LINE が一般家庭にまで普及したように、いつかどこの家庭にもやって来るものなのだ。

本書は最新の技術が進化して行った先に、どんな世界が待っているのかを “不可避なもの” として表現していた。

“不可避なもの” の傾向を、動詞としてまとめていた。その動詞を強引に名詞として挙げるならば、例えば AI / IoT / ビッグデータ / VR / ロボット / シェアリングエコノミー などがある。最近これらワードを聞くことは多いけど、"不可避なもの" が発展した 5年 10年先のことをあなたは考えたことがあるだろうか?

例えば、 AI が人間以上に賢くなった (シンギュラリティーを迎えた) とき、私たち人間の立場はどうなる? 眼鏡や時計、体内に埋め込まれたチップなど、あらゆるものがインターネットに繋がったときにどうなる? 人間の五感すべてをハックし、別世界へと飛び立てるようになったら?人間の脳を操作できるようになったら?….

こんなことが数十年で現実になってしまうのだ。私たちはその流れに抗うことはできても完全に止めることはできない。テクノロジーってのは進化を常に続けていくものだ。例えば一時的に法律で固めたとしても、人が決めた法律自体がなくなっていくのは時間の問題だ。今 Uber のようなサービスを止めようと一部の業界が躍起になっているけども、どこかの誰かがそれをこっそり始めて圧倒的なサポーターを味方にすれば法律だって変えられてしまう。そんな感じでインターネット自体も歴史の中であらゆる課題にぶち当たって今まで成長してきた。

現在一部の人がやっているだけの最新のテクノロジーは、3年もすれば一般に普及し、5年もすればそれをやらないほうがおかしいレベルにまで変わっていく。スマートフォンを例にとれば明らかなことで、このスピードは今後ますます速くなっていく。インターネットの与えるスピードの力でね。

私たちは確実にやって来る未来を受け入れる必要があるってことだ。

私たちはどう対処していくべきか

不可避な現実に対して私たちはどう対処していくべきなのだろうか。もちろん自分がその未来を作る側に入ることだってできるだろうけど、99% 以上の人はその未来の流れに乗っていく運命にあろう。

個人的に思うのは、"為せば成る" ということだ。かつて(今でも)あんだけインターネットが人に悪影響を滅ぼす的な批判を言われているけど、発展に発展を重ねた今、そう思っている人はどれだけいるだろう(ほとんどいない)。逆にインターネットで情報が透明化されて、より良い未来に近づいている。当然悪い方向も考えたらあるにはあるけど、生活レベルは確実に上がっている。なぜなら、今ある不便を解決するために私たちはインターネット上で考え働き続けているのだから。

ネガティブな未来を恐れる必要はない。そのようなネガティブな未来は、必ず未来の人がその解決策を掲示してくれる。そうやって市場は回っていくのだ。ネガティブなことがあれば、あなたがそれを解決して周りから感謝される存在になれるのだ。時代が進化してもどんどん仕事は生まれていく。

“ロボットが仕事を奪う” ってのは、今の仕事しかできることがない人が言うセリフであり、柔軟に時代のニーズを感じ取って自在に行動を変えられる人には全く問題にならない話ではないか。そう思った時、私は気楽になった。今の時代を生きる人間として、起きている課題を解決して顧客に正しいプロダクトを提供する。今も昔もこれの連続で人は生き続けてきたのだ。だから不可避な未来が来たとしても、柔軟に時代の流れを読み、人々の不便を解決する何かを提供すれば良いのである。"変化についていけない" と言うのは、マラソンにおいて自分の実力と割に合わないペースメーカーの後ろをついていく姿のようなものだ。しっかりと時代の流れと同じくして自分のペースで走り続ければ、変化についていけないってこともないだろう。

私としては時代に引っ張られる(流される)ような存在ではなく、常にリードし続ける存在でありたいと思う。そのためには当然たくさん勉強をしなければならないし、最新の動向を気にし続ける必要がある。大変だけども吸収し続ければテクノロジーの不可避な存在を、自分自身で操れるようになる。このような時代の変化を味方につけることが、今後さらに求められて来るのではないかと思っている。

取捨選択を誤るな

このような本を読むと、真っ先に最新技術に飛びつきたくなる気持ちが芽生える。しかし作ろうとしているモノが “今” まさに求められているのかどうかをよく考える必要がある。この点に関して私は慎重派だ。最新テクノロジーよりも、今の時代の顧客が求めているものがあるのではないか。Airbnb のような仕組みは 10年前に作れたけども今になってようやく普及してきたのは、インターネットの中で匿名ではなく実名個人が証明できるようになって責任が持てるようになったからだ。そのように、最新テクノロジーが普及するには何かしらの条件があったりするし、"今" の時代の顧客が本当に求めているのかはわからない。

だから私としては最新テクノロジーの動向に目をむけつつ、今の顧客が本当に求めていることは何かを見失うことはしないようにしたいと思う。 「これからは AI や! 」と言ってサービスをやみくもに AI 化しても意味がない。顧客が本当に AI を使ったソリューションを求めているとわかって初めて使っていかなくてはいけない。

本書を通じて新しい発見もあったし、自分の思いを再確認することもできた。

こうして私はまた明日から、目の前にあるサービス改善に精を出すのである。

良いコードを書くために意識していること

ども、@kimihom です。

今日はこちらの本を一気読みしたので、それの感想と自分の思うところを書く。

良いコードを書く技術 -読みやすく保守しやすいプログラミング作法

まず、著者の縣さん。リモートで1回/リアルで1回お会いしたことがあるのだけども、個人的にものすごく尊敬している方だ。というのも、日本で自己資本x自社サービスで軌道に乗せた第一人者的な立ち位置にいるエンジニアだと思っているからである。私も自己資本自社サービスでやってる会社の CTO なので似ている部分がある。彼はメールで連絡したら、名もない一人のエンジニアの私が作ったサービスをすぐに登録して使ってみてくれて、フィードバックをくれた方だ! あの時の感動は今でも忘れられない。この体験を通して、私も自社サービスがうまくいってきたら、その後に出てくる色々な Web サービス開発者を投資以外で支援できるような人になっていきたいと思ったほどである。

そして本書を読んでみたら何と自社で Web フレームワークも作っていたという過去を知った。まさに日本の Basecamp だなぁと改めて感じた。おそらく国産 Ruby on Rails 的な立ち位置を目指してそのフレームワークの開発は始められたのだろう。実際、当初は Seasar はかなり盛り上がっていたからな。この開発は結局止まってしまったみたいだけど、オープンソースの Web フレームワークに関して今度お話を聞いてみたいなという純粋な感想を抱いた。

良いコードを書く

さて、だいぶ個人的な体験の前置きが長くなってしまたので本題に移ろう。本書を読んでみて思ったのは、「そうだよね」っていう同意が90%以上。本を通じて言語化されていたように思える。私も前職ではコードレビューをひたすらやっていた経験もあったりして、そこら辺の基本は身についていたのだろう。独学で磨き上げのスキルで育った方には、一回読んでみると一般的な企業がどんな視点でコードレビューしているのかとかがわかって、より良いコードが書けるようになるかと思う。

さて、以下は私が思ういいコードを書けるようになるための方法について書こう。

「誰かが書いたひどいコードを読む」ってのはまず一つ目にいい方法だと思う。そのひどいコードってのは、改善の宝庫だ。どの分をどうまとめて、効率よく書けるのかを一緒にコードを書いた人と議論することができる。そうしてレビューする人とされる人それぞれが成長できるのである。コードレビューのいいところってそこだよね。

そういうのは基本的にフレームワークに乗っかったコードなので、基本的にはちょっとしたメソッド分けとか、やったとしてもクラスに分けたり程度だろう。そこから先のいいコードを書くためにはどうしたらいいか。

私はバッチフレームワークを書いてみるのをお勧めしたい。 Web フレームワークはもう世の中に出回ったのを使えばいいし、基本的な認証とかも全部ライブラリで揃っているから、車輪の再発明ってのはあまり楽しくないと思う人も多いことだろう。しかし、バッチフレームワークは割と自前でゼロから書く場合が多く、これはデザインパターンとかを駆使して構造化された正しいコードを書くのにいい練習になる。そもそもデザインパターンってのも、いいコードを書こうとして考えた結果のパターんをまとめたものに過ぎないので、それなりに訓練の詰んだエンジニアが共通認識として言語化された程度のものである。だからまずはしっかりとコードを書くってのが大事だ。

私の場合は、あらゆる外部サービスと連携して顧客データをインポートしたりメッセージを外部サービスに送ったりするようなツールを作っている。それぞれの外部サービスを ストラテジーとして定義し、差分以外の部分をフレームワーク化して共通にしていくのである。結局フレームワークってカッコよく言っても、ちょっとずつ共通化して使いやすくしていく改善に過ぎないので、恐れずに始めて行けばいいんじゃないかな。

ちなみに、ちょっとプログラミングできるようになると黒魔術たっぷりなメタプログラミングなコードを書くことになる。そして後で使ってみるとめちゃめちゃわかりづらくメンテしづらいものができたことに気づくだろう。このような後悔もやればわかるから、後悔するほどにメタプログラミングにどっぷりやってみるのをお勧めする。

オープンソースのコードを読むってのはよく言われる訓練の方法だが、ゼロから読んでいくってのは集中力が続かないので、バグが起きたら徹底してコードを読んで原因を探るような習慣をつける程度でいいと思う。もしうまく見つけられたら Github でプルリクエストを送ればコントリビュータにもなれるし一石二鳥だ。

いいコードを書けば、サービスに愛情が湧く

良いコードを書くってのは大事だ。良いコードでできたサービスは、大切にメンテナンスしたくなる。より良いコードにするために既存機能を壊さずにリファクタリングを積極的に行ったり、そのためにいいテストコードを書いたりする。もっとこうしたら良くなる、ってのをどんどん手をつけて、余計なものが削ぎ落とされた、それはそれは美しいコードってのが出来上がる。 これはもはやプログラマの美徳のようなものだ。

逆にたくさんの人が手がつけて汚くなってしまったサービスのコードはメンテナンスしたくなくなる。そうすると、できるだけ傷をつけずに用件を満たせるような方法を探るようになる。そんでたまにバグの沼にはまってしまった時は「アチャー、ついてないな」と思いながら時間を潰すことになる。そんなサービスのメンテナンスはつまらない。

ここまで書けば、どっちがいいかなんてのは明確だね。必ずいいコードを書こう。そして妥協は絶対にしないこと。未来の自分の宿題を作らないこと。そういうプロフェッショナルとしてのプログラミングを行えば、今後の自分はよりハッピーになる。

そのためには、中途半端なプログラマを雇ってはいけない。彼らは何も考えずにコードを汚していく。コードレビューって言っても、その汚いコードに対して全部書き直せ!なんて言えない場合もあり、基本的にできない人が書いたコードが積もってどんどんとサービスのコードを汚していく。本物のプログラマは、サービスのコアのコードであっても、ダメなコードなら勇気を持って削除して描き直せる人である。そういった人が起こしたバグを責めてはいけない。むしろそれで良くなっているのだから、テストコードなどをしっかりと書いてサポートすべきなのだ。

「機能変わらないのに時間かけてプログラミングするって意味あるの?具体的に言うと今後の開発でどれくらい工数が削減されるの?」とか言うビジネス野郎の意見なんて無視してしまえ。彼らはプログラミングのプの字も知らない奴らだ。サービスのメンテナンス性や柔軟性を高められるリファクタリングがどんだけ大事かはプログラマにしか具体的な効果を実感できないのだ。

そのような強い思いがより良いコードを生むための源になるだろう。サービスやソースコードに強い意志を持っている人が結局はいいエンジニアになっているのである。

終わりに

みなさんのサービスのソースコードは美しいだろうか?

ソースコードの美しさは、今後のサービス開発で必ず他サービスに比べて優位に立てる要素になる。より柔軟性の高く、より読みやすく、より効率の良いコード。それが私たちの目指すソースコードだ!

「風立ちぬ」を見ての感想

ども、@kimihom です。

さて今回は風立ちぬって映画を見たので、それについて思ったことを書いてみる。タバコ吸いすぎだが、いい映画だった。

風立ちぬ

風立ちぬ

以下は私が受け取った感想ってだけなので、まぁあんまり深く突っ込まれたりすると困るので気軽に読んでいただけたらと思う。

"矛盾"

私がこの映画で一番しっくりきた言葉が「矛盾」である。主人公の同期でライバルである本庄が雑談めいて話していた矛盾についてだが、この映画全体に言えることのように思えた。

P.S. この記事書いた後に調べてみたら、宮崎監督自身が「矛盾」って言葉を使ってこの映画を表現していて、びっくりした

その矛盾に対する自分の答えを、宮崎駿はそろそろ出すべきなんじゃないか。僕はそう思った。年も年だし。これはやっておくべきじゃないか、と」(2013年5月9日、東京新聞より)

私が宮崎アニメで一番すきな"耳をすませば"と、この"風立ちぬ"はかなり大きな相関を持っているように思う。"耳をすませば"では、自分の信じる道を生きるその美しさを私たちに教えてくれている。しかし、この"風立ちぬ"は、夢を追い続けることで失ってしまう代償のようなものをリアルに描写しているように見えた。

この映画の最大の矛盾は、彼は純粋に飛行機を作りたいのに、それは戦争に使われるということだと思う。自分が作りたい飛行機を作ったら、それはたくさんの人を殺してしまうのだ。それでも彼は飛行機を作ることを選択した。そして妻が結核という難病を患っていたのにも関わらず、彼は仕事に打ち込んだ。それほど彼の夢への意識は強く、空を自由に飛ぶ飛行機の設計士になりたいという思いに向かって忠実に動いていたのだ。

しかし、大きな夢を実現した(最後のシーン)瞬間、今まで大切にしてきたものを失ってしまったことに気づく(妻や飛行機に乗った人々)。それはもう終わったことで戻ってくることはできない。夢に向かって突き進んでいった結果、同時に多くの人を亡くしてしまったのだ。その矛盾に対する悲しさや現実と向き合って、それでも生きねばならない。私にとって"風立ちぬ"はそんな映画だった。

私が大好きなシーン

風立ちぬの後半はそりゃあもう悲しい悲しいの連続なんだけども、その中で私がとても大好きな1シーンがある。それが、主人公の彼が主催となって開催した「自主的な勉強会」だ。その空間にいる人たち全てが目を輝かせ、未来の理想の飛行機について語り合っている。彼らの目的は「いい飛行機を作る」それだけであり、その先どんな使われ方になろうとかは一切存在しない。男たちの夢とロマンが詰まったあのシーンはこの映画で最大の見所だと思う。こちらもワクワクするし、あのシーンで得られるワクワクな心こそ、夢に向かって突き進んでいる状態そのものような気がしている。夢を見つけ、何かに夢中になった時に得られる高揚感をあのシーンでうまく表現されているように見えた。

私が抱える矛盾

さて現実に立ち返って、インターネットの世界に生きる私の矛盾についてもちょっと触れておきたい。

「インターネットは人々の生活をより便利にした」とはよく言われる。確かにインターネットで人と人との距離は劇的に短くなったし、今までやっていた作業は全部自動化され、あらゆるものがコンピュータに置き換わった。

しかし、私はインターネットこそが現在の不況や格差を生み出している根幹のような気もしているのだ。今までコンピュータがなかった時は、その作業を「人」がやっていたわけで、それだけで仕事がたくさんあったのだ。それが全部コンピュータに置き換わった今、その人たちがやれることっていうのはどんどん失われているし、今後もロボットが台頭すればますます格差は広まっていくだろう。

そんな中で私たちは常にイノベーションという言葉を使って、人々の生活を変えようとしている。その変わった先にあるのは、便利になったという明るい話の反面、その裏でたくさんのものを失うこととなる。

それでも私はやらなければならないというか、やりたいのだろう。主人公が空へ抱いていた希望のように、私も私が作ったサービスでたくさんの人に影響を与えたいと思っている。それこそが彼が空に描いていたロマンのように、インターネットが存在するのだから。

"生きて"。風立ちぬで最後に放たれる言葉だ。色々な矛盾と戦いながら、私たちはこれからも生きていかねばならない。

情熱プログラマーを読んで感じた学び続けることの重要性

ども、@kimihomです。

週末は図書館で気になる本を読むのが最近の日課。地方の図書館だと学生ばかりいて、さながら受験勉強のような感じで読書ができる。

さて今回読んだのは 情熱プログラマーって本。

開発者としてあるべき姿的なのが書かれていた。

とにかく学び続ける

全体を通して感じたのは、好奇心を持って学び続けることの重要性。そして技術的なコミュニティやOSSに絡むことで、自分のブランドや、技術力そのものが向上できるといったことが書かれていた。

例えば日本では "今はとりあえず Java を学んどけば仕事に困らない" 的な流れがあると思うが、その風潮がいつ変わってもおかしくないし、特にJavaは企業プロダクトなのでその会社がダメになったどうなるのとかそういうリスクをはらんでいる。だから Java だけしか書けませんってのはリスクがある。 あと Java ならできますと言っておいて、JVMの細かいところを知らないような人が、Javaの専門家ですなんて名乗っていいのかってのも問題としてある。ほとんどのプログラマーはとりあえず書けるってだけで Java ができますと言ってしまう。これは問題だ。

Javaしかできないと言うのもやはり問題だ。どんだけその言語のプロフェッショナルでも他の概念を知らないと時代に取り残されることになる。 関数型言語とか動的な型付け言語を学んでみるとかそういうチャレンジが新しい発見につながる。全ての点が繋がり、本当に理解したプログラマーはどんな問題が起きても適切に対応する力を身につけることができる。

でも仕事じゃそこまで必要とされることがないから、それ以上は勉強しない。そんなエンジニアばかりが世の中に出回っている。技術が好きでなければ休日を利用してまで勉強するなんてことはできないから、エンジニアはできるできないの差が激しすぎる。できないエンジニアはプログラミング全行程を遅らせる要因にしかならない。ひどいソースコードはバグだらけのシステムを生み出す。

私ができないエンジニア100人よりできるエンジニア1人のほうが生産性が高いと思っているのはまさにこのこと。

仕事だけで燃え尽きるな

今回私が最も考えさせられたのは「仕事に全力になりすぎて学ぶことをおろそかにすると、それ以上のプロダクトはできない」ってことだ。今は自分は CallConnect の開発に100%注ぎ込んでいて、休日も開発していたりした。

ただこれだと今の自分の能力以上のプロダクトはできないんだよね。より高度な技術や専門的な知識がいるようなことは自分が休日を利用してサービス開発してでも作ることはできない。

だからこそ、自分を高める時間をもっと作らなければならないと痛感した。具体的には仕事はちゃんと時間通り終わらせて、そのあとは勉強に時間を使う。休日は開発ではなくて勉強に時間を使うといったことをやっていこうと思った。

それは以前の自分に似ている。企業に勤めていた頃は起業の準備に向けて必要な技術を空き時間で必死になって勉強した。それは誰かに言われてとかじゃなく、自分の使命感からくるモチベーションだった。今起業して自分でサービスを0から作っているが、基本的なことは全て独学で習得した。そしてこれからも独学で学ぶこと以上に効果的な技術の習得方法はないと思う。

"自分のサービス開発が大事だからこそ、時間を作って自分の技術力を高める。"

その思いを持って、これから過ごしていきたい。てことで、このブログも新しい技術を学んだ時のアウトプットの場として、利用していきたいと考えている。

RedisはRDBの次に学ぶべきDBかもしれない

ざっくりとではあるが、以下の本を一読した。

日本語でRedisについて詳しく書かれた本はこの本くらいしかないかと思うが、それでも次のレベルを目指すWebエンジニアにはお勧めしたい本であった。

ただ、注意していただきたいのは本書は全く入門向けではないということ。確かに前半はコマンド一覧のような説明はあるが、後半からはがっつりと実戦的な内容が書かれている。本書はRedisの説明ではなく、Redisを使って一般的な問題をどう解決するか、ということに主眼が置かれている。

そういった意味で私も一回読んだだけでは到底全てを理解することはできなかった。時間をかけて他の文献も参考にしながらもう一度じっくり読みたいと考えている。

近年のサービスはRedis主体で作られる

もっとも有名な例はLINEだ。あれはペタバイトクラスのRedisを立ててメッセージをやりとりしている。本書にはチャットシステムの構築のヒントも書かれており、メッセージングシステムを構築するのにRedisが優れている点が説明されていた。

そのほかにも、転職システムやTwitterタイムライン、広告配信システム、ログ集計など最近のスタートアップが好んで扱う分野についてサンプルコードを含んで丁寧に説明されていた。それらスタートアップのほとんどは本書を参考にシステムを作ったのではないか、とも感じた。インフラの技術が進めば作れるサービスも変わる、ということを実感できた。そしてRedisが登場したからこそ今までできなかった大規模データ処理サービスが実現できるようになったのだとも言える。

RedisはSQLを書き換える?

Redisは本当にいろいろなことができると知った。今まではちょっと高機能なKVS(Key-Value Store)くらいにしか思っていなかったのだけど、そんなことはなくリレーショナルデータベース(RDB)並みの機能をRedisだけで実現できてしまうのだ!

ただReidsだけで全てを作るのはおすすめできない。結局はKVSの拡張であって設計が大変難しいのと、実際に後からメンテナンスするときもRedisだけで作ったシステムはとても複雑なものになるからだ。例えばキー名を"user:124"にして、中身をハッシュにする。といった設計でやっていく訳だがこれだけでもちょっとトリッキーな感じがしてしまう。

ではどういうときにRedisを使うべきなのか。それは高負荷がかかりそうな部分を補助するときに使う、という立ち位置だと考える。 大規模データを素早く処理したいときにRedisは威力を発揮する。

てことでそこまで負荷のかからない初期のスタートアップはぶっちゃけRDBだけでなんとかなると思う。それでサービスがうまくいったときに負荷のかかる処理をRedisに移行する、というやり方でいいような気もする。

それくらいRedisでデータ設計をするのは難しく失敗しやすい。

だからこそ、RDBの次に学ぶべきものとしてのRedisの立ち位置がもっとも良いのではないか、と思った。

現在のRedisの利用

今運用しているCallConnectでは、Redisを利用している。といってもログインセッションをRedisに置いているくらいだ。ただこの用途だけでもCookieに保存していたRailsのセッションをセキュアに管理できるようになるので大変有用だと考えている。今後バックグラウンドジョブのキューイング処理にまたRedisを利用したいと考えている。

それと同時に今後負荷のかかりそうなデータ処理を扱う際にはRedisの利用を検討していく。

Effective Ruby を読んで

以前から気になっていた "Effective Ruby" を読んだ。 Effective シリーズは中級〜上級向けプログラマーの読むべき本として親しまれている。

個人的にもっとも得意な言語はRubyだったので、このシリーズが出るのを楽しみにしていた("得意な"と変換しようとしたら"特異な"と変換されるくらいには使用している)。

中身のネタバレはもったいないので、この本を通じて自分が今まで見落としていた点を挙げてみようと思う。

nil 時の対応

array = hoge()
array.split('/')[1] 

NoMethodError: undefined method hoge for nil:NilClassRubyプログラマーなら何度も遭遇するであろうこのエラー。配列でnilっぽくしたい時は空の配列を用意してあげたいところだが、その変数にnilが返ってきてしまうとこの問題に出くわしてしまう。

例えばある変数があって、それに array.split('/')とさせるとしよう。ここでarray変数がnilなのか、そもそも配列なのか、よくわからない。ちゃんとコードを戻って読まないといけない。

この問題を解決する素晴らしい手段が本書には書かれている。一体何でしょう?

なんでもかんでもHash使いたい

@hash = {}

@hash[:hoge] = hoge
@hash[:fuga] = fuga
...

これはまさしく自分だった。Hashを使えばコードを簡潔に書くことができる。特にRailsアプリなどではViewに渡すインスタンス変数をHashに変換し、View側でそのHashを取得するような処理を書くことは多いのではないだろうか。

しかし、Hashはなんでもかんでもキーとして詰め込むことができるため、このキーが一体どの部分で入れられたものなのか、コードを読み直す必要が出てくる。また、存在しないキーが出てきてもnilを返すだけで、例外を投げないため間違っているかどうかの判断がつかない。

ではどうするのがEffectiveなのか。一体何でしょう?

reduce をマスターせよ

本書で唯一 特定のメソッドに対して複数ページを割いて解説しているメソッドがある。それが reduceだ。これをわかりやすいサンプルとともに、ただ合計値を出すだけでない他のreduceの使い方を示してくれている。これにより、今まで無駄に書いていたあの処理が実はreduceで書き換えられるということを理解できるだろう。

終わりに

ある程度Rubyに慣れ親しんだ方なら、 何かしらのGemを入れ、気になった時はそのGemのソースコードを読む機会が何度かあったと思う。基本的にはそこから学ぶことが大変多いのだけども、この本はそれらの知識・ノウハウをよくまとめられているという印象を受けた。

対象としてはパーフェクトRubyとか読んだ後なら普通に読めると思うけど、Effective Ruby の場合はそれなりにRubyコードを実際に書いて運用した経験をした後によむと、「あ、こういう書き方ができるのか!」という発見があって楽しく読めると思う。

「ミッション」を読んだ

事業についてピッチをすると、毎回聞かれるサービスとしての「価値」。それについて一人で悩んでいても仕方ないということで、本を借りて読んでみた。

ミッション 元スターバックスCEOが教える働く理由

ミッション 元スターバックスCEOが教える働く理由

スタバの企業ブランドは「ミッション」にあり。 そのミッションを社員全員が理解し、行動することでマニュアルにはない不測の事態にもスタバ店員として対応できる力が身に付く。

強い会社は自らを考えることができる。なぜこの会社で働くのか。この会社の目的は何か。利益を得ること、というのは企業を続けるための手段であって目的ではない。本人が突き動かされている使命感というようなもの。それがミッションだ。

ミッションが一言で言い表させるもの程強いといわれている。ありとあらゆることに「なぜ」を突き詰めて、考えた行く先は、とてもシンプルなものに落ち着くということなのだろう。

これを実践できる人ってのはなかなか難しい。考えることを放棄する人の方が多い。自分もこうやって考えるのは苦手だ。でもだからこそそれを考え抜いたミッションは多くの人の心を引きつけ、素晴らしい会社としてのブランドが形成されていくのだ。

このミッション、すぐに見つかるはずが無い。本書の著者も見つけるのに相当の時間をかけたそうだ。だから焦る必要は無い。だけども自分の過去をひもとき、使命感みたいなミッションを掲げることを努力しなければならない。もしそのミッションが見つかれば、その人はそれに向けて努力し、実現することができる。なんか書いているうちに、夢や目標と同義になっている気がしてきた。

スターバックスはコーヒーを提供しているのではなく、人々の心の活力を与えるために活動しているそうだ。コーヒーはその手段でしかない。

自分も考えを切り替えなければならない。テクノロジーはツールでしかない。頭で思っていても、なかなか難しい。。 けどもっと自分やサービスに対して「なぜ」を考える習慣をつけてみようと感じた本書だった。