チーム・バチスタの栄光 ★★★☆☆

3月 7th, 2010 by tune No comments »
チーム・バチスタの栄光 [DVD]
TCエンタテインメント (2008-08-08)
売り上げランキング: 10911

つまらなくはないけど普通かも。
大ヒットした原作の割にはイマイチに感じたからおそらく原作の面白さを伝えきれてないんだろうなと予想します。

ハッピーフライト ★★★★☆

3月 6th, 2010 by tune No comments »
ハッピーフライト スタンダードクラス・エディション [DVD]
東宝 (2009-05-22)
売り上げランキング: 1954

あまり話題にもならなかった気がするし、そこそこな映画かなと思っていたのですがかなり楽しめました。実際のANAの現場があんなにドタバタしているのかは分かりませんが、色々な人が協力しあって飛行機をスケジュール通りに飛ばすのは大変なんだなと裏側を見せられて感じました。

見ていると飛行機に乗って旅に行きたくなる気分になります。おすすめです。

Atlasianの98日リリースサイクルを読み解く

3月 6th, 2010 by tune 2 comments »

先月のデブサミであったAtlassianの発表は結構面白かったと思うのですが、ブログやTwitterに感想を書いている人は思ったよりも少ないみたいですね。会社説明は退屈だったかもしれないけど、社内で行っているアジャイル開発の事例は結構参考になるところがあるんじゃないかと思っています。セッションのスライドは以下から見ることが出来ます。

中でも98日間隔(14週間、約3ヶ月ですね)でリリースを繰り返すイテレーションの仕組みはもっと注目を集めても良いと思います。自分で眺めて考えてみた結果を以下にまとめてみます。

◯図のイテレーションはどうして9週目始まり?
開発の最後のイテレーション(Iteration5)と次期バージョンの仕様を決める時期が重なっているからですね。開発者は12週目から14週目の作業が少なくなっていますが、ここで自由裁量な開発期間(Googleの20%ルールみたいの)を割り当ててる人が多いと講演で言ってた気がします。

◯PMMの仕事
PMがProject ManagerならPMMは誰なんでしょう? パッと見でPMより偉い人みたいですが。PMM:Product Marketing Managerとのことです。気になったのはPMMが実施するレビューの順番です。

  • 1週目:マーケットと競合他社のレビュー
  • 2週目:Messagingレビュー(製品の打ち出し方 とかなのかな?)
  • 3週目:製品ローンチのゴールをレビュー

競合分析と最終ゴールの確認は大事ですよね。

◯PM:Product Managerの仕事
この辺は一般的? リリース基準を事前に策定するのは大事だよね。

  • 1週目:時期製品ターゲット層の検討
  • 2週目:6ヶ月先までのロードマップを更新(これより長期の計画は無いのかな? それとも別途作成?)
  • 3週目:リリース基準の策定
  • 4週目:詳細なストーリー作成(製品が使われるユースケースのことでいいのかな?)

◯デザイナの仕事
PMM/PMが製品コンセプトを固めている段階からデザイナの仕事が振ってあります。初期段階はPMと一緒に動き、開発が始まったらプログラマと協業するんですかね。

◯イテレーション
全5回、うち実質的に開発に振り分けられるのは最初の3週間。4週目は”Polishing”とある、機能追加を止めてパフォーマンスや使い勝手を作り上げていくフェーズなのかな? 5週目はリリースにあたっての準備期間の模様。
あと各イテレーションでコード書きはもちろん、バックログの整理や自動化されたテストも準備しているみたい。
社内でドッグフードを食べ始めるのはBETA1からかな?ドッグフードはイテレーションの1回目から食べ始めるそうです。デブサミの講演では「体感として1日1回は落ちる(Confluenceだったかな?)」と話されていましたが、開発直後の状態ならそれぐらい落ちても不思議ではないですね。

◯各フェーズでの確認事項
下部に書いてるのは各フェーズでの確認事項だと考えました。「顧客が求めているか、お金を払ってくれるか」「長期計画に沿っているか」「リリース出来るほど安定しているか」などなど。当たり前だけど大事なことですよね。

ということで、画像から読み取れることを自分なりに書いてみました。これぐらい短くリリース出来ると開発に緊張感が出て良いですね。どれぐらい短い間隔でリリース出来るのかという課題は突き詰めて考えてみると今のムダも見えて結構良いかもしれません。

並行コンピューティング技法 第1章

3月 3rd, 2010 by tune No comments »

「業務が組み込みメインでもそろそろ並行処理も避けて通れないよね」という雰囲気を年初から職場で醸し出し、勉強会を開くことにこぎつけました。内容は並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミングの輪講です、The Art of Concurrencyの邦訳ですね。

「職場の1人ができてもしょうがなくて、みんなの基礎がある程度揃ってないと話もかみ合わなくなるだろう」という思いが勉強会を選んだ理由の1つ。もう1つの理由は「勉強会ならサボらず最後まで読まざるをえないよね」という自分へのハッパがあります。今は他にも実用Gitを読んでいて、実は昨年の夏からレガシーコード改善ガイド (Object Oriented SELECTION)を積読にしたままです。3冊平行に読むのが良いとは思えませんが、読んだ記録をそれぞれつけて行こうと思います。

前置きが長くなりましたが、まずは第1章「速くしたい人、手を挙げて!」です。

◯並列と並行の違い
・並行:複数の動作を同時に実行状態に保てる機能を備えていること。
・並列:複数の動作を同時に実行できること。
スレッドライブラリを使ってマルチスレッドプログラミングを実装し、シングルコア(Pentiumとか)でプログラムを実行した→並行処理
スレッドを使ったプログラムをCore i7で実行した→並列処理
ということですね。並列処理は並行処理に完全に包含される関係があります。

◯効率的な並行アルゴリズム
コア数に応じて処理時間が短くなる(2コアで1/2、4コアで1/4) が理想だけど、処理の一部は逐次処理が不可避な場合がほとんどで理想的な性能を得られることは殆どない。
特定のコア数を念頭においたアルゴリズムではなく、今後新しく発売されるCPU(16コアとか、32コアとか…)に応じて望ましい性能がそのまま発揮出来るように実装するのが目標。

◯スレッド化のステップ
通常の開発が1.仕様定義、2.設計、3.実装、4.テスト、5.チューニング、6.保守の流れを取るのに対し、スレッド化のステップは以下をとる。

  1. 分析:どこが並列可能かを見極める。並列化によりオーバーヘッドが生じるので重い処理を選ぶ。
  2. 設計と実装
  3. 正当性の検証:不完全なスレッドの実装により起きる問題の対応
  4. 性能チューニング:同期・競合・メモリキャッシュなどの問題への対応

逐次処理のソースで動く実装を固めるのが第1、いきなり並行処理アルゴリズムを実装すると元々の問題か、平行化に起因する問題か切り分けが必要になる。

◯歴史的な話
古くは複数の機器を組み合わせて処理を平行化する分散メモリプログラミングが主流だった。最近はCPUのマルチコア化が進んでいるので共有メモリプログラミングに移っている(本にはこんな記述無いんだけど理解があってるかな?)。

◯これから学んでいくこと

  • 処理の分割の仕方。処理を並列化するのか、処理対象のデータを並列化するのか。
  • 処理の分担をどう決めるか。最初に決めてしまうのか、ロードバランシングを考慮して動的に決めるのか。
  • ロック、排他制御の定石 など
並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング
Clay Breshears
オライリージャパン
売り上げランキング: 11030

GitとSubversionを共存させる

2月 27th, 2010 by tune No comments »

git svn cloneして、ファイル編集して、git commitして、git svn dcommitでSubversionサーバに変更を反映させる。Subversionの変更を取ってくるのはgit svn rebaseだ… なんてのがWeb上で探してすぐ見つかる情報ですが、これでは複数人でgitを使う場合の運用ですぐに行き詰まってしまいます。

実用Gitの16章に定石が載っていると聞き、さっそく買って読んでみました。他の章を飛ばして16章だけ読んだせいもあるのか自分の中ではまだうまく消化出来ていません。とりあえず手順だけ書いておきます。

◯前提条件
git svnを行う窓口は1箇所にする。git svnのオプションを変えたり、とってくるリビジョンを変えただけでもコミットオブジェクトは変わってしまう。

◯前準備
git svnを使ってSubversionリポジトリのcloneを作る

% mkdir example-svn.git
% git svn clone –stdlayout –prefix=svn/ http://example.jp/svn-repos/

git bareリポジトリを作る

% mkdir example.git
% cd example.git
% git init –bare –shared=true

git svnリポジトリからmasterとSubversionのブランチをgitのセントラルリポジトリにpushする。

% cd ../example-svn.git
% git push –all ../example.git
% git push ../example.git ‘refs/remotes/svn/*:refs/heads/svn/*’

◯Subversionにマージを書き戻す

% git checkout svn/trunk
% git merge –no-ff new-feature
% git svn dcommit

何度も実用Gitの解説を読んでいるのですが、マージを書き戻すところだけどうにも謎です。多分きちんとリモート追跡を理解できてないのでしょう。この休みにまた時間をとって勉強することにします。

実際にやってみて出来ることは確認したのですが、

  1. Subversionへの書き戻しを手動でやらないといけない
  2. Subversionのログに残るメッセージがgit mergeで生成されたものになってしまい、何の変更をしたのかSubversionからはさっぱりわからない

という問題があることも分かりました。

そこで上記でいうexample-svn.gitのフックスクリプトを作成し、example-svn.gitのmasterに変更がpushされたらSubversionに書き戻す処理を自動化してみました。動く気はしているのですが、理解が足りてないせいで、思わぬ問題を引き起こすかもしれませんのでご注意ください。

#!/bin/sh

# checkout svn/trunk
git checkout svn/trunk

# Store git log before merge
log=$(git log last-merged..master --pretty=format:"%h %s" --reverse)

# merge master to svn/trunk, don't commit
git merge --no-ff --no-commit master

# commit with git log message
git commit -a -m "$log"

# push back to svn repository
git svn dcommit

# tag last merged
git tag -d last-merged
git tag last-merged master

◯2010年3月3日追記
テスト環境ではうまく行ったのですが、本番環境でgit->Subversionの自動同期をしてみたところ、ソースファイルが削除される問題が起きてしまいました。
git push, git mergeとかのどこかでうまくいってないのにsvn dcommitまで行われたのが直接の原因ですが、なぜこうなったのかログを見ても原因が分からなかったので自動同期は止めました。

◯2010年3月4日追記
よくよく考えたらsvnのゲートウェイとなるリポジトリのmasterとsvn/trunkは別個の歴史を辿るんですね。なので前にマージされてからの差分を求めるにはsvn/trunk..masterでは駄目ですね。上のスクリプトはなんとなく書き換えてみましたが、gitの理解が足りてないですね。

Subversion, Git, Redmine, Hudson – 今考えている連携2

2月 27th, 2010 by tune No comments »

Subversion, Git, Redmine, Hudson – 今考えている連携 » tune webでいただいたコメント、実際にやってみて出来なかったことを反映してアップデートしてみました。

前回からの差分がいくつかあります。

  • git svnの窓口となるリポジトリとgit開発時のcentralとなるリポジトリを分けた。
  • 内部設計書としてソースからDoxygenで生成したものを使っていたことを思い出したので追記
  • 外部との作業項目のやりとりにRedmineからチケット一覧をExcelをエクスポートして使っているのを追記
  • お互いにパッチを送り合うのをやめて、パッチをもらったらgit-bundle(1)で作成したファイルを送るようにした。これなら物理的に離れていても同じリポジトリを使って作業出来る。

gitとSubversionの橋渡しにかなり悩んだのですが、実用Gitによると、窓口を1つにして、いくらか気をつけなければならない点があるそうです。これはまた別のエントリで。

上記構成が出来そうな目処はついてきたんですが、余力があればgerritOverview — Sphinx v0.6.4 documentationTestLinkをうまく組み合わせたいですね。

◯2010年3月3日追記
離れた箇所にリポジトリをコピーするのにはgit bundleは便利だけど、差分を渡し続けるのは無理がある気がしてきた。
masterを両者で同期を取るとなると、git bundleで貰う側はローカルのmasterにpushしちゃうとbundleからpullするのが面倒になる。ローカルでmasterにコミットするなというのは結構な制限を課している気がする。branchを切って、branchを同期するようにすると、branchからcherry-pickするような運用になるのだろうか? じっくり同期を取れる気がするけど、そこまでして同期をとらなきゃいけないものでは無い気がする。

そこまでしてリポジトリの同期を取るよりも、素直にパッチを送り合う方がいい気がしてきた。リポジトリ構成さえあっていれば最初のbundle送付すらいらないかも。
前にコメントをくれたmootohさんも、よくよく読んでみると「bundleを最初に送付して、あとはパッチを”送り合ってる”」てなってるし。

何か思い違いをしているかもしれません。おかしな点に気づかれた方は遠慮なくツッコミください。

BPStudy #30に行ってきたよ

2月 26th, 2010 by tune No comments »

目当てはSphinx! ドキュメントを手軽に各ツールとして前から目をつけてたんだけどそれっきりだったので、思い切って勉強会に行ってきました。日本でSphinxの普及に尽力している渋川さんの話を直接聞け、ハンズオンで試行錯誤しながらSphinxを触る時間もとることが出来ました。

最初はハンズオンか〜なんて思ってましたが、やっぱり手を動かさないと分からないことって多いですね。Pythonを使えない私が感じたのはこんな感想です。

  • 会場はPythonユーザー多し、Pythonプログラマって周りのツールもPythonで固める傾向ありますよね(偏見?)
  • SphinxはreST(reStructured Text)というフォーマットで書くのですが、書き方が良く分からず。
  • スペースが要るとか、改行がいるとか、スタイル関連の注意事項が結構あって「適当にかけば適当に変換される」ものではない
  • HTML以外(具体的にはPDF)の出力口もあるけどつまづきポイントもあるよ。
  • Pythonユーザが使うには敷居が低いかも。そうでないなら習熟に時間もかかる。
  • TeXよりはマシ、RDよりは表現力がある。でも、もうちょっと何とかならないかというのが正直な感想。

翻訳とか、Web上に置くドキュメントを置くには良いかもしれません。仕事で使う〇〇書をSphinxで書くのはちょっと時期尚早かもという印象を受けました。

第2部としてRailsとDjangoのWebフレームワーク談義もあったんですが、Webプログラマーじゃない自分には門外漢な話なので割愛します。

次回はHudsonだそうです。仕事で使っているけど新たに学べることがあるかなと思って迷います。

Subversion, Git, Redmine, Hudson – 今考えている連携

2月 21st, 2010 by tune 5 comments »


これからが本番、検索エンジンから来た方は先にSubversion, Git, Redmine, Hudson – 現状の連携 » tune webを読むことをおすすめします。上記が週末考えていた「こういう連携なら今の問題点を解消できるかな」と思えるフローです。「こうしたほうがいいよ」とかコメントありましたらお待ちしています。

1番のポイントはバージョン管理システムとしてGitを中心に据えました。社内はSubversionで統一するという規則があるので残すとして、開発チーム内ではgit svnを使ってGit化し、Subversionを直接触らないようにします。協力会社はSubversion縛りが無いのでGitで統一してもらいます。これまでは差分ファイルを送り合っていましたが、Gitを使えばパッチをうまく作り、修正単位でパッチファイルをやり取りすることが出来るでしょう。これまでは複数の修正がまとめて送られてきてましたが、パッチ単位ならレビューもやりやすく、「こうした方がいい」とか「こうして欲しい」というやりとりもやりやすくなります。

リポジトリがプロジェクト専用になるので、フックスクリプトも仕掛けやすくなります。現状は「空メッセージのコミットは禁止」程度の緩めのものですが、コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書きました|SNS構築の手嶋屋を参考にすればRedmineのチケットが無いコミットは禁止できます。これで闇コミットがなくなるはず。

さらにGitを使えば「歴史を書き換えて」テストが通らないコミットをなかった事にも出来るはずです。コミット前にテストをする機能がTeamCityにはありますが、Hudsonにはありません。[#HUDSON-1682] Pre-tested commit feature – Hudson JIRAとして要望が挙げられていますが実現はまだ先になるでしょう。HudsonのGit Pluginのページにpushされた変更をテストして、成功したらmaster/stableにマージする設定手順がありましたが、リリースブランチを持ったときにも同じように出来るかは不明です。

というのをtwitterにつぶやいていたところ、@bleisさんと@masanobuimaiさんから情報をもらえました。Gitのフックスクリプトですが

  1. pre-receiveでpush前の状態をタグ付けする設定を追加
  2. post-receiveでHudsonの複数ジョブをキックして起動。
    1. テスト結果を取得して全て成功したらタグを消してgit svn dcommitを実行
    2. 1つでも失敗していたらpre-receiveでタグ付けしたバージョンに戻してpushをなかった事にする。

とすることでいけそうです。Hudsonのジョブ実行結果を知る方法は複数あると@masanobuimaiさんに教えてもらったのがPlugins – hudson – Hudson Wikiのページです。プラグイン無しでもリモートAPIを使っても出来るのかもしれません。
自前でフックスクリプトを用意する必要がありますが、出来ないことはなさそうです。
post-receiveでのテストに多少の時間がかかることを踏まえ、Redmineで参照するリポジトリはGitではなくSubversionにするのが良さそうです。

あとはRedmineのメール経由のチケット登録機能を有効にして、HudsonのナイトリーテストでこけたらカスタマイズしたメールをRedmine指定のアドレスに送ればOKですね。上の絵には「静的解析とメトリクス集計」が入ってますが、これは内製ツールです。リポジトリを集中管理してもらえるとこういうこともやってもらいやすくなりますね。

上記構成に3月中に取り組む予定です。うまく行くといいんだけど。

Subversion, Git, Redmine, Hudson – 現状の連携

2月 21st, 2010 by tune 1 comment »


会社の仕事を「Gitを中心に据えた開発ワークフロー」に変えたいなとこの週末ぼんやりと考えていたんですが、現状を整理して残しておくのも、あとで振り返った時も参考になるかもしれないと思って残しておきます。

開発しているものは画像処理ライブラリで、言語はC言語。プラットフォームはWindowsとLinux両方に対応していて、32bitと64bitどちらでも動くようにしたいのが前提。ほとんどのソースは共用出来るようにしています。開発者はWindowsを使ってVisualStudioで開発し、自動テストやリリース時はLinuxでMakefileを使ってビルドします。

バージョン管理は課で管理しているSubversionを使い、他のプロジェクトともリポジトリを共用しています。他に使っているツールはテスト自動化にHudsonとタスク管理と障害管理でRedmineがあります。Hudsonは2種類のテストを管理していて、コミットの度に動くビルドのテストとCUnitを使った単体テストと、毎晩複数枚の画像入力を処理するストレステストの実行を制御しています。Redmineはチケット駆動開発(TiDD)を意識し、コミットはチケットに関連付けるようにしています。あとは開発者の1人(自分です)がgit svnを使ってローカル開発をgitにしているぐらいです。

開発メンバは社内に2人、あとは社外の協力会社に手伝ってもらっています。両者の間にはネットワーク的に「超えられない壁」があり、リポジトリを参照させることができません。ということで双方でSubversionリポジトリを持ち、同期は定期的(1〜2週間おき)に差分ソースを送り合って手動で実行しています。

ここまでが現状の紹介、以下は上記フローによる問題点です。
問題1 双方でのソースの同期を取るのが大変
一週間から二週間に一度差分ファイルを送り合ってるけど、マージに時間がかかる上、複数の変更がごっちゃになっておくられてくるためレビューしたくても途中で断念してしまう。

問題2 単体テストが通らないコミットが履歴に残り消せない
ちょっとしたミスがあってビルドに失敗してもsvnの履歴が消せない。Windows上での単体テストはコミット前に確認するけどLinuxで毎回やるのが面倒になったり、32bitと64bitを全組み合わせでやるのは面倒だったりする。動くだろうと思ってコミットすると壊れていたりとか。
あとはgccでは警告をエラー扱いしているので、使われてない変数があるとかその程度のことでエラー扱いされてしまう。

問題3 闇コミット
RedmineでTiDDに近いことをしているが、闇コミットが結構ある。スタイル直しただけとか、変数名リファクタリングしたとか。複数プロジェクトでリポジトリを共用してるからチケットIDが無いコミットを弾くのが難しい

問題4 Redmine上でチケットとコミットの関連付けを直せない
テストで問題が見つかってもRedmineのチケットとコミットの関係を直すことが出来ない。間違ってるfixesが残ってしまい、何とも出来ない

問題5 HudsonでビルドにコケてもRedmineのチケットに自動登録されない
Hudsonでコミットごとの単体テストとは別にストレステストを含むナイトリーテストを設定しているが、テストに失敗した時にRedmineのチケットが自動登録されない

問題6 TortoiseSVNのパッチ機能が腐ってる
外注からパッチで差分を送ってもらうことも考えたが、TortoiseSVNの文字コード認識がおかしく、一度エディタで開いて文字コードを保存し直す必要があった。(ちなみにソースはUTF-8)

問題7 機能ブランチの管理が大変。
一度切るとなかなか戻ってこない。戻すにも準備がかなり必要になる。試しに作ったけどいらなかったブランチも扱いに困る。

問題だけ見ると「何でこんなフローにしたんだ」と自分でも思ってしまうけど、少しずつプラクティスを取り入れた結果うまく連携できてない現状になってしまった。近々Subversionのリポジトリを課管理から本部管理に移行するお仕事があるのでこれを機にこれまでの問題点を解消しようと思っています。

詳細は後半で → Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web

Developers Summit 2010 参加メモ

2月 20th, 2010 by tune 1 comment »

2/18の午後だけ行ってきました。きちんと聞いてきたのは2講演です。

【18-B-3】Google 的分散コンピューティング
Gregor Horpe氏によるGoogleの分散コンピューティング技術の紹介と、その背景にある思想の話。

○Google内で使われている分散コンピューティング技術
GFS, Bigtable, MapReduce, Sawzallの紹介、Googleを支える技術 ~巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)が詳しいです。
Sawzallの発音が”ざうざーる”と言っているようでした、これまで”さうざーる”だと思い込んでた。

○Googleの分散システムの背景にある思想
8つに分けて、事例を交えて紹介してくれました。

  1. Shading
  2. Less is More
  3. Expect Failure
  4. Autonomy
  5. Enpower the Runtime
  6. Favor Stateless
  7. Separate Stateless from Stateful
  8. Precision vs Speed

1. Shading
分割して統治する。役割を分ける、機能を分ける、抽象化する。
例として挙げていたのはユーザアカウント管理に中小レイヤをかぶせるやつだった・・・かな? メモがなくスライドもまだ見れないのでうろ覚えです。

2. Less is More
機能を絞って特徴を引き出す。
Bigtableはトランザクションを始めとしたRDBMSの機能が無いが、その分スケールするように作ることができた。

3. Expect Failure
「エラーが起きるかどうか」ではなく「エラーはいつ起きるか」を考える。ifではなくwhen。
GFSもMapReduceもベースにエラー処理がきちんと組み込まれている。
GFSなら自動でマスタが切り替わる仕組みとか、MapReduceなら失敗したタスクの再スケジューリングとか処理対象からの除外とか。

4. Autonomy
とにかく自動化、人では介さない。
例として挙げられていたのはGFSのMaster/Slave構成。
Masterに障害が発生するとSlave同士が投票しあって次のMasterを決めるようになっている。

5. Enpower the Runtime
言いたかった事がうまく受け取れなかった。「役割を明確に決めないで柔軟にやってね」ってことだと理解しました。

6. Favor Statelessと7. Separate from Stateless from Stateful
状態を持たない。なぜなら状態を持つと途端にスケールしなくなるから。
状態を持つにしても、スケールする部分をきちんと切り分けておくことが大事。

8. Precision vs Speed
ソフトウェアではfaster is better。正確性を期するよりも、高速で大体の精度の予測で動く。
Googleのクラウドで正確な負荷とか測れても意味がない。大体の傾向がつかめればOK。

【18-C-4】ドッグフーディングとアジャイル開発
アトラシアン社の営業さんによる会社の紹介と、社内で行っているアジャイル開発の紹介。
アトラシアンはエンタープライズWiki(Confluence)や障害管理システム(JIRA)を主力商品としており、国内外で多くのユーザを抱えている。日本国内では今回が初めての公演ということで会場は超満員でした。

アトラシアン社は2002年にオーストラリアで設立された。3つの方針を掲げ、OSSの世界をはじめ多くのユーザを抱えている。

  • いい製品を手ごろな価格で
  • 伝統的な営業マンを持たない(電話をかけまくったり、会社訪問しまくる営業マン無し)
  • エコシステムの構築に尽力(製品にプラグイン構成を持たせるなど)

アトラシアンの製品はショートリリースを基本としている。それはユーザからのフィードバックを得やすいからであって、サブスクリプションユーザに価値を提供するためでもある。またチームメンバの緊張感を適度に保ち、バグ修正に時間を割いて使うようにもなるメリットが有る。リリース期間が短いことから必然的にアジャイル開発の形態をとっており、社内で開発版を試す「ドッグフーディング」の文化も根付いている。会社設立時メンバが2人しか居らず、早急に事業を立ち上げるためアジャイル開発をとらざるを得なかったことも今の会社に影響しているかも知れないとのこと。

ドッグフード中のシステムは不安定で、Wikiなどはマイルストーンリリース時は1日1回ぐらい落ちるらしい。社員は不便を感じるが、それが客先で障害として発生するよりかはましという考え方をしている。バグ以外にフィードバックも社員から得られることもある。バグ情報やリクエストは社外に公開した障害管理システムで受け付けているとのこと。

最近ショートリリースのタイミングをさらに狭めたらしく、98日でイテレーションを回しているとのこと。98日のスケジュール詳細はDevelopers Summit 2010 Preso – Sean Osawa – アトラシアン ウィキから詳しく見ることができます。Googleの20%ルールに近い制度がアトラシアンにもあるらしく、開発者はイテレーション中の時間がある期間(Week 12 〜 Week 14あたりだったかな?)に直接の業務と関係が無いことも取り組んでいるらしい。

社内ではレビューを多用している。レビューには早期修正できるコスト削減効果や、開発者の教育効果がある。駄目なレビューでは単なるプレゼンになっていたり、熟練による支配が起きてしまう。

アトラシアン社員のレビューTIPSとして以下が挙げられてました。

  1. レビュー前にコードに関する課題、タスクに目を通す
  2. 変更構成を読む
  3. 機能が動いているかを確認する(確かに年に何回か動かない機能のコミットがある)
  4. 自分が変更するならどういう方針を取るかを考えてみる
  5. レビュー終了後に提案リストを優先順位をつけてまとめて送る

レビューのタイミングとしては頻繁に行うこと。朝でも昼でも、帰る前でも、まとめて行い、開発に割く時間をうまく確保するのもコツ。
見てもらうのは同僚が一番、同僚がだめならTech Lead(技術面の開発リーダかな?)がいいとのこと。ごもっとも。