レッツゴーデベロッパー2013とその前夜祭に行ってきた。
前夜祭
今回のテーマは変真ということで、変真した３人の話を聞いて、こんなカードを書くというもの。
カード書くのに、倒したい敵は何かを考えてみた。
自分の今の悩みとして、レガシープロジェクトを長年やって来て、もう飽きたという悩みがある。
それで何が問題かと言うと、
- 今持っている技術だけで作業出来てしまうため、技術面での成長がない
- 使っている技術が変わらないため、他の仕事が出来なくなる懸念がある
というところが問題かと思ってる。
とは言え、これは自分を主体とした問題なわけで、
仕事頂いてる顧客が倒したい敵なわけはないし、仕事をくれている会社を敵というのも何か違う。
結局、何が倒したい敵なのか分からなかったため、カードは書けなかった。
なんて事をつぶやいたら、「敵は多分自分自身」という返信を@nnasakiさんから貰った。ありがとうございます。
確かに、自分のやりたいことをやらせてくれない周りを「敵」と考えるのは変な話。自分がやりたければ自分でやればいいだけ。レガシーだから何も出来ないと諦めずに、やれることを考えてみよう。
本編
講演セッション『DevOps時代のアジャイルな組織作り』
講演者の@ryuzeeさんは以前からTwitterでフォローしていたので、話聞くのを楽しみにしてた。
期待通り、辛口なコメントを多々交えつつ、興味深い講演だった。
DevOpsとは「Dev(開発)とOps(運用)が強力しながら、ビジネスのために継続的に成果を出す、もしくは変化に対応するためにアジリティを工場させていくこと、またはそれにかかわる活動全般」のことだそう。
実際には、開発と運用は、協力より敵視してる所が多いような気がするけど、
開発と運用に限らず、自分たちが苦労したくないので、自分たち以外の所にやって欲しい、というところが大きいんじゃないかな、と個人的に思ったりしている。
このマインドを崩して、顧客の「ビジネスに対する価値」を考えて、そのために動ける組織を作らないといけない。
でも同時に、悩ましいなと思ったのが、組織の変えることの難しさ。
以前から、組織を変えることの難しさは感じていたけど、今回の講演を聞いて、一度文化が固まった組織を変える事のハードルの高さを改めて感じた。
解決方法は「無視する」「仕事を辞める」「チェンジマネジメントについて学ぶ」ですか。うーむ。。。
あと、個人的に気に留めたキーワード。
- 無駄をなくさないとどんな技術を導入しても何も変わらない
- Done is better than perfect.
- Don't Do Agile, Be Agile!
- 開発と運用が協力しても技術がないと向上はない
マインド面でも技術面でもやらなきゃならないことが多いなぁ。。
ワークショップ 『ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう』
無人有料駐車場のモデルを考えるというワークショップ。
うちのチームで最終的に考えたモデルはこんな感じ。
駐車場の料金支払いやサービスを部分をPluggableにして、駐車場の運営状況に応じて、駐車代割引などのサービスを組み込み易くするというところをコアドメインとしたモデル。
ただ、このモデルは実装が出来なかった。(実装可能なモデルにまでは落ちてなかった)
その他感想。
最初はゲート式の駐車場を考えたが、モデルと必要な機能を考えたら、必要機能が多すぎることが分かって、駐車場の方式を変更することで、必要な機能を減らすということをやった。
ソフトで実装する部分に限らず、ハードも含めて提供サービスを考えるというのは新鮮だった。
あと、「精算機のように、汎用的で、コアでないものは外部から調達してしまうという手もある」という話もあった。
モデル化って大事だなと。
チーム内でモデルに合意するのが結構しんどかった。
自分一人でモデル考えてたら、実装は出来てたような気がするけど、そこで出来るのは完全に独りよがりなモデルだし、他のメンバは何故こういうモデルになったのか分からないわけだし、これを顧客まで含めてモデルを合意するのは大変だろうなと感じた。
ただ、しんどい思いをしてモデルを合意するから、後で大きくひっくり返るようなことは少なくなるんだろうし、逆にWFだと、全部作った後にそのモデル妥当性を見ることになるから、そこで大きくひっくり返るような騒ぎになるわけで、そう考えると、どのみちプロジェクトとしては必要なコストなので、早い段階でやっておいた方が後々楽かなとも思う。
物理的に存在するもの(ロック板など)を抽出するのは簡単だけど、駐車代計算のような処理をモデルに落とすのは難しい。
ここはサービスコンセプトに合わせてモデルを考えるところなので、そのサービスコンセプトを提供できるモデルにする必要があり、しかも、実装可能なモデルにする必要がある。
(自分のチームはここをコアドメインにしたので尚更難しかったかも？)
生TDDを目の前で初めて見た。
テストコードでユーザストーリーを作るって、本では読んだことあったけど、いまいちイメージがなかったけど、目の前で見れたのでイメージが出来た。
DDDは本読むだけじゃなくて、実践が必要だなと改めて思った。
今回の駐車場モデル面白かったので、後で実装してみようかと。
ふりかえり
今日を振り返って、変真するためのメソッド名を考えるというもの。
前夜祭、本番の内容を振り返ってみて、変真メソッドはこんなのにした。
変身というと、いきなり別人になるような感じだけど、
仮面ライダーみたいに、ある日突然変身できるようになるわけはないと思ってて、
継続的に徐々に変わって行って、ふと気がついたら昔の自分とは別人になってるというのが自分の考える変真。
思えば、1年半前にTDC4周年のイベントに参加したときは、何も知らない状態だったけど、
その後、色々な勉強会やイベントに参加したり、興味持った技術に手を出したりして
気がついたら１年前とはかなり違う自分になっている気がしている。
(まだまだ未熟ではあるが)
なので、これからも継続して変化し続けていけるように、まず実践する、ということをやっていこうと思う。
