「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
を読んだ。実は１ヶ月以上も前だったが、実はブログを書いていないことにさっき気付く。
8/27のイベントに先立ち、事前に自分の頭の中を整理しておきましょうって感じの２本目記事。
１本目はこちら。
システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか? - 部屋とアジャイルと私（仮称）
さて、Amazonでベストセラーになっているとも聞く「納品をなくせば・・・」だが、元々はソニックガーデン倉貫氏のブログをちょくちょく見ていたので、待ちに待ってた書籍化であった。著者である倉貫氏は大手SIer(TIS)に居ただけあってSIの実態をちゃんと把握されていて、いつも説得力のある文章でまとめられているが、今回は書籍ということでまたいつも違う新鮮さもあった。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
サマリ
一括請負の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はどう生き残ればいいか?
- 作者: 斎藤昌義
- 出版社/メーカー: 技術評論社
- 発売日: 2014/06/05
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
サマリ
ビジネス環境変化に対して「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
Publickey新野さん
・IT予算の７割が現行システムの運用・維持
残り３割で新規だが、予算捻出が難しいのが現実
→ クラウドで「早く・安く・簡単に」
→ 運用維持費用を圧縮して、新規分へ投資
・日交のタクシー配車アプリ（社長直轄プロジェクト）、情シス２人で内製したら大ヒットして、アプリで４０億売り上げるまでに
・スシロー、情シス５人、ビッグデータ解析で廃棄75%削減（ビジネスモデル的に売れ残りの削減がポイント、店長の勘をやめる）
・ハンズラボ、POS端末をwebブラウザで作りたいということでGoogleエンジニアを紹介した
ハンズラボ長谷川さん
・情シスだからこそ、金を使わないで既存インフラでマーケティング
・やるなら新しいことの方が楽しい やる気があれば情シスでスタートアップできる話
・情シスの人数、15人中2人が開発だったが、３年で26人中21人に。結果、ITコストにおける保守委託料は半分に（ITコストトータルでも微減）
■セッション A-1 「情シス/SIerは本当に不要なのだろうか？」
パブリック・クラウド・えバンジェリスト：co-meeting 吉田パクえ
・パブリッククラウド（フロント）とプライベートクラウド（データとかセキュアな）の使い分け
・沢山のアズアサービス、言葉の定義をする意味無し
・情シスがサプライヤになれる時代
・利用者は何を求めているのか？
→ ユーザーはSaaSを選択するか内製するか
→ IaaSやPaaSで足りない部分の調整役にニーズあり
→ 内製でもビジネスとの調整役必要
→ ★今後のSIerの生き残る道のひとつ★
・ソフトウェアの学習コストは圧倒的に下がった事実
→ これをどう捉えるか？とても重要なポイントだ！
■セッション B-2「継続的デリバリーへ！クラウドによってアプリケーション開発はどう変わるのか？」
■セッション B-5「Enterprise TED」
あのTEDとは関係ない!?ひとり15分程度のプレゼン。
伊藤さん（KAIZEN platform）
・技術的課題は実は難しくない（なぜなら正解があるから）
でも、人と人のコミュニケーションには正解が無い（こっちのほうが難しい）
・B2BもB2Cも実は同じである
ネクストスケープ上坂さん「なぜ新しい取り組みは上手く行かないのか」
・アジャイルで効果を出したいならつまみ食いではダメ
→ 手法が生まれた背景を知れ！
ネクスト倉林さん「らしく」ハタラコウ
・HOME’sの話、元々5人のエンジニアだったが、今は200人で開発
・3つのルール（組織、インナー、アウター）
NTTデータ 佐藤さん「Enterprise × コミュニケーション」
最後に
[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)
ー 英 繁雄氏 (日立ソリューションズ)
ー 岡下 浩明氏 (RedHat)
気になったポイント
- DevOpsの言葉の定義が大分、広義になってきたようである。ソフトウェアの開発と運用の障壁を取っ払っていきましょいって元々言っていたが（狭義のDevOps）、ビジネスとITの融合まで含んでDevOpsという言い方をほとんどの人がしていた。ま、確かにそれはそうなんだけど、コンテキストによってさす範囲の意味が変わってくるから気をつけないとね。（※後述）
- オーストラリアの保険会社における分散アジャイル開発（thoughtworks事例）は、ソフトウェア開発の事例というよりも、業務とITの融合を含めた新しいビジネス創出の事例。例えば、スーパーマーケットでバーコードをスマホでスキャンし、その場でPayしてレジに並ぶ必要がないアイディアとか、あ、これは保険会社の商品ではないか。言葉は違えどリーンスタートアップの思想に考え方は近い。ITでマーケティングの常識が変わってきた話とも取れた。
- Jez Humble氏(Continuous Deliveryの著者)曰く、アジャイル開発はまだまだ、ウォーター・スクラム・フォール開発である、との認識のようだ。つまり、本質的なアジャイル開発はまだまだってこと？
- 継続的デリバリーはCI等の自動化必須だが、それは作業効率化だけでなく、どれだけ効果的に学べるか（Feedbackを受けることができるか）に繋がってくる。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (51件) を見る
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
第4回Quesにいってきた
オバマ大領領を接待となると、銀座の寿司屋も三ツ星なのですね。うらやま。
さてさて今回は、初めてTwitterで誘われたイベントに行ってきました。
その名も第4回Ques（イケテルQAエンジニアの集い）＠渋谷ヒカリエDeNA社。
@ryohei_nakazawa はじめましてQues運営スタッフです。4/22に第4回開催決定いたしましたので、是非ご参加おまちしています！ http://t.co/yn2Fx0e31M
— イケテルQAエンジニアの集い Ques (@Ques_staff) March 14, 2014なんてお誘い頂いちゃったり。
中の方、ありがとうございました！
現在の業務が、ソフトウェアの品質保証にモロ近いところにいるということから、自分がイケテルかどうか確認しにいったのですが・・・
自分があの集まりでおそらく唯一のネクタイキャラだったため、ある意味、イケテなかったかもorz
確かに自分は、ちょっと前までQAとQCの違いを人に説明することもできず、基本的にはプロセスベースの品質保証の方がメインなので、ちょっと場違いな感も。
でも、面白い話が沢山聞けて、交流会でも普段お会いできない方々と情報交換できて、大満足♪♪♪
テーマ：テスト自動化について
講演内容：●機械学習分野におけるテストの自動化（小宮氏、ALBERT）
■機械学習分野におけるテストの自動化
・機械学習の応用例としては、AmazonのReccomendやスパムメールフィルタリング。
・機械学習アルゴリズムのアプトプット（テスト結果）が期待する結果と同じかどうかを検証するのが難しい。（＝期待する結果を定義しにくい）
→ codeレベルのテストの重要性
・レイヤーに分けてテストするとか、機械学習機能ソフトとはいえ、普通のソフトウェアのテストと考え方は通じるところ多し。
→ 機械学習アルゴリズムの検証と、ビジネスロジック検証、End2Endでの機能検証を分けて考えるとか
・自分が目指すのはデータサイエンティストではないものの、そっち系の勉強がまだまだ足りないな
■ Mobageオープンプラットフォームでのテスト自動化
・SoftWare Engineer in Testを略してSWET
・SWETグループは、組織として独立したテスト専門部隊（googleのSET＋TEイメージ）
・SWETグループの技術者は各プロジェクトに散って入り込んでいて、朝はプロジェクトのスタンドアップ、昼はSWETのスタンドアップ
・テストを自動化しても、機能が増えれば増えるほどテストコードも増えてくる。そこでCI。
・Webブラウザとスマホブラウザの両方（マルチプラットフォーム）を同じようにテストするため、SeleniumとAppiumを利用し（テストコードの共通化が結構できる）、テスト自動化を実現。
・実機でのテストと、実機レステストは使い分ける。
・SWETグループのモチベーションを保つための工夫。自分たちはエンジニアである。テストをすることが目的ではない。テストはあくまで手段。リリースし続けることに自分たちの価値があるなど。
最後に。
技術的な話にはだいぶついていけていなかった自分ですが、自分の知っているQAの世界よりも相当広い感じだなーっていうのが一番印象深かったです。
でも、例えばWebサービスに代表される開発がアジャイル的なソフトウェアの品質をどうやって保証（担保）するか、これはとっても大事なテーマであることはわかってるつもり。
第5回もあったら行きたいな〜〜〜(・∀・)
