2015/3/18(水) 要求開発アライアンス ３月定例会「アジャイル時代のモデリング」に参加してきました。
DoorKeeper
https://redajp.doorkeeper.jp/events/20994場所は新宿の日本総合システム株式会社 大会議室です。
参加者は５０人くらいでしょうか。
この日の登壇者は平鍋さんで、内容も私が興味ある「モデリング」ということで、期待大でした。
ちなみにこのイベントに対して平鍋さんがブログに書いてます。
当日から１周間以上経ってしまいましたが自分用復習メモ。
■ なぜモデルを使うのか？- 人間はイメージの方が概要を上手くつかむことができる。
■ モデリングの本質- コードと重なるモデルを全部書くのは意味がない。保守が大変になるだけ。
- そこで、モデルを２つに分ける。KeepsとTemps。
- 全体像をみんなに示して、すすめていくのが、Keeps。メンテする。軽く保ってコードと一緒にメンテしてください。
- その場限りのモデルが、Temps。終わったら捨てる。
- この２つを区別してスプリントの活動で使ってはどうか。
■Keep■アーキテクチャ- アーキテクチャは、全体の構造を示す見取り図。
- 私はココを担当してます、と指を指せることが重要。
- クラス図、パッケージ図が代表例。
- システム全体の構造的な表現。
- ポイントは、「よく知られたパターンが存在する」という点。
- アジャイルの人は「アーキテクチャは発現する」というが、それは怖いと思っているｗ
- 過去にやったことある例を必ず僕（平鍋さん）は見るようにしている。
- アーキテクチャは、システムの要求からはこない。
- 過去の人類の知見からも来るし、会社の老人の知見からも来る。
- アーキテクチャのカタログやパターンから持ってくる。
- 「これを使う」と決めたからといって、詳細化するとビッグデザインになってしまう。
- フレームワークもアーキテクチャの選択の１つ。
■ Pattern-Oriented Software Architecture- この本にいろんなパターンが出てくる。
- ノー知識で乗り込むより、知見を勉強してからのほうがずっと良い。
■ Architectureの例： Astah- このパケッジ図はずっとメンテしている。
- 各パッケージに役割を書いておくのがポイント。
- 依存関係を書くのも超大事。
■ドメインモデル- このシステムが扱うデータの構造を表す。
- 利用者がよく使う言葉群
- 最終的にはクラスの名前になったり、DBの名前になったりする。
- DDDを読んでください。
- 問題領域（ドメイン）の概念とそれらの繋がりがドメインモデル。
- 用語辞書をプロジェクト作ると思いますが、あれが一番大事。
- 用語辞書と、できれば、用語間の関係があったほうがいい。それがクラス図。
- 名前は、英語と日本語の両方つけたほうがいい。英語の方はプログラミングに落ちる。
- 人間のコミュニケーションレベル
- プログラミング・レベル
- コードを構成する要素の名前付けで出てくる。
- 普段見る名前は、概念モデルの言葉だけが出てくるようになる
- C言語でmalloc関数の呼び出しとかがロジックの途中に出てくるが、それはシステムの言葉。
- 業務のドメインの中に、急にシステムの言葉が出てくるのはおかしい。
- あと、for(i = 1, i <10; i++) とかも、10回ループを回したいだけなのに、呪文みたいな構文で意味がない。
- Rubyは、10.timesでいいじゃん、としている。その方がちゃんと意味を表している。
■ Key UseCase- 「キー」がポイント。全部書かない。
- キーユースケースについては、発動してからシステムをどう通って実現されるかのメカニズムを書く。
- ユーザから見たシステムの代表的な使い方を書く。
- アーキテクチャを貫くメカニズムを書く。
- 開発者には教育的な例示となる。ただ、全部は書かない。
■ Kepps上にTempsを重ねる- ホワイトボードにKeepsを投影して、その上にTempsを書く。
- Tempsはカジュアルモデリング。書いたら捨てる。
■ Scaling- 100人のアジャイルチーム、どうしますか。
- 本の中の引用で、ケントベックが「ソフトウェアは分割統治できない。生命も一緒。」と書いてある。
- 「分割統括するよりも、conquer＆divedeだ！」
- まず動くものを1個作りなさい。その後に分けなさい。
- たくさんチームがあって大きかったとしても、Keepsとして動くトコまで作り、そのKeepsを持ってサブチームに行って、そのチームにしばくらいなさい。
- ドキュメントでなく、動くものと動かした人とモデルを持って、Tempsの話をしなさい。
- Keepsに修正が入ったら持って帰りなさい。
- 動かないものをバラ撒くな。
■ Model to have a conversion- 本の中で、「会話するためにモデルを作りなさい」と言っている。
- モデルが偉いんじゃない。モデリングする活動が偉いんだ。
- スケールの問題を考えるとき、誰かが考えてバラ撒くのはダメ。動かしてconquerしてから。
■ Other to Keep- Keepsの対象として、意思決定の理由をリストにしておく。
- なぜそうしたのかを書いておく。
- テストの戦略も、伝えるもの。
■ 式年遷宮- 同じ神様の社を隣接した土地に作る。25年ごとに引っ越す。
- なぜこうするのか。
- ハードは劣化する。作り変える時になってしまっては、作れる人がいなくなる。
- 人間がいなくなるまえに、ペアプロならぬペア引っ越しする。
- 作った記憶を部族が持つ。人間から人間へ、経験をもって伝える。
■ ふりかえり- Keepsするモデルは文脈依存する。やってみてチームで合意する。
- ふりかえりをやって、このモデルをKeepsにするかTempsにするかを決める。
■ まとめ- 設計は大事。アジャイルでも大事。
- ただ、全部書こうとすると無理。なので最もシンプルなモデルセットを選ぶ。
- 動かしてから分ける。
- 最初の出だしは、アーキテクチャを作る目的でチームを作って、動くものを作る。
■ おまけ■ FAQで出た話題- 上手く言ったプロジェクトは、必ずぐちゃぐちゃになってる。
- Martin Fowler氏が提唱している「犠牲的アーキテクチャ」という考えがある。
- TempsとKeepsの分けるキッカケは無かった。人間の勘。
- ドキュメントはやりとりができない。なので人間の特性を上手く使うことが大事。
- 平鍋さんが紹介した、参加者である原田さんの講演スライド「モデリングもしないでアジャイルとは何事だ」
★感想：モデルをKeepsとTempsという２種類に明確に分ける、という考えがすごくしっくりしました。
名前を与えたのはで、「それはKeepsだね」とか言えるようになるのはデカイですね。
あと、平鍋さんの話はすごく引きこまれます。
あーゆうふうにしゃべれるといいなぁ
皆様、ありがとーございました。
2015/3/13(金) 「【ハンズオン】はじめてのDocker ～初心者向け～ APC勉強会 #17」に参加してきました。
connpass
http://8a1-apc.connpass.com/event/12381/場所は神田の株式会社エーピーコミュニケーションズ ECHOオフィスです。
参加者は２０人くらいでしょうか。
さすが流行りネタということで、補欠待ちの方もかなりいらっしゃったようです。
ちなみに私、この日が初Dockerです。
見せてもらおうか、Dockerのコンテナ型仮想化技術の性能とやらを！
■ Docker技術概要/導入事例APCの重役？嘉門さんによる、Dockerの技術概要/導入事例の説明から開始です。
Dockerの特徴をいくつか挙げてみる。
- Linux上で動作するコンテナ型の仮想化ソフトウェアである。
- 基本的な機能は、Linuxが元々持っている機能を利用して実現している。
- ゲストOSやハイパーバイザーは不要。
- ゲストOSが不要のため、起動は１秒くらいで軽い。メモリもディスクも、コンテナで使う分だけで良い。
- Docker Hubという公式のDockerリポジトリがあり、OSなどの共有イメージが公開されている。
んで、この日の後半はハンズオンでした。スライドはP.74から。
いちおう時間内に概ねハンズオンの内容はこなせました。
ただ、理解が曖昧な部分が多々あったので、自宅で再度、ハンズオンの内容を復習してみることにした。
■ Linux環境の構築Windows7(x64)にVMWare Playerで起動できるUbuntu 12.04(LTS)環境は前々から使ってました。
なので、この環境にDockerをインストールしようと思ったんですが、カーネルバージョンが古くて上手く行きませんでした。
なので、VMWware Playerを使ってUbuntu 14.04(LTS)をインストールしました。
ちなみにUbuntuのイメージは
ここから入手。
次に、カーネルのバージョンを3.13から3.16にアップデートしました。
カーネルのアップデートは
コチラのサイトが参考になりました。
■ DockerのインストールUbuntu14.04(LTS)へのDockerのインストール方法は、公式サイトにそのまんま書いてあります。（英語だけど）
https://docs.docker.com/installation/ubuntulinux/#ubuntu-trusty-1404-lts-64-bitここに書いてあるコマンドをそのまま実行するだけですんなりインストールできました。
私がインストールしたDockerのバージョンは以下です。
以下、スライドのレッスン順に再現してみる。
■ 【レッスン１】 dockerのイメージを入手、そして確認。 （スライド P.78）docker pull コマンドで、DockerレジストリからDockerイメージのダウンロードします。
今回は CentOS 6 のイメージを入手しました。
次に docker image コマンドでdockerのイメージを一覧表示してみます。
CentOS 6のイメージは、IMAGE IDが f6808a3e4d9e と表示されてます。
■ 【レッスン２】 コンテナの起動。 （スライド P.80）docker run コマンドで、イメージからコンテナを起動します。実行プロセスとして /bin/bash を指定してます。
ユーザが makopi から root に切り変わって、コンテナの中に入ったことが確認できます。
ps -aux コマンドで、 /bin/bash が起動しているのも確認できました。
■ 【レッスン３】 dockerプロセスの確認。 （スライド P.81）別ターミナルから docker ps コマンドを実行します。
CentOSのコンテナがひとつ立ち上がっているのが確認できました。
次に【レッスン４】で exit コマンドを実行し、コンテナからいったん出ます。
■ 【レッスン５】 落ちたコンテナを確認⇒立ち上げてみます。 （スライド P.83）docker start コマンドを実行して、さっき落としたコンテナを叩き起こす。
docker ps コマンドを実行し、ちゃんと生き返っていることが確認できました。
■ 【レッスン６】 もう一回、コンテナに入ってみます(docker-enter)。 （スライド P.84）docker-enter コマンドはデフォルトではインストールされていません・・・
そのため、nsenter というツールを自分でインストールする必要があります。
インストール方法は
コチラを参考にしました。
無事、docker-enter コマンドでコンテナに入ることができました。
次に、コンテナ内で yum コマンドを実行して、telnet をインストールしてみます。
ちゃんと telnet をインストールすることができました。
■ 【レッスン７】 コミットしてイメージを保存します。 （スライド P.85）docker commit コマンドで、コンテナからイメージを作成・保存します。
yourname/test1 というイメージができ、保存しました。
■ 【レッスン８】 イメージを捨ててみます。 （スライド P.87）docker rmi コマンドで、【レッスン７】で作成したイメージを削除してみる。
docker images コマンドで、ちゃんとイメージが消えていることが確認できました。
■ 【レッスン９】 ホストのIPアドレスとかを確認してみます。 （スライド P.88）ip a コマンドを実行する。
スライドによると docker0とveth は同じmacアドレスになるはずなのだが、なぜかなっていない・・・
・docker0のMACアドレス ⇒ 56:84:7a:fe:97:99
・veth1753bd のMACアドレス ⇒ 7a:5f:db:c2:63:48
■ 【レッスン１０】 ホスト側のネットワーク情報とかを確認してみます。 （スライド P.89）brctl コマンドはデフォルトで入っていないので、bridge-utilsというツールをインストールする必要がある。
brctl は、ブリッジに関するコマンドのようです。
brctl show コマンドで、仮想ブリッジに紐付いているのは先程のveth=docker0であることが確認できました。
次に iptables-save コマンドを実行してみますが、なぜか何も表示されない・・・
どーゆうことなの・・・
■ 【レッスン１１】 コンテナのIPアドレスとかを確認してみます。 （スライド P.90）さっき使った docker-enter コマンドで再度コンテナに入り、コンテナの中から ip a コマンドを叩きます。
確認したIPアドレスに対してpingを飛ばすことができました。
■ 【レッスン１２】 不要なコンテナを削除します。 （スライド P.91）コンテナから exit で出て、docker stop コマンドでコンテナを停止させ、docker rm コマンドで削除。
rm の引数に指定したIDを持つコンテナが消えてなくなっています。
■ 【レッスン１３＆１４】 docker inspectオプションを実行。 （スライド P.92～93）再度コンテナを起動し、 実行プロセスとして /bin/bash を指定する。
docker inspect コマンドで、作成時間、実行コマンド、IPアドレス、環境変数などなど、コンテナの詳細な情報を得ることが出来てます。
■ 【レッスン１６】 Dockerfileでイメージ化します。 （スライド P.96）まず、カレントディレクトリに Dockerfile を配置します。
httpdをインストールして、80番ポートで起動する設定のようです。
次に、docker build コマンドでDockerfileをビルドして、イメージを作成します。
docker images コマンドで、Apacheのイメージが作成されてるのが確認できます。
■ 【レッスン１７】 Dockerfileで作ったイメージを立ち上げてみます。 （スライド P.97）docker run コマンドで、先のイメージを起動してみる。
ブラウザから、Apacheが起動していることを確認できました。
以上、自宅でのハンズオン再現でした。
【レッスン９】と【レッスン１０】が上手く行かなかったの、なんでだろ・・・
できれば調査してみたいと思います。
勉強会当日のハンズオン終了後は、その場で懇親会が行われました。
お酒とサンドイッチとポテトフライが振る舞われ、なんと無料！
この時間の空きっ腹には染み入りますね～
参加者さんとAPCの社員さんと、楽しくいろいろ会話させていただきました。
★感想：初Dockerでした。
うーん、まだ正直、Dockerのスゴさがピンと来ていません・・・
というのも自宅で再現したハンズオン、VMWarePlayerでUbuntu14.04を起動してその上で実施したんですが、Dockerより、GUIのゲストOSをPCのホストOS上でバリバリ使えるVMWareやVirtualBoxの方が便利やな～、みたいな・・・
VMWareでゲストOSが使えるようになった、仮想化時代幕開け時の、あんときの衝撃があまりにも個人的にデカ過ぎたので、正直Dockerにはそこまでの衝撃を感じ入るには至っていないのです。
これはもう少しDockerの勉強をする必要がありそうです。
でも、この勉強会はDockerの仕組みを学んで実際にを触ってみるホントに良いキッカケになりました。
勉強会関係者の皆様、ありがとーございました。
2015/3/10(火) アジャイルサムライ横浜道場「イテレーション運営：実現させる」に参加してきました。
DoorKeeper
https://yokohama-dojo.doorkeeper.jp/events/20719以下の書籍をターゲットとした勉強会（？）なのです。
場所はいつもの横浜市西公会堂です。
参加者はスタッフさんいれて１０人かな。
今回は第9章「イテレーション運営：実現させる」がテーマです。
最初に道場主が9章の電子書籍版をプロジェクタに映しながら一通り説明を行いました。
その後各自、議論したい内容をホワイトボードに書き出し、投票で得票数の多いものから順に話し合いました。
ホワイトボードはこんな感じ。
以下、メモ。
■ ストーリーの書き方についていちばん得票数が多かったテーマ。ちなみに、私がホワイトボードに書いたテーマ。
この章に出てくるストーリーの例として
- 作業許可証を申請する
- 作業許可証を印刷する
- ユーザーを追加する
とかが挙がってるんですが、これって「価値」じゃなく「機能」まで落とした書き方になってる点が気になりました。
書籍の6章に「よく書けているユーザーストーリーとは」というテーマがありますが、「価値がある」とか「ビジネス観点で」とか、書き方のアドバイスが書かれています。
でも上の例は、あんまりそうなってないかなー、と思ったのです。
もう一段、上の要求があるのでは、と。
例えば「ユーザーを追加する」というのは手段の１つであって、あくまでホントの目的は「ユーザー情報を管理したい」とかじゃないの？
というわけで、参加者さんから出た意見は以下のとおり。
- TFSを使ってるが、ストーリーを書くときに「～として、～がしたい。それは～だからだ」というテンプレートが出るようにしている。
- Tracのwikiに、良いストーリーの書き方例を、具体例を使って提示している。
- なぜストーリーという書き方が良いかというと、ディスカッションするための元ネタになるから。
- 価値ベースじゃなく機能ベースでストーリーを書いてしまうと、代案が出てこない。
- 価値ベースで書いておくと、「それを実現するにはあの方法もあるよね」とか代案が出やすい。
- ストーリーは顧客に書いてもらうのも良いのでは。
■ タスク管理ってどうしてる？このテーマは、ぺらさんが出してくださいました。
ちなみに私もこのテーマ、挙げようと思ってたんですよね。
というのも、アジャイルサムライもScrumBootCamp The Bookも、ストーリーをタスクに分解するお話が出てこないんです。
スクラムではスプリントプランニングで、プロダクトバックログアイテムをタスクに分解してスプリントバックログに積みますよね。
このネタが両方の本で、あまり出てきていないのが不思議でした。
このテーマで出てきた話題は以下のとおり。
- タスク管理は、カンバンに近い形でやっている。
- 最初はタスク分割するけど、慣れてきたら、タスクに分解せずにストーリーのまま開発を進めるやり方もある。
- タスクに分解せず、ストーリーの数だけで見積もるやりかたをやっている。
- タスクに分解すると、ポイントでなく時間単位で見積もれるようになる。
- 直前のイテレーション分だけタスクに分解している。
- タスクは、付箋のアナログ形式と、JIRAの電子形式で、１つのタスクを両者で管理している。
- タスク分割に際にまずJIRAに書いて、そのあと付箋にも同じのを書くようにしている。
- 二重管理になるが、慣れるとそれほど手間ではない。
- 遠隔地の分散開発だと、タスク管理は電子ツールに頼らざるをえない。
- 付箋をタスクボードに貼りに行くという行為自体が重要。そこからディスカッションが生まれる。
- Excelでタスクを管理すると、いつでも見れない点がダメ。
■ イテレーション・ゼロでスタートする為のチェックリストは有効？イテレーション・ゼロで何を準備しておくかをチェックリストにしておくことは有効か？というテーマ。
他にも、イテレーション・ゼロ、スプリント・ゼロそれ自体の話題とかも出ました。
- チェックリストあれば有効なんじゃね？
- イテレーションが進むと毎回、イテレーション・ゼロで何を準備したっけ？と忘れてしまう。
- 次に活かすためにチェックリストとして残しておくと良いかも。
- CSM研修で講師の江端さんは、スクラムにはスプリント・ゼロというイベントは定義されていない、と言っていた。
- イテレーション・ゼロ用のチェックリストではないが、楽天の川口さんがHenrik Kniberg氏のスクラムチェックリストを日本語に訳して公開している。
- スクラムのアンチパターンとして「ScrumBut」というものがある。高江洲さんが詳しい。 by 道場主
---
以降は時間切れでほとんど議論できなかったテーマ。
■ イテレーション(ｎ)で分析、次のイテレーション(n+1)で開発？9.4節に「イテレーション(n)で分析をして、イテレーション(n+1)でストーリーとして開発する」という図があります。
この、ジャストインタイム分析がテーマです。
私もこの図、1巡目の読書会で意味がわからなかったんですよね・・・
たぶん、この概念はスクラムでいうバックログリファインメント（バックロググルーミング）に該当するんだと思います。
ちなみに、次回10章の10.1節の最後に、この話題が書いてありそう。
あと、「最初に全部分析しなくて大丈夫？最初に全部ちゃんと検討しましたか？」みたいな上司の考えに対する壁がSIerにはある、みたいな話題も出ました。
あと、分析ってどこまでやるの？というのもありますよね。
■ ユニットテストが無くても、イテレーションは回せる？アジャイルをやろうとしたら、「自動ユニットテストなんて無くてもいいじゃん」と会社の雰囲気がなっているそうな。
お金を掛けたくない文化があって、テストデータとかExcelで作ってる、という話も出ました。
■ カンバンって実際に使ってる人？
TFSは2012からカンバンが使えるそうです。
---
そんな感じで、時間切れで最後の方のテーマは議論が出来ませんでした。
■ おまけ終了後の飲み会にて。前回と同じ中華屋さん。
皿うどん、1人前なのにめっちゃデカい！
★感想：年度末なためか、参加者は少なめだったので、もうちょっと参加者が集まるといいかなぁ。
でも、ディスカッションするにはちょうどいい人数かもしれない。
あと、この章でカンバンとWIPのお話が出てきますが、WIPってカンバンのレーン毎に設定することもあるようですね。
これは書籍には書いてなかった。
スタッフさん、参加者の皆さん、ありがとーございました。
2015/2/28(土) 「Regional Scrum Gathering Tokyo 2015 : Day 1: スクラム祭り」に参加してきました。
公式サイト
http://2015.scrumgatheringtokyo.org/場所は六本木のヤフー株式会社さんです。
参加者は２００人弱くらいでしょうか。XP祭りに匹敵する規模ですね～
毎年、このイベントはたしか有料だったんですが、今年から３日間のうち最初の２日間は無料に！
これはありがたいですねー。しかも週末なので業務を気にすること無く参加できます。
2週間近く経ってしまいましたが、自分が参加したセッションのスライドが出揃ったので、自分の復習のため今更ながらメモ書き残す。
■ [1C-1] いまココにある請負アジャイル開発現場の実態
～4年で4億弱売上20案件以上の実践経験から語る～セッション内容：
コチラ 初日１発目のセッション、どれも面白そうだったんですが、拝承SIerに身近なネタということでこのセッションを選択。
■ １．タイプ別Agile PJ事例まず興味深いのが、Agile PJを３つのタイプに分けて、事例を紹介している点です。
- 強引にAgile（請負契約タイプ）
- Agileで提案（コンペタイプ）
- Agileで協業（レベニューシェアタイプ）
「強引にAgileタイプ」では、要件定義を最初と最後の２回やった、という点が興味深い。
あと要件定義書の意味合いをW/Fから変えている点。
「Agileで提案タイプ」でも、請負契約からは逃れられなかったとか・・・。
「レベニューシェアタイプ」、これは新しいですね。得られた収入をシェアしながらそれを元手に広げるタイプ。
■２．プラクティスの適用及び改善事例(1) バーンダウンチャート
バーンダウンとバーンアップを組み合わせる紹介がありました。
バーンアップは登っていくので、開発者の気持ちも上がっていくとのこと。
あと、バーンアップとバーンダウンがクロスする地点を見ることで遅れとかが見やすくなるとのことでした。
なるほど。
(2) ペアプロ
ペアプロは合わなかったとのことで、「親方制度」という形で工夫して運用しているとのこと。
「親方」。名前付けすることで馴染み深くなります。
(3) KPT
KPTにTを足して、KPTTとしているとのこと。Tは、Thanks。追加することで盛り上がったそうです。
自分たちに合う合わないを見極めてプラクティスを採用したり改善したり、プラクティスもAgileであれ！
■３．これからAgileへ挑む方へ ～Agileで悩んでいる方へ～「変えるならチームじゃなくてプラクティス変えればいい」という言葉、良いですね。
上手くいかないからといって人に原因を求めるのではなく、人はそのままに、やりかたを変えることで改善できないか模索。
■Q&AQ.
Agileを一括請負契約にすると、スコープが固定されてしまうが、どう対処するのか？
A.
一括請負契約の解釈を、お客さんと会話して合意するようにしている。
契約に「ここまで開発してリリースしてね」と書いてあっても、「こういうふうに進めたほうがもっと良いですよ」とお客さんと会話して、一括請負契約の解釈を変えるように仕向ける。
---
ちなみにこのQ、私が挙手して質問しました。契約の「解釈」を変えるとは、斬新です。
■ [1C-2] 開発モデルの作り方 ～守破離の破！～セッション内容：
コチラ AEP読書会でいつもご一緒している藤村さん。
読書会でも以前、
オフショア開発に関する発表をしていただきました。
CSM研修や勉強会で学んだことを現場にひたすらアウトプットしようとする姿勢がまず素晴らしい。
INPUTばかりしてても価値は生み出せず、OUTPUTしないと意味が無い。
あと、パリス・ヒルトンとの写真にまつわる何気ない話、あれ、結構大事だと思うんです。
うるさいくらい言い続けること。自分の考えを声に出して、相手にアピールすること。
そうすると、それに関連するチャンスが来た時に、「あ、そういえば」と声がかかる。
自分が「守・破・離」の今どこにいるのか、意識すること大事。
守が出来てないのに破をやろうとしてしまうこと、多々ありますよね・・・
守破離の前に「お試し」を入れて、「試守破離」と自分なりにカスタマイズしてみたり、RFCモデルという開発モデルを自分で作ってみたりと、新しいものを生み出すパワーと発想力が裏山氏・・・
最後のQ&Aでも藤村さん
「失敗しても個人じゃなく会社が痛いだけなんだから、失敗を恐れずチャレンジしたらいいんじゃね？」
こーゆう考えを持てるように私もなりたい。
■ [1B-3] 大きな組織にスクラムの輪を広げていくためにセッション内容：
コチラ パターンランゲージを作る取り組み、最近特によく見かけるようになりました。
テスト自動化については、テスト自動化研究会や関西の方でもパターン化に取り組んでる点は先日のブログにも書いたし。
あと、アジャイルでもFealess Changeとかもパターンですね。
「６．失敗していただく」は、これは難しい判断ラインだと思いました。
失敗を許容する、失敗に妥協する、というラインにならないよう、どこまで介入するかの見極めが難しい・・・
「１３．蟹の季節」、パターン名が斬新でワロタ。
「１．新しいこと担当」は、前のセッションで藤村さんが紹介したパリス・ヒルトンのお話と通じるものがあります。
個人的には、「３．対岸の火事のうちに」がしっくりきました。
来るべき時に備えて技術やノウハウを貯めておいて、いざ、声がかかった時にスッと対応できるように準備しておく大事さは、これまでの仕事でとても実感してきたからです。
■ [1A-4] 自己組織的なScrumチームの目指し方セッション内容：
コチラ 会社名から「ドラクエ開発してる会社や！」と思って参加したんですが、違いましたスミマセン・・・
私も会社で「自己組織的ってどういうこと？」ってよく聞かれるんですが、土肥さんは「ワクワクする組織」という定義をされてます。
ちなみに去年１１月に受けたCSM研修では、自律的、という意味を考えるワークショップとして、床に線路のテープを引いてその上をペアで歩くやつやりました。
私はあのCSM研修のワークショップから得られたイメージが強いですね。
あと、自己組織化プロセスを個人とチームでそれぞれ５段階で分類している点が面白いと思いました。
自分やチームの取り組みが、自己組織成長プロセスのグラフの、どこに位置しているのかを考えるのは役立ちそうです。
ちなみに、土肥さんがいろんな取り組みをチームメンバにさせてた中で、「異質で大変な経験をさせて失敗させてみる」というのが心に残りましたね。
土肥さんは、メンバを海外に行かせて英語がしゃべれない体験をさせて「英語ができないと始まらないんだ」という実感をさせた例を挙げていましたが、これ、すごい重要だと思うのです。
人間、モチベーションが上がるタイミングって、興味があるか、追い込まれるかのどちらかなんじゃないだろうか。
そして、前者だけでなく後者を上手く利用することで、もっと進化を多様化させていけるんじゃないかな、と思った次第。
上手く取り入れていきたいなと思いました。
■ [1A-5] XP Never Dies ～あなたがXPを学ぶべき108つの理由～セッション内容：
コチラ西村さんの話を聞いて、そういやXP本、読んだことないな～、と激しく実感した・・・
ちなみにピアソンなので絶版になってしまいましたが、西村さん曰く、今年９月くらいに新訳が出るそうな！
翻訳はリーダブルコードなどで信頼と実績の、角さん。
これは買うしかない。
ちなみにXP本のポイントは、「最初に読むべき本だけど詳しい」だそうな。
オフショアやスケールの話まで書いてあったり、ちゃんとプラクティスを基礎と応用に分けていたり。
XP本と対比されてたのが、この日配布されてたスクラムガイド。ルールブック的。
西村さん曰く、「あんな薄いので、ホントに実践できますか！？」
あと、XPはGeek！のくだりで、「プロペラ帽」の話を紹介していました。
XPではプロペラ帽をかぶる文化があったそうで、「XP プロペラ帽」でググってください、だそうな。
んでググってみると、どうやら
"「プロペラ帽」はハッカーの印、トリッキーなコードを書いた人はこれをかぶらないといけない。"というネタがいくつかヒットしました。
いかにも技術寄りなXPらしい逸話ですね。
他に紹介されてた１０８の理由の一部。
■プレッシャーが少ない- スクラムだと「スプリントが終わった後に、毎回リリースしなきゃ・・・」ってなる。
- スプリント ・・・ 走り抜けろ、的な。しんどい。
- イテレーション ・・・・ カッコイイ。単に「繰り返すんだよ」としか言ってない。
■１人でもできる- 西村さんも一人で始めた。
- ペアプロとかも、一人でやってた。ドライバーとナビゲーターを時間で区切って、１５分で交代してた。
- 一人でタスクボード作ってみたり。
- やってみてわかることが非常に多い。やればやるほど上達する。一人でやっててスキル上がったなぁ、と思う。
■価値が明記されている- このチームをアジャイルにしていきたいと思った時、上手くいっているかどうかを考えるのは難しい。
- 大事なのは、価値が浸透してきているかどうか。
- XPは、価値がちゃんと明記されている。
- でも抽象的なので行動に移せない。なのでXPは・・・（下に続く）
■原則がある- 原則に従ってると行動しやすくなる。「例：小さなステップで」
- 原則を自分の行動規範にできる。
■経験者を呼びやすい- XPが日本に入ってきて１０年。大御所はXPから入ってることが多い。
- XPの一部をやったことある人は、結構多い。XPの経験者は探しやすい。
- XPを初めてやる時に経験者を呼べるのはアドバンテージ。
■コーチいらず
- コーチ重要。呼んだほうがいい。でも、いなくても大丈夫。
- ほとんどのチームって、コーチを呼べない。でも、「いなくても大丈夫」と本に書いてあると安心。
■始め方に触れている- 最初は何をやらないといけないのか？まずXPのプラクティスをマッピングしましょう。とかちゃんと書いてある。
■役割と振舞いが詳しい- チームメンバはどういう振る舞い、権限を持ったらいいのか。
- XPは役割が明言されている。例えば「重役」というロールとその役割までが明記されている。
■大事なのは改善だけではない- 悪いことを見つけて良くするだけがジャイル開発じゃない。
- 調和とかバランスとか活気のある仕事、とかも大事。
- それを追求するのもいいんじゃないか。
■XPを使用しない理由が明確- XPの価値と組織の価値が合わない時は、XPをやるな。
- 人間性を無視する会社はXPをやるな。
- XPをやるかどうか、判断するときのきっかけになる。
■バージョンアップ- XPはプラクティスの数とか増えていっている。
- スクラムガイドだと、改訂で抽象度が上がるだけ。「考えろ」と言われているだけ。
- XPだと、バージョンアップに具体性があるので心強い。
- XPは、自分たちの身近な取り組みがXPのプラクティスとして取り込まれるかもしれない、という夢がある。
■ユーモアがある- 前述した「プロペラ帽」の話は、一番酷いコードを書いた人がその帽子を１日中かぶる、というルール。
- ユーモア大事。「効果がなくても面白いプラクティス」とかも人を惹きつける。
■目的が壮大、名言連発- XPは壮大な社会実験だ、と言ってたり。
- プログラマの生活を俺が変える！
- ５０年後はITからバイオ分野に変わると言われているが、俺がそんなことさせない！とか言っている。
- Social Change with you
- みんなもっとすごいことできるだろ、とか
西村さんが最後に言ってたのは、
XPは超楽しそう！という点から始まったということでした。
チーム角谷の事例とか。
私が最近よく聞くフレーズに
「Be Agile, Not Do Agile.」があります。
個人的にはこれに賛成なのですが、私は「Do Agile」から始めても良いと思ってます。
だって、私だって「アジャイルって楽しそう！アジャイル開発やってみたい！」から始めた１人だし。
誰だって、「楽しそう！」「俺もやってみたい」って思いがまずあって、そっから始めるもんではないでしょか。
ってなことを考えさせられたりと、大変参考になるセッションでした。
■ Closing最後に参加者全員が一部屋に集まって、Closingです。
７～８人で１チームになって、「来年のScrumGatheringのポスターを考える」というテーマでチーム対抗戦です。
各チーム、制限時間内で模造紙と付箋とペンを使い、ポスターを仕上げていきました。こんな感じ。
そしてウチのチームはと言うと・・・
５枚も作ってしまった・・・。でも、けっこーいい感じ出してるんじゃないでしょか。
最後に、各チーム１名がみんなの前でプレゼンしてアピールし、投票で優勝チームを決めました。
そして・・・
・・・最多得票で、なんと優勝は我がチーム！
@iwaoRd さんと @araratakeshi さんが上手くチームを引っ張ってくれました。感謝。
最後に参加者全員で集合写真を撮ってScrumGathering １日目は終焉となりました
★感想：今回、１日目が無料イベントとなったことで初参加しましたが、とても内容が濃くて有意義でした。
これで無料なんて、有料の３日目なんて、どんなんやねん。
来年も無料だといいなぁ～
あと、やっぱ英語頑張らないと・・・
せっかく大御所のコープとかセッション持ってたのに、俺の英語力が貧弱すぎて、二の足を踏んでしまった・・・
関係者の皆様、ありがとーございました。
2015/2/19(木)～2/20(金) 「Developers Summit 2015」に参加してきました。
公式サイト
http://event.shoeisha.jp/devsumi/20150219先日、デブサミの参加メモ3発目をブログに書きました。
- 「Developers Summit 2015」に参加してきました - 其の壱 - 「ドメイン駆動設計再入門」
- 「Developers Summit 2015」に参加してきました - 其の弐 - 「モバイルアプリ開発系」
- 「Developers Summit 2015」に参加してきました - 其の三 -
3発で終わりかな、と思ってたんですが、聴講したセッションのスライドが新たに公開されたり、書き忘れてたセッションとか出てきたので、追加で３セッションのメモ残しておくことにした。
（自分の復習のため書いてるだけなので、他の人が読むには適さない！）
■ 【19-B-6】スクラムならうまくいく？～グリーのネイティブゲーム作りの歴史をひもとく、そして未来へ～ 登壇者さん、プロジェクト外から組織横断で改善のファシリテートをしていく部署にいるということで、私が配属されている部署の位置づけにとてもよく似てます。
参考になるトコは参考にさせていただきたい、という気持ちで聴講してました。
「価値 vs 機能」のスライドで、作りたいのは「価値」だが作りやすいのは「機能」、という話題が出ましたが、このネタ、ちょうど今、ウチの部署でもよく議論しているんですよね。
人は作りやすい方に流れるので、どうしても「価値」でなく「機能」を作る方に流れてしまう・・・。
あるある～
あと、「コアとサイクル」の仮説が興味深いですね。
少人数のスクラムが適するのは「コア」や「サイクル」までで、「量産」以降ではチーム作りが異なるとのこと。
スーパーマリオの1-1面だけ作ってゲームの核を確立させるのと、そこから先の違い。
ゴールを目指して改善し続けること大事。
■ 【20-C-L】要注意！？効果の出ない技術研修に共通する３つのこと 軽食付のランチセッション。去年もそうでしたが、今年もサンドイッチ美味しかったです～
テーマは技術研修。
ちなみに私も会社で技術研修の講師やってます。
拝承向けの設計教育を２科目担当してるし、部署に配属された新人にも２～３日かけて講義・演習します。
■効果の出ない技術研修- 其の１： 研修期間が固定 ⇒ 弊社、該当
- 其の２： 優れた教師がいない ⇒ わかりやすい教育になるよう、日々必死に頭捻ってます・・・
- 其の３： 個別フォローがない ⇒ 少人数の場合は、できるだけ個別に見るように心がけてます・・・
特に２で提示されてた「優れた教師の条件」、納得感がありますね。
情熱、教育の力量、人間力。
どれも磨こうと心がけてる項目なんですが、３番目の「人間力」、どーしたらいいですか・・・？
講師をやっていてよく思うのは、上司もちゃんと教育の向き不向きを考えて講師役をアサインすべき、という点です。
若手を順に講師役に割り当てていく風潮がどうしてもあるんですよね・・・
いろいろ参考になるセッションで、反省点や改善点について考える良い機会になりました。
■ 【20-D-4】モバイルを業務システムに使ったときのワクワク。今、開発者が知っておくべきこと 「スキルの成熟度モデル」がスライドに出てきますが、このモデル化は参考になりますね。
"知らないことは思いつけない。" という言葉、確かにそうです。
この言葉を聞いて、英語勉強法でやっとむさんがおっしゃってた、「知らない単語は聞き取れない」というフレーズを思い出しました。
「何がわからないのかわからない」という状態と、「何がわからないのか自分でわかってる」というのは大違いだと思います。
登壇者の方曰く、「こんなサービスがあるんだ、こんな接客があるんだ」というのを観察し、そこにノウハウをどう突っ込んでいけばいのかを考えることが重要とのことでした。
あと、ITの本質は
「中抜き」の実現である（例：セルフサービス、ダイレクトサービス）というのは確かに。
あと、UIの重要性を説いてましたが、これも確かにそうですね。
- ノートPCを挟んで相手と向き合うのはNG！
- ディスプレイが壁になって、相手がPCに向かって何やってるのかがわからない。
- ⇒ オペレーションをオープンにすべき。
- PCに向かうとそっちに意識がいって、接客にならない。もっと話を聞け。
- ペアプロのように二人が同じディスプレイを覗きこむようにして、「問題ｖｓ私達」にすること。
- それには、お客さんが覗きこんで安心できるUIにすることが重要。お客さんは壁のない話を望んでいるんだ。
あのExcelでさえ、予想外にスマホ版はユーザに「キーを打たせず、選択で済むように努力している」そうです。
- キーボードを打たせるのではなく、「選択肢を設計する」というのが重要。
- このタイミングでユーザはこんな操作するよね？だからこういう選択肢を用意しておくと便利だよね。という感じで、きちんと考えて設計すること。
- そのためには、業務プロセスとデータ項目を整理できていることが重要。思いのほか、ここが出来てない。
■まとめ- 何はともあれ実装スキル重要。ちっさくてもいいから実装せよ。
- 実装の際、UIには気を使え。
- そもそも業務設計できないと、UIの設計さえできないことを認識せよ。
- 知らないと思いつけないので、サービスのボキャブラリを学んでください。
- サービスに対する感度をあげてください。
この時間帯枠、どのセッション聞きに行こうか迷ってましたが、このセッションで正解でした。
★感想：今回もダラダラと書いてしまった・・・
ただ、自分にとってはスライドとTogetterと自分のメモ読みなおして、良い復習の機会になりました。
振り返ってみると、聴講したセッションはどれも勉強になるものばかりで、ハズレと感じたものが１つもありませんでした。
それほどデブサミのセッションの品質は高いですね。
「あ、この時間帯、自分に興味ありそうなセッション無いな～」と思っても、どれか聞きに行ったほうが得られるものはとても大きいと実感しました。
来年もぜひ、参加したいと思います。
関係者のみなさま、ありがとーございました。
2015/2/19(木)～2/20(金) 「Developers Summit 2015」に参加してきました。
公式サイト
http://event.shoeisha.jp/devsumi/20150219先日、デブサミの参加メモをブログに２発書きました。
- 「Developers Summit 2015」に参加してきました - 其の壱 - 「ドメイン駆動設計再入門」
- 「Developers Summit 2015」に参加してきました - 其の弐 - 「モバイルアプリ開発系」
今回はその３発目、まこぴが聴講してきた残りのセッションについてのメモ。
（自分の復習のため書いてるだけなので、他の人が読むには適さない！）
■ 【19-B-5】システムテスト自動化のアンチパターン Test Automation Patterns Wikiに纏められているテスト自動化パターンの紹介です。
英語のサイトを翻訳して紹介してくださるのは助かります。
私、このセッション聞くまでこのサイトの存在さえ知らなかったし。
ちなみに、パターンランゲージで表現する取り組み、関西の方でもやってますね。
１２月の「システムテスト自動化カンファレンス2014」でも紹介されてました。
パターンとして整理・分類し、言語化するのはとても有用な取り組みだと思います。
名前付けすることで認識することができ、共有することができますし。
このセッションでいくつかのパターンが紹介されましたが、聴いて「あ、あるある～！」と思うことしきりでした。
セッションではスライドを全部紹介していたわけではないので、このブログ書いて復習する際に、全部目を通しました。
こーゆうのを自分のペースで読みなおして復習するためにブログ書いているのです。
今後、自動化を検討する前、あるいは上司を説得する前に、目を通し直すと良さそうです。
■ 【20-A-5】「じつは私、情シスでした。」セッション紹介：
http://event.shoeisha.jp/devsumi/20150219/session/678/Togetter：
http://togetter.com/li/784369 楽天の佐藤さんと川口さんのお話。
タイトルからは読み取れませんが、アジャイル開発のお話です。
佐藤さんのスライドは公開されてないようですが、「継続的チーム」の重要性をアピールされてました。
「ずっと居て、話を聞いてくれるチーム」のようなものだそうです。
あと、「分からないことは、訊いて、自分たちで確認する」ことが大事とのこと。
これは納得ですね。
訊いた内容を鵜呑みにするのではなく、自分で確認する。
人間は楽な方に流れやすいので、「自分で確認する」という最後の部分が抜けやすいように思います。
「大事なことは、話を訊いて、変化を汲み取ること」 by 佐藤さん
---
川口さんのスライドは手書き感が満載でエモいですなｗ
お客さんは、動くソフトウェアが出てきてから本気（マジ）になるので、ユーザをずっと本気（マジ）にさせるために、作ってリリースを繰り返すことが大事とのこと。
これはそのまんま、アジャイル開発の思想に当てはまりますね。
お客さんが本気（マジ）になるとクレームとかも出てきますが、クレームに対する対策が遅いと、お客さんは本気（マジ）モードから諦めモードに入ってしまう。
なので、お客さんが諦めの川を渡ってしまう前に意見をもらうことの重要性を説いてました。
他にも、チーム文化の引き継ぎなどにも言及がありました。
とにかく人にフォーカスしたセッションでしたね。
■ 【20-B-6】情報革命時代における新しい多様性の共存と、これからのエンジニアのキャリア、評価制度について 2日間のデブサミで私が聴講したセッションの中で、個人的に一番感銘を受けたセッション。
エンジニアの性格について深く切り込んだ分析がなされており、しかもその分析結果に納得感があり、実に興味深い・・・
- 人間は遺伝子レベルで５０％程度、「内向型」と「外向型」の二種類に分かれている。
- 外向的人材の偏重主義になってきており、都会に集まってきているので短期的に雄弁でリーダシップをとって振る舞うというスタイルの人が信頼を勝ち取る傾向になっている。
- 近年、インターネットが生まれて何かが変わりつつある。内向的な人がすごく活躍している。
- 文書化されたもの、非同期、確認作業を伴った文章を作るのは内向型の人のほうが圧倒的に強い。
- ★「理系の逆襲」
- 内向的と外交的の人材の相互理解が前提として重要。
- 内向型、外向型、それぞれに気持ち良い制度設計がされているべき。
これらの分析を踏まえ、キャリアと評価制度はどうあるべきかについて鋭い考察があります。
ビズリーチのエンジニア評価制度も、それを前提に組まれているとか。凄いぜ・・・
デブサミのアンケートで、ベストスピーカーにこのセッションの竹内真さんを選びました。
■ 【20-A-7】Agile TED「アジャイル」をテーマに、各スピーカーさんの経験を語るセッション。
(1) 及部 敬雄さん 及部さんの話は何度か聴講したことあります。
まだ若いながら、自分の考えをきちんと持って主張する姿は清々しいですな。
現場主義で、改善のために徹底的に行動するパワーが溢れて、内容も参考になります。
「参加した勉強会の回数」よりも「現場でのTRY数」という言葉は突き刺さりますね・・・
(2) 知花 里香さん とても謙虚なイメージがする講演者さん。スクラムマスター向きかもしれません。
- 役割分担するのは作業上だけ。意識は役割分担してはいけない！
- スクラムマスターは、Scrum屋さん（Scrum Slaves）になってはいけない。
- スクラムマスタは、チームや現場のことを知ってないと信頼されない。
(3) 鹿島 恵実さん このセッションの中で一番印象に残った・・・
名前付け、イラスト、そしてパイルドライバーｗ
こんなイラストが書けると、エンジニアとしての幅が広がりそうだなぁ。裏山氏。
あと、名前の付け方が斬新すぎて、インパクトありすぎやろ。
名前付け、是非、試してみたいと思うのでした。
(4) 西村 直人さんコミットベルという仕組みもさながら、自分の好きな音を鳴らすよう工夫した点が参考になりますね。
「特に困ってなくても、楽しくしようとした」、西村さんのこの一言に尽きます。
アジャイルで成果を出すために追求し続ける姿勢、私も意識していきたいと思います。
あと、山口鉄平さんのお話もありました。
スライドはまだ公開されてないみたいですね。
元、私と同じ会社で、社内のアジャイル勉強会でも講師をしてもらったり。懐かしい・・・
今はYahooでアジャイル関係のお仕事のみならず、様々なコミュニティでご活躍されている様子。
この積極性とパワーは、元・同じ会社の人間として見習いたい・・・
★感想：他にも聴講したセッションはあるのですが、スライドが公開されてなかったりするのもあるので、公開され次第ブログに追記していきたいと思います。
ブログ書くためにスライドやTogetterやメモを読み返して、とても良い復習になりました。
デブサミ、ホント素晴らしいイベントです。
実務にも役立つし、何よりも楽しくて元気が貰える。
来年も業務をなんとか調整して、是非参加したい。
あと、うちの部からも後輩が2名参加していたようで、そーゆうのも嬉しいですね。
関係者の皆様、ありがとーございました。
-->
