2010/09 07
X-over Development Conferenceに行ってきました。
マイクロソフト 長沢さん
ソフトウェア開発でのアジリティを高めるために。これまでの「個の力」だけではなく、チームとしての力を。そしてIDE+ツールによる自動化、省力化を、という話。長沢さんのセッションはVisual Studioの話を軸にしつつも開発の現場をもっと良くして行きましょう、という根っこの思いが常に感じられるので聞いていて楽しいです。
僕が社会人になって最初に仕事で使ったのはVisualC4.0だった。訳もわからないまま、ツールに言われるがままに組んで行くだけで、実行ファイルがポンと生成されるのがなんだかすごいなぁと思った。
Visual Studio 2010には、TFSに代表されるようにチームでの開発や情報共有などを意識したアプリケーションが組み込まれている。今は、Visual Studioの製品群の中でまだ若干浮いた存在にも見えるけれど、今後さらに密接に、開発者が意識しないレベルまで仕組みや考え方が浸透していくのだと思う。
今後、Visual Studioを使っている開発者は、構成管理、スケジュールやタスクの共有、自動テスト、継続的インテグレーション、そういうのが当たり前になっていく（意識せずとも）。Web系とかオープンソースとかだとこのあたりを自前で始める必要があってちょっと辛いのだけど、でも、とにかくやらなきゃ、いう気持ちを新たにした。
奈良先端科学技術大学院大学 森崎さん
いちいちうなずきながら聞いてたので隣の人に怪訝そうな顔で見られたw。
- レビューが儀式のように形骸化してませんか？
- コミュニケーション不足
- リソースの不足
- 事前合意、意識合わせの不備
- 「指摘が自らを助ける」。チームとしての考えを。
- 設計段階からこまめにレビューを。それだけでも効果がある。
- 目的を明確にして、レビューに必要な人を入れよう。誤字脱字の指摘などで終わらないように。
- コードレビュー、自動化できるものは自動化を。仕様書で「早く」「等」といったワードがある場合は明確にする。
その後はいくつか製品紹介系のセッションを。
聞きながら、「プレゼンテーションZen」の内容を思い出していた。
話す方の根っこの思いがいまいち伝わってこなくて、ヘッダとフッタに企業ロゴが入って、いかにもよく見るカットが差し込まれた資料でプレゼンされるのはちょっと辛かった。選ぶセッション間違えたか（汗）
2010/08 20
「Agile2010とは何だったのか」に行ってきました。
会場は楽天テクノロジーカンファレンスが行なわれた広ーい場所。席がだいぶ空いてたので、みんなも来ればいいと思った。
川口さんの話
- 参加 38カ国 1,400人。人口比で言うと日本人少なめ。もう15人くらい出てもいい。
- Agile20とShibuya.tracに両方出たので学生の参加者の方へは私のカンパも入ってるはず（笑）。報告聞きに行こうと思う。同郷なのかな？
- 「この辺りで向こうだとバンバン質問が来るんですけど」って発言しやすい雰囲気を作る川口さん
- Jeff Pattonさんのセッション
- Outcome（ユーザが受ける成果）を最大化する。Outputはむしろ最小化すべき
⇒Output = Outcome と考えてしまうことが時々あるので注意したい。
- David Hussmanさんのセッション
- なぜ（Why?）作るのか、誰に向けて（Who?）作るのか書き出して壁に張り出す。コミュニケーションのためにささっとペルソナを書く。
⇒ポンチ絵大事！テキストだけだと難しいことも絵だと伝わりやすい、というのは経験的にも納得。 絵を描き始めるとその場の雰囲気もフランクな感じになるので好き。個人的によく使う手。
- もう１つの壁にはカンバンを。
- エレベータの中で伝えられるように話をまとめるのも大事
- Linda Risingさんのセッション
- Hugh Beyerさんのセッション
- ユーザーの「いいですね」は信用しない方がいい
⇒これは任天堂の宮本さんの話を思い出した。肩越しの視線。
- GAMEがyattomさんのと酷似してたらしい
- 日本から学んだ多くのことがAgileの考えの源流に繋がっている。日本人だってできるはず！
藤原さんの話
- ロボコーチ！チームの性能を見える化。
⇒こういう図でチームの成長が見えると張り合いが違うよね
- AgileやるならCI必須。ですよねー。がんばります･･･
- 日本だとアジャイルコーチが足りないのかも？
- アジャイルでも何でも良くて「常に改善する意欲」「探究心」が大事。
⇒「ふりかえり」をちゃんとやろうと思った。
吉田さんの話
- 32ちゃいとTypo
- 海外のIT業界の話。PCが会社に一斉導入されて仕事のやり方がガラッと変わったのと同じような変化が今、再び起きている。それに対応するためにAgile。
- プロジェクト成功率の話はもういいかな･･･。
- 様々な会社での試行錯誤、そして結果の情報を共有して、成功しているチームで共通して見られるやりかた、考え方、習慣が Agile Best Practice になった。
⇒Agile Best Practice が割としっくりくるのは、そういう理由なんだろうなーと思う。机上の話になってないところ。
- Salesforceでは、この月にリリースするということは決めるが、何をリリースするかは決めない。ユーザの要求は変わっている。
- リリースプランニングの方法。プロダクトオーナー（？）が大部屋に100から200人が集まって、壁に付箋を貼りながら次に何をリリースするか調整する
- 欲しい情報聞きたい情報は英語で共有されてる。
⇒英語を学ぶ上で非常に強い動機になると思う。
吉岡さんの話
- Oracleでは、マーケットの状況によって優先順位を変えながら、数百人規模でデイリービルドを行う方式がOracle8の頃に既に実践されてた。
- Webは毎日リリースしてユーザーのフィードバックが得られるよね
- 金曜日の夕方や休暇に行く前はコミットしちゃいけない（笑）。diffで変なトコロがあると怖い人から電話がかかってくる。
- 経験談ってやっぱり聞いてて面白い。いろんなところにいろんな話が眠っているんだろうなぁ。そして、自分の中にも。そういうのを言葉にしていきたい。
Higaさんの話
- 体調は大丈夫ですか・・
- アジャイルはオブジェクト指向に次ぐ革新。これまでの知識や技術が蓄積が通用しない異なる文化に、抵抗を覚えるのも当然。
⇒「変わること」に柔軟でいたいですよね。
- Agileを広めるには。価値を認めてもらう、正しく理解してもらう。価値を認めてもらうには成功実績も必要。
これ書きながら思ったこと
- SalesforceにしてもOracleにしても、プロダクトに対するイニシアチブが自社にあるパターン。そうでない仕事、他社からの請け仕事の場合、「これだけの機能をこの期間でこの金額でよろしくね」となって（しかも機能と期間と金額が見合ってないことがよくある）、そういうプロダクトでのアジャイル導入事例の紹介があれば聞きたかったかな。Contract negotiation より Customer collaborationだよね、っていう。WFとコンペで争って勝ったぜ、とか。
- えらい人向けのセッションとかあったのかなー。日本も開発者レベルではアジャイル開発、あるいは考え方が広まりつつあるとは思うけど、契約重視、予算重視の「えらい人」をどう巻き込んでいくかも重要と思う。
- ビアバッシュ担当はShibuya.tracの皆さんでした。さすがです。お手伝いできずにすみませんー。
2010/07 08
初の（？）渋谷区開催、Tanabata.trac勉強会に行ってきました。
参加者は約60人と大盛況。ビアバッシュがよかったのでしょうかねー。
休日よりも平日の方が行きやすいとか、0.12の情報を仕入れたいとか、単にTracのユーザーが増えているとか、その辺の要因もありそうですが。
- Tracと連携できるほかのツールも試しておこう、と改めて。
- 「沸く風呂」にグッときた
- 残念ながらIISは仕事で使う機会が無いけれど、RyuzeeさんのIISとTracの話、オープンソースだろうとIISでも問題ないですよ、MS等からいろんな無償ツールも出てるし、ということで覚えておく。
- 無料クーポンって誰かもらいました？
- AnkhSVNは知らなかった。さっそく導入＆社内展開してみる。
- Pivotal Trackerすごいなぁ。要チェック。
今回、LTさせていただきました。資料貼っておきます。
スライドのために自作したアイコン素材も置いておきますね（誰となく）
アイコン詰め合わせ（Tanabata.trac）
2010/04 28
meeting/06 – Shibuya.trac Wiki – SourceForge.JP
@kanu_ さんのウォーターフォールとTracの話
@ryuzee さんのScrumとTracの話
@kompiro さんのScrumとKanbanの話
@wayaguchi さんの仕切りでw、@kkd さんと @shibukawa さんの話
今日のキーワードとしては、ryuzeeさんやkompiroさんの話の中で出てきた
TracやRedmineのようなプロジェクト管理ツール、
スクラムやかんばんといった進め方、は、あるけれども、
大前提なのは、「プロジェクトの成功」である、ということ。
ツールの使い方とか、手法とか覚えるとすぐ取り入れたくなるし、
（多少歪めてでも）その手法の通りに進めることで
プロジェクトがうまく進んでいる気になってしまう、
あるいは、
ツールでキレイなグラフを作ることで、
プロジェクトの状況を把握した気になってしまう、
そういう落とし穴は普通に、その辺に隠れてるんじゃないかと思う。
一度それで成功したりしてると、なおさら、
そのやり方に頼ってしまうというか。
このあたり、そもそも脳が「安定」「固定」の方向に
向かいたがる性質を持っているそうなので、
それとの格闘にもなるんだろう。
kanu_さんの話のときに質問した方が
とてもいい問いをしてくれたと思うんだけど、
まぁ、各所で何度も話されているコトではあるけれども、
これを使えばすべてがわかる、すべてうまくいく、というような
万能なツールがあるわけではなく、あくまで１つの道具として、
うまく使いながら、日常的には、サボらずに、プロジェクトから
目を離さないように進めて行くしか無いんだろう、と改めて思った。
あと、@shibukawaさんが話してくれたsphinxはちょっと試してみたい。
tracのwikiの文法に近いならとっつきやすそうだ。
今回は（も？w）、どちらかというと開発手法の方に
重きが置かれた感の強い勉強会でしたが、
Tracの事例紹介とか、もう少しあった方がよかったかな、と。
自分のトコの話でもちまちまとまとめてみようかねー。
あと、これをきっかけにTracを周りに広めたい、という方、
自作のパンフレットを添付しておきますのでご自由にお使いください。
何かありましたら、twitterやコメントでどうぞ。
Trac説明資料
2010/04 02
アジャイル開発支援 – 記事一覧 – 第 11 回 すくすくスクラム 勉強会開催レポート
2月に参加した「すくすくスクラム」の勉強会は、いろいろと
気付きの多い勉強会だったので楽しかったし、
角さんの話し方とか話題の持って行き方とかも参考になって
とても充実した時間だったので、
そんな場を作っていただいたスタッフの方や参加者の方、
角さんに感謝しつつ、書かせていただきました。
いろんな繋がりが広がっていけばいいな、という思いも込めて。
Recent Comments