本の成り立ち
最速の仕事術はプログラマーが知っている、という本を書いてください。
本の目次
はじめに
１速くてムダのないシンプル仕事術
1 辞書登録でメールを５秒で送信
2 タイピングを見直して生産性３割アップ
3 主語・動詞・目的語で議事録は書け
4 紙の資料でもリンクを張れ
5 長文にＷｏｒｄを使うな
6 企画を宇宙戦艦にするな
7 プレゼン資料は直前に書け
column 1 エジソンは手抜きの天才だった
２ 頭がクリアになる情報の整理法
1 情報を覚えて置く時代はもう終わった
2 情報の整理は見出しのつけ方が９割
3 目当てのファイルが瞬時に見つかるタイトルづけ
4 １秒でスクショ、２秒で共有
5 書類トレイの２つのモード
6 フォルダに穴を開けて取り出さずにサインする
7 Ｗｅｂに本当に大事な情報は載っていない
8 Ｇｏｏｇｌｅの本当の使い方
9 一次情報を集める最も効率のいい方法
10 クリエイティビティは移動距離に比例する
COLUMN 2 数学少年カールとアルゴリズム
３ 致命的なミスを防ぐ賢いダンドり
1 危機を事前に察知するプログラマーの本能
2 外部チェックを入れて大失敗を回避する
3 簡単なタスクをど忘れしないためのリマインダー
4 そつのない幹事の思考法
5 匿名チャットで経営会議
6 問題解決は切り分けることから始める
7 「順調です」は信じない
8 想定外を想定しておく
9 今日と明日に急な予定は入れない
10 客からの電話にはでない
COLUMN 3 独身ＯＬとループの最適化
４ チームの成果を最大化する仕組み
1 好かれるリーダーよりやりきるリーダーになれ
2 他人を思い通りに動かすスキル
3 リーダーは「働いたら負け」
4 仕事は細分化してラインをつくれ
5 二択の掛けにはどっちにも張る
6 進捗会議はチャットで同時書き込みさせろ
7 褒めるも叱るも合理的にやれ
8 ８時間に６つ製品を作らせてみる
9 なぜ行動基準がわかりやすいリーダーが成功するのか？
COLUMN 4 ルームシェアと負荷分散
５ 視野を広げてビジネスを設計する
1 お金を多次元で捉える
2 潔く選択肢を捨てる
3 取締役には２種類ある
4 ビジネスの構造を理解・設計する
5 プログラマーは未来を予見する
COLUMN 5 ハックが最適化のすべてである
あとがき
おすすめの読者
・国家認定天才プログラマーの最速仕事術を知りたい人。
・プログラマーの仕事に興味がある人。
・プログラマー思考を仕事に取り入れたい人。
プログラマーは情報処理の達人
熟練したプログラマーは、素人の何百倍、何億倍という効率の
差を生み出すことができる。
熟練したプログラマーの一瞬の思いつきが
世界を永遠に変えてしまうことがある。
Windows、Mac、iPhone、Facebook、Twitter等を
生み出したのはプログラマーである。
コンピューターの計算能力は人間の計算能力の実に４８億倍に達する。
そして現代、仕事と言えば大半が情報処理である。
ミーティング、プレゼンテーション、リサーチ、それらは
すべて情報処理の異なる側面にすぎない。
情報処理においてプログラマーはプロである。
したがって、最速の仕事術はプログラマーが知っている
ということになる。
残念ながらプログラマーの思考法はそれ以外の仕事からは身につかない。
ＤＲＹの原則
Don’t Repeat Yourself
「同じことを繰り返すな」
一度書いたプログラムをもう一度書き直すと、遥かに洗練されたものとなる。
繰り返し書き直した結果、もうこれ以上のものはないという段階に達することがある。
この洗練されたプログラムを何度も使いまわすことになる。
そのため熟練プログラマーは未熟なプログラマーに対して生産性が数倍から数百倍高い。
プログラマーは同じことを２回以上繰り返えさないようにする。
コードをコピペして少しだけ変更を加えてプログラムを書くのはとてむ楽。
なので似たような部分が、いつの間にか増えてしまう。
ＤＲＹ原則はそういうこともするなということ。
一つのプログラムで似たような処理は１か所にまとめたほうがミスが少なくなる。
自分だけのテンプレート集（ライブラリ）
仕事の効率化を進める上で、型通りのことはすべて再利用可能な状態にする。
例えば企画書や契約書などは自分でテンプレートを用意しておく。
昔のプログラムを再利用するのと同じように、過去の資料を参照して
あっという間にプレゼン資料を作成できる。
とある会社の講演では半日かけて講演内容をまとめた。
スライドは１００ページに及んだ。
講演５分前になって作成した資料をノートパソコンに入れ忘れたことに気づいた。
著者は慌てずに、以前作っていた資料をつなぎ合わせ１２０ページの資料を５分で作成。
講演は大好評でしかも資料の質は事前に完成させていたものより向上していた。
過去の講演資料をライブラリとして残していたおかげである。
ＰＩＥの原則
Program Intently and Expressively.
「プログラムを書くときは何を意図しているのか常に明確にせよ」
ビジネス文書の中でメールについで多いのは議事録。
後で見返してもわからない議事録を書く人も多い。
Ｘ社Ａプロジェクト 5/21/2015 ＠お茶の水
・案件定義書は来週末にＦＩＸ予定
・先方としては今回はアジャイル的にやりたいとの意向
・先方の子会社で市場調査を実施中
・こちらは見積もりを再来週提出
・再来週に再度会議
これでは後で見返しても、どういうプロジェクトで、関係者が誰で、
先方の誰が市場調査していて、来週のいつ再度会議をするのか不明である。
プログラマーは「来週の自分は他人」だと考えて後から読んでも理解可能なコードを書く。
最適化してコードの可読性が（読みやすさ）低下するときは、コメントで本来の
コードを記述しておく。
ＰＩＥ原則の適用である。
先ほどの議事録をＰＩＥの原則で改めると、
✕社Ａプロジェクト 5/21/2015＠御茶ノ水
参加者 ✕社 山田部長 橋本主査
Ｍ社 林田氏（Ｘ社の関連子会社）
当社 清水 柿澤
・要件定義書は来週金曜日までにＸ社橋本氏がＦＩＸ予定
→ＴoＤo 5/29正午までに要件定義書が来なければ電話確認
・✕社としては今回はアジャイル的にやりたいとの意向
→山田部長の意向
・Ｍ社で市場調査を実施中
→林田氏が担当。調査終了は5/25、報告は5/29
・こちらは見積もりを再来週提出
→5/29に要件定義書が来るので6/5までに提出
→ＴoＤo 再来週前半に開発部と要件定義書の確認会議を社内で実施する
・再来週に再度会議
→6/5 13：00-14：00 ＠御茶ノ水で仮押さえ。柿澤から後日連絡。
となる。
ビジネス文書においてはＳＶＯを明確にすることでＰＩＥを高めることができる。
Subject (主語）
Verb（動詞）
Object（目的語）
議事録の目的は
①２社が揉めた時に証拠になる。
②急な人事異動でも経緯の共有が容易になる。
③自分の評判をまもるため。
・あの人の議事録は使えない、わかりにくいと言われないように。
ＫＩＳＳの原則
ＫＩＳＳとは「Keep It Simple,Stupid!」
「シンプルにしておけ、この間抜け！」という意味。
プログラムを極力シンプルに保ち誰が見ても理解できるようにすること。
とはいうもののプログラムをシンプルに保つことはとても難しい。
だが、シンプルに保てなければ混乱してしまう。
これはプログラム以外の仕事にも応用できる。
例えば企画書やプレゼン資料。
１枚の紙に難解で多くの情報を詰め込んでも伝わらない。
自己満足でしかない。
プログラムはシンプルであるべきなのと同様にビジネス文書もシンプルであるべき。
明確なメッセージが必要。
複雑なデータや図表がどうしても必要なときは、付録として最後に添付する。
インターネットが普及した現代においては、大量な情報のなかから、
必要なものを必要なときに必要なだけ
取り込み要点をまとめるキュレーション能力が必要とされる。
ＹＡＧＮＩの法則
「You aren’t gonna need it」
「君が今必要だと思う機能を、君がいつか必要とする日は来ないだろう」という意味。
企画書を作るときは無制限に果てしなく先のことまで考えて盛り過ぎないようにする。
企画を作るときには「いま必要なのはどれ？」を心がける。
最初から非現実的な１００万人のユーザーを想定して作らない。
「自分一人でも楽しい」企画を考える。
Googleは当初、検索エンジンしかなかった。
Facebookは最初、自分のプロフィール登録と他人のプロフィール参照機能しかなかった。
多機能でなくても最初の体験が面白ければどんどん広がっていく。
最適化の原則 アルゴリズムとは
プログラマーは些細なことでも極力手間を省く方法を考える。
省力化をプログラマーは最適化と呼ぶ。
最適化こそがプログラムのパフォーマンスを決める最重要スキル。
プログラミングに熟知しているだけでは最適化はできない。
柔軟で大胆な発想の転換が求められる。
最適化次第でプログラムの性能に数倍から数百倍の差が出る。
コンピュータの性能が飛躍的に向上した今でも非常に重要なことである。
最適化の原則は“ループの内側から最適化しろ”である。
ループとはプログラム中で何度も繰り返される処理を指す。
1000＋2000＋3000＋…100000＝5050000という計算をプログラミング的に記述すると
となる。
このプログラムを実行すると最終的にはaは100になり、bは5050000になる。
cとbの計算を行っているループでは、aの値は常に同じなのでcの値も変化しない。
同じ計算を１００回繰り返すのは無駄である。
c←a*10をループの外に出すと
となり、cの計算を９９００回減らせる。
もともとの計算量は１００＋２００×１００＝２０１００なのでこれだけで約２倍の性能になる。
今ではこの程度の最適化は支援機能が自動的にやってくれる。
さらに、bをcに１００回足すのはc×１００をbに足すのと同じである。
これでループがひとつなくなり計算は４００回まで減少する。
最初の計算量の２％であり、約５０倍の高速化を達成したことになる。
さらに、c←a*10をbの計算と同時にさせることで計算を減らすことができる。
この処理で計算は３００回に減少。
さらに、bはaを１０００倍しているだけなので、ループ外に置ける。
さらに、このプログラムは答えが常に5050000である。
ということは
b←5050000
でもよいことになる。
計算量は１回であり、２万倍の最適化となる。
通常はここまでムダなプログラムはない。
外側のループをn回に変更したいとすると、
１からｎまで足した公式（（ｎ＋1）×ｎ/２）を活用して
b←（n＋1)n/21000
というコードになるが、２で割ってから１０００をかけるのは、５００をかけるのと
同じことなので
b←（n＋1)n500
となる。プログラムに汎用性を持たせることができた。
計算量は３回なので元のプログラムに比するとおおよそ６７００倍の速さになる。
これが最適化の基本的な思考法である。
プログラムの書き方次第で効率に雲泥の差が出る。
毎日の生活や仕事の中にも数多くのループが存在し、最適化により効率
を上げることができる。
危険察知能力とデバック
プログラマーの仕事のおおよそ半分はバグとの格闘である。
バグを修正する作業をデバックという。
デバックのノウハウは他の仕事にも応用しやすい。
バグとは簡単にいえばプログラミング上のミスのこと。
ミスをしない人間など存在しない。
ミスを自覚できることが大事。
重要なのは危機を察知する能力。
危機やミスを認識することができず、あれ、と思ったときはすでに手遅れになっている
ことが多い。
プログラマーの職業的特質の一つは、自分の無能を自覚していることだ。
悲しいことにいくら経験を積んでも凡ミスなバグはなくならない。
問題はシステムに大きな打撃を与える深刻なバグである。
しかし、ベテランになれば、大きなバグを回避できるようになる。
事前に防ぐ方法を学ぶからだ。
ソフトウェア工学とは失敗を克服するための学問といえる。
プログラマー的忘年会の幹事
まず、アーキテクチャ（基本構造）を考える。
確認漏れが起こるのは何を確認すべきかわかっていないため。
例えば社内飲み会。
段取りが重要。
仕事全体の流れを把握。
１参加者と参加人数を確認
２日程の調整
３店を探す
４会費の徴収
５二次会の設定
簡単に見えるが、各ステップには複雑な課題が絡んでいる。
会費、アレルギー、飲み放題にするのか等の情報。
可能な限り全員出席できる日程。
漏れのない会費徴収。
会費徴収に当たっては上司は多めに出すことを前提に逆算して設定。
以上の条件を考慮すると
１キーマンの日程と意向を確認（予算の概算）
２参加希望者の人数とアレルギーの有無把握
３店の選定
４会費徴収
５二次会の設定
上記の順番に話を進めるのが妥当。
参加希望人数、アレルギーの有無、会費の徴収状況を把握するために
Ｅｘｃｅｌでチェック表を作成しておくと完璧。
事前に必要な手順、チェックリスト表を用意しておくとヌケモレなく
効率よく仕事を進めることができる。
このように仕事の手順や構造を決めることを、アーキテクチャの設計という。
アーキテクチャの設計は部署や組織の構築にも応用できる。
実行前にさまざまな状況を予想して仕事の構造を決定する。
問題発生時に事前に決めたアーキテクチャを修正することで
二度と同じ問題が起きないようにすることが可能になる。
アーキテクチャを洗練することで仕事はより精度を上げ、効果的に回ることになる。
アーキテクチャがよくできていれば、引継ぎも容易になり、時代に合わせて効率を
損なうことなく調整可能になる。
アーキテクチャのもっともいい例がＣＰＵである。
一般に現在使われているＣＰＵのアーキテクチャは何十年も前に設計されたものである。
アーキテクチャがまるごと変わると、プログラムそのものも変わってしまう。
そのため、時代の要請に応えながら互換性も保ちつつ高性能を実現してきた。
非常に洗練されたアーキテクチャといえる。
時代に合わせてアーキテクチャを随時変更し、洗練させていく。
長期的にケアレスミスを防止して仕事の効率を上げる最も有効な方法である。
問題の原因を特定する方法
デバックのときに原因を特定するときに使うプログラマーの典型的な手法。
原因不明のバグの場合。
例 タイミングは不明だがときどき落ちる。
１そのバグが発生したときの状況をできるだけ詳しくヒアリングする。
２仮説を立てバグを再現する。
３再現できたらバグの発生個所を特定する。
４そのためにプログラムの１部を順次無効化する。
５どこで止まっているのか突き止める。
チーム不調の原因究明の仕方（デバック応用例）
チームの運営がうまくいっていない場合に、バグ原因特定方法を適用してみる。
スタッフを順番に有給休暇を取得させ休ませる。
つまり、チームの機能を一部無効化する。
できない場合は、チームを二つに分割して別の作業をさせる。
そうすることにより、
・Ａチームは順調、Ｂチームは不調。
・両方順調。
・両方不調。
など状況が出てくる。
整理して表にすると
不調チームを２つに分割すると両方うまくいくことがある。
相性の悪い人がいたことになる。
好不調に分かれた場合には、不調チームに原因を特定できる。
この場合はさらに不調チームを分割するかＡ・Ｂのメンバーを入れ替えてみる。
Ａ・Ｂどちらも不調の場合は、絶望的である。
最低二人の問題児がいて組織を機能不全に陥れている。
しかし、一番の問題として考えられるのは、リーダーのマネジメント能力である。
リーダーとチームが合っていない、リーダーが未熟で組織全体が能力を発揮できていない
可能性が高い。
このように問題を切り分けるデバックの手法はいろいろな仕事の場面に適用できる。
ＣＰＵの命令パイプライン
パイプラインは産業革命時に考案された仕事効率化の手法である。
仕事全体を細分化し、専門的に行うことにより効率を追求する方法。
これをチームワークに応用できる。
パイプラインは作業を細分化し、長ければ長いほど、処理効率（スループット）は
向上する。
コンピューターの実行単位をスレッドという。
チームで作業をする場合、このスレッドは作業内容に該当する。
通常、ひとつのパイプラインは、ひとつのスレッドで構成される。
仕事内容によっては、ひとつのパイプライン（ひとつのスレッド）にメンバー全員を
配置するより、複数のパイプラインを作って配置した方が効率的である。
複数のスレッドを同時並行処理することをマルチスレッディングという。
ゲーム開発の場合
企画、シナリオ、グラフィックデザイン、プログラミング、デバック、
テストプレイ、納品という段階に分けられる。
これを１本のスレッドでパイプラインを組むととんでもなく効率が
悪くなる。
通常、デバック以前の各段階は同時並行的に進められる。
企画者が企画を提出、プログラマーとグラフィックデザイナーは
企画の初期段階から試作開始、シナリオライターはシナリオを
書き始めるとい感じだ。
デバック、テストプレイ段階で全員が参加し、完成させ納品する。
いわゆるアジャイル開発スタイルと呼ばれる効率化の方法である。
予測不能への対応
コンピューターの中ではさまざまな予測不能な分岐が起きる。
予測不能な分岐が起きると、パイプラインが１５段であるならば
効率は１/１５に低下してしまう。
予測不能分岐によるパイプラインハザードに対応するために
投機的実行という機能がある。
予測できない現象に対して、仮説aと仮説bを立て先に計算する。
最終的に否定された仮説の実行結果を破棄する。
捨て駒を作ることで全体のスピードを上げる。
コストは２倍かかるがスピードは落ちない。
結果、最速になる。
リソースが２倍かかっても２択のどちらも３倍以上のリターンがあれば
リスクをとる価値がある。
スマートフォンは普及するか
２００７年にiPhoneが発売された。
ガラケー全盛時代、大半のアナリストはiPhone失敗の予測を立てた。
ガラケー事業で大きな収益を上げていた著者も対応を迫られた。
著者の勘として、iPhoneは今までのスマートフォンと明らかに
違っていた。
そこで投機的実行を応用した。
iPhoneをはじめとしたスマートフォンがガラケーにとって代わる。
という有り得ない未来を想定したスレッドに着手した。
大学生のアルバイトを雇うなどして低コストでiPhone向けのアプリ
を開発・研究した。
批判も多かったが、ＡかＢではなく、どちらの場合でも
生存可能にするのが戦略である。
結果、大学生がコーディングしたiPhone向けアプリは大ヒットして
会社の売上は倍増した。
セカンドライフの失敗を予見
脚光を浴びている新技術が今後定着するかは
プログラマーに聞くのがより確かである。
プログラミングを日常的にできる人間は新技術を
見極めるのが上手い。
実際に新技術をプログラミングすることは
将来性、有効性を理解するのに非常に役立つ。
どんな技術もプログラマーが一定数集まらなければ
発展することはない。
例えば昔、「セカンドライフはこれからどうなるか」
というパネルディスカッションに参加したことがある。
当時、セカンドライフというメタバースが流行していて
仮想空間の土地が売買されたり、仮想空間上の通貨が
実際の通貨と取引されていた。
そこで、著者はセカンドライフで使用されている
リンデンスクリプトというプログラミング言語を調査した。
ところがそれは、とてもまともなプログラマーが設計した
ものとは到底思えなかった。
このブームは長続きしないと発言した。
大ブーイングだったが、ほどなくセカンドライフは姿を消した。
プログラマーがプログラマー視点で技術の未来を予測することは
高精度で可能。
アーキテクチャ
コンピューターやソフトウェアは複雑な構造を持つ。
このような構造をアーキテクチャと呼び
構造を考案する人をアーキテクトという。
アーキテクチャを考える場合、まずほかのアーキテクチャを
学ぶ必要がある。
あらゆるアーキテクチャは既存のデッドコピー、改良品である。
ゲームならゲームのアーキテクチャ。
ツールならツールのアーキテクチャ。
オペレーティングシステムならオペレーティングのアーキテクチャ。
という具合に徹底的に研究する。
ハック＝最速化
ハックとは例えば３Ｄプログラミングでいうと裏側を向いている面は最初から
表示しない。
立方体の場合はこちら側の３面だけを表示する。
これだけで描画する部分が半分になる。
シンプルに目的を達成しようとすることがハックの考え方だ。
何度も繰り返すものは省略する。
状況の変化を推測して拡張性を持たせる。
他の目的で作られたものを別の用途に使いまわす。
といったことをプログラマーは常に思案している。
リーダーの仕事
著者は製品プログラムを書かない。
なぜかと言えば
コンビニのオーナーを例に例えれば
オーナー自ら商品を陳列してレジ業務をこなしていたら、
運営に失敗している可能性がある。
現場に率先して立つことは、尊敬を集めやすい。
しかしそれでは、リーダーとしての資質を疑われる。
リーダーはそのグループで一番給料が高い。
そのリーダーが給料の安いアルバイトの品出しやレジ打ちを
するのはリーダー資源のムダ使いである。
リーダーの主な仕事はチームビルディング、ディレクション、トラブルシューティング
である。
そして、トラブルシューティングの比重が大きくなる。
忙しかったならばトラブルシューティングがおろそかになる。
優れたリーダーは一時の尊敬のまなざしを集めるために時間を
浪費しない。
結果を保証できる能力がリーダーに求められる。
会社は人気があっても結果を出せないリーダーを必要としない。
リーダーとして成功する人
Googleがリーダーとして成功する人の条件を分析したところ
学歴や知能指数は関係なく、「行動や反応を予測しやすくかつ
一貫性がある人」との結論が得られた。
上司が予測可能であればあるほど、部下は行動しやすい。
部下は上司が求める仕事をしているかどうか、
判断しやすくなり、上司もその分干渉する必要がなくなる。
行動が予測可能であるならば付き合いやすい上司という
ことでもある。
怒るべきときは怒る
著者は怒るときは激しく怒る。
怒ることは面倒で労力もいるので苦手だったが、経営の大先輩から怒るべきときは
怒るように諭された。
以来、行動を改めた。
怒るべきときに怒らなければ伝わらない場合がある。
あまり例はよくないが、ＡＩにおける強化学習の一つである。
きちんと怒ることは相手にとってもわかりやすい。
まとめ
国家認定の天才プログラマーによる仕事術です。
プログラマー思考はプログラミングだけではなく
通常の業務をＤＸする上で極めて重要です。
６分でプレゼンをまとめたり、１時間かけていた会議を
５分に短縮できたりと、ＤＸによる業務効率化の手法が学べます。
プログラマー思考が仕事全般の業務効率化に有効であることが
理解できます。
著者紹介
１９７６年、新潟県生まれ。
高校在学時、雑誌にプログラミングの連載を持つ。
電気通信大学在学中には米MicrosoftCorpにて家庭用ゲーム機の開発、
技術動向の研究、教育に携わる。
文部科学省の委託事業を経て、９８年にドワンゴ入社。
エグゼクティブゲームディレクターとして携帯電話事業を立ち上げた後
２００２年に退社。
ＣＥＤＥＣ（ゲーム開発者向け技術交流会）設立にかかわる。
２００３年、株式会社ユビキタスエンターテイメント代表取締役社長兼ＣＥＯに就任。
（現在は解散）
２００４年度、独立行政法人情報処理推進機構（ＩＰＡ）より
天才プログラマー/スーパークリエイターとして認定される。
０８年～１０年九州大学非常勤講師。
誰でもプログラミングできる環境を目指し「enchant.js」「enchantMOON」など
を世に送り出す。
２０１７年に株式会社ソニーコンピュータサイエンス研究所、ＷｉＬ, ＬＬＣと共に
ギリア株式会社を設立、代表取締役社長に就任。
取締役会長を経て２０２２年６月よりファウンダー・顧問に就任。
著書に『ネットワークゲームデザイナーズメソッド』（翔泳社）
『教養としてのプログラミング講座』（中央公論社）
『はじめての深層学習(ディープラーニング)プログラミング』
（技術評論社）
『よくわかる人工知能 最先端の人だけが知っているディープラーニングのひみつ』
（ＫＡＤＯＫＡＷＡ）
など。
出版情報
著者 清水 亮
発行日 ２０１５年７月３１日
発行所 株式会社クロスメディア・パブリッシング
定価 １４８０円＋税
|
|
コメント