「小さなチーム、大きな仕事」を読んだ

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (36件) を見る

「37シグナルズ」の仕事を行う上での哲学・思想が詰まった本

仕事の進め方だけではなく、生産性をどのようにして維持するか、競合相手についてどう考えるか、プロモーションをどう行うか、人を雇うときの考え方、どのようにしてダメージコントロールするか、会社文化に対する考え方など多方面の話題に触れている。

著者のビジネス体験がそのまま綴ってあるが、根本の考え方は"ソフトウェア開発"(小さく回していくアジャイルUNIX思想)に通ずるものがあると感じた。

TL;DL

思うだけでは何も変わらない。動き出すこと(形にすること)が大切

気になった箇所をメモ。

計画は予想にすぎない
  • 計画を作っただけで、実際には制御できないものをコントロールした気になる
  • 計画なしに仕事をするのは恐ろしく思えるかもしれない。しかし現実と折り合わない計画にしたがうのは、もっと恐ろしいことだ
失敗から学ぶことは過大評価されている
  • してはいけないことについては学べるが、次になにをすべきかがわからない
  • 一方で、成功から学ぶことは、次の手段を与えてくれる
制約を受け入れる
  • 少なければ少ないほどよい。資源が制限されると、それでなんとかしなければならなくなる。そこに無駄の余地はなく、創造性が求められる
  • 中途半端な一つの製品ではなく、よくできた半分の製品
  • ディテールは後から
決断して前進する
  • これについて考えようではなく、これについて決断を下そうと思う
  • 何かを説明する必要があるときそれを形にしてみよう
解決策はそこそこのもので構わない
  • 柔道のような(最も少ない動きから最も多くを得る)解決策を見つける
  • その課題をとっとと片付けて次につなぐ何かを作るだけ
熱意を優先順位と混同するな
  • 「素晴らしいアイデア」はしばらく棚に上げておこう
  • イデアを思いつくことはいいことだ。落ち着いてから、そのアイデアの優先順位を評価しよう
ヒーローにはなるな
  • やめることが最善の方法となりうることを覚えておこう
  • 本当のヒーローは、仕事をさっさと片付ける方法を見つけだし、とっくに帰宅している
基本的にノーと言おう
  • ただ正直でいよう
料理人を見習う
  • 彼らが有名なのは、自身の知っていることを全て外に出し皆と共有しているからだ
  • 共有することを恐れてはならない
造花が好きな人はいない
  • 欠点を見せることを恐れてはならない。不完全さはリアルであり、人はリアルなものに反応する
  • 不完全の美しさ(ワビサビ) = 本質だけになるまで切り落とす。だが詩を取り除いてはいけない
文化は作るものではない
  • 文化はつくるものではなく、自然に発達するものである。新しい会社には独自の文化がない
  • 文化とはふだんの振る舞いの副産物だ。文化とは方針ではない。無理に文化をつくろうと考えないこと。熟成には時間がかかる
  • いる人の振る舞いや思い考え方が文化になる
ひらめきには賞味期限がある
  • イデアは不死身だ。永遠だ
  • 一方ひらめきは永遠に持続できるものではない
  • ひらめきとは「今」のものだ。虜にされたら仕事に専念すること

See also

雑に考えてみる

雑な発想を活かすチーム作り - クックパッド開発者ブログ

GitHub上にリポジトリを作成するのも、そうだけど、 ローカルマシンに"zatsu"ディレクトリを作成して、 ここに雑にメモした文章や一時的に試してみた系のスニペットなど格納することにしよう。

todoistに”雑”プロジェクトも作成したので、雑なタスクはここに追加していこう。

雑アイデアをタスクへ
雑な発言を許容することは、常に志向を発散させることに他なりません。業務プロセスとして雑さを扱うためには、これを然るべきタイミングでうまく収束させる必要があります。

もちろん、"雑"を"放っておくと意味のないものがたまるだけなので、 然るべきタイミングで棚卸ししないといけない。

前日のタスクをわざと途中でやめておくメソッド

Rebuild: 139: Productivity Extremist (higepon) で話していた。(1:13:00~くらいから)

rebuild.fmで話していたのは、コンパイルエラーの例。

  1. 前日、コンパイルエラーが出るところでタスクを止めておく
  2. 翌朝、コンパイルエラーを機械的に直し昨日の作業のコンテキストが頭に入ってきて、スムーズに仕事に取り掛かることができる

自分はコード書いてて詰まった時は、

悩み悩み時間だけが延々と過ぎてしまい、終電で諦めて帰るパターン。
家で寝る時間を忘れてまでなんとかしようとして、結局寝落ちするパターン。

これらのパターンは大体に応じて、翌日脳がすっきりした状態だとスッと解決したり、 軽微なミスだったりする。

心理的に、「どうにかキリの良いところまで終わらせよう」という気持ちになるのは正常で、 ただこのような時は大概焦っていたり時間的なリミットが近づいて冷静ではいない気がする。
(さっさと帰ろう/寝よう)

中途半端な状態という気持ち悪さはあるが、 何をやるのか自明な状態*1で応じたほうがスムーズにタスクに取り掛かることができ(やることは決まっている)、 後のタスクをテンポ良くこなすためのリズムも出来上がるのかなぁと思っている。

"敢えて前日に仕事を残して、翌朝のスタートをスムーズに"

実践しよう

*1:コンパイルエラーを直すとか機械的な作業が残っている状態

「今日からはじめる情報設計」を読んだ

今日からはじめる情報設計 -センスメイキングするための7ステップ

今日からはじめる情報設計 -センスメイキングするための7ステップ

混乱(Mess)を解きほぐして整頓、理解(センスメイキング )する方法を説いた本

"なぜ"起きて”どう"解決するかを判断できる人 = 問題解決能力が高い人は仕事ができる人だと思うので、 どういった思考で問題を捉え、解決に導くかを考えさせられる本だった。

TL;DL

情報設計とは、
現実を直視・コンテキストとチャネルを判断し、それらを踏まえた複雑さの中から情報を選び出し、 意味が伝わって良い結果が得られるような"カタチ"にすること。

以下、各章毎のメモ。

1. 混乱を見極める
  • 情報はデータでもコンテンツでもない
  • 行う事は知ること
  • データやコンテンツが不足している状況でどのような情報が生み出されるかを考えるのが大事
2. 意図を表明する
  • 良いとは何か? 私たちの意図することが良いや悪いの定義の仕方を決める
  • 良く見えることと使いやすいことには等しく注意を払うべき
  • 誰が重要
  • なぜから始める
  • どうやっての前に何を
3. 現実を直視する
  • 現実と向き合うことで解決策を見つける事ができる
  • 現実と深く対話するために「オブジェクト」「メンタルモデル」を育てる
  • スコープ(範囲)とスケール(規模)を決めてからスタートする
  • 道具箱を拡張する*1
4. 方向を決める
  • 「なぜ」から「何を」
  • 階層(場所)を、階層間の影響を意識する
    • 小さな決定が次へ次へと繋がる
  • 言葉の定義が大事
    • 名詞に、それに合わせた適切な動詞を組み合わせると要件(必要なもの)を示すことができる
5. 距離を図る
  • 現実と意図の距離
    • 進捗度をどのように評価すべきか、意図を分解し具体的な目標へと置き換える
  • 不明瞭であるのが普通
    • 良い、悪いは主観的なもの
    • 重要なものは複雑な現実の世の中で達成したいと思っていることに対して誠実であること
6. 構造で遊ぶ
  • 曖昧さは明快さを犠牲にし、正確性を柔軟性を犠牲にする
  • 曖昧さはシンプルさを隠す
  • パターンを意識する(階層構造、並列構造、シーケンシャル)
7. 調整に備える
  • 新しい問題に遭遇した時に、その問題に対応するために自分の進むべき道をそれに合わせて調整する
  • はっきりするまで議論しよう
  • フィルターになろう。コーヒーかすではなく
    • センスメイキングとはユーザに提供しようとしているアイデアから、余計なものを取り除くようなもの
    • 取り除かれるものは加えられるものと同じくらい大事、アイデアを濾そう

See also

simpleとeasyの違い

TL;DL

迷った時には、simple(単純)な方を選びたい
小さなsimpleを組み合わせて、問題を解決したい

simple

  • 客観的
  • 単純
  • 1つだけ
  • 構造などが簡単、単純な物

easy

  • 主観的
  • 簡単
    • 自分にとって簡単なだけかもしれないけど、誰にとっても簡単は存在しない
  • 人が簡単に思う事(感覚)、単純な事

See also

「ゲームプログラマのためのコーディング技術」を読んだ

ゲームプログラマのためのコーディング技術

ゲームプログラマのためのコーディング技術

ゲームプログラマではないけど...
読んでみた。

ゲームと唄っていますが、またコード例はC++ですが、
例なだけで、より汎用的なコーディング技術をざっと学べる本。(リーダブルコード、リファクタリング本と同様の切り口)

TL;DL

  • コードの意図を伝えよう
    • 問題を深く理解し、小さく分割
    • 対象となるものの本質を掴み、わかりやすい名前を付ける
  • 凝集度(1つの事を行う)は高く、結合度(他のクラスとの関連)は低く
  • "いかに書くのか"ではなく"いかに書かないか"が重要
  • 難しいことをいかに簡単にやれるか

わかりやすいコード

  • 可読性が高いコードはわかりやすく、保守性が高い
  • 他のプログラマーに明確な意図を伝えるのが、わかりやすいコードを書く目的
  • わかりやすいコードを書くコツは、「複雑なコードの問題を小さく分割しながら、わかりやすい名前を付けて整理する」

わかりやすいコードを書くためのテクニック

  • 1つの意味を表すコードであれば、たとえ1行でも関数化する
  • 条件が連なるなら、早期returnを活用する
  • ループの中では一つの事だけを行う
  • 不正な状態は、assert(表明)を使って表現する
  • 関数を2種類に分類する(計算などを実行し実作業する関数/実作業する関数を複数組み合わて大きな仕事をする関数)
  • 小さな関数の必要性(コードの最小単位を関数とする) *1
    • 細かく関数化すると自己説明的なコードになる、テストがしやすい
    • 小さい方がコンパイラの最適化の恩恵を受けやすい
  • 関数名からクラスの候補を見つける
  • 継承よりも委譲
  • ユーザ定義形(typedef)を使って適切な名前を与える

シンプルな設計のための原則とパターン

  • クラスを利用する側から考えると、どのようなメンバ変数があってなどは知る必要はない > 適切に動作することが保証されているならブラックボックスのまま利用できる方が望ましい
  • オブジェクトの内部の状態を保護し、実装の詳細を隠す
  • DIP(依存性逆転の原則)を使用し、具象ではなく抽象に依存する
  • 呼び出す側は命じるだけ*2
  • 複雑なswitch文が出てきたらStrategyパターンで解決できないかを考えること
  • データ構造とアルゴリズムはオブジェクトを動作させるための手段でしかない
    • 利用者はクラスがどんな役割を持っていて、どのような責任を果たすのかが重要
  • クラス間の結合度を下げる
    • 仲介者(Mediator)を使って依存関係を単純にする
    • 窓口(Facade)を使って外部とのやり取りを隠蔽、単純化する
  • 複雑なオブジェクト生成はFactoryで行う
  • 利用者が楽できるように担当クラスに責任を完全に委譲する
  • 実装手段からボトムアップで考えるより、クラス利用者視点からトップダウンで考えた方が抽象度が上がる
  • 実装手段の交換ができるようにinterfaceを使ってプログラムを組み立てる(Strategy)
  • 問題領域は特定の環境に依存しないように設計する/実装領域は動作環境に依存する
    • 問題/実装領域を分離しておけば実装領域を交換することで他の環境にも移植可能
    • 問題領域を中心に設計すること

See also

*1:小さな関数もコンパイラによってインライン展開 されれば、パフォーマンスのオーバーヘッドはそこまで意識しなくてもよい

*2:そのクラスが管理するデータについてはそのクラスが妥当性のチェックも行う => 利用側からはそのクラスの値についてのチェック(Ask)はしない

送別会

前職の最終出社日は1月末だったが中々タイミングが合わず、 昨日送別会をしてもらった。
土曜日に多くの方が集まってくださり、遠方からわざわざ来てくださった方もいて、
本当に本当にありがとうございます。楽しかったです!

欲しい欲しい言ってた、

  • メチャクチャ水を吸い取るバスマット*1
  • 肌がすこぶる弱い自分のためにシアバターたっぷりのロキシタンのハンドクリーム

を頂きました。
早速ハンドクリームを使ったところ、信じられないくらいシットリして最高ぽい。

これで、まだまだ乾燥するであろう今年の冬も乗り越えられそうだ