XP祭り2014に行ってきました!!

2014年9月7日(土)、初めて早稲田大学のキャンパスにこの足を踏み入れてきますた。

初参加の「俺の」XP祭り、思った以上にゆるーい雰囲気の中、沢山の「俺の・・・」を聞き、沢山得るものがあったような気がする。

自分のEvernoteメモを元に、遅ればせながら、個人的に気になったところをblogってみようかと。

XP祭り2014

　アジャイルのダークサイド

聞く話は自分のコンテキストで理解しようと最近しているが（そういえば、最初のお菓子漫談で小井土さんもそんなこと言ってたような）、この日MAXビジバシ感じるものがあったのが、鈴木雄介さんの話。

特に最後の『社会基盤を担う大企業にITの使い方を変えてもらいたい云々』 というのはシビレタなぁぁぁ。　あの会場に同じことを感じた人がどのぐらい居たのか分からないが、自分には、スンゴイ切実に響いた！！そんな大企業のSIはまだまだ従来型の人月積算工数で１システムおいくら万円の世界ですし、ここに凄まじい可能性が埋もれているはず。ITを使う側は「アジャイル」なんて言葉はどうでもよく、だからこそ余計に、情シスやSIerが勝手にアジャイルのダークサイドに堕ちやすいって側面もあるかな、と。

知らない間にオレも堕ちかけていることを気付かされました(；´∀｀)

そういう意味でも、アジャイルという手法に拘るのではなく、アジャイルを手放して、組織ごとに最適なやり方をちゃんと考えた方がいいっていう提起にはもう唸ることしかできなかった。

 以下箇条書き

・ISO品質モデルから、ソフトウェア作るのは難しいんだよ

・だからこそ、マネジメントとアーキテクチャの両輪が重要

・アジャイルは全体整合性（アーキテクチャ）を軽視しているようにも感じる。それはアジャイルの伝道師たちにとっては、アーキテクチャの重要性なんて当たり前の話しすぎたからなのかも（仮説）。

・「良いものを作りたい」という覚悟がないと、アジャイルのダークサイドに堕ちやすい。自分で運用しない人とか偉い人とか危険。情シス部長とかSIerとか。

・言葉上は、ダークサイドに堕ちる人と堕ちない人が同じことを言っているから、さらにたちが悪い。「良いものを作りたい」という覚悟、自分ももっと拘らないとダメだとも感じた。（リスクの低い方低い方へ流れたがるSIって妥協の産物的な要素が強いし）

・アジャイルはこうすればいい、と思った時点で思考停止してしまう。状況によって重要性・価値観は変わるもの。（アジャイル宣言の右と左）

★どう作るか（手法）ではなく、どこへ至りたいか（ビジネスのゴール）を考えろ！！

　関さんの話を誤解してみる

基調講演の関さん。失礼ながら今回、初めて名前と顔が一致しましたです。

Twitterでつぶやいていた人がいたような気がするが、関さんは本当に不思議な雰囲気を持っている方。吸い込まれてしまう感じ。たぶん自分は話の9割分かってないんだけど、半分ぐらいは分かった気になってしまったし、たぶん結構誤解しているんだとおもう。でも、今回の話は、SECIモデルでは形式知を誤解していいんだって話もあったし、そもそもXP自体が人は間違うことを前提にしているから、それでいいんだと、妙に納得感。

お話、のっけから、550イテレーションで数万チケットが溜まっているから統計噛ませて云々とか、もうホント異次元の世界の話を聞いた感じ。ありがたや。

気になったこと箇条書き

・減らすのは難しい、増えるのは簡単。テストケースの話。だから健康体でテストは望もうね、と。

・従来の開発手法と異なり、XPは人がミスすることを前提としている。そういう意味でも１つ１つのミスを小さくすることができるモデルと言える。

・ソフトウェアの信頼性。CheckingとTestingの話。モデルベーステストと探索的テスト的なイメージかな・・・

・忍者式テスト、初めて知りましたが、人が学習しながらテストを育てる（テストケースを洗練）感じでしょうか。自動化テストはChecking。人がテストしてテストケースを書き直したりはTestingってことかな・・・

・計画ゲームがアツイ。

・ビジネス側と開発側はうまくいっていないことが多いのだが、この計画ゲームでは、やりながら分かることがあることを前提にしているから、お互いが理解し合える、歩み寄りができる。

・質問の回答で「うちのチームにリーダーはいないからわからん」とか本当かなぁって思ったが、ゴールは同じで途中ズレていることはあるかもしれないけど歩調を合わせていくような話をしていたので、なんとなく理想的なチームを想像した。

・（製品開発をされているのだとおもうが）現在、ビジネス側は開発側のスピードに不満がない的な話をしていたのも印象的。ビジネス側は効率化・コスト削減を常に考えていると思っていたが、それをも駆逐するチームがこの世にあるのかもしれない。

うーん、 たぶん誤解だらけ。

　ビジョンとミッション

 Fearless Changeと超迷ったが、先日の受託開発イベントに行けなかったので倉貫さんの話に言ってみた。 すげーエネルギッシュなトークの中に、SIerに身を置く自分にとって「今の俺ならどうなんだ？」って考えさせられる話が山盛りだった。

何度か「アジャイルは結果」という倉貫さんの言葉を見たが、それを改めて感じた。

自分は何をしたいのか（理想＝ビジョン＝ゴール）を考え、そこ向かうために今何をすべきか（ミッション＝スタートライン）というメッセージは、まだ咀嚼し切れていないが、今の自分も向き合わなければいけないこと。

気になったこと箇条書き

・2000年あたりからSIerは「マネジメント重視」に。（PMBOKとかオフショアとか確かにその流れ）で、それまではその会社のことを”技術の○○”って・・・すげー思い当たる話

・プログラム書くのが好きな自分は、デスマに放り込まれて、辞めようとおもって役員に相談したらしいが、社外で活躍したいならもっと有名になれ。でないと辞めてもうちの下請けになるだけだぞ、と。そして仲間を作れ、と。それを実現してソニックガーデンなのですねぇぇぇ(・∀・)

・ Don’t just do agile, be agile!（これいい言葉）

・アジャイルをやる？それって本当に組織のためになるの？みんながみんなアジャイルをやりたい訳ではない。出来る訳でもない。（雄介さんの話にも似た話あり）

・帰り道にリフレインし続けた一言

　『 理想を語れ、そして行動しろ。共感を得られれば仲間は増える！』

倉貫さんは元XPユーザー会の代表。

知っている人をイジリながら、会場の空気を自分のモノにしたり、話の内容もさることながら、すごいなーーー

　他にも沢山の話を聞いておなかいっぱい

最後はLT祭り。14本連続は正直ぐったり・・・疲れ果てますた:(；ﾞﾟ'ωﾟ'):

みんな個性たっぷり面白い話が多かったが、自分のコンテキストに置き換えて聞くような余裕は全くなく、話についていくのに精一杯。

進行の方の合いの手も絶妙で、あの雰囲気はLTじゃないとあり得ない。

以下、自分のメモと順番が合わないが・・・

デザインスタジオというアクティビティの紹介：平松 欣也さん

 　→　Yahoo!モバイルのUI/UXのお話、のっけから勢いありまくり

僕がスクラムマスターをクビになった訳：石井 智康 (@zambiker)さん

 　→　スクラムやってて管理層から言われるあるある。「で、いつ出来るの？」「もっとベロシティあげてよ」 「人投入すればできるでしょ？」非開発者のアジャイルには気をつけろ！禿同。

俺の「機能横断的チーム」 に近づくためのあれこれ：渡邉 太一さん

 　→　スクラムの取り組みの中で、全員に全部できるようになってほしいというなか、あえて機能特化型チームをつくったというお話。ある程度は自分の持ち分が明確な方が動きやすい人って多いし、結構現実的だなーって思いながら、自分だったら・・・と聞き入ってしまった

忍者式テストをやってみた：中島 滋 (@ledsun)さん

　→　テストケースからちょっと外れたテストでバグが見つかるって本当にあるある。だからこそ成長する忍者式テストの話、続きがキニナル・・・

俺の事業部：木下 史彦さん

　→　実は木下さんのセッションも聞いていた。Twitterでのリアルタイムツッコミ（寿司で釣っているとか）も面白かったwww　永和さんのチャレンジ精神、すごい！

チームや組織を良くしようとしている皆さんへ〜課題解決型イベント「Scrum master’s Night」のお誘い〜：長岡 実さん、知花 里香さん

　→　本気で今度行ってみたいな〜　スクラムマスターぢゃなくても大丈夫かな〜　ということで早速connpass.comをチェックしてみたらまだ無かった　Yahoo! × DeNAってのもスゴ〜

ももたろう：てらひで (#terahide27)さん

　→　てらひでさん、まさかの英語すぴーち( ´ ・ω・｀)!!　しかもそのTｼｬﾂ!!(ﾟДﾟ≡ﾟДﾟ)ﾜﾗﾀ!!

アジャイルソフトウェア開発の道具箱～永和システムマネジメント勤続10周年記念講演：伊藤 浩一 (@koic)さん

　→　なんかイケてる雰囲気な方で、壊れているおもちゃを用意するとか、うちの息子に・・・（ry

8年目の活動報告：よねざわ まことさん

　→　関さんと咳さんってどう違うのでしょうか？　自分もスピード違反注意しないと:(；ﾞﾟ'ωﾟ'):

○○したら受託開発が180°変わった：原田 敦 (@harada4atsushi)さん

　→　あれ？写真見たことあるとおもったら、あじゃいるヒヨコクラブの方ぢゃないですか。（今度行ってみよっかなー）

リーンスタートアップと野球2014：中川 伸一さん

　→　いやー、最高に面白かった！！スポーツの世界のデータサイエンティストの話。自分も野球好きだけどここまでdeepぢゃなかったので、興味津々。ピタゴラス勝率とかちゃんと理解してみたいな。

【Report】XP祭り2014に参加しました&LTをやってきました。 - Lean Baseball

アジャイル病を患ったおっさんビギナーが現場でトライしたこと：すなだ (@orinbou)さん

　→　 なんかとっても親近感（勝手に）　朝会に集まらないってこれもアルアルwww　アジャイル語を口にしてはいけない現場、爆笑　これも身近にアルアルwww

モデリングもしないで”XP”とは何事だ：原田 巌 (@iwaoRd)さん

 　→　XP祭りの盛り上がりを自分のLTの盛り上がりにすり替えるテク「いただきます(・人・)」

メトリクスによる「見える化」のススメ: エッセンシャル・リーン：伊藤 宏幸 (楽天)さん

　→　agile2014登壇の伊藤さん、自分の理解しているメトリクスとここでいっているメトリクスはちょっと違うような気もしたが、すげー興味深い話だった。見ている世界がグローバルでもあり、測ることは目の前の自分のことでもあり、いろいろ掻き立てられた

Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says

あ、ちなみに野良LTもあったみたいだけど、どんなかんじだったのかなぁぁぁ

来年はネタ作って出てみるか〜〜な〜〜 ( ´ Д｀)

　最後に

初参加優先で頂いた戦利品。読んだらレビュー書きますです。

ありがとうございました！ 

ちなみにこの津田さんの「タイムボックスの話」も聴講していたのですが、スライドもアニメーション効いていて、話がすげー分かりやすく、マジでパクりたくなりました。分かりやすく説明するスキルってとっても大事！！！嫉妬。

LT祭りでMPをすべて奪われてしまい、懇親会にドタ参加する元気までありませんでした。沢山の人の話を聞けたのにで、その後いろいろと突っ込んだ話を聞けると更にいいんですけどね。次回のための良い教訓です、はい。

スピーカーの皆様、スタッフの皆様、本当にありがとうございましたm(_ _)m

追伸

この記事を書きながら、お話を聞いた人を見つけては次々をフォローしていますナウ。あと発表で使われたスライドも見つけ次第、リンクさせていただきます。どうぞヨロシクおながいします。

　リンク集

しかし、みなさん、blogにまとめるのが早い＆上手いな〜〜〜

XP祭り2014に参加してきました。 #xpjug - ミッションたぶんPossible

2014-09-08 - Vestige is fragments of memory

XP祭り2014に参加してきました！ -Agileってなんなんだろう が少しわかったお話- #xpjug - エンジニア的なネタを毎週書くブログ

XP祭りに行きました #xpjug - @ledsun

XP祭り2014に参加してきました（１） | NCデザイン＆コンサルティング株式会社

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

を読んだ。実は１ヶ月以上も前だったが、実はブログを書いていないことにさっき気付く。

8/27のイベントに先立ち、事前に自分の頭の中を整理しておきましょうって感じの２本目記事。

１本目はこちら。

　システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか? - 部屋とアジャイルと私（仮称）

さて、Amazonでベストセラーになっているとも聞く「納品をなくせば・・・」だが、元々はソニックガーデン倉貫氏のブログをちょくちょく見ていたので、待ちに待ってた書籍化であった。著者である倉貫氏は大手SIer(TIS)に居ただけあってSIの実態をちゃんと把握されていて、いつも説得力のある文章でまとめられているが、今回は書籍ということでまたいつも違う新鮮さもあった。

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

　サマリ

一括請負のSIモデルでは、作ったシステムを「納品」して売りが上げるSIer（受注側）と、そのシステムを動した後に効果が生まれる顧客（発注側）という相違のため、お互いディフェンシブになりがち。またシステム開発金額は人月積算のため労働集約型。この根本的な問題点に対して「納品」を無くし、開発〜運用ず〜っと顧客と一緒に、月額定額契約で「受託開発（運用・メンテ）」を実施するという新しいビジネスモデルを提唱。ソニックガーデン社はこの形でもう３年ビジネスを行っている。ポイントは顧客と一緒にビジネスを育てていくというCTO的なITプロフェッショナルサービスで、俗に言うDevOpsにも通じるし、Webを使った新規事業のスタートアップでの事例が多い。開発スタイルは（結果的に）アジャイル開発。IT業界のエンジニアは「ナレッジワーカー」であるため自律的でなければならず、また、会社が１つのチームとして機能することを最優先しているので、エンジニアを大きく増やすことは考えておらず、「のれん分け」という形でのビジネス拡大にもチャレンジ中。

ザックリいうとこんな感じであろうか。

ひとつひとつの部分について、倉貫氏が大切にしている考え方や価値観（およびその裏付け）が反映していて、それが見事に１つにまとまり、実際にビジネスモデルとしても成功しているというから本当に説得力がある。

とても読みやすい文章で、事例や生の声もあり、自分の身の回りでも沢山の人に読んでもらいたいと感じた本である。特にエンジニア仲間というよりも、上司や経営者に読んで欲しいな、というのが率直な感想。

　ここもポイント

キーとなると感じたポイントをいくつか。

１．工夫したくなるビジネスモデル

新しいことにチャレンジしたり生産性を向上させるために工夫したり・・・というのはエンジニアの知的欲求の本質。この「納品のない受託開発」は、それらを阻害しやすい（もしくはやっても評価されない）従来型のSIビジネスやSIerの人事評価の問題点が解消しやすいビジネスモデルといえよう。

２．顧客からの信頼を得やすいビジネスモデル

「納品（もしくは本稼働）」を目指して受注側と発注側が協力する形よりも、共に新しいビジネスにチャレンジしながら、試行錯誤する形は、結果が出なかったときもWin-Winの形を作りやすいと言える。IT投資の費用対効果は実は測りにくいため、月額定額というのもポイント。

３．技術の統一化

扱う技術を統一していることも実はとっても大事なポイント。クラウドサービスの普及で更に一段と技術的な複雑度が増す中、このこともとても重要なポイント。Ruby on Rails、AWS、Linux・・・という形で技術は統一化し、もちろん進化させているとのこと。 

４．マネジメントしない？

というと語弊があるが、要は指示命令で動くエンジニアではなく、自分で考えて行動できる自律したエンジニアである必要があるということ。平鍋氏のいうマネジメントは「コマンド管理型」から「リーダーシップ協調型」へ、という話がリンクする。そしてチームとしては自己組織化された形。どのようなビジネスにおいても、これは理想であり、常にここを目指すべきであろう。

５．属人性を排除しようとしない

サブ担当者を置くなどしているということだが、「属人性を排除」することよりも「人を大切」にするという。属人性排除はプロセスありきになるが、個人的にはこの部分は非常に迷いがある。プロセス標準化によって定量化・見える化が実現され、エンジニアリングが発展するためにはこのことは大切なのだが、プロセスなんて糞喰らえってエンジニアが多いのも事実。自律したエンジニアとこの属人性排除はセットで考えた方がよさそうだ。

いずれにせよ、ソニックガーデン社はエンジニアの皆さんにとって従業員満足度がとっても高いのだろうと推測する。それは、給与もそうかもしれないが、やりがい的な部分が大きいのだろう。ビジネスモデルの裏にある話かもしれないが、ここが一番の差別化できている部分なのかもしれない。

　最後に

既存SIもしくは、既存受託開発は、明日から無くなることはないが、新しいビジネスモデルが求められているのは事実であろう。倉貫氏は「納品のない受託開発」という新しいひとつのビジネスモデルを作って、ビジネスとして成功させ、そして華々しい舞台にいるのだと思う。そして何よりもご自身のチャレンジを社会に還元しようとしている姿勢は、利益追求を超えた、経営者として素晴らしい方なのだと。そして、現在はまだ模索中であるが、いずれ自分も新しいビジネスモデルを形にしたい！

先日の夏サミで、倉貫さんとお話しする機会があった。 ま、実際は、この本が手元に無いのにサイン会に自分が勝手に押し掛けたのだが・・・　でも、とても気さくに対応してくださったのだが、その飾らないけど輝くオーラは、ブログ等で感じてた印象そのままだった。だからといって、この書籍のベタ褒めはしたくないのだが、ビジネス書としても類い稀まれな良書だとおもう。

この業界を知らない父にも薦めてみようかな。あ、でも、その前にうちの上司と経営陣に読んで欲しいな。

エレベータ・ピッチを練習だ！！(・∀・)

最後に、

8/27のイベントが更に更に楽しみになった。何を質問しようかなぁ〜

受託開発ビジネスはどうなるのか、どうすべきか | Peatix

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

を読んだので書くことにした。

8/27のイベントに先立ち、事前に自分の頭の中を整理しておきましょうって感じで。

もう1本目の記事はこっち。 

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル - 部屋とアジャイルと私（仮称）

最近、SIビジネスが曲がり角に来ている話題はなかなかホットトピックスで、自分自身もSIビジネスに携わるものとして、また新しい価値を生み出すITサービスを実現するためにも、この話題はとても興味深いところ。

 「SIの闇」に光を当てたい！　

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

　サマリ

ビジネス環境変化に対して「SIビジネスも変わらなきゃいけない」理由から、では「具体的にどういうアクションが重要か」という提案までが、読みやすく簡潔にまとまっていたと感じる。特に、「変わらなきゃいけないけど、でもどうやって・・・」と認識している人を対象にしている印象。

終盤に書かれている、既存SIを進めながら新しいSI事業（文中は"ポストSIビジネス"と表現）を作り上げる、部分については、同じことを考えている人は多いはず。顧客（情報システム部門とかの発注側）とSIer（ベンダーなど受注側）の両視点で整理されており、SIビジネスの「創造的破壊」を起こす側に向けたメッセージと言えよう。（この議論を発展させると、市場のIT利用者（ユーザー）の視点ももっと加えていく必要あり！）

このポストSIビジネスを成功させるためには以下の５つシフトが必要とのこと。（各論の感想は後述）

サービスビジネス

クラウドビジネス

OSS活用

グローバル対応

新しい存在意義・新しい役割

それぞれのテーマがとても深い話題であるが、SIビジネス全体を俯瞰して整理し「では、どうするか？」のきっかけになる良書であろう。次のSIビジネスにチャレンジしたいと思っている仲間や上司にも薦めたい。

 なお、１点だけ違和感を感じたのは、事例に出てきた方の言葉かもしれないが「受託開発が嫌い」「受託開発を止める」など、労働集約的工数積算モデルと受注開発を同義に書いてあった部分。従来多かった一点モノ（フルオーダーメイド）のシステム開発は無くなったとしても、企業の競争力の源泉（つまり他社との差別化）にITを有効活用することが今まで以上に求められているので。

※んー、まー、言葉の問題かなー

　5つのシフトについて

１．サービスビジネスの例が３つ紹介されている（月額定額モデルとしてソニックガーデン「納品のない受託開発」、レベニューシェア（成功報酬型）として日本ユニシス、取引量に応じた月額金額としてNTTデータのANA基幹システム）。初期投資を押さえての月額支払（定額もしくは変動)は、発注側と受注側の関係性を変え、Win-Winに向かいやすいだろう。

２．クラウド利用への流れは止まらないことも、月額支払モデルを後押ししているため、クラウドが一括請負を淘汰していく流れと言えよう。クラウドサービスは層構造で成り立つので、SIerはどのレベルのサービスを誰に提供するか、が重要。

３．OSS活用も止まらない流れ。OSSに関連する技術者は会社を超えたコミュニティに積極的に出ていった方がよいし、実際にインターネット上で情報発信することを奨励している会社は増えてきている。とはいいつつ、Githubひとつとってもハードルに感じるところはまだまだ多いだろう。

４．グローバル化について、日本と欧米の文化の違いの話は外せない。ITサービス展開のグローバル化と組織や開発チームのグローバル化は分けて掘り下げる必要あり。後者については人材流動性（横のキャリアパス）のジレンマ・・・

５．SIビジネス事業者が、顧客のCIOになれ的発想は大賛成。アジャイル開発の本質は「全部を作らないこと」というのはソニックガーデン倉貫氏と同じ主張。また、アジャイルは開発手法ではなく「働き方」というのも、自分の中では納得できた言葉であった。

　　　アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!

　まとめ

今現在、既存SIで人が足りない・足りないという話を身近でも聞く。従来型の労働集約的なSIを明日から捨てることはあり得ない。放っといてもSIビジネスはある程度緩やかに変わるだろう。でも、生き残るのは変化する市場に対応して変われた組織であり、変われた人たちだけであろう。今、自分は、そのことにチャレンジできる環境に居る。

8/27のイベントが更に楽しみになった。著者である斎藤昌義氏とはお会いしたことがないが、この「システム・インテグレーション」について、とても熱い想いをビジビジ感じ、読む前よりもいっそう、直接話をお聞きしてみたくなった！

受託開発ビジネスはどうなるのか、どうすべきか | Peatix

・

・

・

あ！

「納品をなくせばうまくいく」はまだブログに書いてなかった！(´・ω・｀)

書いたつもりになってた自分・・・orz

転職おめでとう！

酒飲んだ後ブログ書くのは初めてか？

ま、書きたくて仕方ないので、書くことにする。結構個人的な想い満載だが、それほど本当に今宵は嬉しい夜だったから。

同士が転職すると、さっき聞いた。

失礼ながらちょっと意外だったが、でも本人が自分の実力を試したい環境を見つけられたことはとてもいいことで、素直に嬉しい。目の前を考えると同士が辞めるというのは寂しいけど、これは健全なことだし、そういう判断を出来た同士をオレは尊敬する。

オレは新卒からとあるSIerにずーっといる訳で、去年ぐらいから、社外に出ての活動を本格化させ、ブログもはじめ、twitterもちゃんと見るようになり、有志のアジャイル系社内コミュニティがちょうど１周年になるいま、このタイミングだったから余計に衝撃も大きい訳だが、正直な話。

でも、オレは会社に雇われているけど飼われている訳ではないし、SI崩壊とかSIの闇が騒がれる今だからこそ、オレは今の環境でチャレンジしたいことがある。ディフェンシブという言葉がぴったりなSIビジネスだが、受託開発の喜びは言葉にできない素晴らしいものだし、だからこそ今の環境を変える試みに引き続きチャレンジし続けたいとおもっている。その同士だった親友が自分の人生の岐路を判断して新しい道に進むことは素晴らしいことで、お世辞でもなくオレは応援している。

「夢」を叶えるのは会社というステージではなくで、「人生」というステージの上である！！

俺の中で いっしょに仕事してみたいマネージャ一位は10年前から変わらず @ryohei_nakazawa だ。その機会がないのが残念でならない。 / @ryohei_nakazawa: チームメンバが活き活きしている、あの感動を思い出した #natsumiB3

— ますごん (@ymasuda_) 2014, 8月 1

だから、お互いの環境は変わっても、「夢」の実現はできる。

そうだろ？

一緒に仕事をすることもその「夢」の一部かな〜

嬉しい言葉をありがとう。

お互い頑張ろう(・∀・)!!

夏サミ2014に行ってきました！

※講演資料やまとめへのリンク先を更新（2014/8/2）

今日は月末恒例、パケット上限での帯域制限を喰らっている日。こんな日はwifi環境が整備されているところがﾏｼﾞﾃﾞ天国ﾃﾞｽ!!(・∀・)　東京五輪といわず、wifi充実はもっともっと加速度的に進んでほしいな。

さて、今日は久しぶりに御茶ノ水に行ってきました。

初めての夏サミ参加でテンション真夏。

　Developers Summit 2014 Summer [Enterprise] #natsumi

SI終末論を良く耳にする今日この頃。

この問題は長らく言われ続けていて、アジャイル開発とともにユーザー企業の内製化は進み、クラウドの普及で自前システム不要からの情報システム部門不要や、納品のない受託開発の成功とか、色々な話がごった煮で如何せん整理するのが大変。

でも、次のSIの形を模索する自分としては、得るもの多く、とても刺激になる話が多かった１日でした。

　受託開発の喜び

今日の一番の収穫は、受託開発ならではの「喜び」に気付き直せたこと。

これは、[B-3]セッションGxP・商工リサーチの事例、および[B-5]セッション倉貫さんのお話がメインから。

商工リサーチの300人月の再構築では、８割ウォーターフォールで作って、残り２割をアジャイル型でテスト・改善の繰り返しという進め方で成功したということだが、（GxPの鈴木さん・和智さんが）プレゼン内容でフォーカスしていたのは、受託開発として最も基本的な顧客とSIerの「信頼関係」部分。確かに、顧客と二人三脚でプロジェクトを進めるってSIer側としては理想的で、本当にそれが出来た（お客さんが認めてくれた）時の喜びは、言葉にできないぐらい感動的なもの。

倉貫さんは「納品の無い受託開発」のダイジェスト話の中で、ネタを振りまきながらソフトウェア開発がナレッジワークであることや働くエンジニアの満足度を大事にしながら、その上で、顧客から信頼してもらえて仕事が続くという受託開発ならではの「喜び」に言及されていた。倉貫さんの初リアルプレゼン、沢山笑わせて頂きました(・∀・)

この２点は、顧客向けの受託開発プロジェクトを少し離れている自分に、大切なものを思い出させてくれた。共通するのは顧客とシステムサイドが同じ目的を目指している形。これらの話を聞いてて、自分の中では、いくつかのプロジェクトの場面がスナップショット的にリフレイン。お客さんと一緒にリリースを喜び、道玄坂を転げ落ちてスーツを破いたあの日や、納品日のチーム解散のふりかえりで、メンバ１２人とお互い涙を流したあの日とか、色々なシーンがリアルに甦ってきて、１人で遠い眼をしてしまった・・・

技術がどんどん進歩し、新しいビジネスモデルができたり、働く場所がオフィスだけでなくなったり、仲間との国境がなくなったり・・・・そんな劇的な変化が起きている今だからこそ、B2Cでグロースハックもいいけど、「人と人」が「感動」できる『受託開発』はやっぱりいいな、と。

SIの形が変わっても、この「喜び」は変わらないのではないでしょうか。

とても大きなヒントを頂きました。

あ、あと、世間様からSIerは「業者さん』って呼ばれないようにもっと変わりたいぞ

　ほかにも沢山ありました 

 

■セッション S-1

　「クラウド時代の情シスのロールモデルとは？」

     夏サミ2014【B-1】KDDIのAgile&DevOpsへの挑戦と戦果 #natsumiB1 - Togetterまとめ

 

Publickey新野さん

・IT予算の７割が現行システムの運用・維持

　残り３割で新規だが、予算捻出が難しいのが現実

　　　→　クラウドで「早く・安く・簡単に」

　　　→　運用維持費用を圧縮して、新規分へ投資　

・日交のタクシー配車アプリ（社長直轄プロジェクト）、情シス２人で内製したら大ヒットして、アプリで４０億売り上げるまでに

・スシロー、情シス５人、ビッグデータ解析で廃棄75%削減（ビジネスモデル的に売れ残りの削減がポイント、店長の勘をやめる）

・ハンズラボ、POS端末をwebブラウザで作りたいということでGoogleエンジニアを紹介した

 

ハンズラボ長谷川さん

・情シスだからこそ、金を使わないで既存インフラでマーケティング

・やるなら新しいことの方が楽しい　やる気があれば情シスでスタートアップできる話

・情シスの人数、15人中2人が開発だったが、３年で26人中21人に。結果、ITコストにおける保守委託料は半分に（ITコストトータルでも微減）

 

■セッション A-1　「情シス/SIerは本当に不要なのだろうか？」

パブリック・クラウド・えバンジェリスト：co-meeting 吉田パクえ

夏サミ2014【A-1】情シス/SIerは本当に「不要」なのだろうか？ #natsumiA1 - Togetterまとめ

・パブリッククラウド（フロント）とプライベートクラウド（データとかセキュアな）の使い分け

・沢山のアズアサービス、言葉の定義をする意味無し

・クラウドのサプライチェーン、入れ子構造、下のレイヤー担保できない、まだ訴訟無し

・情シスがサプライヤになれる時代

・利用者は何を求めているのか？

　　→　ユーザーはSaaSを選択するか内製するか

　　→　IaaSやPaaSで足りない部分の調整役にニーズあり

　　→　内製でもビジネスとの調整役必要

　　　　→　★今後のSIerの生き残る道のひとつ★

・CROWYをサービスとして展開しているが、外部進化に付いていけなくなり捨てようと思った。でも捨てる前にGitHubにソースを上げてみたら神君臨！しかも複数回！（これ、マジらしいっす〜）

・ソフトウェアの学習コストは圧倒的に下がった事実

　　→　これをどう捉えるか？とても重要なポイントだ！

■セッション B-2「継続的デリバリーへ！クラウドによってアプリケーション開発はどう変わるのか？」

IBM江木さん

夏サミ2014【B-2】継続的デリバリーへ！～クラウドによってアプリケーション開発はどう変わるのか？～ #natsumiB2 - Togetterまとめ

・IBM製品”Bluemix”のデモ、チケット管理、構成管理、進捗管理の環境がすぐにつくれる時代

・Blue-Green Deployment

・Canaly Deplpyment

・アジャイル開発する道具立てがクラウドで揃ってきました

 

■セッション B-5「Enterprise TED」

あのTEDとは関係ない!?ひとり15分程度のプレゼン。

夏サミ2014【B-5】Enterprise TED #natsumiB5 - Togetterまとめ

伊藤さん（KAIZEN platform）

・技術的課題は実は難しくない（なぜなら正解があるから）

　でも、人と人のコミュニケーションには正解が無い（こっちのほうが難しい）

・B2BもB2Cも実は同じである

 

ネクストスケープ上坂さん「なぜ新しい取り組みは上手く行かないのか」

・アジャイルで効果を出したいならつまみ食いではダメ

　　→　手法が生まれた背景を知れ！

 

ネクスト倉林さん「らしく」ハタラコウ　

・HOME’sの話、元々5人のエンジニアだったが、今は200人で開発

・3つのルール（組織、インナー、アウター）

 

NTTデータ 佐藤さん「Enterprise × コミュニケーション」

・５年社内でコミュニティをやってみた話

・ITアーキテクトのコミュニティ

　　→　横のつながりで組織のたて組織（硬直化）を壊すイメージ

　　→　terasolunaやhadoopの技術者同士のつながり（提供側と利用側）

　　　　→　社内だから失敗事例も言いやすい

　　　　→　発表は公募制

 

 

 

　最後に

[B-1]のKDDIの話は聞けずに残念。でも色んな方のTweetに感謝。まとめでみてます。

  夏サミ2014【B-1】KDDIのAgile&DevOpsへの挑戦と戦果 #natsumiB1 - Togetterまとめ

あと、Twitterやブログで知っている有名な方々と名刺交換とかご挨拶できたのも、本日の収穫♪♪♪

SNSやブログでも今後ともヨロシクお願いしますm(_ _)m

これは、モノにつられて・・・頂いちゃった本。パクえ吉田さんありがとうございます！　もっと勉強しますw

しかし、中指が使えないと、タイピングが遅くてイライラ・・・　しかも包帯グルグルだから、タッチパッドでのスクロールが人差し指と薬指は厳ちぃぃぃorz

明日の仕事が思いやられるわ😭

　その他リンク集

・講演資料とTogetterまとめ

　　エンタープライズIT版のデブサミ「夏サミ2014」開催、講演関連資料のまとめ：CodeZine

・参加した他の方の記事・ブログ

夏サミ2014で確認したユーザー企業と開発ベンダーの姿 #devsumi #natsumi #natsumiB1 #natsumiB3

夏サミ 2014 『KDDIのAgile&DevOpsへの挑戦と戦果』聴講メモ #natsumi - べにやまぶろぐ

Agile Conference Tokyo 2014 に行ってきた!!

梅雨明け、そして熱帯夜・・・　(；´∀｀)ﾌｩ

皆様いかがお過ごしですか？(；´∀｀)ﾌｩ

先日久しぶりに外部セミナーに行ってきました。品川シーサイドは１年ぶりかな。しかし、朝から疲れた〜　あの通勤ピーク帯、ここのたった一駅移動で消耗するHPはマジ計り知れず・・・なんか去年よりも人が更に増えたような・・・(；´Д｀)ﾌｩ

 ※ってこの写真、全然人がいないやん!!

先月のAgile Japan は残念ながら業務で行けなかったのですが、今回は抽選に当たって（？）行くことができました。

Agile Conference Tokyo 2014という、テクノロジックアート社主催。

去年は「KANBAN」がテーマで、今年は「継続的デリバリーとDevOps」がテーマ。

特にThoughtWorks社のお二人の話が面白かった！

　プログラム

１．エンタープライズDevOps: 開発とIT運用間の障壁を取り除くには

　　　ー　Jez Humble氏　(ThoughtWorks Inc.)

２．アジャイルなプロダクト計画策定と分析手法

　　　ー　藤井 拓氏　(株式会社 オージス総研)

３．アジャイル開発を支えるコード品質とリスク解析

　　　ー　JUNG Sang Hun氏　(コベリティジャパン 株式会社)

４．Thoughtworks社による海外導入事例

　　　ー　Xiaoshen Wang氏　(ThoughtWorks Inc.)

５．継続的デリバリーの実現へ！

　　　ー　江木 典之氏　(日本IBM)

６．JBoss BRMSとアジャイルプロセスの親和性

　　　ー　英 繁雄氏　(日立ソリューションズ)

　　　ー　岡下 浩明氏　(RedHat)

　気になったポイント

• DevOpsの言葉の定義が大分、広義になってきたようである。ソフトウェアの開発と運用の障壁を取っ払っていきましょいって元々言っていたが（狭義のDevOps）、ビジネスとITの融合まで含んでDevOpsという言い方をほとんどの人がしていた。ま、確かにそれはそうなんだけど、コンテキストによってさす範囲の意味が変わってくるから気をつけないとね。（※後述）

• オーストラリアの保険会社における分散アジャイル開発（thoughtworks事例）は、ソフトウェア開発の事例というよりも、業務とITの融合を含めた新しいビジネス創出の事例。例えば、スーパーマーケットでバーコードをスマホでスキャンし、その場でPayしてレジに並ぶ必要がないアイディアとか、あ、これは保険会社の商品ではないか。言葉は違えどリーンスタートアップの思想に考え方は近い。ITでマーケティングの常識が変わってきた話とも取れた。

• Jez Humble氏(Continuous Deliveryの著者)曰く、アジャイル開発はまだまだ、ウォーター・スクラム・フォール開発である、との認識のようだ。つまり、本質的なアジャイル開発はまだまだってこと？

• 継続的デリバリーはCI等の自動化必須だが、それは作業効率化だけでなく、どれだけ効果的に学べるか（Feedbackを受けることができるか）に繋がってくる。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

　DevOpsって何だ？

今日のテーマはDevOps（と継続的デリバリー）。そもそもDevOpsってなんだっけ？

前にも書いたように「アジャイル」って言葉も同じことが言えるのだが、「アジャイル開発」がだんだん、ビジネスや経営レベルを含めた広義な意味でもつかわれるようになったように、DevOpsにも同じことが言えるというのが、今日、複数の登壇者に共通していえることのひとつ。

つまり、開発だけでなくて、運用も含めて、（DevelopmentとOperationの）障壁を無くしてうまくやりましょって狭義のDevOpsが、ITと製品戦略・マーケティングとビジネスモデルそのもの全部をうまく回していきましょって広義になってきたってことを再認識した訳です。

ん？それってリーンスタートアップじゃん？って言う人がいても同じで、結局、「広義のアジャイル」「広義のDevOps」「リーンスタートアップ」の意味することが近づいてきちゃって、人によってはますます混乱する・・・的な。

プログラマのためのリーン・スタートアップ入門（最終回）：リーン・スタートアップの実践――ソニックガーデンは2度ピボットした - ＠IT

にもあるとおり、

リーンスタートアップ　＝　マーケティング　＋　DevOps（開発はアジャイル） 

 という整理が一番しっくりくるので良いのですが、この辺の言葉の定義の境目がもう曖昧になってきたってことですね！

　まとめ

今回のセミナーでもそうでしたが、自動テスト〜継続的インテグレーション〜継続的デリバリーをまとめている絵がいろいろありますが、どれも間違っていないとはおもうのですが、まとめる人の意図によって（若干）異なる。当然。

DevOps、アジャイル、リーンスタートアップ・・・同じ視点に立てばどれも考え方は共通であるため、そのベースを共有した上で、議論すれば言葉に惑わされることはないかな、なんて思いました。

あ、今月は夏サミにもいけそう♪（　＾ω＾）ﾜｸﾜｸ

 （おまけ）

会場で質問できなかったので、Jez Humble氏にTwitterで質問したら、凄いスピードでレスが帰ってきたw

Feedbackが早いって素敵☆

アジャイルって何だ？ 〜今だからもう一度整理し直してみる〜

［2014/5/29］スライド内の誤字を修正し再UP、一部追記

１ヶ月ぶりの投稿です・・・

サボり癖がついてしまうとホント悪循環。この１ヶ月間、書きかけた記事３本（未だ編集中）。これは本当にいかん！

よし、言い訳はしない。

「今回こそは！」必ず書き切る。

今日のテーマは、「アジャイル」「Agile」という言葉・単語・keyword。

　提起

自分が初めて「アジャイル開発」を知って、たぶん１０年ちょっとが過ぎた。

最初はXPのプラクティスやプロジェクトファシリテーション的なことを、自チームに取り込んでみたり、であったが、当時社内（自チーム外）でアジャイルの話をすることは殆どなかった（ような気がする）。

時は経ち、「アジャイル開発」はソフトウェア製品開発では当たり前となり、２、３年前ぐらいから徐々に、企業向け大規模SIの領域にも「アジャイル」は徐々に浸透してきた。そして最近では、結局「アジャイル」って何なの？という声を良く聞くようになってきた。昨年「アジャイル」と銘打つ社内コミュニティを立ち上げたことも影響あるのかもしれない。

特に今、自分は、「アジャイル」を整理して説明することが求められているケースが増えつつある。

確かに、記事タイトルやプレゼン資料で踊る「アジャイル」「Agile」というkeywordにはいろいろな意味が含まれている。

客観的に見ながら結局、何なの？という意見が出るのも分かる。

そんな今だからこそ、自分なりに整理してみる必要を感じた。

　２つの軸

整理すると２つの軸がある。よこ軸とたて軸。

絵にするとこんな感じ。

ざっくり言うと・・・

[よこ軸]

　 アジャイル開発におけるコミュニケーション面とエンジニアリング面

　これはシステム開発・ソフトウェア開発のシーンにおいて、分野が異なる。しかも「アジャイル開発」とは言わず「アジャイル」と言うことが多いので、次の縦軸を踏まえると、聞き手によっては混乱を招くことがある。

[たて軸]

　変化の中で継続的に成長するという、ビジネスの本質的な側面

　これはレイヤーが異なる。マーケティング的な意味も含めた組織活動そのもの、と、（プロジェクト・チームの）開発活動に限定した使い方である。後者(a)についてのみ、よこ軸がある。

「グロースハッカー」に象徴される、昨今のビジネス成果とエンジニアリングを密接に考えなければいけない傾向が、このレイヤーの混乱も招くことがある。

ちなみに、これは平鍋氏の言うアジャイルのライトウィング・レフトウィングにも繋がっている。というかヒントにさせていただいた。パクリとも言う。（しかし、この整理は素晴らしい！！初めて見たときマジ感動した！！）

［2014/5/29］追記 

それからアジャイル開発とフォーターフォール開発の違いについては倉貫氏がblogで分かりやすく解説されている。

アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!

以下、先日の勉強会で発表した資料。

［2014/5/29］スライド内の誤字を修正し再UP

　まとめ

個別のプラクティスをさして「アジャイル」とも呼ぶし、もっと広い範囲で「アジャイル」と呼ぶこともあり、その意味はコンテキストによって微妙に変わってくる。

想像してほしい。コミュニケーション上で、お互いの認識がkeywordレベルで噛み合っていないときほど、辛いことが多くないだろうか。

おそらく、そんな時の会話では、言葉の意味する範囲を自分の都合のいいように変えながら話していることが多いのではないだろうか。（自戒を込めて・・・）

しかし、言葉の定義という意味では、そんなものなのかもしれない。

新しい言葉というのはどれもそういう側面を持っているし、新しければ新しいほど、keywordの定義も発展途上であることがおおく、このような整理を都度都度繰り返していかなければいけないだろう。

投資家、経営陣、コンシュマー・・・。

お金をPayする人が「アジャイル」「Agile」を理解しているとは限らない。むしろ、このような方の専門はシステム開発・ソフトウェア開発ではないことが多い。投資してもらうためにも説明責任はこちらにある。説明して納得してもらえなければ、どんなに素晴らしいチャレンジでも投資してもらえないのだから・・・

よし、書き切ったwww