最近、文系不要論とか、
文系人間は理系から学ぶべきだとか、
世間様が好きそうな二元論争が盛んだ。
そんなトレンドに振り回さず、
逆に抗い、斜に構えることもなく、素直に聴いて欲しい。
あなたがもし非プログラマーとして、
ITに関わる仕事をしていたとしたら、
そしてまた、
もし、
仕事を楽しみたいと思っているなら、
仕事で大成したいと思っているなら、
迷わず読まなければならない書籍の1つとして、薦めたい。
最近、改めて、自分という人間が、
いかに無知であるか、ということを、
嫌というほど突き付けられる機会に恵まれ、
自分の勉強不足を真摯に受け止めることが出来た。
おかげで、
当たり前すぎて学ぼうと思えなかったことや、
軽視してしまいそうなことを学び直している。
今更、「仕事術」なんて、、、
と一笑に付している場合じゃない。
仕事で感動し、その他大勢から抜け出したいのなら、
自らの無知を知り、
自らに必要な知識を貪欲に吸収し続けていきたい。
””プログラマーは同じことを2回以上繰り返すことを極端に嫌がる。プログラミングの世界にはDRY原則という言葉がある。Don’t Repeat Yourself. 同じことを繰り返すな、という意味だ。プログラマーは同じことを繰り返すのが嫌いだが、コピペは好きだ。コピペしてちょっとだけ変更してプログラムを書いていくのはとてもラクなので、ついついプログラムのなかに似て非なる部分が増えていってしまう。DRY原則はそういうことさえもやるな、という意味だ。一つのプログラムで似たような処理は1か所にまとまっているほうがミスが少なくなる。””
DRY原則なるものがあるそうだが、
プログラマーじゃなくても、効率的に、仕事を仕組み化しようという人間はいるだろう。
しかし、ここでは、大多数のプログラマーが、そういう考え方をしている、
ということを、素直に受け止めてむることが大事だな、ということを忘れちゃいけない。
””ライブラリ ＝ 自分だけのテンプレート集 。この考えを仕事に応用すると、ライブラリという発想になる。自分の仕事を効率的に進めるために、仕事の上で典型的なことをすべて再利用可能な状態にしておくのだ。例えば、企画書や契約書などは自分で典型的な内容のテンプレートを用意しておく。昔のプログラムを再利用するのと同じように、過去の書類を参照してアッという間にプレゼン資料を作り出せる。 ””
これまた何も真新しい表現でも何でもない。いわゆる「仕組み化」的な仕事術みたいなものに、よくまとめられている。僕の場合は、出来るプログラマーは、この「ライブラリ」という名の自分だけのテンプレート集を持っていると、何度か言われたことを思い出したことと、プログラマーじゃなくても、Professionalとしての「ライブラリ」や「テンプレート」を沢山あつめてよ、と言われたことを思い出した。
その当時、僕は、サービスや運営の責任者、兼、ゲームプランナーを担当していたのだけど、ビジネスディベロップメントのプロとして、誰にも負けない「ライブラリ」を持てるようになっておいてね、と指摘してもらったのだが、そのような習慣を続けられていなかったな、と反省した。
【抜粋】
●シンプルこそ命 プログラミングの鉄則の一つにKISS原則というものがある。 KISSとは「Keep It Simple, Stupid!」の頭文字をとったもので、「シンプルにしておけ、この間抜け！」ということだ（誰が言い始めたのかはいまいちはっきりしないが、ゴロのよさとフレーズの刺激がプログラマーの感性にフィットしたのだろう）。 基本的にプログラマーは人間の頭脳を信用しない。 それは人間の頭脳や思考能力には致命的な限界があることを誰よりも熟知しているからだ。
● 筆者が企画を作るときに心がけているのは、「今必要なのはどれ？」ということ。 そのソフトはなぜ必要とされるのか、どの機能だけがほんとうに必要なのか、コアの機能を作りこめば、それだけで勝負できるのか、できないのか。 よく言っているのは「ユーザが自分一人でも楽しい企画」ということ。一人で楽しくないものは二人で使えない。
● プログラマーは手抜きの天才でなくてはならない。 泥臭い仕事を瞬時に片付けるためには、まず手抜きができなければならないのだ。 そして手抜きこそが、物事の本質を瞬時に見極め、有意義な時間を作り出すプログラマーに備わった本能なのである。
● プログラマーの職業的美点をひとつ上げるとすれば、ほかのどの職業人よりも自分が無能であることに自覚的であることだ。 プログラマーは常に自分自身の生み出したミス、すなわちバグとの戦いを余儀なくされる。 自分のバグに自分でケリをつけられないプログラマーは半人前だ。 だからプログラマーは自分の生み出したバグという怪物と、とことん戦うことになる。 そして悲しいかな、プログラミング歴をいくら重ねてもつまらないバグは繰り返してしまう。 しかし経験を積んだプログラマーは大きなバグは繰り返さない。つまりプログラマーは大きなミスを事前に防ぐ方法を知っているのだ。 ソフトウェア工学の歴史とは、大げさに言えば人類が自らの無能と戦うための方法論の歴史でもある。
● 「順調」という言葉で報告するのではなく具体的に「何をしたのか」ということと「後は何をいつまでにしなければならないのか」という点をハッキリさせる必要があった。そのプログラマーはすぐさま現場から外し、ほかの人間をアサインすることでなんとかその場を乗り切った。あと1週間発覚するのが遅れていたら致命傷になる際どいタイミングだった。 違和感を感じたらとにかく徹底的に追及する。 それがプログラマーの本能だろう。
● 突発的な予定をなくして効率的なペースを保つ こういう、事前に行動計画をイメージしておくことをコンピュータ用語では「プリフェッチ」と呼ぶ。 フェッチとはプログラムをとってくることであり、プリフェッチはそれを事前に行うことを意味する。通常、コンピュータのCPU（中央演算処理装置）はプログラムをプリフェッチしながら並行して計算処理を行うよう設計されている。それが最も高速にプログラムを実行する方法だからだ。 しかし割り込み処理が入ると、このプリフェッチした情報が無意味なものになる。それをパイプラインハザードと呼ぶ。パイプラインハザードは効率的な処理にとって最大の敵だ。したがって、通常は1営業日空けてしかスケジュールを入れないというルールを前もって定めておけば、パイプラインハザードを抑制することができる。
● プログラマーだけは、現実と理想のはざまを常に経験する特異な職業である。 自らの頭脳で構築した理論（プログラムの設計）を、実際の現実世界の実装に落とし込む（プログラミングする）。その際、自分の理論は正しかったのか、そうでもなかったのか、どこが間違っていたのか、ということをイチイチ検証しなければ、仕事は永久に終わらないのだ。 そしてこれは「結果を出す」という、リーダーに求められる根源的な資質をプログラマーが常に訓練されていることをも意味するのだ。 結果を出すためには、非情にもメンバーを切り捨てたり、彼らから恨まれるような決定を下したりしなければならないこともある。 しかし結果が出せないリーダーは、その場ではみんなから好かれたとしても、最終的には仕事が回ってこなくなる。結果が出せないリーダーは長続きしないのだ。
● プログラムとは何か、突き詰めていうと、自分のいないところで自分の思い通りに自分以外の存在を動かすこと、である。 つまり、そもそもプログラマーが扱っていたのは、コンピュータではなく人間だったのだ。
● 組織のアーキテクチャとは、組織構成はもちろん、人事考課や給与制度、会社の理念や社員の採用方針など、会社を構成する全てである。
● 僕の仕事はコミュニケーションの構造を設計し、実現することであり、つまりコミュニケーションのアーキテクチャを作っているということである、と解釈できる。 それから、自らを「コミュニケーション・アーキテクト」と名乗るようになった。
● アーキテクチャを設計する際にはまずほかのアーキテクチャを学ばなければならない。 ゲームならゲームのアーキテクチャ、ツールならツールのアーキテクチャ、オペレーティングシステムならオペレーティングシステムのアーキテクチャをまず徹底的に研究する。会社の場合なら他社のビジネスモデルだ。 プログラマーでないビジネスマンのために、ここではとあるサラリーマン鈴木氏がある新規事業を立ち上げることを想定しよう。
● すべて仕事の「手抜き」につながる。手抜きというと聞こえが悪いが、要は手品と同じ、タネも仕掛けもあるちょっとした器用な工夫である。そして、それを使う人が実際にいい気持ちになって実用に供すれば、途中の経過なんて短いほうがじゃないのという姿勢である。 これをプログラマー的に言うならば、「ハック」という言葉になる。