概要

DHH 先生の Rework を読みました

メモがてら書き留めていたことを紹介しようと思います
「うーんまぁその通りだね」という点については特に触れていません
大きく共感した点や自分はこう思うという点についてのみ記載しています
書籍の内容を細かく説明しているわけではないので既に同書籍読んだ人向けの内容になっています

Remote も過去に読んでいます

環境

Kindle App on iPhone

見直す

「失敗から学ぶこと」は過大評価されている

失敗しても成功しても何を得てそれを今後にどう活かすか考えることが重要だと思う
得られるものが結局一緒であれば成功し続けることに越したことはない
失敗しても何も得ず活かさない人は次もまた結局失敗するだけだと思う
自分の経験値になるのであれば失敗でも成功でもどっちでも良いのだと思う (もちろん成功のほうがいいが)

会社の規模なんて気にしない

日本でということになるが大きな会社が悪いということは決して無いと思う
単純に安定した生活を送りたいという人には大きな会社で働くほうが安定はすると思う (福利厚生や保険など)
ただ、小さな会社というか小さな組織であればあるほど単純にフットワークは軽くなるだろう
多くの日本企業では業務にフローがあり申請や承認がないと先に進めないことが多いと思う
小さな組織であればそのあたりのフローが極めて最低限で構成されており、無駄な時間やコストを消費しないで済むと思う
そういった意味で気にしたくはないんだけど、気にしないと前に進めないケースが存在してしまっている、そういう文化があるというのが問題だと思う

先に進む

あなたに必要なものをつくる

非常に大事な考えだと思う
特に技術力がありパッと作って試せるのであれば尚更だと思う
そしてそれがビジネスにつながれば最高だ
ただ、一歩引いて考えるのもいいと思う
自分がほしいと思っているものをいきなり作らないで探してみると良いと思う
なぜなら大抵な場合はすでに誰かが作ってくれている時代だからだ
そしてそのアプリやツールを触ってみよう
サードパーティのアプリやツールを触ることはエンジニアにとって非常に大事なことだと思う
新しい発見やアイデアの発見につながると自分は考えている
なので、開発する以上とは言わないが既存のサービスやツールを試す機会も非常に大事だと思うので探すクセをつけておくと良いと思う
数分探してもないなら諦めて開発する方向にしよう

必要なものは思ったより少ない

書籍内ではお金に関わる項目を上げていたがそれ以外にも単純に「業務」や「会議」などもあると思う
そしてそれらの不必要だと判断したものたちを捨てるという行動こそが本当に重要だと思う

売却するつもりのビジネスは廃却されることになる

これは個人的にはありかなーと思う
最初から売却目的で行くというのは良くないと思うが最終的にもしくは成り行きで売却の方向に行くのはビジネス的にはありだと思う
ただ、自分が愛したサービスであれば話は別で売却の方向には持っていかないほうが良いと思う
逆にまた次に新しく初めたいアイデアなどがある状態であれば売ってしまって綺麗さっぱりゼロにしてから再スタートするというはありだと思う

進展

制約を受け入れる

ここは全体的なコンテキストからは少し矛盾を感じた
自分たちをあえて制約下に置くことが良い方向になるという主張だと思うが自分は制約は少なければ少ないほうが良いと思う
もしかしたら自分の「制約」の捉え方が若干違っていたのかもしれないが

副産物を売る

個人的にこの考え方は非常に好きな考え方である
何をやるにも無駄なことはないと思うことができる考え方だと思っている
人生無駄なことや辛いことは非常に多いと思うが何か副産物が生まれていると考えるだけで個人的には何とかやっていける
辛いことや無駄なことの「体験」だけでも副産物になると思う
少しポジティブすぎるかもしれないがこの考えを持つことは個人的にもおすすめしたい

生産性

邪魔が入る環境では生産性は上がらない

ひとりきりモードは時間で制約するのもいいが個人的には「行動」というか「儀式」を決めると良いと思う
要するにやる気スイッチ的なものを作るようにする
これをやったら、これを付けたら、これが終わったら必ずひとりきりモードになり集中して作業を進めるという感じ
というのも個人的な問題で時間だとどうしても決められた時間を設けることが難しいというケースが多いかなーと思っているだけです

会議は有害

「Outlook で 7 分の会議を設定した人は見たことがない」確かにと思った
ということは会議が有害に思われているのは Outlook などスケジュール管理ツールが 15 or 30 分単位でしか会議を入れられないことが原因だったりするのだろうか
たぶんそんなことは全くないと思うが
「会議」という言い方も良くないのだと思う
「会議」はダラダラとお話するイメージがそもそも付いてしまっている、なので会議ではなく「決断の場」として決めることだけ決めて解散する場にすれば少しは有意義になるかもしれない
まぁそれにしたとしても人を集めてお話する必要はまったくないと思いますが

小さな勝利を手に入れる

これも好きな考えです
ちょびちょび出して小さな成果が毎日得られるほうが最終的には良いものに繋がると考えています

あなたの見積もりは最悪だ

この次で多すぎる TODO について言及しているが、細かくタスクを分割して見積もると多すぎる TODO 問題に繋がってしまうのではと感じた
あとその後で述べている長いリストは終わらないという話にも繋がるが TODO はできるだけ細かく残したほうが良いと思う
長すぎると終わらないと指摘している点には同意だが終わらない場合は一定期間などで見直しをしてフラグなどを付与して一度クローズするようにすれば良いと思う
その場で長くなることを恐れてリストにしないと後で思い出せないこともあると思う (思い出せないくらいの重要さならやらなくても良いことだとは思うが)

競合相手

ケンカを売る

気持ちはわからなくはないがやりすぎは良くないと思うｗ
そしてこの後で「相手は気にしない」という結論になっているので結果ケンカも売らなくて良いんだと思う

競合相手以下のことしかしない

たぶん意味合いとしては「何事も上を目指していろいろと機能を追加すれば良いというわけではない、シンプルに行く路線もある」ということだと思う

進化

基本的に「ノー」と言おう

この章の中で「自分たちのサービスに顧客が満足しなければ競合他社を薦める」という説明がある
自分はその意見には賛成なのだが、実際営業の世界でその表現を聞いたことはほとんどない
思い返してみるとなぜだろうという気持ちになるが自分たちの製品ではなく他社の製品を薦めるということ自体冷静に考えればおかしなことである

プロモーション

特になし

人を雇う

まずは自分自身から

まず先に自分でやってみる習慣をつけることは非常に大事だと思う
コーディングするにもインフラを構築するにも結果的には一番始めにやっていた人が詳しくなる
詳しくなるし結局それがビジネスを進める上でも一番貴重な情報となると思う

経験年数は意味がない

「どれくらい質の高いことをしていたか」を定量的に計れる指標があると良いと思った
たとえば OSS の Contribute 数や公開しているアプリの数などだろうか

ダメージ・コントロール

文句は放っておく

当然だが障害レベルの文句はしっかりと対応するべき

文化