読者です 読者をやめる 読者になる 読者になる

2012年

2012年は怒濤の年だった、ような気がする。

2011年に執行役員を拝命してから、

開発から遠ざかるような近づくような微妙な案配を繰り返していたけど、

単に技術だけではなくて、

ビジネスのやり方とか、人の育て方とか、マネジメントとか、

色々な事を考えることが増えた。

そして、技術だけではダメだと感じるようになった。

勿論、技術も必要なんだけど、技術だけでは組織をつくることはできないし、組織を活かすこともできない。

技術はあくまで道具で、それを使いこなすのは人間だ。

 

そうした中で、やはり人から学ぶしかない、というのが最近の結論で、

最高の教科書は共に働く人間であると思う。

さて、今年も頑張りますかね。

デザインパターンにまつわるエトセトラ

misc

社内でデザパタが盛り上がっていたので、社内勉強会でLTしました。
その資料です!

基本的に自分はデザインパターンは「言語に依存しない設計に名前をつけたもの」だと定義しています。
なので、よくある「デザインパターンってJavaじゃないと役に立たないよね」なんていう意見には反対です。
勿論、言語によっては適応する意味の無いパターン、意味の薄いパターンもありますが、
GoFのパターンだけがすべてではないですし、
"設計に名前をつけて共有する"というスタンスこそが最高のものだと思っています。

(酒井姐さんは社内のエンジニアです)

最後でも紹介していますが、この本が超オススメです!

デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series)

デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series)

アジャイルが失敗する本当の理由

最初に結論を書いてしまえば「プロセスは銀の弾丸じゃないよ」ってこと。

そして、エンジニアだけがやるものじゃないんだろうね、ってこと。

 

最近というよりも、アジャイルという言葉はずっと以前から言われていて、

アジャイルソフトウェア開発宣言は2001年だし、

Scrumが生まれたのも1986年だ。

 

20年以上も多くのソフトウェア開発プロジェクトはプロセス改善を叫んだし、

実際にやってもきたけれども、

何故未だに建物を建てるようにソフトウェアを創れないんだろう?

 

これは自分がよく知る話。

 

「ソフトウェアの開発に変更はつきもので、かつエンジニアの力量によっても工数は大きく変化する」

というエンジニアの認識があったとき、こんな話がでることがある。

 

「なら最初からそれを織り込んだスケジュールを立てれば良いだけの話です」

原発東京スカイツリーのような巨大建造物でさえ、当初に立てたスケジュールに沿って建設されています」

「数十万キロ彼方の小惑星まで飛んで帰ってくる人工衛星でさえ、秒単位、分単位のスケジュールを立てて運航されています」

「どんなプロジェクトだって、事前には想定しきれない不具合や支障があるでしょうが、それを織り込んだスケジュールを立てて、皆がそれを運用しています」

 

確かにそうかもしれない。

でも、

なぜソフトウェアは建築物を建てるように構築できないんだろう?

なぜソフトウェアは秒単位、分単位で運行される衛星や列車のように運用できないんだろう?

 

答えはエンジニアの中にあって、エンジニアの外にはない。

だとしたら、どうやって伝えれば良いんだろう?

 

顧客を巻き込むプロセスは多くの場合、

これらの問題に答えをもたらしているし、

現実は多くの場合、顧客を巻き込めない。

だから、アジャイルは失敗する。

 

なので、

恐らく、ソフトウェア開発が劇的に改善することはきっとないだろう。

 

でも、それは技術によってではなく、人間の心によってだと思う。

だからこそ、今やれることがあるんじゃないかな、とは思っているところ。

開発に必要な力は二つしかない

最近開発をしてきて開発者に重要だと思うのは、

・問題を発見する力

・問題を解決する力

の二つだと思っている。

実際にコードが綺麗とか、技術が卓越している、というのは個人の手腕であり、

持ちうるスキルではあるのだけれど、

それは「問題を解決する際に使われる力」だ。

そして、これには「コミュニケーション力」や「交渉力」、

「論理的思考」や、「選択肢の中から成否を見据える力」も含まれている。

 

そして、これを行うためには「問題を発見する力」が欠かせない。

「何が問題なのか?」を考えずにこれらの力をふるうことはできない。

いかな高い技術力があっても、それを使う場所や使うべき場面が解らなければ何の意味もない。

 

要するに重要なのは「問題を発見し、解決する力」だ。

これが出来れば職場も個人の問題も、何でも解決できる。

そして、組織が強いのは沢山の眼があること、沢山の思考があること。

要するに重要な力は2つに分割することができる。 

 

勿論、「解決できない問題」も存在するし、「そもそも問題とは何か?」ということもある。

でも、解決できる問題を見つけて解決していけば前に進むことはできる。

そうすれば、視界は広がって、もっと大きな問題に出会える。

基本的に問題を解決することは楽しいことばかりだ。

学校のテストのように答えが用意されている訳ではないし、

その答えが正しかったかが分かるのが10年後だったりもするけれども。

 

そして、文句ばかり言う人たちは本当には問題を発見できていない。

問題を発見するには、不平不満を述べるのではなく、

手を動かし口を動かし、様々な事に耳を傾ける必要があるからだ。

だから、問題を見つけたら愚痴る前に何とかしてみようと自戒する。

さぁて、もうちょい頑張らないとねえ。

 

長く座るつもりでリープチェアを買うなら、ミラチェアかアーロンチェア

msic

ということでキーボード話に次いでよくありがちな椅子の話題です。
お手軽に生産性向上させるなら椅子ですよね!
ってな話で。


この手の話によく挙がるのはアーロンチェア

ハーマンミラー アーロンチェア ポスチャーフィット フル装備 AE113AWB PJG1BBBK3D01

ハーマンミラー アーロンチェア ポスチャーフィット フル装備 AE113AWB PJG1BBBK3D01


自分が愛用しているのは、ミラチェア。


そして、リープチェア、


なんですが、これはコストパフォーマンス悪いなあと。
リープに10万出すくらいなら、アーロンかミラ、あとはオカムラの椅子にするほうが……、と。


ミラチェアをずっと使っていて思うのは、
飽きない椅子なんですよね。
疲れている時、集中したいとき、
色々とカスタムできるのは最高に使いやすい。


リープに関しては、
何度も言いますが3万円以下の椅子の鉄板は中古のリープチェア - Future Insight
な話もあるのですが、
確かに中古で三万円に抑えるなら確かにリープチェアかなあとも思います。
三万円の椅子としてみたら破格なので。


ただ、長く座ろうと考えたり、生産性向上のために椅子に座ろうと考えた時は、
アーロンやミラはカスタムが豊富で「椅子を身体にあわせる」というスタイルなのに対し、
リープはそうでもないです。
ちょっとカスタムできる良い椅子、くらいの椅子。
二つを座り比べると解るのですが、リープにはアーロンやミラにあるクッション性や包み込む感じが欠けています。


またリープを使っていて微妙と思うのは、

・カスタムがミラチェア、アーロンチェアに比べて物足りない
・手すりが2年くらいでボロボロ崩れるようになって交換しないといけない
・クッション性能がメッシュなどに比べて弱いので、そこまで良い椅子とは思わない

ってな感じかなと。


リープの良い点は、「中古が安く、新品の同価格帯の下手な椅子に比べクオリティが高い」一点に思います。
なので、アーロンやミラがお勧め!

時間がないなら生活を自動化すべし

misc

プログラマの明言として、こんな言葉があります。

プログラマーとしての君の仕事とは、君自身をクビにすることだ。君が今日やっていることは、明日には自動化することもできるのだ。

さて、生活で自分がやらなくても良い事を自分がやっていることないでしょうか?

見直してみると実際には色んなことがあります。
……ということで、最近はこんなものを使ってます、というお話。
生活の中で自動化できること、自動化してみませんか?

で、言わずと知れた自動掃除機。

iRobot Roomba 自動掃除機 ルンバ 770

iRobot Roomba 自動掃除機 ルンバ 770

こいつは思った以上に優秀。
放っておくだけで部屋の埃や髪の毛をどんどん取ってくれるのは最高です。
よく考えると掃除する時間って無駄ですよね?
でも、部屋が汚いのは嫌、ってことでこいつは役立ちます。


本体が侵入できないところなどは別のハンディ掃除機などで対処すればよく、
ボタン一つやスケジュールによって掃除してくれるのは凄く便利。
どんどん高性能化しているのも良いですね。


多少高額ですが、時間はお金では買えないもの。
日々の時間の積み重ねが得られると思えば安いのではないかなと。

僕と契約してPythonistaになってよ!

misc

すっかり更新が滞ってましたが、
弊社が東京(都庁前)にてPythonアジャイル開発できる仲間を募集しています。
開発対象は、大規模アクセスをさばくソーシャルアプリおよびその環境周りです。


基本、Python、Django、Flask、Redis、memcached、MySQL、Git、Capistoranoなどを用いた軽量な開発です。
軽量開発もスクラムマスター研修などを通じて軽量化、効率化を心がけ、
かつ、お互いにとって刺激ある開発環境を目指しています。
自分でサービスを書いたり、Webゲームを書いているメンバもおりますし、
社内勉強会なども積極的に行っています。


開発環境について自分は「ゆとりの法則」「ピープルウエア」を意識してはいるのですが、
何が最適か、は組織やチームによって変わってくるので、
常に改善し続けること、楽しくあろうとすることかなあ、と思っています。
そういう意味で変に柵もないので、開発者にとって働きやすい環境です。


年齢/性別不問です。
もしご興味があればお気軽に wow[at]snow . dti2 . ne . jp
にメールをください。(不要なspace除去、および@置換でお願いします)
採用面接などは自分がやっております。


別にPythonが書ける必要は無いです。
どちらかというとC++RubyScalaHaskellLua、Groovy、Smalltalkしか書けないけど書きたいんだよぉぉ、みたいなマインドがウェルカム。
適切な言語やフレームワーク、ライブラリも柔軟に変えていきます。
あとバグるとヒールで踏まれます。