2012-04-26

gumistudy 福岡 #2 を開催しました

4/25 に福岡オフィス移転後最初の gumistudy を開催しました。

今回のテーマは「バージョン管理システム」。同じく福岡にオフィスを構える KLab 株式会社様と共催させていただきました。KLab 様では Bazaar、gumi では Git を中心に使用しています。

gumi からは「実践 Git」というタイトルで、どちらかというと Git の高機能な側面ではなく Git の内部構造を掘り下げた内容の発表を行いました。

実践 Git

View more presentations from Youhei Nitta

今後も gumistudy 福岡、定期開催して参りますのでよろしくお願いいたします。

2012-03-22

アジャイルな見積もりと計画づくりをするために必要なたった１つのこと

単に「見積もりをする」ときどのように見積もっていますか？
「プランニングポーカー」ですか？
それは正しく使えていますか？

それらの再確認も含め、
社内勉強会にてやっとむさんをお呼びして「アジャイルな見積もりと計画づくり」勉強会を行いました。

「計画」とは何か？
「見積もりと計画づくり」とは何か？

といったようなことを主体に参加者で話し合いました。

まずはやっとむさんによる「アジャイルな見積もりと計画づくり」の「計画」について。

「計画づくり」とは？

見積もりの不正確さについて。

さて、これは何でしょう？

プランニングポーカーによる実践。
ポーカーは手作り。

こんな感じで出していきます。

何度か繰り返します。

最後に勉強会の振り返りと感じた事の共有。

gumiではこういった事を積極的に行ってプロセス改善を意識しています。
大切なことは「改善する」という強い意志を持つこと、
そして、それを「継続する」という強い想いを持つ事。
それが「改善し続け、価値のあるソフトウェアを育てること」に繋がっていると考えています。
即ち、「改善し続けること」それがアジャイルの心でもあると思います。

また、勉強会を用いなくても以下の本で見積もりを学ぶ事ができます。
もし良かったら読んでみてください！（やっとむさんと角谷さんが翻訳されています）

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
出版社/メーカー: 毎日コミュニケーションズ
発売日: 2009/01/29
メディア: 単行本（ソフトカバー）
購入: 74人クリック: 764回
この商品を含むブログ (226件) を見る

2012-03-02

自然に偉大と呼ばれるエンジニアになるたった６つの方法

XP(Extreme Programming)で有名なケントベックは言いました。

僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。

今まで出会ってきた「偉大だ」と感じるエンジニアには共通した習慣があるように感じます。

道具に拘りがあり、常に研鑽する

道具というとキーボードなどを思い浮かべるかもしれませんが、道具とは物理的なものに止まりません。
エディタ、OS、言語、モジュール、フレームワーク、ライブラリ、様々なものがそれにあたると思います。
勿論、キーボードもマウスも、ディスプレイも、ガジェットもそうです。
そして、それらを使いこなそうとします。
深く探求し、自分なりのリズムを刻もうとしています。

コードリーディングから始める

新しいものを学ぶとき、「書くことから始める」か「読むことから始めるか」という違いです。
多くの場合、新しい言語を与えられると人は「書くことから始めよう」とします。
これはある意味正しくも見えますが、偉大と感じるエンジニアは大抵の場合、「読むことから始めよう」とします。
未知のものに触れるとき、良いと言われるものを探し、その場所で良いものとは何か？ということを追求し続けています。
なぜなら、新しい分野で自分の経験が通用しない可能性があることを十二分に知っているからです。

推測で物事を言わず、常に自分から疑う

不具合が起こったとき、「まず誰のバグか？」ということを考えないでしょうか。
よくあることとして、「誰かのバグなんじゃ？」もしくは「ライブラリやフレームワークのバグなんじゃ？」と感じることがあると思います。
優れたエンジニアの場合、「自分が何をしたか？」といったようなところを疑う傾向にあります。
新しい技術を扱う場合も同等で、以前の自分の経験に照らし合わせるだけでなく、
「自分が知らないのではないか、自分が間違っているのではないか」ということを常に考えています。
そして、憶測で「〜だろう」というのではなく、「まず計測してみよう」という姿勢を崩しません。
空疎な議論よりも自明であることが何よりも優れていることだと知っているからです。

知らない事を知らないと言うことが出来る

変にプライドが高いエンジニアは知らないことを知らないと言わず、取り繕うとします。
なぜなら「知らないこと」を恥だと思っているからです。
でも、優れたエンジニアは知らなければ「知らない」と素直に言うことができます。
それは、「未知である」ということが新しい見識を得るチャンスでもあり、かつ面白いことだからです。

つまみ食いだけでなく、１つの事を掘り下げることができる

常に新しいものを追い続ける人はつまみ食いだけで興味を発散してしまうことがよくあります。
物事に関して深く理解するよりも、パッとできることで満足感を得ようとするからです。
でも、優れたエンジニアはそれが必要なことであれば、必要なだけ掘り下げていくことができます。
理解する、ということは楽しい行為であり、弄ぶのではなく、使いこなそうとするからです。

インプットをアウトプットに変え、そのサイクルを継続できる

どんな小さなアウトプットも恐れない傾向があります。
「こんなこと書いても誰も見ないだろう」と考えてブログなどで発信をしないエンジニアはもの凄くいると思いますが、
実際にアウトプットがどんな影響を及ぼすかは誰にも解りません。
よって、えり好みせずにアウトプットするという行為が自然になっていきます。
アウトプットすることで、反応を得られ議論に発展させることもできます。
即ち、インプットしてアウトプットし、それを議論に発展させ、さらにインプットする、というサイクルを自然につくっているのです。

これらは、自己組織化と言い換えることもできるかもしれません。
「偉大な習慣」を身につけ、それを実践することで、自然に良いエンジニアへと昇華されると私は信じています。
そして、そういったエンジニアが集う場所ではもっとそのサイクルが高まると感じています。

それこそが、「偉大だ」と呼ばれるに足るエンジニアへの最短の道なのかもしれません。

2012-02-29

我々は「Python」に何を求めているのか？

弊社ではプログラミング言語としてPythonを採用しています。

最近のウェブ系スタートアップが採用しているプログラミング言語やフレームワークまとめ - laiso

パッと見て頂くと解るかと思うのですが、思った以上にPythonという言語はスタートアップに採用されています。
日本にはLLというと、
CGIで一世を風靡したPerl、
そのPerlを塗り替えたPHP、
もしくはRailsと共にブームになったRubyというイメージがありますが、

Pythonは十分に実用的な言語でかつ、実践的な言語だということがおわかり頂けるかと思います。
特に我々が重視しているのはその思想です。
バッテリー内蔵言語とも呼ばれるPythonですが、
PythonにはZenの考え方が採用されています。
即ち、

import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.（汚いより、綺麗が良い！）
Explicit is better than implicit.（暗黙よりも明示が良い！）
Simple is better than complex.（シンプルな方が小難しいより良い！）
Complex is better than complicated.（でも、複雑になるよりは小難しい方が良い！）
Flat is better than nested.（ネストさせなくて良いなら、そっちが良い！）
Sparse is better than dense.（詰め込みすぎるよりは隙間がある方が良い！）
Readability counts.（読みやすさは重要だよ！）
Special cases aren't special enough to break the rules.（特別なこともあるけど、ルールを壊すってほどじゃない）
Although practicality beats purity.（実用性を求めると、型破りなこともあるさ！）
Errors should never pass silently.（エラーをひた隠しにしちゃ駄目だよ！）
Unless explicitly silenced.（わざとそうしているんじゃない限りはね！）
In the face of ambiguity, refuse the temptation to guess.（曖昧な事を適当に推測しちゃ駄目ですよ！）
There should be one-- and preferably only one --obvious way to do it.（それをするためには、優れたたった一つの方法があるに違いないからさ！）
Although that way may not be obvious at first unless you're Dutch.（あなたがオランダ人でなくて、ちょっとわかりにくかったとしても！）
Now is better than never.（やらないよりは、今やろうぜ！）
Although never is often better than *right* now.（けど、いま"すぐ"にやるなら、やらない方が良いこともある！）
If the implementation is hard to explain, it's a bad idea.（造ろうとしているものをうまく説明できないなら、そのアイディアは没！）
If the implementation is easy to explain, it may be a good idea.（うまく人に説明できるなら、それは良いアイディアだぜ！）
Namespaces are one honking great idea -- let's do more of those!（すげーアイディア名前空間、もっとそれをしようぜ！）

Perlでは"There's More Than One Way To Do It."（やり方は一つじゃない）という思想を持っていますが、
Pythonは"There should be one―and preferably only one―obvious way to do it"（誰もが正しいと考える、たった一つの方法がある筈だからさ！）という思想です。

これが言語の可読性や保守性に大きく寄与する事はおわかり頂けるでしょうか？
誰が書いても大きく違わないものに近づくということは、
チーム内の誰でも読み書きでき、
かつ1ヶ月後、1年後の自分も読み書きが容易だと言うことです。

そして、
中には"誰が書いても一緒になるなんて面白くないじゃないか！"
と考えるエンジニアも時にはいるでしょう。

でも、考えてみて下さい。
本当に自分たちが書くコードをは一緒になるでしょうか？
経験もバックグラウンドも違うのに？
そうです。
本当には一緒にはなりません。
だって、我々は同じ人間ではないから。
でも、みんなで同じ至高＝ある筈のたった一つの優れた方法に自然と向かうことが出来る！
それが、Pythonの強さです。

そういう意味でPythonは"至高を目指す言語"とも言えます。
最高のものを作り出すために自己研鑽を繰り返す言語Python、
その力は開発者にも及びます。

そのために我々はPythonなのです。

2012-02-28

第壱話　見積もり、襲来

働く環境

変化を愛せよ！
見積もり、やってますか？

アジャイル、やってますか？

さて、今回紹介したいのは「プランニングポーカー」です。
これはカードゲームのように見えますが、実際にはプロジェクトにおけるタスクの大きさを見積もるために必要なツールです。

これって、どうやって使っていくんでしょう？
簡単に言えば、一つのタスクを元にして相対値によって「みんなでそのタスクの大きさを見積もる」そういうツールです。
では、なぜこんなことをするんでしょう？

何故かといえば、人は簡単に見積もりを誤ります。
このタスクなら３日で出来るな、と思って、
「３日でできるよ」って言った経験ないでしょうか？

でも、ちょっとしたバグがとれなかったり、タスクの割り込みが入って……できんかった！
できたとしても、１週間とかかかった経験とか誰しもお持ちだと思います。
簡単に言えば「見積もりは経験を持ってしても難しい」と言えるでしょう。

それは何故か、というと「最初にリスクを洗い出せていないから」に他なりません。
このプランニングポーカーを使う事で、こうしたリスクの洗い出しがずっと容易になります。
どうしてかといえば、「他人と見積もりが大きく異なることがあるならば、それは見積もれていない何かが存在する」ためです。
この見積もりを繰り返すことで見積もりの精度を高めていく、それが「真の見積もり」です。

さて、最初に述べた「変化を愛せよ」の元ネタはXPの「変化を抱擁せよ（Embrace Change）」です。
ゲーム開発、サービス開発は本当に変化がつきものです。
試行錯誤の積み重ねによる研鑽こそが真に面白いものを作り出すためです。

そんな中で、苦労することは「決定する」ということです。
ここに関して「できる」と断言し、かつ実行することは勇気と努力を必要とすることです。
不確実なものに対し「できる」と宣言してしまうことは大きなリスクでもあり、
失敗した際に大きな無駄を生む原因でもあります。

そんなときに力になってくれるのが、仲間とアジャイル開発です。
何故なら、正しい見積もりができることによって、
大幅な軌道修正をすることなく、失敗したとしてもリスクを最小限に抑えられるからです。

よかったら俺たちとアジャイルしませんか？

2012-02-28

すべての開発者は快適な椅子を持つべきである

働く環境

プログラマの権利宣言、って知っていますか？

すべてのプログラマは快適な椅子を持つべきである
現実に目を向けよう。我々は毎日8時間大方座って過ごしている。どうしてその8時間を快適な優れたデザインの椅子で過ごさないんだ? 開発者には8時間座っていることがどうにか耐えられる椅子ではなく、楽しくなるような椅子を与えることだ。確かに開発者を雇うのは主としてその大きなおつむのためではあるが、開発者が持つそのほかの資産も粗末にしないことだ。
プログラマの権利宣言