迷走

友人と slack で話してて、「エンジニアとして生きていくためにはどうするべきか」という題の結論として離島に橋を掛けたい、といういい話をした。

2017年1月27日の深夜の会話。

star__hoshi [00:25]  
:thinking_face: これガチで動いたらすごいけどどうなんだろ

sjnya [00:29] 
htmlをjavaとかswiftに変換する感じなんかな

star__hoshi [00:30] 
なのかなあ、クソアプリが増えるのだけはやめてほしいな

sjnya [00:31] 
逆に考えるとネイティブエンジニアはちゃんとネイティブ要素考えないとって気になってくるな
ネイティブ要素だけで生き残れるのか…

star__hoshi [00:31] 
確かに

sjnya [00:32] 
webエンジニア極めたほうがニーズある気が

star__hoshi [00:32] 
まあ5年たったらスマホもオワコンな気がするんで、アプリに縛られない基礎的な知識とかサービスの概念とかそこらへん押さえとけって感じですかね

sjnya [00:33] 
あー分かる、そういうこと考えたことある

star__hoshi [00:33] 
web の方が明らかにニーズありますよね、 react-native キテるし、webフロントエンドに投資するのが一番コスパは良さそう

iOS やってて、iOSで最適に動かすためにはどうするかってのよく考えるんですが、それって iOS がなくなったら死ぬ知識なんでもっと根本的に OS がどうとか言語がどうとか設計とか知らないと死ぬなあという気持ちです

sjnya [00:35] 
そうだねー

コード書くのが楽しいから、目先の楽しさ追っちゃいがちになるけど、そういう先のこと考えないとだめだよなー

star__hoshi [00:40] 
といっても雇用は創出されるし、低レベルと言ってはあれですがもっとダメなエンジニアもたくさんいると思うので死ぬことはないですが、がむしゃらにコード書いてても成長しないなあと最近実感します

sjnya [00:44] 
スキルどうこうじゃなくてコード書くのが好きなんだからいいんだよ、的な言い訳してる感あるし、その言い訳のためにコード書くの好きだと思い込んでるだけかもしれないって思うことがある

冷静になるとコード書くよりも、パン焼いてるほうが楽しい的なw

star__hoshi [00:45] 
わかる

sjnya [00:45] 
本当にやりたいのかって思うと分かんなくなる

star__hoshi [00:45] 
というかおれにはコードを書いていく以外の人生が見えていないのでひたすらそれで高みを目指さねばならない、という強迫観念が強くて辛いところがある

もっと広い視野とか持てば人生楽になるのだろうな〜とか思う...

sjnya [00:46] 
あぁそれねー
無理にアイデンティティー化しようとしてる感

star__hoshi [00:48] 
そばとか1回も打ったことないけど、そば打ってみたらそれが天職かもしれないし、狭い IT 業界で色々考えるのもな〜という感じ

sjnya [00:48] 
ww

[00:49]  
hoge さんにこのはなしするとき、そば打ち題材にしてたわw

自分が本当になりたいものに自信がないのが原因だから、同じことばっかしないで人生経験つんで何か見つけなさいって結論だった

star__hoshi [00:50] 
そば打つか

sjnya [00:51] 
飲食のバイトとか楽しかったしなぁ

star__hoshi [00:52] 
コンビニバイトは何も身につかないし何も楽しくなかった

sjnya [00:52] 
コンビニバイト以外の何かだな

star__hoshi [00:52] 
早朝の新聞配達とかやってみたいな

sjnya [00:53] 
案外生き生きしてるかもね

shinyaozawa [00:53] 
土方おもしろいよ

star__hoshi [00:53] 
ITドカタ

物理でもの作りたい

sjnya [00:54] 
まじでやってみないと分かんないよなぁ

star__hoshi [00:56] 
不労所得で生きいけるようにして3年くらい色々やりたいけどそれただの自分探しの旅だわ

[00:56]  
アメリカ横断する意識の高い大学生みたいだな

shinyaozawa [00:57] 
橋作ろうぜ

star__hoshi [00:57] 
橋良い

shinyaozawa [00:57] 
離島にかける橋

star__hoshi [00:57] 
カッケェ

sjnya [00:57] 
あぁーいい

star__hoshi [00:57] 
本土と Dash 島つなごう

shinyaozawa [00:58] 
Dash 島って福島じゃねーの?w

sjnya [00:58] 
近いw

star__hoshi [00:58] 
それ dash 村では

[00:58]  
http://xn--50-hi4azc9fsf5155c.com/wp-content/uploads/2014/10/e.png (254KB)

sjnya [00:59] 
ばれてんのか

star__hoshi [00:59] 
荒らしに行くか

[00:59]  
海賊だ

sjnya [01:00] 
僕はもくもく会からはじめて世界広げてくよ

[01:01]  
今年は迷走してみよう!

star__hoshi [01:01] 
いいな

[01:01]  
スローガン: 迷走

sjnya [01:02] 
嫌いな人としゃべるとかもして、世界広げてく

star__hoshi [01:02] 
意識高い

sjnya [01:02] 
圧倒的成長

star__hoshi [01:03] 
やっていくぞ

「エッセンシャル思考」を読んだ

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

誰かの DeepWork の書評に「これならエッセンシャル思考を読んだ方が良い」などと書いてあったので読んでみた。

エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方で、本書の中で繰り返し述べられてたのは2点だと感じた。

  1. 本質的なことのみ行い、より大きな成果を出そう
  2. 本当に重要なことにのみイエスと良い、その他全てのことにノーと言おう

とにかく本当に大事なことにだけイエスをして、それ以外はノーと言うので、結果としてより大きな成果が出る、と言う感じ。わかる、しょーもない仕事はしない方が良い。

と言ってもなかなかノーと言うのは難しい。この前も悩んだ末に社員旅行と言うイベントにイエスと言ってしまった。行きたくないが、まあ断るのもアレだしと思ってイエスにしてしまった。

イエスと言ってしまうことはあるかもしれないが、ノーと言える基準はしっかり持っていきたい。

私はなぜソフトウェアエンジニアをしているのか?

話は変わるが、サンクスコストと言うのがある。一度やり始めたから後戻りができなくなって無駄にズルズル続けてしまうのは良くないので、早々に辞めろと言うやつだ。本書でも言及されている。

なぜいまソフトウェアエンジニアをしているのかと言うと、その職しか知らないから、と思っている。もちろんコードを書くのは楽しいし、ユーザに価値を提供できる仕事だし、合理的な会社が多い、などの理由もある。

そもそもコードを書こうと思ったのは、大学の周りの人がプログラミングをしててかっこいいと思ったからが5割で、暇だったからが5割。

そのコードを書き始めたのも大学の中盤からで早いとは言えず、最初の頃は勉強するのが辛くて仕方がなかった。中学高校から息を吐くようにプログラムを書いている人とは違う。数学も苦手で、高校1年の初めてのテストが赤点でそれからずっと苦手で、受験も日本史で入学した。仕事でコード書いててもつらい気持ちになることが多いし、毎日勉強しないといけないという焦燥感があるし、5年コード書いているのにオブジェクト指向も良くわからないし、デザインパターンも5個くらいしか知らないし、劣等感ばかりつのる。

つまり私はソフトウェアエンジニアに向いていないのではないか、という話である。

向いていないのであれば、それはサンクスコストなので早々に辞め別のことをした方が良い。
「ソフトウェアエンジニアに向いていないかもしれない」と思いながら「自分の仕事の本質」などを考えるのはおかしいのでは?と思ってしまっている。

しかしコードを書くのが楽しい時もあるし、適当にコード書いてる人よりかはまともなコードかける自信が付いてきたし、正直それ以外の職でどうやって働くのか全くイメージが湧かない。
結局ソフトウェアエンジニアとして顧客に価値を届けることに従事していきたい、という結論に達した。

IT と全く関係ない他の職も経験してみたい、パン屋さんになりたい、蕎麦打ってみたいし、ろくろも回してみたい。しかし他の職を体験したら絶対に「こんな非効率的な職業ありえない」と言うと思うし、ソフトウェアエンジニアに向いているのかもしれない。いや染まっただけか。


以下 wikihub 日報 のまとめ

読み始めた、半分近くまで来たので明日読み終わりそう。
Deep Work みたいな内容で、何かを選択することは何かを捨てることである、自分が何を選択すべきなのか考えよう、みたいな内容。
いわゆる自己啓発本ってやつっすね。

  • エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方
  • 今自分は正しいことに力を注いでいるか?を絶えず問い続ける
  • 優先順位を決められない人は他人のいいなりになる
  • 重要なことにイエスというために、その他すべてのことにノーという
  • 何かを得ることは何かを失うことであり、何が最優先か明確にしておかなければならない
    • 以前弊社で「結局ユーザって誰なんですか?」って聞いたら「全員です」って言われてキレそうになったの思い出した
  • トレードオフから目を背けても、トレードオフから逃れられない
  • 集中は歩いてこない、だから自分から集中できる環境に飛び込む
    • Deep Work で読んだやつだ
  • 遊びは大事、遊びはどこまでも本質的である
  • 絶対にイエスだと言い切れないならそれはノーだ

読み終わった。
いい本だったが、自分の考えとだいぶ近く「ウンウンわかる」という内容だったので読む意味はあまりなかったかもしれない。

  • 目的が明確でないと人を動かすことはできない、目的がわからないとやる気が出ない
  • 具体的で魅力的、意味があって覚えたい本質目標を立てよ
  • 絶対にやるべきこと以外の全てに対しノーということが大事
  • サンクスコストにとらわれずダメな行動をすっぱりきる
  • 授かり効果
    • 一度所有すると、それに価値があると思ってしまう
    • これは買う価値があるか?を考えそうでなければ捨てる
  • 人助けもいいが、問題を肩代わるのは逆効果
  • しくみ化
    • 無意識にできるようにすると良い
  • 確実に言えるのは、世の中に確実なことはない、ということだけ
  • 見積もりは1.5倍で考える
  • 仕事を減らしより多くを生み出す
  • 小さいことからはじめ、成功体験を通し、大きい目標を達成しよう
  • 習慣を作れればあとは勝手にうまくいく
  • 大切なのは「選ぶ」こと
  • 「本当に重要なのは何か?」それ以外のことは全部捨てていい

「オブジェクト指向設計実践ガイド」を読んだ

先日 「オブジェクト指向でなぜつくるのか」を読んだ が、内容が薄かったのでもっと濃いオブジェクト指向についての本が読みたかったので、先輩に勧められたこともあり読んでみた。
内容は濃くて良かった、こういう本が読みたかった。

特に良かったのが「オブジェクトがあるからメッセージを送るのではなく、メッセージを送るためにオブジェクトがある」とのところ。
自分はそんな真面目に考えたことはなく、軽い気持ちでクラスを定義しメソッドを作成してしまうので、そうではなく相互関係をちゃんと検討した上で実装すべきなんだなと思った。
そういうメッセージベースの考え方ができるようになると一段上に上がれるとのことなので、意識していきたい。

また、クラス内で具象化してしまうと依存度が高くなってしまい良くないので、 DI して依存度を外から設定できるようにしよう、というのが繰り返し述べられていた気がする。
ここはテスト書くときにほぼ必須なので最近気をつけている。

1つ疑問だったのが、この著者は静的型付を「コンパイル時間がかかる割にメリットが少なすぎる」と言って動的型付を持ち上げているところ。
別にそれはいいのだが、静的型付だったら何も意識しないで済むところを動的型付はテストを書くことでカバーしていて、静的型付にもメリットがあるところをちゃんと書くべきでは、と思った。

全体的な内容は良かったのだが結構難しく、正直あまり理解できない部分が多い… 3ヶ月後くらいにまた読み直そうと思っている。

以下 wikihub 日報 に雑に書いてた感想まとめ。


読み始めた。 Rubyオブジェクト指向についてガチで学ぶ感じになりそう、うわべだけのオブジェクト指向 ではなく真髄に迫る感じがして良い。

  • オブジェクト指向設計とは、「依存関係を管理すること」
  • 設計がないと管理されてない依存関係が大混乱を起こし、1つ変更すると他のが壊れてやばくなる
  • 設計は芸術と言えます、コード構成の芸術なのです。
  • SOLID
  • 前もって詳細設計を作るのは全く意味がない
  • アジャイルが成功するかはシンプル、適応性、柔軟性のあるコード
  • アジャイルは「どれだけの期間で完成するかわからない」を肯定するものであり、オブジェクト指向だってそう、完成時期はわからない

25%まできた。
ためになる!(いつもためになるって言ってる気がする)

Gear と言うクラスを愚直に作った後に徐々に綺麗にしていく流れ。
自分はメンバ変数をいろんなところで叩いてしまうのだが、この本によるとアンチパターンっぽい…。

  • 単一責任のクラスを設計しよう
  • シンプルであれ
  • 設計とはアプリケーションの可変性を保つために技巧を凝らすことであり、完璧を目指す行為ではない
  • TRUE
    • 見通しが良い(Transparent)
    • 合理的(Reasonable)
    • 利用性が高い(Usable)
    • 模範的(exemplary)
  • TRUE なコードを書くために、それぞれのクラスが、明確に定義された単一の責任を持つ ように徹底すること
  • 2 つ以上の責任をもってはいけない
  • クラスが実際に何をしているか、1文で表現できるか?
    • それと、またはみたいな言葉が出たら2つ以上の責任を負っている証拠
  • 設計を決める時、何もしないことで将来的なコストが変わらないなら何もしないで良い
  • 今と未来の可能性のトレードオフを理解しコストが最小になる決断をする
  • 変数はそれらを定義しているクラスからでさえ隠蔽しましょう
    • ruby の attr_reader を使う
    • ジャバで言うと getter, setter かな?
  • メソッドもクラスのように単一の責任を持つべき
  • 1つのこのに専念するクラスは、その1つのことをアプリケーションの他の部位から「隔離」する
  • クラスが知るべきことは自身の責任を果たすために必要十分なことのみ
  • dependency injection で依存をクラスの外にだす
    • Ruby は Interface ないから DI できないと思ってたけどそもそも動的型付だから Interface とかいらないんだった…
  • 場合によっては依存を隠すのではなく、逆に依存部分を強調することでわかりやすくする
  • 初期化の引数にハッシュやデフォルト値を使うとわかりやすい
  • 初期化の引数を変えられない場合(3rd party ライブラリとか)はファクトリーでラップすると良い

オブジェクト思考はクラスがどうこうではなくメッセージをどう送り合うか、と言うことらしい。
正直あまり理解ができてない点が多く、自分は全く理解できてないだなと言うのを理解できて良い。

  • 自身より変更されないものに依存しなさい
    • 具象クラスは抽象クラスよりも変わる可能性が高い
    • 多くのところから依存されたクラスを変更すると広範囲に影響する
  • 変更が多くかつ依存するものが大量にあるとやばい
  • 依存関係の管理で鍵になるのはその方向を制御すること、また自身より変更の少ないクラスに依存するべき
    • Clean Architecture の思想は依存を一方方向にするしそう言うことなんかな
  • オブジェクト指向アプリケーションは「クラスから成り立つ」がメッセージによって「定義される」
  • クラスが何を「する」かではなく、何を「明らかにするか」
  • クラスに基づく設計ではなくメッセージに基づく設計ができるようになるとキャリアの天気になる
    • このクラスがどうするでなく、このメッセージを送る必要があるがどうするかみたいに考えられるようになれ
    • オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する
  • public, private などは明確に意図を持ってやれ
    • rails は private method の先頭に _ をつける (知らなかった…
  • デルメルの法則
    • オブジェクトを疎結合にするための規則
    • 異なる二つ目のオブジェクトを介すことを禁じる (ドットで2つ以上繋ぐな、 music.song.artist とかはドットが2つ繋がれている)
    • 遠く離れたものに依存しているのは影響に気がつきにくくよくない
    • この法則に違反している場合インターフェースがよくないことが多い
  • オブジェクト指向オブジェクト指向間で交換されるメッセージによって定義される、そのメッセージは public interface にそって行われる

真ん中まで読んだ。
ためになる!のだが、静的型付と動的型付を比較し、最終的に「いいから動的型付は最高なんだよ」みたいに押し付けっぽい感じになっててかなり萎えた。
それぞれ良さはあるし、「私は動的型付けの方が良いと思っています」と主張を述べるだけのが良いのでは、この本の内容全部押し付けなのかなと思ってしまう。

  • ダックタイピング
    • DI みたいなもんっぽい、ダックタイピングの概念がしっくりこないまま読み進んでしまっているので結局なんだっけと言う感じになっている
    • 具象クラスに依存しないで抽象クラスに依存しよう
  • 動的型付けに慣れればその方がよくやすく、描きやすく、理解しやすいと思うでしょう
    • お前んなかではな?
  • 静的型付によて安全になると言う考えは幻想です
    • お前んなかではな?
  • 動的型付けはコンパイル時の型検査と言うコストが高い割にわずかな価値しか得られないが、動的型付けは莫大な効率性がある
    • まあビルド時間長いのはつらいな
  • 継承
    • 根本的には「メッセージの自動委譲」の仕組み

65%まできた。 Module と Class の違いが述べられていたがあまりよくわからなかった、つらい。

  • 抽象のルール
    • モデル化しているオブジェクトが一般-特殊の関係をしっかりと持っていること
    • 正しいコーディングテクニックを使っていること
  • Ruby は抽象クラスが存在しないので具象化できてしまうが、みんな良識があるから問題がない
    • いやいや、それで問題があるから静的型付によって強制力を効かせるんじゃないの
  • 抽象クラスを作るときには、具象クラスのメソッドを抽象クラスに移動させた方がいい
    • 抽象クラスから具象クラスに移動させるのはやめた方がいい
  • テンプレートメソッドで継承うまくやろう
  • モジュール
    • 様々なクラスのオブジェクトが、一箇所に定義されたコードを使って共通のロールを担うための完璧な方法
  • is-a
    • class
  • behaves-like-a
    • module

75%。コンポジションとかの話、正直よくわからなくて、もう一度この本を読み直した方が良さそう :cry:

  • 一部のサブクラスだけ使うようなメソッドをスーパークラスに置いちゃメッ!
  • スーパークラスとサブクラスは置換可能でなければならない
  • 継承する側で super を呼び出すのはやめて、フックメッセージを使おう
  • コンポジション
    • 組み合わされた全体が、異なる備品の就業以上となる方に、個別の部品を複雑な全体へと組み合わせる(コンポーズする)行為
    • 自転車にはパーツがある、 has-a の関係であると言うことらしい
    • 包含される側のオブジェクトは、包含する側のオブジェクトがなければ存在し得ないもの
      • 学部と言うのは大学がなくなれば存在しなくなるので、コンポジションと言える

87%まできた。明日読み終わる。
静的型付だったら問題にならないようなことをつらつら書いていて、なんでこの人静的型付ディスってたんだろうって感じがある。

  • 継承かコンポジションか迷ったらコンポジションにした方が良い
    • 継承よりも依存が少なくなるから
  • 継承の懸念2つ
    • 継承が適さない問題に対して、謝って継承を選択してしまう
    • 他のプログラマが予期せぬ目的で使うかもしれない
  • コンポジションをちゃんと使えれば、単純で抜き差し可能で、拡張性のたかく変更にも寛容なのができる
  • 継承は特殊化、 is-a関係に継承を使う
  • behaves-like-a関係にダックタイプを使う
  • has-a関係にコンポジション
  • テストダブルはロールの担い手を洋式化したインスタンスで、テストで飲み使われるもの
  • モックはダブルではない
    • モック、スタブ、テストダブルらへんが何をさすのかよくわからないのでちゃんと学びたい

読み終わった、良い本だった。

  • プライベートメソッドはなるべく書くな、書いたとしてもテストは書くな
  • 副作用のないメッセージはクエリメッセージ
  • テストを書く前にリファクタリングをしてより良い設計にしていこう
  • リスコフの原則に従っているか証明する簡単な方法は、契約を共有したテストを書き、全てのオブジェクトにそのテストをインクルードすること
  • スタブを用意するためにサブクラスを作るのは、リスコフの置換原則を破らない限り使える
    • サブクラスを作るときは、そのサブクラスが古くならないようにテストを書こう

iTunes Connect の売り上げとトレンドにある「デスクトップ」は何者なのか

iOS 向けにしかアプリをリリースしていないのに、 デスクトップ というデバイスでのダウンロードがある。

f:id:star__hoshi:20170427101820p:plain

デスクトップとは

stackoverflow.com

どうやら、 PC の iTunes からダウンロードした時はデスクトップとしてカウントされるらしい。どこ経由でダウンロードされたのかが計測対象になっていると思われる。
デスクトップとしてカウントされると、 iPhoneiPad どちらで使われるかは不明。

おそらくだが、 MDM とかで機械的にインストールする場合もデスクトップとしてカウントされる気がする。
(確信はないが、会社でリリースしているアプリが異常にデスクトップ率が高い)

「モバイルアプリ開発エキスパート養成読本」を読んだ

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパートになりたいので読んでみた。
初っ端からいきなり Kotlin の話があり攻めてて良い。

iOS エンジニアなので iOS 関連のところの心に残ったことだけ、さらにこれは書評ではなくメモに近いので、本の内容がどうこうよりもそれを読んで感じたことを書いておく。

3-1 Swift 3.0 入門

Swift 3 の命名規則についての記事を読むたびに、英語力が足りないと Swifty なコードをかけないと感じる…。

Protocol の命名、 HogeProtocol とか書いてるのみたりするけどそれは思考停止で Swifty じゃないのだろうな。
メソッドの定義はなんとなく動詞で書きたくなってしまうのだが、これは Swift 関係なく改めないとマズそう。

3-2 Xcode 8 入門

Memory Graph Debug の使い方などが書かれている。
Xcode Extension については、私は XVim のために署名を外して使ってしまっている、誰か XVim-Extension を作ってくれと言う気持ちしかない。

4-1 リアクティブプログラミングと Rx, 4-3 RxSwift 入門

Rx なんとなく理解してきたタイミングで読んだが、やっぱり概念はわかるけどモヤモヤが晴れないと言う感じ。難しい。

Subject や Value は積極的に使うべきではないと書かれていて、でも MVVM やるなら PublishSubject とか使うわけじゃないですか、これもアンチパターンなのだろうか。
宣言的にかけるのは確かに良い。のだが、素人が Rx してしまうとわけがわからない複雑な Stream ができてしまう気がする。と言うか私の書いている個人開発の MVVM がだいぶ辛くなっている。
自分一人でやっていると間違いに気がつきにくいので、複数人でレビューし合いながらやるのは良いと思う、自分の理解力や実装力が足りないと言われてしまえばそれまでだが。

UITextField の初期化時に空文字列が bind されてしまうのに困っていたのだが、 skip(1) で初期化時の空文字列は無視しよう書かれていて、一つ疑問が晴れてよかった。

5-2 タイプセーフでモダンな iOS アプリの設計

storyboard, TableViewCell の初期化やキャストを Swifty に書いていこうという内容。
会社でやっているのは segue で画面遷移しているので、 segue は早く引き剥がしたい。
TableViewCell のもこのやり方に変えるぞ!

6-3 iOS アプリのテスト

めちゃくちゃためになる。
UITest は書いたことないし、パフォーマンスがテストできるのも恥ずかしながら知らなかった。
今後 UITest を書くかと言われると微妙、でも書いてある通りログイン画面などの非常に重要なところはあったほうがいいかなと思った。

全体として

読むのにそんなに時間はかからないし、ポイントがわかりやすくまとまっているので良かった。
やはり読んだだけではモバイルアプリ開発エキスパートにはなれなかったので、学んだことを少しでも実践していきたい。

あと表紙のおっさんは誰なんだろう。

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」を読んだ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

めっちゃいい本だった。

ソフトウェアエンジニアとして勝ち組になるためには〜みたいなことがひたすら書かれており、意識が高い。

面接、給料、資産運用、健康などとソフトウェアとは関係ないことも多く、確かに人生マニュアルだった。
1年に1回読み直したい。

特に強く心に残ったことが2つあった。

バカにされるのを恐るな

何かをやろうと思うとき、バカにされるのが怖くて一歩を踏み出せないことがある。
例えば勉強会に登壇して失敗したらどうしようとか、記事を公開した時に内容を間違えていたらどうしようか、などである。 しかし勉強会で上手く話せなかった人のことをあなたは覚えているだろうか、そんなことは誰も気にしないし過ちにも気がつけるのだから勇気を出しなさい、と書かれていた。

また、失敗は敗北ではないのでどんどん失敗し学んでいけとあり、自分は割と失敗を怖がり安全に走るので心にクる内容だった。

本を読み終わりとりあえず勉強会の登壇ボタンをポチッと押した。

ポモドーロ

生産性を高めるためにポモドーロが良いと書いてあり、実際にやってみたらめちゃくちゃ進捗出てすごい。
25分仕事して5分休む、というのは前にもやってみたけど全然効果がなかったけど、「ちゃんとその日やるタスクを決めてからそれを25分以内に1つ消化できるように全力を出す」ようにしたらめっちゃ効果が出て、ちゃんとタスクを決めるのが重要なんだなと思った。

また、ポモドーロやっていると、誰かから話しかけられた時にタイマーを指差して「その話めっちゃ緊急ですか?10分後でもいいですか?」とできるので良い。(向こうは面倒だと思うだろうけど…)

Deep Work にも、毎週・毎朝のスケジュールを決めて時間を意識し仕事をすると進捗が出るなどと書いてあって、本当にその通りだった。

KanbanFlow というサービスがあって、これはタイマーとタスクリストを連携させて、そのタスクがどれだけ時間かかったかなどの分析も丸っとできて良い。

kanbanflow.com


以下 wikihub 日報 で雑に書いてた感想のまとめ。


読み始めた、17%くらい。読み応えがある。
耳が痛いことがめちゃくちゃ書かれている。この本は毎年読み返した方が良い気がする。

特に

自分の仕事はコードを書くことだと思っているなら、考え直すべきだ。…他のあらゆる職種と同様、人と接することである。

がだいぶ心にきた。 :sweat:

以下雑なメモ:

  • あなたはソフトウェア開発の事業主であり、雇用主は顧客である
  • キャリアの目標を決めよ、そして今からその目標に対する月、週、日単位での目標を立てよ
    • ぐぅ、ハードだ…
  • あなたの仕事はコードを書くことではなく人と接すること
  • 悪い行動を懲らしめるのでなくいい行動を褒めよ
    • チームとして〜に出てきた失敗を許容しろって話だ
  • 社交術を学ぶことから得た利益はは一生モノであり、値段をつけられないほどの価値がある
  • 面接する前に相手の会社のブログ読んでマサカリ投げとけ
  • 面接では、能力の高さよりも「頼まれなくても仕事を終わらせるタイプの開発者」と強調しろ
  • まず専門性を特化させ、それから多才になれ
  • ソフトウェア開発で食べている会社は、雇っているソフトウェア開発者に高い価値を置いていることが多い
    • 弊社〜 :innocent:
  • 他の人が嫌がる仕事をすると信頼上がって出世や!
  • プロであれ
    • 自分が正しいとわかっていることのために、難しい選択をあえてすることを厭わない
    • めんどいしこの実装で妥協するか〜というのはプロではない
  • 他人のために働くときは一生懸命度合いが半分くらいになる
    • 独立すると自分のために働くので、その差を感じることになるらしい

5% くらい読み進めた。


32% くらいまできた。
自分の価値を高めよみたいな話で、有名な Podcast にでろとか言ってるけど、そもそも有名な Podcast に出る人は価値が高いんじゃないですかね?

  • 履歴書はプロに書いてもらうのもアリ
  • 自分が選んだテクノロジー以外にもいいものはたくさんあるから選択肢を制限するな
  • 自分をマーケティングするとは、あなたが提供できるものを、欲しいと思っている人と結びつけることに他ならない
  • 質の高いブログを毎週書け

ためになる。
自分をプロモーションするために SNS をうまく使え、カンファレンスで講演しろみたいな話が続く。
ひたすら意識が高い。

  • 自分がやってることの90%は無料で公開せよ(自分のプロモーションのため)
  • SNS で朝食に何を食べたみたいなツイートばっかりしてると人々は離れるから価値のあるツイートをせよ
    • :scream:
  • バカにされるのを恐るな、勉強会にでよ、ブログを書け、マサカリを恐るな
  • 独学
    • 基礎的な知識は何が必要か
    • テーマの幅: どれくらいの規模で、どんなことが可能か
    • 基礎: 20%の知識で日常の80%をカバーするにはどうしたら良いのかを知る
  • 基礎的な理解を得て、その上で何を学習するかの範囲と成功のイメージを定義する

55%まできた。
理解を深める一番の方法は人に教えること、というのが強調されている。
また、生産性の章では Deep Work に書いてあるのとほぼ同じことが書かれている。

本の前半で「あなたの仕事はコードを書くことではなく人間とコミュニケーションを取ること」と書いてあったが、この章では「オフィスのドアの前に'話しかけるな!'と書いた札を置いておけ」と書かれてて、ハア〜どっちなんじゃいという感じだ。

  • 何かを学び始める前に全体概要を把握しておけ
  • 何かを学び終えたと証明できる目標を立てろ、その目標はできる限りスコープを絞れ
    • C# で website 作るぞ、みたいな目標
  • 1冊の本だけでなく多くの異なる本を集めよ
    • 5冊の目次を見比べると重要なことが見えたりする
  • 学習-実践-学習-教え(LDLT方式)
  • メンターは経験をあなたに伝授してくれる重要な存在
    • メンター欲しい〜〜〜〜 :sob:
  • メンターいない人は本を仮装メンターとする
  • あなた自身もメンターになれ、難しそうだけど他者より1歩前に進んでいるだけで良い
  • しかし弟子は選べ、ぶたに真珠を投げてはならない
  • 学位はあって損はない、ない人は資格を取ろう
  • なんかよくわからんけどそのままにしていることは都度メモっていけ、早めに理解した方が今後のためになる
  • チャットは完全な時間の無駄。メールの方が割り込みがないので良い
  • ポモドーロやる時は進捗を計測し分析しろ
  • 毎月、毎週、毎日何をやるのか予定を立てよ。
    • Deep Work で読んだわ…
  • 毎週ブログを1回は更新すること、本を1冊読むことみたいにキメを作ると習慣化される
  • シャローワークはバッチ処理として1日にまとめてやろう

75%くらい。めっちゃためになる。
「この本を読んでる君たちは特別だから勝ち組になろうや」みたいに書いてあって、読んでるだけで肯定感があって上手いな〜と感心してる。

  • 大きなタスクはやる気が出ないかもしれないが小さく分解しよう
    • プログラムだってメソッド分けるでしょ?
  • ハードワークは大変だ、つらい、けどやらないといけない
    • ハードワーク楽しいって口でいう人はいるけど本当に楽しいと思っている人はいない
  • やる気が出ない?いいからデスクに座ってやるしかねえんだごちゃごちゃいうな
  • 怖くて行動に移せない奴がいるが、行動に移さないことが一番怖いんだぞ
  • 給与交渉では先に金額を出すな、会社に言わせろ
  • 筆者もかなりの苦労をした結果金持ちになっているし、運が良かったのもある
    • でも幸運はある程度は自分で引き寄せるもの
  • 不動産投資はローリスクでリターンが見込めて最高

85%、明日読み終わる気がする。 筋肉は素晴らしい、体の健康は心も健康にするなどと書かれている。

私は胃下垂というやつで食べても太れない側の人間で、筋肉をつける前にまず一般的な体型になりたい…。 BMI は17.5とかで異常値であり、大変厳しい。まず病院に行こうと思う。

  • 食事を変えてエクササイズすることで体と頭どっちもよくなる
  • 腹筋割れてるやつは脂肪なさすぎて死ぬやつだからそれを目標にするな
  • トレーニングはつらいが結局最後は根性で歯を食いしばってやるしかない
  • 思考を制御し考えたことを具現化せよ
  • 意志が体を動かす

読み終わった。
いい本過ぎた、感化されたので勉強会に登壇するボタンを押し、病院に予約を入れた。

失敗は良いことだしどんどん失敗しろ、怖いかもしれないが失敗は敗北ではない!とあり、なるほどという感じがある。

  • マイナス思考は実際によくないことにつながる
  • プラス思考は現実を変えるパワーがある
  • プラス思考は、悪いことではなくいいことを考えることを選ぶこと
  • 瞑想はいいぞ
  • 結局正しく実行するためには時間と忍耐が必要である
  • 失敗を喜び、期待し、受け入れ、正面からぶつかることを学ぼう

potatotips #39 で fastlane android について話した

potatotips.connpass.com

最近業務で android も fastlane に乗せたので、 android 枠で話した。
fastlane android 良いと思う、継続的デリバるためのやつだからダメになったら捨てればいい、という軽い気持ちでいけるし。

発表では、たぶん自分はせわしなく話していて、他の人の発表見て「みんな落ち着いててすごいな〜」って思って見てた。
次話すときは資料の枚数もっと減らしてもっとゆっくり話すようにしてみようと思う。

「遅読家のための読書術」を読んだ

遅読家のための読書術

遅読家のための読書術

自分は本を読むのが遅く、さらに理解度が低いというつらい感じなので、そこらへんをなんとかしたいと思ってこの本を手にとってみた。

「本を読むのが遅い人は無駄に頑張って読みすぎなので、音楽を聴くようにもっと気軽に本を読んで、1行でも心に残る文章があったらそれで良いんだぞ」みたいな内容だった。あと見出しで判断して違うと思ったら読まなくて良いんだぞ、とか。

無駄に頑張って本を読みすぎというのは心当たりがあるのだが、見出しレベルで判断するというのはする気になれない…それが遅読の原因なのかもしれないが。

言っていることはわかるのだが、あなたはそう考える人なんですね、という感じで自分にはあまりためにならない本だった。

というかそもそもこの本は内容が薄く、1/3くらいでかける内容を冗長に書いている感じがして、遅読家向けの本なのに内容が薄く長いというのはどうなんだ。
遅読の人が読むんだからもっとページ数少なくするべきでは。わざと冗長に書くことで読み飛ばすことを実践させるという高度な内容になっているのかもしれない、などと思いながら読んでいた。

本を読んだ後に「もっとも素晴らしいと思った引用を1つだけ選ぶようにしよう」とあったので、1つだけ引用する。

「なにか」が頭の片隅に残っているのだとすれば、少なくともその部分が自分にとって必要だということ。
その本から得られる価値の全てはまさにそこにあり、1冊を読み通したことの意味は、その一節に出会えたことにある

以下雑なまとめ。


  • 本はそんなに真剣に読むな、音楽聴くみたいに雑に流せ
    • フローリーディング
  • 1冊に1フレーズでも心に残るものに出会えればいい
  • 100%を得ようとするな価値を感じられる1%と出会え
  • 引用することでその本のどこに心を動かされたか可視化される
  • もっとも素晴らしいと思った引用を1つ選ぶ
  • 12冊ごとに振り返りをし、その中からベストの1冊を選ぶ
  • 小見出しをみて読むべきパートか判断する
  • 自分語りは読み飛ばせ、まとめだけ読めばいい
    • この本かなり自分語りあったな?
  • 本を気軽に読み始められないのは、その本から何を得たいかがはっきりしていないからでは?
  • マーカー引くのは良くない
  • 電子書籍より紙の方が良い(筆者の意見

「プログラムはなぜ動くのか」を読んだ

プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識

プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識

プログラムを書き始めて5年ほど経つが、今までずっと「何かアプリケーションを作る」という目的のためだけにソフトウェアを作ってきて、それゆえに低レイヤで何が起きているのか全然知らなかった。
プログラムを書くのにコンパイラが何をしているのかわからんのもよくないので、そこらへんを知りたくて読み始めた。

CPU から2進数、メモリ、コンパイラ、OS、アセンブラと今まで避けてきたことが色々書いてあった。

特にコンパイラアセンブラの章がよかった。
コンパイラは色々ゴニョゴニョっとライブラリ入れたりスタティックライブラリ使ったりとかしてやっと exe ファイルができるらしい。
アセンブリ言語も mov とかでチョチョっと書ける、逆アセンブルというのはマシン語アセンブリ言語に逆変換することだったのか、それすら知らなかった。

2進数とかってどうなんだろうか、どの程度まで理解していた方が良いのだろうか。あの 1001010101 みたいな数字が苦手で、 2進数を10進数に計算するのもろくにできない。
でもそれで困ったことがないと感じてて、それは私のレベルが低いから困ったことがないだけで他の人は2進数の理解によりメリットを感じているのだろうか。

本の内容としてはためになったけど、この本を読む前とあとで自分の書くコードは変わらないのかな、とも思う。
コンパイラを理解しているとデバッグがしやすいとか書いてあったけど、果たして iOS の Swift などでそれが役に立つことがあるのだろうか…。
自分の理解度が低いのか、時代に即していないのか、果たして。

とはいえ、ためになるいい本でした、終わり。

以下 wikihub 日報 のまとめ。


読み始めた。いつだかに買ったけど積んでたやつ。 ソフトウェアは書けるけどなぜ動くかわかっていないのでためになる気がする。 1章読んだけど全然わからんかった、パソコンは難しい。

  • レジスタ
    • 命令やデータを格納する領域でメモリみたいなもんらしい
  • 制御装置
    • メモリ上の命令やデータをレジスタに読み出し、命令の実行結果に応じてコンピュータを制御するらしい
  • 演算装置
    • メモリからレジスタに読み出されたデータを演算するらしい
  • クロック
    • CPU が動作するタイミングとなるクロック信号を発生させるもんらしい
    • クロックは大きければ大きいほど CPU は早い
  • みなさんが書いたコードがマシン語となり CPU の内部でレジスタを使った処理結果になるらしい
  • コール命令やリターン命令で関数を実行したりするらしい
  • この本を読むと今まで何気なく書いていたプログラムがこれからは生きたものに見えてくるようになるとのこと

備忘録として書いてたらめっちゃ長くなった。

2章 データを2進数でイメージしよう

2進数めっちゃ苦手だ。というか知らなくてもプログラム書けないですか?

  • ビット
    • 2進数の1桁に相当する
  • バイト
    • 8桁の2進数
  • 基数
    • 数の数え方、10進数は10を基数、2進数は2が基数
  • シフト演算
    • 2進数で表された数値の桁を左右にシフトする
    • シフト演算や論理演算の仕組みをイメージできることは 必ず 身につけておかなければならないこと
      • まじ?
  • 符号ビット
    • 0の場合はプラスで1はマイナス
  • 補数
    • プラスの値でマイナスの値を表す
    • 「反転して +`1」で補数を求める
  • 論理右シフト
    • シフト後の上位桁に0を入れる
  • 算術右シフト
    • シフト前の符号ビットの値を入れる?
  • 符号拡張
    • 例えば8桁の2進数を、値を変えずに16桁や32桁の2進数に変換すること
  • 算術演算
  • 論理演算
    • NOT,AND,OR,XOR など
  • 真理値表
    • 2進数の0がfalseで1がtrue

3章 コンピュータが少数点数の計算を間違える理由

計算とかだいたい Math.floor とかしちゃうから気にならないくないですか?

  • 0.1 を 100 回加えても10にならない
  • 10進数の小数点の中には、2進数に変換できないものがある
  • 正確に表せない数は近似値になってしまう
  • 倍精度浮動小数点型
    • 64 bit の double
  • 短精度浮動小数点型
    • 32 bit の float
  • 浮動小数点では、少数点数を「符号」「仮数」「基数」「指数」の4つに分ける
  • 符号部
    • 1bit を使って数値の符号を表す、0は負で1は正
  • 仮数
    • 様々な形式で表せる浮動小数点型を糖質的な表現にする
  • 指数部
    • イクセス表現を使う。
    • 中央の値をゼロと見做すことでマイナスの値を表す工夫、トランプでいうと7を中心とし6以下はマイナスみたいな

4章 四角いメモリーを丸く使う

メモリに関しての内容。
C言語も書いたことないしポインタとか概念としてしか理解してない。

  • 制御信号
    • WR(write), RD(read) のように IC に動作を行わせる信号
  • メモリの物理的な仕組み
    • モリーIC の内部に8ビットデータを格納できる入れ物がたくさんあり、その場所をアドレスで指定してデータの読み書きを行うだけ
  • データ型
    • どのような種類のデータを格納するか示すもので、メモリからすると占有するサイズを意味するもの
  • 変数を使うことで物理アドレスを指定しなくてもプログラムでメモリの読み書きが可能
  • ポインタ
    • データの値そのものでなく、データが格納されているメモリーのアドレスを持つ変数
    • 参照型って理解でいいのかな?
  • 配列
    • 同じデータ型の複数のデータがメモリ内に連続して並んだもの
  • スタック/キュー
    • どちらもアドレスやインデックスを指定せずに配列の要素を読み書きできるもの
  • スタック
    • LIFO = Last In First Out
  • キュー
    • FIFO = First In First Out
  • リスト
    • データの値だけでなく、次の要素のインデックスも付加できる
    • リストでない配列を使うと、途中の要素を消した時に後ろの要素を全て移動しないといけない

ためになる!

5章 メモリーとディスクの親密な関係

メモリとディスク(HDDとかフロッピーとか)について。

  • ストアド・プログラム方式
    • プログラムが記憶装置に格納されていて順次読み出されて実行される仕組み
    • この方式の前はコンピュータの配線を変えてプログラムを変更してていたらしい
  • ディスクキャッシュ
    • 一度ディスクから読み出されたデータを保存しておくメモリ内領域
  • 仮想記憶
    • ディスクの一部を仮想敵にメモリとして使うもの
    • 物理メモリと仮想メモリスワップしながらプログラムを実行する
  • ページング方式
    • 実行されるプログラムを構造に関係なく一定の「ページ」の大きさに分割する
    • ページイン、ページアウトとかいう
  • ページングファイル
    • 仮想記憶を実現するためにデゥスク状に仮想メモリとなるファイルをおく
  • スタティックリンク
    • アプリケーションの実行ファイルの中に関数を埋め込むこと
    • これをやると同じコードが複数アプリケーションに存在することになり微妙っぽい
  • スタックのクリーンアップ処理
    • 関数の引数を受け渡すために使われるメモリ状のスタック領域から不要となったデータを削除すること
    • 関数の前に _stdcall をおく
  • ディスク
  • セクター方式
    • 固定長の領域に区切る
    • ディスクの表面を同心円状に区切った領域をトラックと呼び、それを固定長サイズに区切った領域をセクターと呼ぶ
    • 複数のファイルを1つのクラスタに格納はできない、両方削除されちゃう
  • バリアブル方式
    • 可変長の領域に区切る

6章 自分でデータを圧縮してみよう

zip とかの仕組みが書いてあって面白い。

  • ランレングス法
    • ファイルの内容をデータ*繰り返し回数で表すことで圧縮する方法
    • 同じデータが続いている場合が多い画像ファイルなどでは有効打が文書ファイルではあまり…
  • ハフマン法
    • よく使われるデータを判別して、それを小さいbit数で表す
    • ハフマン木とか使う
  • BMP
    • bitmap は圧縮していないやつ
  • 可逆圧縮
    • 元に戻せる、zipとか
  • 非可逆圧縮
    • 元に戻せない、jpeg とか

7章 プログラムはどんな環境で動くのか

戦うプログラマーでいろんな環境で動くように作るみたいな話をしていたやつだった。

  • ネイティブコード
  • ソースコード
    • テキストファイルで書かれたやつ
  • アプリケーションの機能の中に、ハードウェアを直で触るところがあると汎用プログラムにならない
  • API
    • Application Programming Inteface
  • Ports
  • Java
  • JVM
  • BIOS
    • ROM に記憶され、キーボードとかの基本制御プログラムやブートストラップ・ローダーをもつ
  • ブーとストラップ・ローダー
    • 起動ドライブの先頭領域に記憶された小さなプログラム
    • OS はブーとストラップ・ローダーによって起動する

8章 ソース・ファイルから実行可能ファイルができるまで

コンパイラとかのはなし。
知らないことばっかりだ。

  • ダンプ
    • ファイルの内容を1バイトずつ2桁の16進数で表示すること
  • ロスコンパイラ
    • 動作環境で使われる CPU とは異なる CPU 用のマシン語を生成
  • オブジェクトファイル
    • コンパイルした後に生成される .obj 形式のファイル
    • まだ exe ファイルではない
    • printf() など実行する場合は必要な処理内容が格納された状態に結合しないといけない
  • リンク
    • 複数のオブジェクトファイルを結合して1つのexeファイルを作る処理
    • リンクを行うプログラムのことをリンカーという
  • スタートアップ
    • 全てのプログラムの先頭に結合する共通的な処理が書かれたオブジェクトファイル
  • ライブラリファイル
    • 複数オブジェクトファイルをまとめて1つのファオルに格納したもの
  • 外部シンボル
    • 他のオブジェクトファイルの中にある変数や関数
    • printf() とか
  • 標準関数
    • ライブラリファイルの形式でコンパイラと一緒に提供される
  • DLL
    • Dynamic Link Library、プログラムの実行時に結合されるもの
  • インポートライブラリ
    • 外部にあるライブラリファイル
  • スタティックリンクライブラリ
    • exe ファイルに直接結合するライブラリファイル
  • 再配置情報
    • 実行時にメモリを仮想敵に与えてうまく動くようにするやつ
  • スタック
    • 関数の内部で一時的に使用される変数などのメモリ領域
    • 自動でメモリを確保し自動で解放
  • ヒープ
    • プログラムの実行時に任意のデータやオブジェクトを格納するためのメモリ領域
    • 自分でメモリを解放する

コンパイラはこんな感じの処理になるっぽい。

ソースファイル
-> .obj + タートアップ + スタティックリンクライブラリ + インポートライブラリ
-> スタティックリンク + ダイナミックリンクライブラリ
-> exe


読み終わった。

9章 OS とアプリケーションの関係

  • モニター・プログラム
    • プログラムをロード・実行する機能だけを備えるやつ
  • OS 上で動くアプリはハードウェアを OS を介し間接的にアクセスする
  • システムコール
    • OS の関数とかを呼び出す行為
  • 時分割
    • 短い時間間各区で複数のプログラムを切り替えながら実行する
  • マルチスレッド
    • 関数の単位で時分割を行う
  • ミドルウェア
    • ネットワークやデータベース機能のような、OSには不可欠でないがOSに近い存在のこと
  • システム・ソフトウェア
  • フラグ&プレイ
    • 新しいデバイスをすぐに使えるようにする仕組み
  • バイス・ドライバ
    • 新しいデバイスを接続した時にそれを制御するプログラム

10章 アセンブリ言語からプログラムの本当の姿を知る

この本で一番ためになる章だったと思う。
コードがコンパイルされ、それがどうコンピュータに読まれるかみたいなのを順を追って解説してくれる。

11章 ハードウェアを制御する方法

  • システムコールを使いアプリケーションからハードウェアを制御する
  • IN命令
    • 指定したポート番号のポートからデータを入手する
  • OUT命令
    • CPU のレジスタに格納されているデータを指定しポート番号のポートに出力
  • I/Oコントローラ
    • コンピュータ本体と周辺装置をいい感じに繋ぐやつ?
  • ポート
    • 入出力されるデータを一時的に格納しておくための一種のメモリ
    • えっポートってメモリなの、マジで
    • ポートって行っても https:443 みたいなポートとか USB ポートとか色々あるし何がどれなんだ
  • ポート番号
    • I/Oアドレスとも呼ぶ。ポートを区別するやつ。
  • IRQ
    • Interrupt Request, 割り込み要求
  • 割り込み処理
    • 現在実行中のプログラムを一旦止めて他のを実行する
    • 割り込み番号が振られる
    • 割り込みコントローラが間にいる
  • ポーリング
    • 複数の周辺装置の状態を順番に調べること。パソコンには不向き
  • DMA
    • CPU を仲介せずに周辺装置が直接コンピュータのメインメモリとデータ転送をおこなう
    • DMAチャネル
  • I/Oポート番号、IRQ、DMAチャネルは周辺装置を識別するための3点セット
  • VRAM
    • ディスプレイに表示される情報を記憶するメモリ

12章 コンピュータに「考え」させるためには

プログラムに人間の傾向とかを学ばせるみたいな話。
ディープラーニングみたいに深い話ではなく、人間がグーを出した後はパーを出しやすいとかを覚えるとかの話。

  • 擬似乱数
    • 数式によって得られる乱数、本当の乱数とは言えない

「リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす」を読んだ

個人でアプリを開発するときによく思うのが「とりあえずまずリリースしてみる」というのが大事だと思っていた。
MVP とかいったりするし、そこらへんちゃんと理解したいという思いで読み始めた。

実際に読んで見ると「とりあえずまずリリースしてみる」というのは正しくなくて、「検証可能な仮説が正しいのか検証するための最速の一手を打つ」みたいなのが大事。
最速の一手というのはスケールしない方法という意味で、例えば洗濯をするサービスを作ろうと思ったとき「本当にそのサービスは必要なのか?」を検証するために、街中の人に1000円で洗濯するけどどう?って話して実際に CEO が洗濯する、というのを通して開発する意味があるのか検証しよう、という感じである。

昨今のサービスは、企画があってすぐに開発に移るけどそれはよくなくて、本当にその企画が正しいのか?というのを理解してからやったほうが良さそう。 そういう意味での Minimum Viable Product を作っていこう、というのが印象に残った。

検証するときにはちゃんとそこから学習して、次は良い結果になるように企画を変えるのはもちろん次の検証はもっと早く実施できるようにしよう、とかもよかった。

以下 Twitter に投げた感想。