「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センチくらい積もってました。
帰宅難民になってる同士もチラホラ…。
皆様お疲れさまでした。