転職おめでとう！

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

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

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

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

オレは新卒からとある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

第4回Quesにいってきた

オバマ大領領を接待となると、銀座の寿司屋も三ツ星なのですね。うらやま。

さてさて今回は、初めてTwitterで誘われたイベントに行ってきました。

その名も第4回Ques（イケテルQAエンジニアの集い）＠渋谷ヒカリエDeNA社。 

　　第4回Ques : ATND

　　Ques

@ryohei_nakazawa はじめましてQues運営スタッフです。4/22に第4回開催決定いたしましたので、是非ご参加おまちしています！ http://t.co/yn2Fx0e31M

— イケテルQAエンジニアの集い Ques (@Ques_staff) March 14, 2014

なんてお誘い頂いちゃったり。

中の方、ありがとうございました！

現在の業務が、ソフトウェアの品質保証にモロ近いところにいるということから、自分がイケテルかどうか確認しにいったのですが・・・

自分があの集まりでおそらく唯一のネクタイキャラだったため、ある意味、イケテなかったかもorz

確かに自分は、ちょっと前までQAとQCの違いを人に説明することもできず、基本的にはプロセスベースの品質保証の方がメインなので、ちょっと場違いな感も。

でも、面白い話が沢山聞けて、交流会でも普段お会いできない方々と情報交換できて、大満足♪♪♪

テーマ：テスト自動化について

講演内容：●機械学習分野におけるテストの自動化（小宮氏、ALBERT）

　　　　　●Mobageオープンプラットフォームでのテスト自動化（中川氏DeNA） 

■機械学習分野におけるテストの自動化

・機械学習の応用例としては、AmazonのReccomendやスパムメールフィルタリング。

・機械学習アルゴリズムのアプトプット（テスト結果）が期待する結果と同じかどうかを検証するのが難しい。（＝期待する結果を定義しにくい）

　　→　codeレベルのテストの重要性

・レイヤーに分けてテストするとか、機械学習機能ソフトとはいえ、普通のソフトウェアのテストと考え方は通じるところ多し。

　　→　機械学習アルゴリズムの検証と、ビジネスロジック検証、End2Endでの機能検証を分けて考えるとか

・自分が目指すのはデータサイエンティストではないものの、そっち系の勉強がまだまだ足りないな

■ Mobageオープンプラットフォームでのテスト自動化

・SoftWare Engineer in Testを略してSWET

・SWETグループは、組織として独立したテスト専門部隊（googleのSET＋TEイメージ）

・SWETグループの技術者は各プロジェクトに散って入り込んでいて、朝はプロジェクトのスタンドアップ、昼はSWETのスタンドアップ

・テストを自動化しても、機能が増えれば増えるほどテストコードも増えてくる。そこでCI。

・Webブラウザとスマホブラウザの両方（マルチプラットフォーム）を同じようにテストするため、SeleniumとAppiumを利用し（テストコードの共通化が結構できる）、テスト自動化を実現。

・実機でのテストと、実機レステストは使い分ける。

・SWETグループのモチベーションを保つための工夫。自分たちはエンジニアである。テストをすることが目的ではない。テストはあくまで手段。リリースし続けることに自分たちの価値があるなど。 

2014-04-22 Ques #4 Automation Testing of Mobage Platform from Masaki Nakagawa

最後に。

技術的な話にはだいぶついていけていなかった自分ですが、自分の知っているQAの世界よりも相当広い感じだなーっていうのが一番印象深かったです。

でも、例えばWebサービスに代表される開発がアジャイル的なソフトウェアの品質をどうやって保証（担保）するか、これはとっても大事なテーマであることはわかってるつもり。

第5回もあったら行きたいな〜〜〜(・∀・)

「失敗の本質」を読んで共有・議論してみた

今日の夜は、毎月開催している社内勉強会。

実はMacbook Airでのプレゼンデビュー♪♪♪

いままで自分が知らなかっただけなのですが、keynote（OfficeﾊﾟﾜﾎﾟのMac標準版）のスライドショー機能がホント感動的。単に手元で次スライドも見えて、かつ時間が表示されてるだけなのですが・・・

今回のお題は２つ。後者が自分発表。

　・JUnitアンチパターン

　・ スクラムの起原を追う「失敗の本質」より

そういえば、結果的にみごとアジャイルのライトウィングとレフトウィングになってるじゃないですかwww

いつもに増して、議論は多方面かつノンストップに盛り上がり・・・

まずは発表したスライド。

20140421_「失敗の本質」より from uhe_uhe_uhe

 ちなみに、本を読んだ直後のblogはこちらで、それを共有用にまとめた感じ。

　失敗の本質―日本軍の組織論的研究 - 部屋とアジャイルと私（仮称）

結構みんな食い付きがよく、議論も白熱。

「沈黙は美」とか「あうんの呼吸」とか「水に流す」とか日本人独特のでも脈々と遺伝子に刷り込まれているような文化的に思い当たる節がみんなある模様。たとえば、知識よりも経験ベースで物事を判断しがちで、システム保守プロジェクトなどのドキュメント化もされない秘伝のノウハウが脈々と受け継がれるか、本当にあるある。

ナレッジマネジメントの重要性はは組織の経営側はどこも感じることだろうし、でも知識の集約と再利用には、どこも悩みを抱えていると仮定して、その理由は当時の日本軍にも日本の企業組織にも共通しているという視点は、いろいろと視野を広げる。

ただ、

今回だけの話では、アジャイル開発におけるスクラムとのつながりにはたどり着かず、その点は、自分も含めて消化不要。

今後の継続テーマでもある。

そういえば、今回に限らず、グローバル化というキーワードはいつでもでてくるのだが、その中ではよく「日本と諸外国の違い」が話題に出る。具体的な違いを単純化するのは難しいが、ビジネスとITの今後を考えるうえで、日本の文化や特徴を勉強することはとても価値があるとおもう。

というか、

自分が歴史（特に日本史）大好き人間なだけかもしれないがwww

しかし、また読みたい本がまた増えて、読むペースが追いつかない・・・orz

ソフトを他人に作らせる日本、自分で作る米国

Agile Samurai Base Camp 2014 Re:TDDに参加してきた！

うらら〜。うらら〜。春うらら〜。

今日、日曜日は、渋谷マークシティのCA社（２回目）に行ってきました。

実は１回目は昨年12/8。このblogを始めるきっかけにもなった、感動と、衝撃と、自分も動き出さなきゃ！っていう最高の刺激を頂いた機会であり、はてブやTwitterのプロフ写真も・・・（ry　とにかく個人的にとても想い深いイベントでありまして・・・

とにかく、その刺激がリフレインしまくったそんな一日でした。

※ピザとbeerの交流会もあったり、前回以上にいろいろなお話を聞いたり、質問できたり、満腹♪満腹♪

※この手作り感も大好き!!

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

12/8の最初の記事。

Agile Samurai Base Campに参加してみた - 部屋とアジャイルと私（仮称）

その後、社内勉強会でTDDのサワリを発表したり、すんごいモチベーションもゲッツ。

明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称）

TDDと直接関係ないが、前回もご説明いただいた同じスライドでも、１回目に感じなかったことが、沢山あったこと自体、blogを始めたおかげであり、そんなきっかけを頂けたことを改めてここに感謝♪感謝♪感謝♪

しかも前回に増して、参加者メンバの中でも、TDDを実際にやっている方（チームだったり、個人だったりはさておき）が結構いて、その現場の本音を聞けたのもすごい収穫でした。

自分は、まだまだ、TDDを「分かった気になってしまっていた」ってことに気づかせていただいたのも、とっても良かった。

分かったつもり、一番の自分の悪い癖。

(・A・)ｲｸﾅｲ!! (・A・)ｲｸﾅｲ!! 

うむむ。相変わらず前振り長すぎ・・・orz

～～～～～～～～～～～～～～～～～

■当記事のアジェンダ

（１）今日の自分テーマ

（２）結果サマリ

（３）その他、雑メモ

（４）補足・・・関連リンク集とか

～～～～～～～～～～～～～～～～～

（１）今日の自分テーマ

事前に考えていた、今日ノ場で学びたいこと主な５つ

●仕様のテストと実装のテストの件。実装詳細をテストする必要はないとある。でも不安をテストするともある。自分が前回一番理解できなかった（勘違いしてるっぽいところ）

●レガシーコード改善から始めるTDDに取り組む件（これが一番自分の周辺にハマりそう）

●テスト粒度（テストコードのメンテナンスと、テストコードの資産価値、小さいテストを積み上げてEnd2Endのテスト、どこまでがTDDなのか）

 

●三種類のテスト（Developer、QA、Customer）

 

●TDD三原則。TDD実践においてどこまで厳格に（原理的に）したほうがいいのかの加減を含めて。

（２）感想サマリ

※自分テーマと順不同

●テストを必ず先に書かなければいけない訳ではない。そこにテストコードが存在することが重要。あまり原理的になる必要はなく、その辺の加減・工夫がいろいろな現場でいろいろ方にノウハウあり、自分なりにTDDをうまく使えるようになることが一番大事だろう。

●TDDはプログラミングの一部であり、TDDだけで品質が保証される（担保される）わけではない。TDDでソースもエンジニア自身も「健康に」というメッセージは非常に深い！

●仕様のテストこそ、テストコードとして価値がある。実装のテストはリファクタリングすることでテストコードが崩れてしまうので、積極的に書くのではなく、でも不安がある場合は、一歩一歩階段を上るという意味でも実装を確認する。（＝思った通りに動くことを確認する＝つまり不安をテストする＝TDD）

※「仕様のテスト」と「実装のテスト」についての参考：

「実装をテストする」とは？ - ふぃーるどのーつ

●エンジニアのスキルアップには、フィードバックが細かければ細かいほど良い。TDDのサイクルは小さく小さく回したほうがいい。（でも自信があるときは大股で走ってもよく、でも一歩一歩確認しながら、赤くして自信があってたことを確認する癖をつける）

●自身のモチベーションを保つための工夫は人それぞれ。ひとりから始められるのもTDDのいいところ。こういう社外勉強会にも今後積極的に参加していきたい！

（３）その他、雑メモ

・チームで考えるワークショップいかにボールにチーム全員が触るか（19秒→3秒→0.9秒）

・今年後半ぐらいに「テスト駆動開発入門」が本屋に並ぶかも

・リファクタリングがし難い環境が身近にある・・・動けばいいじゃん。壊したくない。という堕落と恐怖（グサっ！）

・必ずテストコードから書かなくてもよい。少し実装してからテストから書いてみるのもあり。

・リファクタリングは、気づいたときにすぐにやったほうがいい（溜まれば溜まるほどリファクタリングに時間がかかり、理解がないとそんな時間はモラエナイ）ただし、少し先にどのようにリファクタリングすればいいかの答えが見つかりそうなときは一時的にtodoリストに書いておくのもあり

・テストコードが無い現場にて、TDDを普及させていくため、まず最初、まずは依存の少ない部分を狙い撃ちして、テストコードをつくりはじめるとよい。また、その際は大きな仕様のどんどん荒いテストから作り始めて、テストして、カバレッジ範囲を少しづつ広げていくことを繰り返していくとよい

・JUnitの場合、テストコードにGroovyを使うとよい。（これは良いことを聞いた〜）JUnit実践入門「テストフィクスチャ」をあとで見る。

・オフショアでTDD（というかアジャイルプロセスでの開発）を導入している事例。交流会で「アドバイスください」と図々しく・・・、でも、そのチームだけにMacを与えて、周囲が憧れる開発環境のチームをつくるとよい。実は投資額としてはちょっとしたもの。何よりMacでの開発は良いyo！とかナルホドー 

・新人研修でテストコードを書かせて、TDD実践のハードルを下げて組織的に取り組む姿とか眩し（真似したいけどなぁぁぁ）

・レガシーコードにおけるEdit & Pray。ソースを修正して、祈りながらリリース。（ドキっ）

・一人からでも始められるTDD

・レガシーコードの不具合修正で、TDDをつかう（これだけが正解ではないが有効な事例あり）

     →　レガシーコード改善で、自分のTDD力をあげる！！

・スプラウトメソッド（TDDしたい部分をくくりだすのはIDEまかせ）

・まずは手元（ローカル）でJenkinsを回して、テストして、ドヤ顔www

・DBをつかったテストをどうするのか？

　　→　DB環境を毎回つくり直すのが理想（ただ現実問題、そう簡単にはいかない）

　　→　まずは自分でSQLでテストデータを突っ込んで、DBを使った部分のテストを地道に

　　→　周りを巻き込み、新しいDB環境をたててDBUnitでデータを突っ込んでテスト実施

・テストを書きながら進めることで、安全に前にすすめる

・TDD→BDD→ATDDとテスト範囲を広くしていくイメージ・・・テスト粒度はユニットテスト→結合テスト→システムテストに近いイメージ

・プロダクションコードよりもテストコードの方が高いスキルを要求されるとおもう

　　→　テストやり過ぎは疲れてしまうのでハードル低く

　　→　必要最小限のテストをテストコード化して、そこから膨らませていくイメージ

・TDDを組織に文化として根付かせるためのアドバイス

　　→　テストを書いたことを褒める（ハードルを下げる）：高橋さん

　　→　社内勉強会を開催して各自が勉強したことをLTしあったり：中川さん

　　→　ベースキャンプ（ここ）は帰ってくるところ　うまく行っても行かなくても戻ってくれば良い：有野さん

（４）補足・・・関連リンク集とか

Agile Samurai Base Camp 2014 Re:TDD #agilesamurai - Togetterまとめ

Agile Samurai Base Camp 2014 Re:TDDに参加してきました - 個人的なまとめ

Agile Samurai Base Camp Re:TDD に行ってきた！ - 終電23時15分って早くね？

アジャイルサムライ TDDトラック行ってきた - まっつんの日記

Agile Samurai Base Camp 2014 Re:TDD｜ラブリー東京♡気まぐれコリアンの東京日記

※随時追記ヨテイ（しかしみんなblogうp早〜！ ）

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

まだまだ整理が必要で混乱もしている。

自分で手を動かしながら、体現しつつ、少しづつでも前に進みたい。

いきなりTDDというおっきな相手に立ち向かうのではなく、分解して１体づつ倒していく・・・そんなTDDのイメージで、これからもTDDを続けていこう！！

余談

インセプションデッキの２回目もあるらしいよ〜〜〜〜っ (￣ー￣)ﾆﾔﾘ