これまでの組織の形やスタイル崩すこと、特にうまくいってる部分があるうちに変えてしまうことには恐れがあるけれど、変化のないところに成長はないはずだ。成長とは変化だ。

フラットでオープンであることは当然の価値観として、さらにフェアであることを大事な価値観として持っていたい。

フリーランス的に働きつつ、営業や経理、総務などはせずに、プログラミングと技術に集中したいような人は、うちに来れば良いと思うな。ひとりひとりがお客さんを持ちつつ、お互いの弱いところは補いつつ働くことが出来るスタイルです。

現場で起きてる不条理を見つけたときに、それを許せずに現状に対して戦うことの出来る人か、不条理すら受け入れて全てを許せる人か。問題なのは、何も感じないことだ。

最近のアジャイルは、わりと大規模への導入をどうするかだったり組織変革だったりして、なんだかお行儀の良い話が多い気がするけど、アジャイルって、もっと泥臭くて、でも実践的で、なにか混沌とした中から何か、を産み出すのに合ったやり方だった筈じゃなかったか。アジャイルはロックだったはずだ。

モチベーションに頼らずにコンスタントに成果を出せるようにするためには、毎日の習慣にしてしまうのが良さそうだ。習慣を身につけるためには、代替手段を断ち切ること、一度の量を無理の無い範囲から始めること、記録を付けておくこと、日々のルーチンに組み込むこと、辺りがポイントかな。

なにかを始めるときには情熱はいらないが、なにかを続けていくには情熱が必要で、続けていくことの方がよほど難しいが、続けないと成功することはない。

大きな会社には必要悪のような必要無駄というのがあるものだけど、そんな無駄なことをしなくて良いのが小さな会社の良いところなので、大きな会社に勝つには、無駄なことをしてる場合じゃないね。

仕事を進める上で、任されたことをしっかりやり遂げることは大事なことだけど、それよりも、どう進んでいるかなどを共有するためのコミュニケーションの方が大事。成果は一人で出せば良いのではなく、チームでゴールを目指してることを忘れてはいけないと思うよ。

うちは会議がないことが特徴のひとつだと再認識。話したいこと、話すべきことがあれば、すぐにその場で話が始まるし、終われば仕事に戻る。

プログラミングで車輪の再発明が駄目というけれど、練習のために既にあるサービスを模倣して作るというのは良い方法だと思う。バンドを始めるときはコピーバンドから始めるように、シンプルでカッコいいサービスを見つけて、データ構造などを予想しながらプログラミングしてみると良いと思う。

プロダクトオーナーに決められた仕様通りに作れるプログラマと、プロダクトオーナーから仕様を聞き出して仕様にして作れるプログラマには大きな壁がある。その壁を越えるには「聞き出して仕様にしてプログラムを作る」という一連の行為を、何度も繰り返すしかないのだろうな。

シンプルなものでも動くものを作っていくことで、確実に必要な要望から出てくるから、動くことが重要なんだと思う。

リーンスタートアップのことを安く起業できるみたいに言ってるのは違和感ある。アジャイル開発のことを安く開発できると言ってるのと同じ。どちらも違う。リーンスタートアップでは一度の失敗でやめなくてすむように、小資本で始めて小さく賭けて、失敗を経験値にして成功に近づけていこうと言ってる。

人を役割で分けてしまう弊害は、まじめな人ほど余裕が出来ると、その役割の中で自分の仕事を探してしまうことに尽きる。大きな組織になると役割で分けてしまいがちで、それを大企業病と呼んでいる。ウォーターフォールで途中の工程でさほど意味の無いドキュメントに固執するのも同じ原因だろう。