「Developers Summit 2014」に参加してきました #devsumi

今年もDevelopers Summitに参加してきました。
http://event.shoeisha.jp/devsumi/20140213/

仕事の都合で2/14（金）だけの参加でしたが、今回も良いセッションを聴け大満足です。
以下、参加したセッションのメモ。

やる気を引き出す組織風土のつくり方

http://event.shoeisha.jp/devsumi/20140213/session/409/

サイバーエージェント社長の藤田さんのセッションです。
大雪の影響で最初から聴けませんでしたが組織のトップしてどのようなことを大事にしてアクションを起こしているのかが伝わってきました。

あした会議・合宿（中長期的な課題や新規事業を考える場）、社内キャリアエージェント（適材適所のための継続的なサポート）、オープンなSNSの活用、楽しい社内ポスター、などなど社内の雰囲気を盛り上げる施策が聴けてとても参考になりました。

印象に残ったのは、
個人の成長が会社に貢献できていることを大前提（楽しいだけじゃダメなのは当たり前、ってことだと思います）として、
コミュニケーションによる社員の納得感、居心地の良さを大事にしていること。
トップがこういうところにコストを掛ける気概があるのはうらやましい限りです。

管理職やリーダーは自分ではメンバーとコミュニケーションとっているつもりでもとれていないことが多いです。
想いが伝わっていないと期待通りの結果にはならないですよね。（それなのに「下はまだまだわかってない」とか「成長してない」とか考えてしまう）

「想いの共有」という大事なことを再認識させてくれたセッションでした。

伝統的な品質管理モデルをアジャイルに適合させる処方箋

http://event.shoeisha.jp/devsumi/20140213/session/434/

日本ヒューレット・パッカード 藤井さん

エンタープライズでのアジャイル開発をテーマに、HPQM（HP Quality Model）とDAD（Disciplined Agile Delivery）を融合させていこう、というお話でした。
藤井さんはDAD本の監訳者です。

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

※DADの勉強会に参加した僕のブログ
「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove

「日本のエンタープライズ アジャイル」の課題とは

なんちゃってアジャイル（要件定義はウォーターフォール/開発からインクリメント）、プラクティスだけ導入など、アジャイルの本質から若干離れているのが日本のエンタープライズアジャイルです。

なぜそのようなことが起きるのか、について藤井さんは以下のことを挙げています。

• サイロ型の組織。ステークホルダーが多すぎ。
• 保守主体。複雑な構造。既存システムなど、アジャイルじゃない人達と一緒にやらなければいけない
• 手作業が主流。非効率。運用の化身みたいな人がいる。効率化を促さない組織風土。
• 共有されない情報。

僕も同じような経験があります。
特にどうしようもないのが、既存システムとの連携や縦割り組織構造による意思決定の遅さ（というか決まらない場合が多い）です。
こういった組織に「アジャイルはこうやるんです」とかプラクティスだけ持ち込んでもうまくいきません。

意思決定のプロセスを決める

多様なステークホルダーとどのように意思決定をしていくかというプロセスがあることが重要、とのことです。
品質、進捗などをどの時点でどういう検証を行うのかをプロセスとして定義してしまうやり方です。
それにはプロジェクトのマイルストーンやKPIをしっかり決めておく必要があります。
これはアジャイルに限らず必要なことなのでまともな組織であればできるでしょう。

…なんかアジャイルって感じの話じゃなかったです。でもたぶん複雑な組織でアジャイルやるにはこういうプロセスは必要なんでしょう。
エンタープライズアジャイルが主戦場の僕にとってとても参考になったセッションでした。

IMPACT MAPPING～インパクトのあるソフトウェアを作る

http://event.shoeisha.jp/devsumi/20140213/session/404/
チェンジビジョン社長 平鍋 健児さんのセッションです。
僕がアジャイル開発に出会ったのは平鍋さんによる多くの書籍翻訳とアジャイル開発の啓蒙活動のおかげ。憧れの人です。
最前列に陣取って聴きました（笑）

デブサミで、『インパクトマッピング』のお話をしました！

Impact Mapping from Kenji Hiranabe

この書籍の話です。

IMPACT MAPPING インパクトのあるソフトウェアを作る

書籍は事前に読んできました。おかげで具体的な活用方法がより理解できました。（デモや例がわかりやすかった）
でもまだちょっとやってみないとわからないこと多そうです。
インセプションデッキやビジネスモデルキャンバスと同じような発想なのかな…。ちょっとずつ視点が違う感じ。
プロジェクトの大事なことを開発チームだけではなくビジネス側も一緒に共有できるツールです。

OpenJamでBackbone.js 、AngularJS、Senchaのバトルトークが

休憩しよー、と思ってたらBackbone.js 、AngularJS、Senchaを代表する３名の方がそれぞれのメリット・デメリットについてバトルトークしてました。
今年はJavaScriptをちゃんと勉強しようと思っていたので立ち止まって拝聴。
軽さや自由度だとBackbone、きっちり作りたいならAngularJS、豊富なコンポーネント使うならSenchaって感じの話でした。
うーんまずはBackboneから勉強してみようかなー。AngularJSにも俄然興味が出てきました。

ソフトウェア工学からコンピューターサイエンスへ

http://event.shoeisha.jp/devsumi/20140213/session/415/
日本マイクロソフトの萩原 正義さん。

ソフトウェア工学からコンピューターサイエンスへ （デブサミ2014） from Masayoshi Hagiwara

えーと…、ちょっと難しい話でした（笑い）
「ソフトウェア工学」だけでイノベーションは牽引できないのではないか、そこで「コンピューターサイエンス」がもっと重要になってくるという話。

• 複雑な課題をシステムで解決するのが我々の仕事。
• そこには様々な制約があり、すべてを最適化することはできない。
• アーキテクチャが複雑さをある程度解決していることが重要となる。
• そのためにソフトウェア工学ではなくコンピューターサイエンスもとても重要。

こアーキテクトにとって大事なこと

萩原さんが考えるアーキテクトにとって大事なこと、をお話しされてました。

• 自分自身を理解すること：どういう思考をしているのか。モデリングの進め方は何が得意なのか（箇条書き、マインドマップ）。どういうときにパフォーマンスが出せるのかを自分で知ること。
• モチベーション：どうやって維持するのか。何で上がるのか下がるのか。
• 知識管理：問題に対するアプローチをどうやって早く引き出すのか。自分の知識を整理していつでも引き出せるようにしておく。
• アウトプット：成果をどうだすのか。何が出せるのかを知っていること。

そしてこれから

• リアルタイム、アドホック、双方向性、スケール
• イノベーションはクラウドから起こる：分散システムが主要なテーマとなる
• スケールは可能性、耐障害性が大前提となる

なぜ、システム開発は必ずモメるのか？　プロジェクト見積もりから契約作成まで

http://event.shoeisha.jp/devsumi/20140213/session/416/
東京地方裁判所 民事調停委員(IT事件担当) 兼IT専門委員の細川 義洋さん
ブロガー・投資家・イレギュラーズアンドパートナーズ代表の山本 一郎さん

この本をネタに（にあまりしてかったな…）、システム開発における裁判沙汰の諸々のお話。
大きなプロジェクトに携わることもある僕にとっては一歩間違えばこういうことになるかもしれないので背筋が凍る思いで聴いてました。
「私の顔を見るのはここだけにしておいた方が良い」「裁判所で会う時は皆さん疲弊されて大変でしょう」by 細川さん。ああ怖い…。

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

ベンダーのプロジェクト管理義務はけっこう重い

ベンダーにはプロジェクト中止勧告をする権利・義務がある。とのことです。
でもこれって普通は言えないですよね。って山本さんも突っ込んでました。そりゃそうだ言える訳ないです。やる気あるのかとか言われて終わりです。
度重なる仕様変更、スケジュルの遅延などは裁判所的にいうと「つどつど言え」ということになるそうです。
うーむ…。難しい。

大事なのは信頼

細川さんが「登山者とシェルパ」に例えてました。
もちろん登山者がユーザ、シェルパがベンダーです。シェルパは行程が危ないと判断したら登山者に中止することを納得させなければいけません。
ITベンダーも同じように専門家としてプロジェクトの進行に責任を持ち要件の増加やスケジュールの遅延などに目を光らせ、プロとして厳しい判断をすべきなんでしょう。
ただ細川さんは「まだまだ時代がそういう感じになっていない」と仰ってました。シェルパにもそういう時代があったそうです。（登山者が権力として強くアタックを決行し全滅する…みたいな）

我々に出来ることはこんな感じでしょうか。

• ITのプロとしてプロジェクトに責任を持つ
• それによって信頼を得て、プロとして判断をユーザに聴いてもらうようにする
• 何度も何度も提言したり、根回したり、泥臭くプロジェクトを正しく方向に導く

「商売の基本は信頼。ITの専門家としてユーザにリスペクトされないといけない」という細川さん言葉がすべてのような気がしました。

感想

去年は「自分と違う分野を見よう」ということで、ゲーム業界や広告関連での事例を見て回りました。
（去年はデブサミの後にDevLOVE行って色々あったなー）

今年は特にテーマを決めず、適当に興味の赴くまま参加しましたが、アジャイル関連の話でちょっと気がついたことがありました。

開発チーム内部の話ではなく、開発チームの外とどうコミュニケーションをとっていくのか、というテーマが多かったように思えます。
もう開発自体はアジャイルでやれる、だけどアジャイルは「顧客への価値」を大事にするんだからビジネスも一緒に回さないとダメですよね、ということ。
これは僕自身が仕事で課題に感じていることと同じでしたのでとても得るものが多いデブサミでした。

来年も期待したいと思います。

目黒雅叙園の中庭。雪が積もって風流ですねー。

大雪で大変だった…

あまり良い天気な印象がないデブサミ。
今年は記録的な大雪でした。

終わった後、コミュニティの方々と軽く飲みに行きたいなー、と思いつつ帰宅できなくなる前に帰りました。
京王線はものすごい混雑はありましたが、止まったりせず１時間くらいの遅れで無事帰宅できました。
JR組はちょっと大変そうでしたね。ぜんぶ雪のせいです。

ウチの近くはすごい積雪…。30〜40センチくらい積もってました。
帰宅難民になってる同士もチラホラ…。
皆様お疲れさまでした。

冬の沖縄で穴場探し

ちょっと早めに仕事を納め、沖縄に12/26～12/31の6日間滞在してきました。
夏の旅行だととにかく慌ただしい日程になるのですが、今回は予定はあまり決めずにのんびりすることにしました。冬だし。

のんびりしながら夏には行かないような場所、穴場のレストランなど回ってきました。

沖縄の小さな宿 「かふーわ」でのんびり

小さな一軒家に宿泊します。
ウチは子供が3人。とてもうるさくするので音や振動を気にしない一軒家は快適です。
普通のホテルだと床は土足ですので赤ちゃんを床に置けません。
ベッドに乗せておくことになるのですが、落ちないようにずっと見ていないといけません。これが地味に疲れる。
そういう点では一軒家で自由に這いずり回ることができて三男にとってもいい宿でした。

かふーわの中

まだまだ小さな3男（1歳）もくつろいでました

憧れの2段ベッド！

毎朝パン（またはおにぎり）が届きます。美味しいです。メッセージも添えてあって楽しい。

ちょうど嫁が誕生日だったのでケーキのプレゼントもありました。すごい。

機会あれば行ってみてください。いいところでした。
沖縄の小さな宿 「かふーわ」
facebook pageはこちら

港町食堂で安くて美味しい洋食

穴場のにおいがプンプン漂う洋食屋さんです。
見た目と安さとは想像もできない美味しい料理ばかりでした。会社の近くにあったら毎日行く。

港の倉庫っぽいところにあり、探すのに苦労しました…。
すごいところにあったし、外観もすごい。

ビーフカツレツ

山城牛のハンバーグ

ふわとろオムライス

キノコとベーコンのクリームパスタ

港町食堂

比地大滝でトレッキング

天気が良かったのでトレッキングでも、ということで国頭村（沖縄本島の北のほう）の「比地大滝」に行ってきました。
片道３０～４０分の山歩き。次男（6歳）でもすいすい歩ける安全な道ばかりです。
涼しい森の中を抜けていくのは気持ちいいです。

ただアップダウンが激しく、三男（1歳）を担ぎながら歩いた僕にはちょっとキツかった…。

途中で大きな吊り橋がありました

「アカヒゲ」という鳥がお出迎え

沢遊びができるところもあります。カニがたくさんいました。

前田食堂で牛肉そば

大宜味村、58号線沿いにある沖縄そばのお店です。「牛肉そば」が絶品でした。

2014年の目標的なもの

年も明け、怒涛の冬休みも一段落したので、今年の目標というか進む方角というかそんな感じのことを考えてみます。

そういえばBlogを始めて1年たちました。初めてのBlogですがなんとか1年続けられました。
今年も無理せず続けていきます。
「Blogを続ける」大事な目標です（笑）

2014年の目標的なもの

仕事まわり

• 社内勉強会を継続する。続けることで色々と学びがあるので面白い。
• 「個人振り返り」をやる。昔やってたけどいつの間にかやらなくなってた。復活させよう。
• チームの成長を記録する。なんとなく良くなった、ではなく「～ができる」「ｘｘができる」など具体的な成果を記録し成長を振り返れるようにする。
• フロントエンドのプログラム技術に触れる。Javascript、スマホのアプリとか。技術要素や難易度が判断できるレベル（大雑把には見積りができるレベル）にはなりたい。
• UI/UX力を上げる。業務システムの設計が主戦場なのにUI/UX力が足りなさすぎるのを2013年で思い知った…。
• 「成長の機会が得られる現場」を作る。特に若手が成長を実感できる場を作りたい。
• インセプションデッキ（http://www.ryuzee.com/contents/blog/4009）をとにかく書こう。何かにつけ目的や意義を明確にせず仕事を進めてしまうことがよくあるので習慣にできれば。

その他

• サッカーの戦術/戦略に詳しくなりたい。このチームはどういうチームなのかをキックオフ15分くらいで理解できるようになりたい。どこを強みとして設定し、どういう攻めと守りを目指してるのか、なんてことを理解できたら面白いだろうなー、と。とりあえず戦術系の本を読みまくるかなー。
• 月2回はサッカー/フットサルする！
• 週1回はジョギングしようかな
• 次男のサッカーに根気よく付き合う

TDD（テスト駆動開発）の練習をやってみた

先日、イベント開催のお手伝いをさせて頂きました。
「アジャイルサムライベースキャンプ」
http://www.agilesamuraibasecamp.org/

そこに僕のチームメンバーが何名か参加してくれました。

当日の和田卓人さんの講演

TDD のこころ @ Agile Samurai Base Camp from Takuto Wada

TDDの実践は難しいなぁ...　→　じゃあ練習しよう

そんなわけでTDD（テスト駆動開発）を学んだわけですが、TDDってその意義は理解できても現場で適用するのは難しいと思うんです。
そもそもテストコードを書くという意識が希薄な職場です。我々のチームではようやくテストコードを書き始めた段階。

いきなりTDDを仕事で、というと僕も含めて「うーん...」って感じでした。
ということでとりあえずTDDの作法に則って練習をしてみることにしました。練習なら失敗してもいい。

TDDの素振り

やり方

• 終業後に集まって２時間やってみる
• スキルにバラツキがあるのでペアプロ
• 題材は僕が準備

題材

• とりあえずみんな慣れてるJavaで簡単なロジックを作ってみる
• 「時刻表から次の電車を探す機能」を作る
• 時刻表、指定時間をインプットし、指定時間の直近の発車時間を返却するメソッド

仕様上のポイント

• 時間またがり、日付またがりのロジックができているか
• 普通に境界値、同値分割がテストケースとして考えられているか

途中で仕様を追加してみる

• 土日用の時刻表と平日用の時刻表があったことが発覚。なんてこった。仕様追加。なるはやで。
• ２種類の時刻表をインプットとする
• 時間だけではなく、日付もインプットとし、日付から曜日を自動判別して該当する時刻表から電車を探す

このような簡単なロジックであればTDDっぽく進められました。２時間半くらいで４人（２ペア）とも完了しました。
例外的なケースの考慮が若干不足してましたが、まあTDDの練習が主旨なのでよいでしょう。

やってみて

「TDDをやる」ってことを目的とするよりはTDDの考え方に沿ってテストコードとプロダクションコードを書いていくことで、コードはよい設計で読みやすいコードになっていくのかな、と感じました。
目的はちゃんとしたコードとテストコードを書くこと、ですね。

今回の題材からは「なるべく変更を加えず（テストコードも作ったものを活かしつつ）仕様変更に対応する」ということが出来たのですが、仕様追加/変更の内容によってはテストコードの書き直しがあるかもしれません。その場合はどのような書き方がよいのか。違うノウハウがありそうです。
色んなテストコードを書いてみて色んな対応方法を学ばなければ...。経験するしかないですかね。

そういえば

４月に参加した「CI and Testing Unconference in Tokyo」
http://citcon-jp.doorkeeper.jp/events/3473
その時の僕のレポ/感想

ここでの僕のTryは「TDD Bootcampをチームでやる」だったのでした。
若干忘れてたような気がしなくもないですが、なんとか実現できました。

「DevLOVE現場甲子園2013」に参加して #devlove

2013.11.9（土）「DevLOVE現場甲子園2013」に参加してきました。
http://devlove.doorkeeper.jp/events/5464

いつもと違うのはただの参加者ではなく、発表者として参加したことです。

発表！？

@takigawa401さんに声をかけて頂き、発表することになりました。
突然お誘いを受けてビックリしましたが、いつもDevLOVEに参加させてもらってパワーをもらっている身としては断るわけにはいきません。
（と言いつつ家庭の予定がないことを確認してから返事しましたが…）

10月中旬あたりでしょうか。どのような主旨のイベントなのか、僕には何を期待しているのか、を打合せし発表の軸を決めました。
まあ僕も@takigawa401さんもエンジニアというよりFC東京サポーターという共通項があったので8割くらいはサッカーの話をしてたんですが…。

「バラバラの同僚を社内勉強会でつなげよう」

こんな感じの発表をしました。

バラバラの同僚を社内勉強会でつなげよう from sugiim250

沈みゆくSIerは元気がありません。仕事に遊びがなく厳しいプロジェクトが続きます。

極端な話、成長している業界は育成を意識する必要がありません。成長産業っていうのはそれだけで良い「場」なんだと思います。
良い人が入ってきて勝手に成長するし、良い人に引っ張られて良い場ができます。

我々の仕事場は良い場ではなくなりつつあります。
だからって何もしなくてよいのか、何かできることはあるだろう、といつも思ってます。

何かを始めてもすぐには改善しません。
ちょっとずつ良くしていくことを続けてみて、何か変わることもあるかもしれません。

隣の芝をみて憧れるのはいいけど、自分の庭の批判ばかりしてるようでは何も変わりません。
自分の現場、自分の周りからちょっとだけでもいいから何かを始めてみよう。

そんなことをこの発表では伝えようと思ったのでした。

「DevLOVE現場甲子園2013」は熱いイベントだった！

他の方々の発表はそりゃあもう圧倒的でして。
全60話。もちろん全部は聞けなかったのですが、少なくとも僕が参加したセッションは全部素晴らしかった。
すべてのプレゼンには熱い思いが詰まってました。

みなさんの熱い思いに触れ、また自分の現場で頑張ろうと思います。

最後にスタッフの皆様には改めてお礼を言いたいです。
このような素晴らしいイベントを作ってくれてありがとうございました。

優れたスクラムマスターは壁を創り出す

Photo Credit: andyi via Compfight cc

大きな組織に紛れ込んだアジャイルチーム

だだっ広いオフィスにアジャイルチームがポツリ。
取り囲むは純然たるウォーターフォール。
オフィスは1000人は入るような大きさ。
びっしりと並ぶプロジェクト構成員。

大きなプロジェクトの中で一部でもアジャイルを導入してみようという試みです。
大きな組織では最近よくある話ですね。

壁がない…！？

組織からはアジャイルチームとして認められているので、周りが何してようが関係ないんですが、ちょっと困ったことがありました。

壁不足です。

何かっていうと、大きなプロジェクトは大抵の場合大きなフロアで仕事します。
ちょっといい感じのオフィスだったりするとガラス張りだったりしてそもそも壁が少ない。そして壁際には大抵の場合、管理職が陣取ってます。
そして我々のチームが配置されたのはフロアの真ん中あたり。壁不足が深刻な状況です。
壁はアジャイラーの命。タスクボード（カンバン）でタスクや課題が見れない。振り返りの内容も貼れません。
これはピンチ。壁があってこそちゃんと機能するのがアジャイルチーム。こんな状況ではチームの力を十分に引き出せません。

「壁ください」って言っても「？」って顔されるだけです。じゃあホワイトボードをチームに１つください。と言っても他のチームはそんなことしてないので、君たちだけ特別なことやらないでね、とか言われておしまいです。

さあどうしよう。スクラムマスターとしての腕の見せ所です！（笑）

無いなら作ればいい

というわけで壁（カンバン）作りました。

• その辺に置いてあったハンガーラック
• ポストイットの巨大なやつ

を組み合わせて即席カンバンの出来上がりです。
ポストイットの巨大なやつは我らアジャイルチームの嗜みとしてどの現場にも持参するものです。
ハンガーラックは使ってなさそうなのを拝借しました。さすが大きなオフィス。使ってなさそうな備品が転がってます。
ハンガーラックを勝手に持ち出してしまったので後で怒られるかもしれません。が、「Don't ask for permission, Ask for forgiveness」の精神でとりあえずよしとしました。
（怒られたら謝ろう）

ハンガーラックにいい感じに引っかけるものがついてました。
ポストイットの巨大なヤツのカバーにちょっと穴をあければバッチリハマりました。
サイズもピッタリです。何これ。このための道具じゃないの。

ハンガーラックなので動きます。「こいつ…動くぞ！」とか言って遊べます。ああ楽しい。

スクラムマスターの必須スキルに「壁を創りだすことができる」を追加しよう

アジャイルチームに大事なのは何より「壁」。優れたスクラムマスターはどんな状況でも壁を創りだし、チーム力を向上しなければいけないのです。

おしまい（笑）

システム思考を学ぶ #devlove

2013.10.22
DevLOVE「システム思考を手に入れよう」に参加してきました。
http://devlove.doorkeeper.jp/events/6155

覚えたこと、感じたことをメモ。

講師は有限会社チェンジ・エージェント 小田 理一郎（おだ りいちろう） 氏
とても心地よい話し方をする方でした。

システム思考について

• システム思考は身に着けるのがとても難しい。本来は長期的（６ヶ月とか）にトレーニングすべきもの。今日は紹介のみ。
• システム思考とは「木も見るけど森も見る」もの。
• 立場や役割など視点が変わると見え方も違う。時系列で構造も変わっていく。偏った視点になりがちなのが一般的な論理的思考の落とし穴。
• 成功体験が視点を固定してしまうこともある。

• 「出来事」→「時系列」→「構造」→「根本/根源」の順に深くなっていく。問題として表出する「出来事」だけを見て解決しようとしてもうまくいかない。
• 問題は時系列で変化していくことが多い。今日の問題は昨日の解決策から生じる場合もある。
• MECEのように物事を細分化して局所的な対応をしても、別の問題が出てしまう。（ルービックキューブの１面だけを揃えても…、という例を出してました）
• ループ図で問題の構造を表す。事象の関連を関係者で対話しながら作る。
• 問題がある箇所では、人を責めず構造の問題と捉える。

感じたこと

ループ図の説明があり、これは現場の問題を分析するのに使えそうだなーと感じました。
ただ書き方が難しそう…。何度か練習する必要がありそうです。
また客観的に構造をループ図にするというのも難しそうです。何をもって客観的なのか…。なんかコツとかありそうです。

問題を見つけ解決策を導く方法について何かコツはあるのか？という質問に対して、
ピーター・センゲの本にいくつかのパターンが書いてあるとのこと。
これは読まねば…！

小田さんが書いたループ図の例

「進捗の遅れ」を例にしてます。なんて実践的な例！明日から使える！

勉強しよう

有限会社チェンジ・エージェント
　　http://change-agent.jp/
システム思考についての解説など

学習する組織――システム思考で未来を創造する

なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方