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

BPStudy#30 のお知らせ

Tue, 09 Feb 2010 00:40:58 +0900

2月26日（金）にBPStudy#30 が開催されます。

全体は２部構成です。

■１部
MC：渋川よしき（@shibukawa ）氏
テーマ：Sphinx
Sphinxは、reStructuredTextという形式で書かれた文書を変換し、PDFなどの文書を生成するツールです。

Googleも開発でドキュメントを重視しているように、開発現場においてドキュメントは欠かせません。

Sphinxでドキュメントを作成する楽しさを伝えていただけると期待しています。

■２部
MC：松田明（@a_matsuda ）氏、岡野真也（@tokibito ）氏
テーマ：｢Ruby on Rails vs Django｣

Rails のコミッタである松田さんと、実践でばりばりDjangoで開発し、bpmobile を始めとするライブラリをオープンソースで公開している弊社の岡野が、RaisとDjangoについて話すことでそれぞれの魅力を浮き上がらせようという企画です。

参加申し込みはこちらから。
懇親会もあります。是非ご参加を！！

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

BPStudy#29開催報告

Sun, 07 Feb 2010 17:29:44 +0900

１月２９日（金）にBPStudy#29 を開催。週末にもかかわらず５２名（懇親会２８名）に参加いただきました。

発表していただいた和田卓人さん、そして参加いただいた方々、誠にありがとうございました！！！

以下は当日のまとめ。

MCはタワーズクエストの和田卓人（id:t-wada さん)にご担当いただき、｢Test Driven Development（TDD：テスト駆動開発）｣をテーマとして開催された。全体はTDD概論、ペアプロ大会、コードレビュー大会の３部構成。

■TDD概論
TDDの基本的な考え方について、和田さんにご説明いただいた。

○TDDの黄金の回転
・１つずつ少しずつ
・複数を相手にしない。ひとりずつ対処する
・動作するきれいなコードへ
・まず動くものをつくってから、きれいにしていく
Red（動かないコード）→Grren（とりあえず動作する）→Refactoring（きれいなコードに）→Red（動かないコード）

○不安な箇所をテストする
○TDDはテスト技法ではなく設計技法
○テストは目的ではなく手段
○デモ
PiroさんによるUxUの話

■ペアプロ大会
TDDへの意欲が高まったところで、ペアプロ大会。
・お題はLRU（Last Recently Used）の実装
・皆がそれぞれの言語、環境でペアを組み、ペアプロに励んだ
・１時間弱の時間だったが、わいわいガヤガヤ、皆が楽しんで実装している様子が印象的。仕事のプログラミングの雰囲気と大分違う。

■コードレビュー大会
・C（kazuho ）
・perl（tokuhirom ）
・python（akisutesama ）
・JavaScript（piro_or ）
・Ruby（t_wada ）

言語ごとの実装方法、人による実装の違いが如実に感じられて興味深かった。人が違えばコーディングも違う。

■全体の感想
・ペアプロについては、久しぶりであったが、実際にやってみるとコミニュケーションが難しい
・テストがあると実装を変えたときの安心感が違う。不安やストレスだらけの仕事において特効薬になる可能性が高い
・エンジニアにとって実際に手を動かすという体験がとても大事というのを再認識。今後の勉強会（BPStudy）では手を動かすという要素を積極的に取り入れたい

■懇親会
・出席２８名
・夜遅くまで皆でわいわいと楽しく。
・@imai78 さん、@raitu さん、@sugamasao さん、@akahigeg さんらと席が近くになり、カオスな話に。
・解散しても帰らない人多数
・文殊堂は有名人。｢ビープラウドという会社の社長です｣と紹介するより｢文殊堂がいる会社の社長です｣と紹介した方が早い。文殊堂は我が社の広告塔。
・フロントエンドエンジニア＝三国志で、最初に突っ込んでいってやられる兵士

■当日のまとめなど
文殊堂
BPStudy#29 java-ja JOJO勉強会TDD編

kazuhoのメモ置き場
BPStudyと並カンとLRU

Ian Lewis
BPStudy#29 テスト駆動開発

Go for it!
bpstudy #29 TDD

aomushi510の日記
BPStudy#29 TDD

にひりずむ::しんぷる
BPStudy #29にいってきた

いまいにっき
BPStudy#29 ｢テストドリブン開発（TDD)｣に参加してきました！

Togetter
BPStudy#29まとめ

今年の目標１０２エントリーまであと９５

python Hack-a-thon#3 に参加した

Wed, 03 Feb 2010 23:48:00 +0900

1月23日（土）にPython Hack-a-thon#3 に参加。

場所は青山のOracle本社。

前半は小さなグループに分かれてのハンズオンに参加する人たちと、それ以外の人たちに分かれた。

ハンズオン以外の人たちは自分のPCで黙々とプログラミングなどに励み、その様子は受験生時代の予備校の自習室を思い出した。

私はid:yssk22 さんのApache CauchDB ハンズオンに参加した。

当日のハンズオンの資料とid:yssk22 さんがLTで発表された内容は以下を参照。

Python-Hackathon #3 で話してきました
Web屋修行中の人の日記 || WebJourney 開発ログ

Apache CauchDBはBPStudy#28でhagino_3000 さんが、発表した時に興味を持っていたので、ハンズオンが開かれると聞き、真っ先に参加した。

ハンズオンは、CauchDBインストールに始まり、データの保存、更新、添付ファイルの保存、JavaScriptによるデータの抽出、絞り込みなどをひととおりを体験できた。

CauchDBは、データをJSON形式でそのまま保存できるので、CMSなどのドキュメント指向のデータを使用するシステムで使うことができるだろう。アメリカ新聞社のサイトでも使用されていて、実践投入も可能だろう。

ハンズオンの良さは、実際に操作し、動かして学べると言うこと以外にも、id:yssk22 さんのような優秀な方と直接話すことができることであろう。普段集中してできないことを、Hack-a-thonに参加してこなすのもよいが、ハンズオンに参加してみることを是非ともおすすめしたい。

最後に、このような貴重な場をつくっていただいた、Voluntas さんを始め、Hack-a-thonを主催していただいた方々、そして会場を貸していただいたOracleさんに深く感謝したい。

しかし１３０人以上も集客するとは、pythonおそるべしである。

Python Hack-a-thon#4 が7月に開催が予定されているが、是非参加させていただきたいとおもう。

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

appengine ja night#4に参加してきた　その２

Sat, 30 Jan 2010 13:04:24 +0900

１月２２日にappengine ja night#4 に参加（主催者のスティルハウス佐藤一憲さんのまとめはこちら）。

後半は、荒川さん（@ashigeru ）さんの｢Transaction puzzlers｣（前半の発表は、前のエントリーにて）

Google App Engineでいちばん難易度の高いところは、DataStoreの使い方とトランザクションに対する考え方である。

@ashigeruさんの発表内容は以下の通り。それぞれの概要を復習代わりにまとめておく。

■トランザクション処理の考え方
トランザクションはリソースを一時的に独占できる技術で、同時に変更して不整合が起こるなどを回避するためのもの

楽観的ロック/悲観的ロック（GAEは楽観的並行性制御）

■Entity Groupの基礎説明
・GAEのトランザクションはEntity Group単位
・同一Entity Group内のエンティティに対する操作はACID
・Entity Groupは、同じルートキーを持つエンティティ群
　→データストア上で近くに配置される
・トランザクションの範囲はエンティティ新規作成時に決まり、後から変更できない
・Entity Groupの設計が非常に重要
　間違えると並列性が極端に低下する。うまくいやればスケールアウトする

■トランザクションのパターン
○Read-modify-write
トランザクションの範囲は読込-書込-保存の間。SQLでいうSELECT FOR UPDATE

○トランザクションの合成
同じEntity Group内の複数のトランザクションを合成する
（例）非正規化した２つの情報を同時に更新など
同じトランザクションが２つあったら１度に処理する。

○ユニーク制約
キーでエンティティを取り出して存在しない場合新規に登録する(get～putまでが1トランザクション内)

○冪等な処理（idempotent）
複数回成功しても、１回分しか結果が反映されないような処理
1度成功しているか確認し、成功していない場合、処理を実行し、成功していたら何もしない(1トランザクション内）。

○Exactly Once
いつかは、確実に１回成功する処理
無限ループで実現するのはGAEの30秒ルールにかかるので、Task Queueを使用する

○BASE Transaction
複数のEntity Groupにまたがる緩いトランザクション
上記のパターンを組み合わせて、実装する。
（Read-modify-write、Exactly Once、トランザクションの合成、冪等な処理）
例：口座間の送金処理

注意点
・Eventual Consistency：いずれ整合性がとれる

@ashigeru さんが発表したような実装パターンを集めていくことによって、前半に浅海智晴さんの発表したような自動生成が可能になるのではないかとおもう。トランザクションの実装パターンを、シンプルなパターンから丁寧に説明し、聞いている人の理解を確実に深めていく発表でとてもわかりやすかった。内容だけでなく、資料のつくりかた、プレゼンテーションなど参考になることいっぱいの発表だった。

今年の目標１０２エントリーまであと９５

appengine ja night#4に参加した　その１

Sat, 30 Jan 2010 10:48:52 +0900

１月２２日にappengine ja night#4 に参加。

前半は浅海智晴さんの｢クラウド・アプリケーションDSL駆動アプローチ｣

浅海さんの理論の特徴は、今までの成果（主に方法論や設計論）と新しい技術（主に実装技術やプラットフォーム）を組み合わせ、新たな体系的かつ実践的な理論が構成されるところ。

浅海さんはRelaxerの開発以来、10年以上にわたってDSL駆動開発をテーマに取り組んでいて、今までの活動結果がかたちとなってあらわれたものがSimpleModelerである。

SimpleModelerが目指していることは、アプリケーションの開発プロセスを大きく変えるアプローチであり、それは１書いて１もしくは 1.5くらいの開発量だったものを、１を書いて１０のものをつくり出す生産性にすることであると私は考えている。SimpleModelerによって開発プロセスは以下のように変化する。

（従来のアプローチ）
仕様書（文書＋UML）作成→設計書→プログラミング
↓
（DSL駆動開発）
テキストDSL記述（モデリング）→プログラム＆仕様書自動生成→さらなるモデリング＆プログラミング

ここで誤解してはならない点は、ソースコードは全てが自動生成できるわけではないという点である。

自動生成に適さない独自の作り込みが必要な部分は、実際にプログラミングする必要がある。

とはいってもシステムの１から１０を自分でつくるよりも、１～８までを自動生成してあとの２をつくりこむというほうが生産性が高いことは明らかであろう。

またフレームワークのリファレンスに書かれているお作法的なものも、データの種類と操作方法が決まれば自動生成できるだろう。

自動生成などしないで、自分でごりごり書けばよいではないかという考え方もときどき見受けられるが、それは従来のやり方に固執した考え方だと思う。手組みでつくるよさもあるが、それにとどまっていては大きな進歩は得られないだろう。

とはいえ、新しいアプローチが広く認められるには実績が必要である。

DSL駆動によるアプローチでシステム内の全体でこれだけのソースがつくられ、そのうちの何割が自動生成されたものなどという定量的な実績も求められるのかも知れない。

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

組織のルール

Sun, 17 Jan 2010 13:25:34 +0900

ルールのある組織は良い組織、ルールが存在しない組織は良くない組織。

そのように考えている人がいるかもしれない。

しかし、本当にそうだろうか。

これについて、ルールがどのようにして生まれるかという点から考えてみたい。

まず、なんらかの組織（会社に限らずサークルやコミュニティなど）が生まれたときには、集合・解散時間のルール、役割分担など、簡単なルールのみを決めることだろう。

そして、組織の活動がはじまってしばらくすると、時間を守らない人、他の参加メンバーに不快な思いをさせるような行動をする人が出てくる。

そうなると、それに影響されて同調する人が出てきたり、きちんとした活動をしていた人までもが不満を持つようになる。

組織にそのようなことが起こると、行動を縛るためのルールを設けたり、注意しても直らない場合は罰則をつくらざるを得なくなる。

このようなルールは、組織に集まる各個人が、自覚を持って行動していれば、本来は不要なはずのルールである。

明確なルールが存在せずとも、各個人の信頼において、組織が成り立つ。

信頼を守ることができないようであれば、その人ははじき出される。

このように人間関係によってつくられるルールのほうが厳格なルールがあるよりも、むしろ厳しい関係といえるかもしれない。

また、ルールをつくる側の立場の人にも気をつけなければならないことがある。

それは、あらかじめ、さまざまな悪い行動をする人を想定し、管理、規則、手続きをつくろうとすれば、それは管理中毒であり、管理のための無駄な業務を生み、官僚的な組織への道を歩むということである。

そうなると、組織には次第に無駄な手続きが増え、自由な雰囲気が失われていくことだろう。

ルールをつくらざるを得ない状況にならぬためにも、組織をまとめる立場の人は、各個人自らが自覚を持って規律を守る｢自律の文化｣を育てていく必要があり、信頼を守れない人には厳格な態度で臨む強さをもたなければならない。

いわれないと行動しない＝｢子供｣、いわれなくても行動する＝｢大人｣

目指すべきは｢自律の文化｣を持った大人の集団である。

また、上記の縛りのためのルールとは違い、組織に必要なルールが存在する。

それは業務が効率よくまわるためのルール、すなわち仕組み化のためのルールである。

これがないと、組織はときに混乱した状態に陥り、本質ではないところで手をとられ、不効率な組織となる。

このようなルールがある会社は守りがしっかりとしていて、攻めに集中できる会社であるといえるだろう。

このようにルールにも、それぞれ意味があることを認識し、組織づくりをしていければとおもう。

今年の目標１０２エントリーまであと９７

会社移転（２０１０年１月８日）

Wed, 13 Jan 2010 08:26:27 +0900

今年の１月８日に、会社を移転しました。

昨年の９月に２年ぶりに移転したのですが、今回は４か月での移転です。

移転の理由は、会社に成長の伸びしろをつくるためです。

スペースに余裕のあるオフィスをすぐに埋め尽くす。そのような気持ちで臨みたいと思います。

恵比寿駅から徒歩５分くらいなので、お近くにお寄りの際は是非お越し下さい。

大きな地図で見る
今年の目標１０２エントリーまであと９８

今年の目標その３（会社編その２）

Thu, 07 Jan 2010 07:34:14 +0900

前回までで｢個人の信頼｣｢人間関係の信頼｣に関する目標を書きました。

今回は｢組織の信頼｣｢市場の信頼｣｢社会の信頼｣に関する目標を書きます。

まずは｢組織の信頼｣に関する目標は、働きやすい組織づくり、規則づくりを掲げたいと思います。

規則は組織を縛るためのものではありません。組織にいる人たちが働きやすくものである必要があります。

どのような組織にしていったら良いかということを、会社メンバの意見を取り入れながら、働きやすくなるための組織づくりをして行ければと思います。

次は｢市場の信頼｣です。

お客さんとの関係をより信頼できるものに育てること、組織として結果を出せること。信頼されるサービスをリリースすることを目標とします。

特に｢市場から信頼されるサービス｣とはどのようなものか、ということを常に考えていきたいと思います。

｢市場の信頼｣の次は｢社会の信頼｣です。

｢社会からの信頼｣は、BP Study を１年間継続することを目標とします。

1月29日に第29回が開催されますが、毎月１回開催を守り続けていきたいと思います。

勉強会という場をつくることで、社会に貢献して行ければと思います。

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

今年の目標その２（会社編）

Tue, 05 Jan 2010 08:11:39 +0900

前回同様｢ビープラウドを社会から信頼される存在に育てること｣という視点から目標を考えました。

｢スピード・オブ・トラスト｣に書かれている信頼の５つの波の「自分自身へ信頼」の次は｢人間関係の信頼｣です。

社内で人間関係の信頼を保つには、まずはリーダがその模範になることです。

｢スピード・オブ・トラスト｣に｢信頼されるリーダの１３の行動｣が書かれています。

・率直に話す
・他者を尊重する
・透明性を高める
・間違いを正す
・忠誠心を示す
・結果を出す
・より上を目指す
・現実を直視する
・期待を明確にする
・アカウンタビリティを果たす
・まずは耳を傾ける
・コミットメントし続ける
・他者を信頼する

今年の目標はこれに従い行動することで、社内の人間関係をよりよいものにして行くことです。

信頼の上に成り立った自由な雰囲気づくりをしていければと思います。

組織、市場、社会の信頼に関する目標は次回以降で。

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

年間目標（個人編）

Fri, 01 Jan 2010 23:57:21 +0900

明けましておめでとうございます。
今年もどうぞよろしくお願いします。

朝起きたら、実家の窓から富士山がきれいに見えて、良いスタートを切れました。

そのあと、今年の目標をノートに書き続けていたら、ノートがいっぱいになりました。

ということで、今年の目標を書きたいと思います。

私の経営者としてのミッションは｢ビープラウドを社会から信頼される存在に育てること｣なので、目標を考えるに当たり、これを基点に考えました（ミッション・ドリブン志向）。

外から信頼されるためには、まずは自分から（自分自身への信頼）ということで、自分への信頼を高めるための目標です。

・経営者として正しい習慣を持ち、一貫した行動をとる
今年も会社を成功させるために、自分ができることは何でもやりたいと思います（積為小大：大事を為さむと欲せば、小なる事を怠らず勤むべし）。

・経営者としての人格向上
ある小さな１企業の社長にとどまらず、ビープラウドが一流企業になったときに備えて人格向上を目指します（経営者の器以上に会社は大きくならない）。

・長期志向、戦略志向、投資志向の考え方を習慣化する・身につける・学ぶ
場当たり的な対処を経営者が繰り返していては、伸びる企業も伸びなくなります。個人の学習ポイントをここに置きたいと思います。

歴史から学ぶ
｢歴史は繰り返す｣というように、人は同じ失敗を歴史においてかたちを変えて繰り返してきています。昔からものは変わっても人は変わっていないと言います。歴史上の出来事を、自分への戒めとして学んでいきたいとおもいます。

・体づくり
体力勝負にも耐えうる体つくり。仕事の成果は最後の0.5%を踏ん張り、やり切れるかで成果が大きく異なります。
会社をつくって以来、体をつくるための運動をほとんどしていないので残念ながら貯金を使い果たし、負債を抱えています。ここで再度、体を鍛え直すことで、体力、気力を充実させたいと思います（長い目で見た場合、これが最重要課題と考えています）。

個人の目標だけでだいぶ書きました。会社編は、次回に書きたいと思います。

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