no strict

ちゃんとしない。面白いことからやる。

コモディティ化したサービスをムダに使うと次のビジネスが見えてくる:書評「フリー」

フリー 〈無料〉からお金を生みだす新戦略

フリー 〈無料〉からお金を生みだす新戦略

YouTubeクックパッドなどのウェブサービス、フリーペーパー、無料体験コーナー、スーパーの試食コーナーなど、無料で受けられるサービスは多数あります。なぜ無料でサービスが提供できるのか、その背景にあるものは何なのか、という点を掘り下げてまとめた本。

インターネットが普及してからは特に、無料で受けられるサービスがあまりにも多く、あまりにも当たり前になってしまいました。しかし、無料サービスをマネタイズすることはとても難しいことです。フリーミアムのビジネスモデルと成り立ちを理解することは、これからのビジネスモデルを考えるにあたり必須な気もします。

本書では、潤沢に供給されるものの価値は下落し、最終的には無料になると述べています。

人々が欲するものをタダであげて、彼らがどうしても必要とするときにだけ有料で売るビジネスモデルをつくるのだ。

とのこと。無料サービスで集客して有償サービスにシフトさせるとか、広告モデルとか、フリーミアムのビジネスモデルは成功が困難であることが多いですが、コモディティ化するものは対価をとらず、希少なものでフィーを得るという考え方は納得できます。

その上で、本書ではコモディティ化による価格の低下を前提に、その活用の仕方がカギとなるとも述べています。

今日の革命者とは、新たに潤沢になったものに着目して、それをどのように浪費すればいいかを考えつく人なのだ。

例えばムーアの法則により半導体の性能は年々向上し、CPU性能はある程度ムダに使ってもコスト的に問題ないものとなりました。開発手法で言えば富豪的プログラミングが可能となったわけです。 同じように、情報や人件費など、コモディティ化し、価格がゼロに近づいたものを思い切り使うことでそれまでできなかったことができるようになります。これまでの市場を理解している人であればあるほど、かつて希少で高価だったものは大切に、節約して使ってしまう。このようなものを意図的に浪費することで、事業機会が生まれるというわけです。 コモディティ化するサービスについては、多くの人にメンタルブロックがあるとも言えそうです。

本書ではこうまとめています。

フリーと競争するには、潤沢なものを素通りしてその近くで希少なものを見つけることだ。ソフトウェアが無料なら、サポートを売る。(中略)もしも自分のスキルがソフトウェアにとって代わられたことでコモディティ化したならば、まだコモディティ化されていない上流にのぼって行って、人間が直接かかわる必要のある、より複雑な問題解決に挑めばいい。

無料に見えるサービスはコモディティ化しているものであり、思い切り浪費することで何ができるのか、または無料の周辺に「希少なもの」が眠っている可能性がないか、などと思いを巡らせてみると新たなビジネスチャンスが見えてきそうです。

多くの気づきが得られた良書でした。

ランチタイムを開発の時間に当てたら半年でNode.js+Socket.io+Reactを使ったウェブサービスができた話

はじめに

「コードを書いているときが一番楽しい。プログラミングを仕事にしよう。」そう思って就職し、プログラムを書くことでお金をもらうことができた夢のような日々。でもそんな日は長くは続きませんでした。数年のプログラマ生活の後、徐々にマネジメントが主な業務になり、コードを書く仕事から離れてしまい、いつのまにか十年が過ぎました。かつて覚えた技術は、いつしか全て時代遅れになってしまいました。

俺はもっとコードを書く仕事がしたい。 SEだなんてつまらない。なぜか? ..

上記のエントリーにとても共感できました。気力・努力・技術力が足りないために何も書けず何も作り出せず、そんな状況に負い目を感じるような日々を過ごしてきました。

しかし、ある日発想を転換し、時間を確保して手を動かしてみたところ驚くほどスムーズに学習と開発が進み、半年間で最近のトレンドっぽい技術(ES2015/Node.js/Express/MongoDB/Socket.io/React/React-Router/Material-UI)でWebサービスを作ることができました。どれも初めて覚えた技術要素です。

折角なので、この学習プロセスをまとめてみます。

目的

最近の技術を使ってウェブサービスを作ること。

学習・開発方針

普段の生活の時間を削って開発に当てることは負担が大きいので、以下の2つの時間を使うことにしました。

  1. 通過時間に技術系の書籍を読む
  2. ランチタイムは60分きっちり開発に当てる

一念発起して夜中や早朝に時間を確保する、なんてことは自分にはできませんでした。この方針ならほぼこれまで通りの生活で毎日開発時間を確保できます。短時間ですが、毎日のことになるので前日やっていたことを忘れづらいのもメリットです。 ランチタイムを使うことで平日5時間、月に20時間、年間240時間を確保することができます。これだけあれば何かできるでしょう。

前提

保有スキル

10年前にLAMPでWebアプリケーションを作っていたことがあるものの、現在のフロントエンドの知識はゼロ。マネジメント寄りの仕事になっているため、仕事でコードを見ることはありません。エンジニアとしてはそろそろ使い物にならない感じです。

作るもの

昔から興味があったのでなんとなくチャットを作ることにしました。作り終える頃には別のものを作れるノウハウも得られるはずです。

学習・開発プロセス

1ヶ月目:技術の方向性検討〜基礎学習(読書)

チャットということで非同期通信を試してみることにしました。非同期通信でチャットを作る場合、Node.js + socket.ioが定番のようです。このあたりから覚えることにしました。 JavaScript周りの技術を使うことになりそうだったので、まずJS系の書籍を2冊とGithubの書籍を買ってきて通勤時間に斜め読み。なんとなく目を通して雰囲気をつかみました。読み終えたら細かい内容は忘れましたが、全体像がつかめました。

2〜3ヶ月目:プロトタイプ作成

一ヶ月間、通勤時間に技術の本を読んでJavaScriptが書けるような気分になってきました。いよいよ開発をはじめます。 でもいきなり白紙からコードを書くのは無理なので、コピペ駆動開発発動です。

  1. 以下のエントリーに書かれているコードを持ってきてそのまま動かす http://creator.cotapon.org/articles/node-js/socket_io-mongodb-chat-sample
  2. コードをgit/Githubに登録
  3. ソースの一部を修正→動作確認→git commit→動作がおかしくなったら以前のコードに戻す、の繰り返し。 動くものがあれば、少しづつ修正していくことができます。問題が出たらconsole.log()で原因を探って修正。大胆に変更してもGithubに残っているので大丈夫。 具体的には、拾ってきたコードをベースに以下のカスタマイズを施していきました。一から書いたりはできないので、それぞれぐぐって出てきたコードを適当に貼り付けて修正していくだけです。レゴブロックのようなものです。

    • Room分割
    • MongoDB導入
    • デーモン化
    • セッション管理
    • アイコンチャット化
    • LINE風表示
    • 現在の参加者リスト表示
    • BootStrapでデザイン付け
    • React.js/React-router導入

4ヶ月目:期初のため仕事が忙しく時間がとれず。

5〜6ヶ月目:プロトタイプを元にベータ版を再作成

プロトタイプは機能を動かすことを目的に適当にコードをツギハギに足していったものなので、かなり酷いスパゲッティコードになっています。 手を動かしているとES2015、Express、Reactの書き方が多少はわかってくるので、この段階で一旦コードを破棄してゼロから書き直すことにしました。 動いている見本があるので、うまく動かずに悩んだ時にはプロトタイプのコードを見れば解決できます。

プロトタイプからの変更点

  • 基本的にゼロベースで書き直し
  • ExpressのViewをJSXに変更(express-react-views)
  • BootstrapからMaterial-UIに変更
  • 簡単なデザイン付け(CSSで色を変える程度)

完成

以下のチャットサービスができました。シンプルなものですが10年間コードを触っていなかった自分がウェブサービスが作れたと思うと感無量です。

作ったもの→brunch.chat

  • 主な構成要素
    • サーバ周り
      • Docker/Rancher
      • Node.js: v7.10.0
      • MongoDB: 2.6.10
      • express-react-views: 0.10.2
      • socket.io: 1.7.3
    • クライアント周り
      • React: 15.5.4
      • react-router-dom: 4.1.1
      • material-ui: 1.0.0-alpha.20
      • superagent: 3.5.1
      • webpack: 3.0.0

サーバ・クライアントをJavaScript/Reactで統一したので頭の切り替えが不要で楽でした。今後、サーバ・クライアント間でコードの共有もできそうです。 開発環境・本番環境共にDocker上で動かしています。

まとめ

何か新しい取り組みが進まないという場合、マインド不足(精神論)よりもリソース不足を先に解消した方が良いと感じました。 手を動かすことによってのみモチベーションは向上するものでもあり、始める前にモチベーション不足を嘆くよりもとにかく行動する時間を確保し、無計画に非効率にだらだらと手を動かす方が良い気がします。結果的に短期間でモチベーションがあがり、楽しく開発を進めることが出来ました。

通勤時間は読書の、ランチタイムは開発のとても良い時間枠です。この2つの時間を活用することで、半年でウェブサービスを作ることができました。最近のフロントエンドの技術をざっくりと使ってみることもできました。 睡眠時間や土日を削るわけではなく、普段の生活は何も変えていないので特に負担なく開発を進めることができました。今後も気楽に続けられそうです。

ということで、今後もコピペ&ランチタイム駆動開発を続けてみようと思います。 ランチタイムに効率悪くダラダラと手を動かしてみるというやり方、オススメです。

補足:その他読んだ書籍

論理的な視野狭窄とは:書評「精神のけもの道」

精神のけもの道 (アスペクト文庫)

精神のけもの道 (アスペクト文庫)

おかしな人は沢山いるけれど彼らの中ではそれはおかしなことではない、というテーマについて現役精神科医が語る、人の正気と狂気の境目のようなエッセイ。

日常生活において、この人の行動原理や価値判断は理解できないな、ということはたまにあります。特に親戚縁者など親しい関係の人の行動などは、細かいことでも気になるものです。 多くの人が「理解できない」と感じる行動は奇行といえるけども、そこまでは言えなくても首を傾げたくなる行動をとる人は多い。

例えば、徹底的に部屋を綺麗にしないと気がすまない、ジンクスとして毎回何かをしないと気がすまない、壁な顔で嘘をつく、会うたびに毎回同じ話を繰り返すといったあたりです。

本書では、人間が焦りから視野狭窄に陥り過剰な行動をとってしまう心の動きについて、軽妙な語り口で事例が挙げられています。

あとがき対談によると、「精神のけもの道」とは

人間というのはどんなに頭が病気でも変なやつでも、基本的に論理的なのだと思っています。といっても、本人にとって論理的なだけで、ぜんぜん現実には通用しないんです。(中略)無意味に過剰なだけ。そんなとき、人は、「精神のけもの道」を歩いて行くという理解で書いていきました。

という定義なのだとか。興味深いです。

人のこだわりや癖がどこに起因するのか、ということに思いを巡らせると、もっと人に優しくできるようになるかもしれません。そんなことを思わせてくれた一冊。

伝説の漫画家、吉野朔実のエッセイ漫画も収録されておりお得な本でした。

スクラムの原典:書評「リーンソフトウェア開発」

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

2003年に書かれたアジャイル開発の指南本。 伝統的なウォータフォール開発からアジャイル開発に移行する際の要諦が詰め込まれています。内容はどれも現在に通用するものであり、14年も前に書かれたとは思えません。本書に書かれていることの多くはその後スクラム開発として体系化されたと言えるでしょう。いわば、スクラム開発の「原典」のような本です。

トヨタかんばん方式がなぜ優れているのか、短いイテレーション(スプリント)はなぜ必要なのかなど、開発プロセスを変革する必要性が語られており納得感が得られます。

実践してみたいメソッドが満載。

  • 七つのムダ一つひとつについて議論する
    • 未完成の作業のムダ
    • 余分なプロセスのムダ
    • 余分な機能のムダ
    • タスク切り替えのムダ
    • 待ちのムダ
    • 移動のムダ
    • 欠陥のムダ

というチーム内アンケートはやってみたくなるし

ほとんどの改善プログラムでは、マネジャーが作業者に仕事のしかたを教える。ワークアウトでは、それが逆になっている。つまり、作業者がマネジャーに仕事のさせ方を教えるのだ。

というマネジメント改善プロセスの話も面白い。

以下のような部分も、とても頷けます。

  • スケジュールによって作業を押し進める(プッシュ)のではなく、顧客のニーズが作業を引っ張る(プルする)ことだ。
  • まずサブシステムのインターフェース(結合部分)のみを開発し、うまく機能したら中身を作る
  • チームマネジメントはボランティアに接するように人に接すれば良い
  • モチベーションをくじかせる、最も簡単な方法の一つは「ゼロ欠陥精神」だ
  • 変更承認プロセスを気にするのではなく、変更に強い設計プラクティスを気にかける
  • 開発チームの各メンバーに、チームの専門分野が「浅い」分野を書いてもらう

従来型の製造のプロセスがなぜ変革を迫られたのか、スクラム開発の本質とは何なのかを考えさせられる一冊でした。 手法だけでなく、手法が産まれた背景を理解することも大切ですね

WithingsとMyFitnessPalを使ったら半年かからずに20kgダイエットに成功した

はじめに

2016年夏のある日、ふと思いました。

「いくらなんでも太り過ぎている。痩せよう。」

「痩せていたらいいのになあ」と思うことは日々あるものですが、思うだけでは痩せることはできません。今回ダイエットをするにあたり、何らかの行動の方向性、おおげさに言えば戦略が必要だと考えました。そして具体的な戦略を立てることで、5ヶ月間で大幅に体重を減らすことに成功しました。

体重の推移
f:id:launcelot:20170505020803p:plain:w300
89.2kg→69.2kg(マイナス20kg)
※期間は2016/08/06から2016/12/24の5ヶ月弱。

このエントリーでは、昨年考え実施したダイエット戦略についてまとめてみます。

ダイエット戦略概要

業務プロセスと同じように、ダイエットにおいてもKGI/KPI、アクションプラン、モニタリングが必要だと考えました。以下の四点が今回のダイエット戦略の概要です。

  1. KGI(究極目標)の設定
  2. 目標に至るための方針(仮説)の決定
  3. KPI(プロセス目標)の設定とモニタリング
  4. 行動計画

この4点を統合的に運用することが重要です。どれか一つでも不足しているとPDCAが回らずに破綻する確立が高くなります。特に(4)の行動計画を具体化し習慣化できたことが大きかったです。

具体的な内容

KGI 2016年末 68kgの達成
方針(仮説) 一日あたりの摂取カロリーを一定量に制限することで体重は減少する(はず)
KPI ・行動指標:一日の摂取カロリー量
・結果指標:現在の体重
モニタリング基準 ・一日の摂取カロリー量:一日1200kcal以内(1000kcal〜1200kcalを想定)
・体重:減少傾向が週次単位で継続しているかどうか。
行動計画 (1)低カロリーで満足感を得られる食事の選択
(2)夕方に間食
(3)OK/NGルール設定

KGIの設定

「普通の体型に戻りたい」という動機だったため、年内に標準体重に到達することをKGIとしました。自分の身長は177cmなので標準体重は68kgです。
この数値がKGIとなりました。(結果的にはわずかにこの目標には到達しませんでした。)

目標に至るための方針(仮説)の決定

ダイエットの手段としては、以下の二つを検討しました。

  1. 摂取カロリー制限
  2. 糖質制限

摂取カロリー制限ダイエットは過去に試して痩せることができた手法です。近年大ブームとなっている糖質制限ダイエットについては理解が浅かったため、今回は(1)のカロリー制限を選択しました。今後、糖質制限についても検証してみたいです。

KPIの設定

ダイエット手法を「摂取カロリー制限」と決めたので、過去のダイエット経験からKPIを設定しました。

行動指標(一日の摂取カロリー量):1200kcal以下

成人男性の基礎代謝は1600kcal〜1800kcal程度なので、これを下回るカロリー摂取量であれば痩せる可能性が高いと考えて上記のKPIとしました。単純な引き算です。

結果指標(現在の体重):体重の減少トレンドが週次単位で継続しているかどうか。

ダイエット中は体重は大きく上下しながら減少していくため、前日と比較しても減少傾向なのかどうかの判断はつきません。前週同日よりも減少しているかどうかを指標としました。
後述のWithingsを用いると体重の平均移動曲線が表示されるため、減少トレンドにあるかどうかを簡単に判断することができます。

KPI(プロセス目標)の設定とモニタリング

KGI/KPIは設定するだけは不十分であり、KGI/KPIが常に達成トレンドになっているかをモニタリングすることが必要です。
KGI/KPIは日次でモニタリングするルールとしました。モニタリングは非常に重要な要素であり、この作業を簡単にできるようにすることは目標達成のための成功因子の一つです。

行動指標:一日の摂取カロリー量

f:id:launcelot:20170505024317p:plain:w350
摂取カロリー量のモニタリングにはMyFitnessPalを使用しました。
毎回、摂取した食品のカロリーを調べて記憶することはあまりにも面倒です。MyFitnessPalを使えば簡単に食品のカロリーを調べて記録することができます。膨大な食品データベースから商品名で検索できる他、コンビニ食品などの多くの食品はバーコードをスキャンすることで登録することもできます。MyFitnessPalに登録されていない食品はGoogleで調べて「クイック追加」でカロリーを登録すればOK。例えば、自分の場合飲み会は一回800kcalとしています。

一日に摂取できるカロリーを「1200kcal」と定め、その中でどうやりくりするかはゲーム的な楽しさもあります。何かを食べたらMyFitnessPalでカロリーを記録することを習慣化することで、楽しみながらカロリーを管理することができました。

【異常値の対策】
一日に1200kcalを上回る量を摂取してまった場合、翌日、翌々日のカロリー摂取量を控え、数日間の平均摂取量がKPIを下回るようにするルールとしました。

結果指標:現在の体重

体重のモニタリングには、Withings WS-50を使用しました。
以前、オムロンの体重計を用いて、体重、体脂肪率、骨格筋率など細かい数字を記録してはてなグラフに書き写すということをしてみたことがありますが、あまりにも面倒で継続できませんでした。

Withings WS-50であれば乗るだけで体重・体脂肪率が計測でき、自動的にウェブサイトとアプリにデータが反映されるのでとても簡単です。一つのボタンを押す手間すらありません。
起床後にこの体重計に乗ことを習慣化することで、とても簡単に体重がモニタリングできるようになりました。

【異常値の対策】
体重は結果指標でありコントロールすることはできません。コントロールできるのは行動のみです。幸い、体重が週次で減少トレンドにない時期と、同時期の平均摂取カロリー量には明らかな相関関係が認められたため、異常値を元に摂取カロリー量をKPIの範囲に収めることで、体重を減少トレンドに戻すことができました。

(つまり、週単位で食べすぎる日が続くとすぐに体重は増えるということです。当然ですね。)

行動計画

次に行動指標である「一日1200kcal」を達成するための行動計画を立てました。具体的には以下の3点です。この行動計画が重要なポイントでした。

  1. 低カロリー食品の活用
  2. 夕方のおやつ
  3. OK/NGルール設定

1. 低カロリー食品の活用

一日1200kcalはかなりの低カロリーなので、このカロリー量でどう満足感・満腹感を得られるかが重要な要素でした。
幸い、低カロリー食品は非常に沢山販売されているので、この中で自分が美味しと感じる食品を選ぶことが重要です。無理なく続けられる食品がないとこの計画は継続できません。

私が食べているものは主に以下です。

特に大塚食品のマイサイズシリーズ、セブンイレブンのサラダチキン&カット野菜、ローソンの低糖質パンはカロリー量が少なくボリュームがあり、とても助かっています。
コメは一切食べていませんが糖質量は一切気にしていません。穀物はカロリー量が多いため、カロリー量を制限すると必然的に穀物を避けることになりました。

2.夕方に間食

自分は夜に沢山食べないとストレスが溜まってしまうので、一日1200kcalで過ごすためには昼食のカロリー量をかなり抑えなくてはなりません。そうすると、仕事が一段落する夕方に甘いものが食べたくなります。

一日1200kcalの範囲内であれば何回食べても良いルールなのでおやつを食べても良いわけです。そこで、夕方にビスケット二枚程度のおやつを食べることにしています(100kcal程度)。おやつを食べることで、過度な空腹の反動として夕食をドカ食いしてしまうことを回避することができます。

3. OK/NGルール設定

あらかじめ、行動のルールを明確に決めました。ダイエットのストレスや、モチベーションの維持に役立ちました。んでした。

【必ずやること】

  • 体重は毎朝測る
  • 食べた後はMyfitnessPalにカロリーを記録する
  • KGI(究極目標)を毎日確認(Withingsアプリに表示されます)
  • 体重が減少傾向を維持しているかどうかを確認する

【やってもよいこと】

  • 何を食べても良い(糖質でもお菓子でもファストフードでも)
  • いつ食べても良い(夜中でも)
  • 一日のカロリー摂取上限は多少なら越えてもいい(その後数日間で帳尻をあわせる)

私は夜に沢山食べたいタイプなので寝る前の食事制限はルールに含めませんでした。このルールであれば、深夜2時にカレーを食べてもよいわけです。

食事のモデルケース

ある日の実際の食事内容です。これで1122kcal。

まとめ

「◯kgにしよう」といった目標はすぐに立てることができます。体重計に乗ってみることもすぐにできます。ですが、それだけではなかなか目標達成には至りません。

どうすれば目標を達成できるのかという仮説と実現するための手段を確保し、達成トレンドになっているかどうかをモニタリングするという行動をまとめて行うことが、目標達成のためには重要です。
業務と同じく、生活改善においてもこのフレームワークが大きな成果をもたらすことを認識しました。

補足

体重が落ち着いてきたら、次は糖質制限についてKPIなど検討してみたいと思います。
ダイエットの要諦は血糖値のコントロールであるような気もするので、できれば血糖値をモニタリングしてみたいです。

おまけ:ダイエットに活用している食品

大塚食品マイサイズシリーズが最強です。

大塚食品 マイサイズ マンナンごはん 140g×6個

大塚食品 マイサイズ マンナンごはん 140g×6個

 

買いだめしているマンナンごはん。普通に美味しいです。

大塚食品 マイサイズ 欧風カレー 150g×10個

大塚食品 マイサイズ 欧風カレー 150g×10個

 

マンナンごはんと合わせると、250kcalでカレーが食べられる。素晴らしい。

大塚食品 マイサイズ チーズリゾットの素 86g×10個
 

マイサイズシリーズのおすすめその1

マイサイズシリーズのおすすめその2