@kotyのブログ

PythonとかAWSとか勉強会のこととかを、田舎者SEがつづります。記事のライセンスは"CC BY"でお願いします。

ソフトウェア技術者サミット in 長野 2012 に行ってきた

2012/06/04に行われた、ソフトウェア技術者サミット in 長野( http://www.agileprocess.jp/news-1/nagano2012 )に行ってきました。開催を聞いたときは「何で長野でやるんでしょ?」って思ったんだけど、数年前から全国津々浦々を巡業して回っており、今回で16回目だそうです。NSEG関係者も数名ほど来てました。せっかくの長野開催なのでもう少し人が集まれば良かったんですけど、平日の日中なので仕方ないですかね。

印象に残ったことをメモ。細かな記録は、議事録の人がきっとレポートしてくれるでしょう。

湯本 剛 氏「ソフトウェアテストにまつわる3つの疑問」
  • hpのプロダクトはいかにアジャイル開発に適用するか?を考えて作られている(所感:TFSもそうだなー)
  • ソフトウェアは工業製品と違うので信頼度曲線を見るのはあまり意味がない
  • ガントチャートは「計画」じゃない。どうやって考えて計画したのかが大事
  • アジャイルテストの重要性はフィードバックを得ること。適切なタイミングでフィードバックを得られるよう計画する
  • 計画→分析→設計→実装(テストケースを書く) (所感:いきなり実装から入りがち。。)
水越 明哉 氏「アジャイルマインドの重要性」
  • アジャイル=プラクティス+マインド
  • ナースのマインド、CAのマインド(所感:異業種の人の話を聞くのは面白いと思った)
パネルディスカッション「アジャイル開発での悩み相談」
  • 情シスはアジャイルを喜ばない(ことが多い)。「ちゃんと考えている」ユーザーにリーチし信頼関係を築ければ、アジャイルでやろうという話もできる
  • 見積もりは外れる、という前提で。バッファでいかに吸収するか
  • BTSなどのツールは、コミュニケーション手段にしてはいけない。トレースするもの。会話のきっかけを作るもの。(所感:確かに、コメント機能で会話を始めてしまわないようにしないと。。。)
  • BTSはチケット登録のルールを決めた方が良い
  • アジャイルだとプロジェクトの問題が良く見えてくるようになる。問題がたくさん出てくるので短期的には大変だし不安を感じてしまう。でも長期的にみれば、問題が早く出てくるので良いのです。

どうせだからと、「イテレーションイテレーションの間で依存している部分はどうするんですか?(あまり訳されてないけど意訳)」という質問してみました。これに対する回答は、いろいろ脱線したりしたんですけど、アジャイル開発の考え方のひとつに「YAGNI(You Aren't Gonna Need It」」というものがあるため、その考え方に従って「そのイテレーションで必要なもののみ作る」んだそうです。帰り際に@(ペンネーム:とみたまさひろ)さんと立ち話ししときに「作ると分かっている部分は、そのつもりで作っておきますよ。」とのこと。まあそう固く考えるなってことですね。アジャイルの経験がないもんで、「イテレーションごとに作る」ってところがいまひとつ想像がつきません。

パネルディスカッションの中で、「機能間のやりとりはキューにして依存関係を弱くする」、とか「イテレーションごとにテストがしやすいようにアーキテクチャ設計すべきだ」、みたいな話があって非常に面白かったです。この辺はアジャイル云々を抜きにしても大事な考え方ですね。

あと、某HDDの話もあり、やっぱり他社の方と話すと勉強になるなーと思いました。HDDについては居酒屋で酒の肴にでもどうぞ。