デブサミ関西に行ってきました
9月14日(金)、DevelopersSummit2012に行ってきました。
帰り道に、「まだまだ勉強することしかないと実感した」とつぶやきましたが、決して悲観的な意味ではなく、やっぱり未熟な部分は多いんやけど、まだまだ知らないことを知るチャンスがあることが嬉しくて、そういう場所に足を運べたことも嬉しくて、「仕事を楽しむこと」に繋げていけたらなぁという想いでした。
スタッフ、スピーカーのみなさん、貴重な時間をありがとうございました。
(また、快く業務で参加させてくれた上司にも感謝です。)
以下、参加したセッションのまとめ。
■『Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法』 及川 卓也 氏
大規模な開発で重要なことがギュッと詰まったセッションでしたが、それは何も大規模開発だけに言えることではなくて、たとえ小規模な開発であってもそれが出来たら、もっと効率良く価値を届けることに繋がるんだろうなぁと感じました。
＜講演内容メモ＞
【大規模開発で重要なこと】
□工程管理
・どのフェーズで何をするのか、何を持って完了とするのか(doneの定義)を明確にする。
・doneとしていいかをチームメンバで確認してから、次のフェーズへ進む。
□情報共有・目的共有
・チーム人数は少数がベスト(多いと必要以上にMTGが必要になる)。
・チームに分割した時、チーム間での目的を共有することが大事。
→チーム間で目的を共有しないと向かう方向がずれてしまうことは容易に起こりうる。
・プロジェクトのコンセプトは短く覚えられるように表現する。
→原稿用紙何枚も書いたところで、誰もが同じ認識を持てる訳ではない。
→誰もが簡単に共有できないと意味がない。
□ブランチ管理
・少人数なら1つでも問題なく、リリースしてから保守と開発で分けるのはよくあること。
・「check in window」チェックインしていい時間を決めて、毎日定時にbuildする。
□テストとバグ
・「bug bash」「find it」一定のテスト期間を確保する。
→一旦開発をとめて、みんなで叩きまくってバグを見つけるのも大事。
・バグによっては、直さないことも重要。
→他に大きな影響があるものは直さないなど、優先順位を付ける。
□クラウドの特徴
・クラウドにおいて大事なことは、サービスをリリースした後にダウンしないこと。
・初めからユーザの希望に合う完璧さは求めない。
→小規模なものを短期間でリリースして、ユーザの反応を見た上で完成度を上げていく。
□大規模開発と小規模開発の特徴
・少数拠点であれば、厳密なソース管理、ビルド管理が可能。
・世界中、異なる組織から開発に参加すると、ゴールも様々になってしまう。
→開発方針を徹底して共有することが必要。
・Chromeの開発では、コードレビューしていないソースコードをコミットさせない。
□自動化
・開発拠点が異なると、ブランチの管理を人がやるのは不可能。
・テストが通らなければ、コミットできない。テストがないものも、もちろんコミットできない。
→その時点でコミットするものに対してはもちろん、他者がコミットしたことで自分が作ったものが動かなくなることを避ける。
■『Continuous Value Delivery to the NEXT DECADE』 長沢 智治 氏
ウォーターフォール開発、Excelが批判されてるのをよく見聞きしますが……
でも、私はSIerにいながらも、"いかにも"ウォーターフォールな開発をしていないし、(良いか悪いかは別として)ドキュメント類もそこまで重要視されていないという、風変わり(？)なチームにいるために、批判する感覚があんまり分かっていなかったりします。
なので、「なぜ今、ウォーターフォールでは良くない」のかについて、しっくりくるお話が聞けました。
＜講演内容メモ＞
【価値を提供し続ける】
□これからは「Information Technology」ではなく「Business Technology」
・ウォーターフォールモデルは、時間をかけても安全なものを届ける開発方法。しかし、ユーザの要求は変化するものであるため、BusinessとTechnologyが同時に成長しなければならない。(今までは、ビジネスに「ITがあれば便利」程度の要求だったのに対して、今は「ITが不可欠」になっている。)
・それを防ぐために、定期的に小さな単位で価値を届けることを考える。
・ユーザの価値は固まっているため、ビジネス価値は固定された状態でスタートする。それ故に、時間を書ける程、投資対効果は低くなる。
→投資対効果を高くできる短い間隔で、その時々で必要な機能だけを提供する。
・仕掛りが長いと、各々がI'm done.で仕事を終わらせた時に、基準がバラバラになり、完成したときに思ったものと違うものができていることがありうる。
□アジャイルプラクティスの実践
・フィードバックを得る機会が少ないと、開発者は自分勝手な魔法を使いがち。
・継続的に価値を届けるためには、「リリースした後は知らない」ではダメ。
・実装、テスト、リリース、フィードバックを繰り返し、ビジネス価値を考える。
・ユーザのフィードバックを得て、顧客とのやり取りによって、次のイテレーションで実装可能な機能を明確に決める。
□開発者に求められるもの
・常に進化する意識をもつこと
・利用者の視点で見ること
・技術と相乗りする勇気
・これらは、持続可能なペースで継続することが重要。
(新しい習慣を身につけるためには、中学生は3ヶ月、大学生は半年、大人は一年かかる。)
・開発だけではなくて、価値を届けるための流れを意識する。
■『エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方』 鈴木 雄介 氏
ウォーターフォールとアジャイル、各々の特徴と、どんなプロジェクトにどんな開発方法が効果的なのかであったり、開発方法にこだわっても意味がないというお話で、「頭を使ってしっかり考えること」が大事ということを再認識させられました。
＜講演内容メモ＞
【エンタープライズ開発の現状】
□エンタープライズ開発は、より複雑で不確定なものになっている。
・ステークホルダーの多様化、不確定要素の増加などが原因。
・IT化によって、顧客が技術に詳しくない場合もあり、認識のブレから成果物にもブレが起こってしまう。
→ウォーターフォールの限界。
・イテレーションなタイムボックスによるマネジメント。
・動くソフトウェアを作った上で、フィードバックを得る。
→仕様の決まっていないことを一旦おいておけるという利点。
・全体感の事前共有ができている必要がある。
【最適なプロセス】
□どんな開発プロセスでも「作業の管理」と「コミュニケーションの管理」が必要
・「作業の管理」「コミュニケーションの管理」には、対象物によって最適なモノ、方法を選ぶべき。また、必要ないモノは必要ないと宣言すべき。
・プロセスは道具でしかないので、何を管理したいのかを考えることが大事。その上で、対象に合わせて方法を選ぶ。
■『ブラウザテストを自動化することにした ～TestNGとSeleniumでやってみる～』 阪田 浩一 氏
今の自分の仕事に活かせる、取り入れられたらいいなぁと思っているトピックだったので、デモを交えた実践方法が聞けて、とても有意義でした。「これ取り入れてみましょうよ！」というために、まずは自分でやってみることから始めます。
(実践的な内容やったから、メモ少ない…)
＜講演内容メモ＞
【ブラウザでのテスト自動化】
・「Selenium IDE」Firefoxアドオンでブラウザでの操作を記録する。
・「Selenium WebDriver」ブラウザでの操作をコーディングする。
・「Selenium Grid」複数ブラウザでのテストを複数マシンで並列実行する。
□Selenium WebDriver
・ブラウザの種類を選ぶことが可能(IEとChromeは設定が必要)。
・実際の画面遷移に沿って、画面遷移ごとの処理時間を設定可能。
・ファイルのアップロード、javascriptのアラート、ダイアログなどの制御も可能。
・エビデンスとして、スクリーンショットを撮ることも可能。
→JUnit、testNGなどでテストコードを書いて、ブラウザテストも自動化。
■『Struts の時代から、標準 Java EE で実現する効率的な Web サイト構築の時代へ』 寺田 佳央 氏
「strutsにこれ以上の発展はない」らしい。
会社に入って1年半、ずっと同じチームにいてstruts2しか使ったことのない自分にとっては、今の開発環境に慣れてしまって、それが普通という感覚ができつつあったりします。だから、「使いにくい」とか「設定が面倒」とかっていう感覚もそこまでなかったりします。(チームに入った時にはすでに保守開発やったから、開発環境は整ってたこと、フレームワークなにそれ状態からのスタートなために、むしろ便利だと思ってたこととかが基点かなぁと思いますが…)
寺田さんのお話もデモも流暢すぎて、若干ついていけてませんでした。。
でも、すごく興味深くて、自分でもやってみたくなったので、家に帰ってすぐNetBeansをインストールして、デモを再現しようとしてみました！が、同じDBを利用できなかったので、他のを選んで適宜修正しながらやってみたら動かなかった。。動画を止めながらやってみてたけど、寺田さんのブログの詳細見ながら、もう１回やってみようと思います。上手く行ったら、何か作ってみようかな。。
＜講演内容メモ＞
□JavaEE、JSF2.0(JavaServer Faces)を使ってみる
・NetBeansをダウンロードするだけで、apache、tomcatなどの設定が必要ない。
・viewはfacelets(xhtml)
・コンポーネントベース
・htmlと一対一で対応するJSFのタグが存在する。
・国際化対応もロケールごとのpropertiesファイルを作成して、ロケールを指定するだけで可能。
・画面遷移のxmlは不要。xhtmlでActionのメソッドを直接指定可能。
■『あの人の自分戦略を聞きたい！－デブサミ関西編』
□前川 直也 氏
■自分のエンドロールをどう描くか
・エンドロールに名前を残す。
→「人間としての自己の存在を自覚し、生きてきたことの証を残して生涯を終われ」
・人生の分かれ道
→変化を抱擁せよ。
・SNSは人から認めてもらうことのacknowledgment。
→試行錯誤⇒人に認められる⇒次への原動力
・自分には何ができるか、他の人と何が違うのか。
→吸い取る⇒考える⇒伝える⇒つなげる⇒描く
・自分自身を信じることも大事。
□野崎 啓史 氏
■プログラマであり続けるために
1. がんばらないこと
・がんばる＝無理すること
→無理したら続かない
・継続は絶対的な力。
2. 選択する
・選択しないことも選択。
・迷ったことはする。
→迷う＝やりたいこと
3. 年齢を気にしない
・若くても20年そこら積み重ねてきたことがある。
・自分の歳から考えて、残り時間がないと思わないため。
→新しいことを始めるのに、枷は少ない方がいい。
■ありたいプログラマ像
・ジョーカー
→エースではなく、広く浅く
・三人目
→思いつくのは一人でもできる。始めるのは二人いれば出来る。でも、続けて広めていくには三人目が必要。
■何かを始めるには障害があるもの
・すべての障害がなくなったとき、自分はどう振る舞うか。
□中村 洋 氏
■自分の源泉
・チームの成長
→自分だけでなく、周囲の成長
→成長出来る環境を整える。
・お土産
→次会ったときにお土産を渡したい。
→成長した姿を見せる。
・恐れ
→素晴らしいコードを書けるわけではないし、1人でリリースもできない。
■自分戦略
・自分でハンドルを握る。
□表明
→やりたいことは表明する。黙っててやりたいことが入ってくるわけがない。
□準備
→いざやりたいことが舞い込んできたときのために、やりたいことをやるための準備をしておく。
□雪かき
→他の人がやりたがらないことを積極的にやる。それは、信頼貯金になるし、待ってたボールが飛んでくることに繋がるかもしれない。
□巻き込む
→一人だとできなかったことでも、二人ならできるかもしれない。
・「仕事なんて楽しくないやんか」(昔の上司に言われた言葉)
→楽しく仕事をするために自分ができることにベストを尽くす。
3人の方の自分戦略は、それぞれ全然違うんやけど、自分の想いというか信念というか、そんな気持ちをもって行動してきてはることが見えて、自分が大事にしてることってなんやろう…と、考えるきっかけになりました。
特に、irofさんの「がんばらないこと」と「年齢を気にしない」という話には、自己否定しがちな自分にとって、自分を肯定するための勇気をもらえた気がします。
まとめを書いてて思ったけど、前川さんの「自分には何ができるか、他の人と何が違うか」という話も繋がってくるし、「他の人と違う、自分にしかできないこと」を考えることは、中村さんの自分戦略とも繋がってくるなぁと。。
今の自分は、すごく恵まれた環境にいることは間違いなくて、でもきっとそれを活かしきれてなくて、もったいないことをしてるような気がしないでもない。
自分に足りないことは見えてきてもいるし、少しずつでももうちょっと積極的に。。。
懇親会では、スピーカーの寺田さん、阪田さん、irofさんとお話させていただいたり、社内読書会でテレビ越しにしかお話したことのなかった先輩にも相手してもらったり、自分戦略の前川さんにもお声掛けさせてもらって少しお話できたり…と、とても楽しくて有意義な時間を過ごすことができました。ありがとうございました！
