恵比寿で働く社長のアメブロ

テンションが高い状態で集中しプログラミングをしているときの開発生産性は驚くべきものがある。

しかし、好きな技術、ジャンルの仕事をしていたとしても、どうもテンションがあがらない、モチベ－ションがあがってこないというという状況になってしまうこともあるだろう。

このエントリーでは、私があるperlのシステム開発プロジェクトに参画した際に、自分のプログラミング・テンションを高めるために試みた１つの方法を紹介する。

今回の方法は、心理学で言う「お預け理論」をベースとして考案された方法である。

私が参画したプロジェクトはスケジュール的余裕もなく、夜遅くまで精一杯やって終わるかどうかという開発量であった。このような状況では、少しでも早く手を動かし、プログラミングを始めたくなるのが人間心理ではないだろうか。

しかし私は、朝に席に着き、マシンを立ち上げ、メールをチェックしたあと、すぐにプログラミングを始めずに「perlベストプラクティス(オライリー出版)」を３０分かけて読むという作戦をとった。（perlベストプラクティスの表紙もお預けを食らったかのような犬のイラストである）

Perlベストプラクティス/Damian Conway

￥4,515

Amazon.co.jp

「perlベストプラクティス」は、perlプログラムの堅牢性、効率性、保守性をアップすることを目標としてコーディング理論、ノウハウがまとめれた名著である。これを読むことで、perlに限らず他の言語でも適用できる優れたプログラミング理論、お作法を学ぶことができる。

内容は、コードのレイアウト、命名規則、値と式、変数、制御構造、ドキュメント、組み込み関数、サブルーチン、I/O、参照、正規表現、エラー処理、コマンドライン処理、オブジェクト、クラス階層、モジュール、テストとデバッグなど１８章に渡り、かなり重厚である。

（余談だが、perlベストプラクティスで貫かれているポリシーとしては『perlはいろいろな書き方、文法が用意されていて便利な言語だけど、それを各個人が、自由気ままに使うと、プログラムが読みづらくなって、保守性が下がったりバグを見つけにくくなるから、使う機能、文法を限定して、誰にも読めるようにしようね』と言うことであるように感じた。ちなみにpythonは、ひとつのことをやるのにひとつしか書き方がないという言語設計なのでそのような本末転倒っぽいことはなく、普通に書けば読みやすいコードとなる。ビープラウドがLL（Light Weight Language)の開発言語としてpythonを推す理由の１つもそこにある）

１日１章を読むことに目標していたので、かなり集中しないと内容も頭に入らないので、自然と集中できる。

読み方としては、まず昨日読んだ章をざっと目を通し復習する。前日の復習が終わったらその日に読むべき章を読み進めていく。perlベストプラクティスに載っているプログラミング作法を学んでいくと、実践で試したくてうずうずしてくる。しかし、そこは我慢してひたすら読み続ける。さらにうずうずは増す。

まだかまだかと待っていた３０分が経過したところで、うずうずを解き放ちプログラミングをはじめる。そこから昼までの時間はまさにゴールデンタイムとなる。１日につくるべきものは大体できあがってしまうときもあった。

この方法の良いところは、テンションが上がり、生産性が向上するというだけでない。

もう一つの効果として毎日継続して３０分勉強したことをすぐに実践で生かせるので、理論面と実践面が合わさり、相乗効果でスキルが伸びていくという点である。プロジェクトが忙しいから勉強時間がないということもあるだろうが、最初に勉強しているのでそのようなこともない。

そして、おまけとして、１か月もすれば、perlベストプラクティスのような分厚い本（１８章）でも自然に読破できてしまっているのである。継続による積み重ねはおそろしい成果をあげる。

１００の実力がある人がモチベーションがあがらず５０の力しか発揮しなかったとすると、５０の実力をもった人が全力で仕事したのと同じ成果ということになってしまう。これでは高いスキル、知識を持っていても宝のもちぐされとなってしまう。

そして上がらなくなったテンションはいつしか習慣となり、なかなか抜け出せない状態となってしまうこともある。

イチローも「心に贅肉をつけてしまうとなかなか取れない」と言っていたが、まさにそのような状態であると言えるかも知れない。

そのようなことにならないためにも、プログラマは意識的に、積極的にテンションをあげていく術を知っておくことも大事ではないだろうか。

BP Study でそのようなエンジニアの心理学的なものをテーマに開催するのも面白いかもしれない。

Perlベストプラクティス/Damian Conway

￥4,515

Amazon.co.jp

今年の目標１０１エントリーまであと８６

37signalsのGetting Real をshin_no_sukeに奨められて、じっくり読みました。

今後のビープラウドにとって、参考になることが山ほどあったので、まとめておきます。（文が汚くてすみませんが）

・デザインからはじめる
　インターフェースが製品である。顧客からみえているのはインターフェースである。
　アプリの改修は一番重い。デザインなら捨てることもできる

・チームは小さくはじめる（三銃士）
　最初のバージョンは小さく、タイトで構わない。そこからアイディアに翼があるかどうかを知ることができる。
　小さな人数で構築することにより、綺麗で、シンプルな基礎を手に入れることができる。

・最初の資金のかき集めは不要。自分たちの手持ちから
　→外部の資金を出す人は、自分の手元に早く短い期間でお金が戻ることを期待する。製品もその思惑に左右されることが多い。そして、さっさと撤退しにくい

・スリムなアプリケーションにする
機能追加にはまずノーをいう。｢less(より少なく)｣
　→本当に必要な機能は、何度も要望があがってくる
　→一つの機能をつくるということは、一人の子供をもらうようなもの
　｢より少ない｣特徴、機能、オプション・設定、スタッフ数、チーム構造、ミーティングと曖昧なアイディア、約束
より少ないソフトウェアは、管理が簡単、コードベースを削減する、メンテナンスが楽、変更コストを低下させる、バグ数が減る、サポート量が低下する
ムダがないほど変化しやすい。変化のコストを抑えることができる

・ユーザ設定による選択より、完璧なデフォルト値

・開発者には、干渉されない時間を１日にかならず半分つくること
　レム睡眠になるには時間がかかるように、集中するには、段階があり、時間がかかる

・個々に分けない
　多くの企業が、デザイン、開発、コピーライト、サポート、マーケティングを個々に隔てすぎている
　それには、利点があるが、木を見て森をみずになる。可能な限りこれらを１つのチームにする。　全体を見渡すことにより、質の高い議論ができるチームにする。人を雇うときは、開発中、様々な帽子を被ることができる多才な人を雇うこと。結果的に良い製品ができあがる。

・人材は少なく雇い、スピードを上げたい場合に、あとで少しずつ足す。
　最初に100人の最高の人材を選んでも、教育、研修、個人と個人の対立、コミュニケーションの喪失になやまされることになる。

・人材を雇うとき
　言葉より行動をみる
　スペシャリストよりゼネラリスト
　小さなチームには、何足もの草鞋を履ける人間が必要。
　一つのことに固執する人より、変化できる人
　不満だらけの優等生より、普通だけの幸せな人
　熱意のある人、１人でも仕事を任せられる人、作る物に熱中できる人、自分たちの列車にわくわくして乗ってくれる人

・ツールは、チームの刺激や情熱を維持し続けられるツールを選ぶ
　正しい選択をすると、利用可能なだけではなく、楽しく刺激的に作ることができる。毎日のちょっとしたことを楽しくすることができる。結果、開発者たちは、良い製品を生み出すことになる。

・製品のプロモーション方法
　広告よりも安価で効果があるのはブログである

・ユーザサポート
　ユーザサポートへの問い合わせには最優先事項で取り組む

他にもあげてない項目ありますが、このへんで。おすすめです。是非ご一読を。

今年の目標：１００エントリーまであと４１。

私がフリーの時に自宅で開発をしていたときは、自分の好きな音楽、特に邦楽をかけていた。

しかし、私はあるときからそれをやめた。

邦楽をかけていると、頭の片隅でその歌詞を追っかけていて、開発中に自分の中から聞こえてくる小さな声を聴き逃したり、忘れてしまったりするからである。そのような小さな声は、大抵の場合、開発の深い部分に関することであり、大事な部分に関することである。

そのようなことから、開発のように、最新の注意、集中力がいるような仕事では、邦楽をかけるのは向かないのではと私は思う。開発現場で、有線で邦楽をかけてしまうのはご法度だろうと思う。

しかし、音楽をかけていると調子に乗れる場合もあった。それはJAZZをかけている時である。

私の場合、なぜかJAZZだと音楽をかけているのも忘れて集中することができていた。これはまだ理由は判明していないし、調べてもいない。

仕事中に邦楽を聴くことも悪いことではなかった。仕事を始めるのに気が乗らない時は邦楽をかけながら始めると、徐々に乗っていくことができたのである。しかし、乗ってきたところで、そのままずるずると音楽をかけたままにすると集中が最高に高まらないので、音楽をとめるか、JAZZに切り替えることが必要であった。

その切り替えを思い切ってできるかが、大人の心で開発ができるかどうかの分かれ目である。

私の場合、JAZZをかける、もしくはなにも聞かないで静寂の中で開発するという集中方法がみつかった。しかし、それは人それぞれだろうと思う。

エンジニアは自らが最高に集中できる音環境をみつけておくと良いだろう。

今年の目標：１００エントリーまであと５３。残り２３７日。