第2回 Scrum Boot Campに参加して来ました

ここ数ヶ月、社内的に導入を検討していた、Scrumについて理解を深めたいと思い、Scrum Boot Campに参加して来ました。
概要については、@Ryuzeeさんのblogを拝見して頂くのが良いと思います。
http://www.ryuzee.com/contents/blog/4115

私のバックグラウンドは以下の通りです。
・携帯でのオンラインゲームサイトプロジェクト等を担当
・サービスの特性としては、ユーザの方の反応が重要なので、機能を細分化して、いち早くリリースを実施
　例えば、SNSにていいね！機能を導入といった場合でも、当初は単純にボタン押下機能だけをリリースして、次にいいね！獲得数でのインセンティブ付与機能をリリース等
・開発サイクルの特性としては、小規模なプログラムリリースを含めると、基本週1回のリリースタイミングを設定。現実的には、週3回に近い。
　Scrumに近いとも言えますが、サイクルの早いウォーターフォール開発であるとは思います。
・デイリースクラム（朝会）やタスクボード等は活用済み

問題意識は以下の通りです。
・受託開発の場合、顧客にどう理解を得ることが可能なのか？
・チームメンバーがどう実践してみようというモチベーションとなるのか？

■10:00〜 概要と理論 @kawagutiさん
・Scrumにおいて重要な要素は、「信頼」、「経験主義」、「自己組織化」
・必要とされるリーダーシップの特性としては、サーバント（メイド？）リーダーシップ
・タスクボードの中で、ピンクの付箋紙は、予定外のタスクを示す
・スプリント計画には時間を掛ける
（感想）
・受講者の方からは、スプリントタイミングと、リリースタイミングの調整について等、問題意識の高い質問が多く投げかけられていました。
・同じチームの方々も、理論は学びつつもある中で、実践に踏み込んでいないという方々が大半で問題意識の高い方ばかりでした。そのため、座学とワークショップというBoot Campを選択されたようでした。私も同じです。

■11:30〜 ワークショップ#1 @miholovesqさん
・スクラム提唱者のジェフ･サザーランド氏が提唱されている紙飛行機ゲーム
・チームで時間制限内で様々な制約条件の中、紙飛行機を折り、一定の条件以上の飛行した飛行機の数を競い合うというゲーム
（感想）
・気付きの多いワークショップでした。Scrumの本質が揃っているワークショップというお話がありましたが、その通りだと思います。
・紙飛行機がいかに美しく、かつ、大量に折ることができた（＝品質、生産性）としても、タイミング良く飛ばすこと（＝納品、リリース）が出来ないと意味が無い
・明示されている/されていないに限らず、制約条件や前提条件は疑うべき
・紙を切る人、紙飛行機を折る人、飛ばす人、等がそれぞれが、チーム全体としてボトルネックがどこに存在するのかを発見することが重要

■15:00〜アーティファクト＆ワークショップ#3　@Ryuzeeさん
・ユーザーストーリー、プロダクトバックログ、スプリントバックログについての説明
・ワークショップでは、社内での飲み会予約システムについて、ユーザーストーリー、プロダクトバックログを作成
・プランニングポーカーという手法で、チーム全員でユーザーストーリーを相対見積もり
（感想）
・スプリントバックログについては、ワークショップは時間切れで行われませんでしたが、残念。
・バーンダウンチャートにしても、アナログで行うことは重要と思いました。現在、プロジェクトでもホワイトボードは重宝しています。
・現在、プロジェクトでは見積もりは通常、プロジェクトマネージャーと担当メンバーの2名で行うことが多いですが、チーム全員で行うというは新鮮な経験

■18:00~　懇親会
（感想）
・受講者の方で、実際にプロジェクトにScrumを取り入れてみた、もしくは、取り入れてみた直後の方々からお話を伺う事ができ、貴重なお話を伺えたと思います。今後、Scrumの導入を目指す上で、勇気付けられます。
・その中でも、WFからScrumに開発手法を変えて、チームメンバーのモチベーションが上がった点が良かったというお話は印象的でした。
・Scrumを導入する上で、アサインをプロダクトマネージャーが行わず、チームメンバーが自発的に立候補することでアサインが決定されるというところが、ハードルが高いというお話も。
・講師、スタッフの方とも、Scrumを導入して行く中で、顧客（ステークホルダー）との調整の仕方、開発フェーズの中でのScrumの開始のタイミング等、為になるお話を伺えました。

最後になりますが、講師、スタッフ、受講者の皆さん、お疲れ様でした。大変ありがとうございました。
実践してみないことには、身にならないと思いますので、昨日学んだ事を少しずつでも実践に落とし込んでいきたいと思います。

Android Bazzar and Conference 2011 レポート

・ABC 2011に行ってきました。レポートです。

14:00〜　GREE Platformがソーシャルアプリケーション開発を加速する　GREE　佐藤大介さん
●GREE　Android　SDKによるソーシャルアプリ開発
・GREE SDKの特徴とは、共通UIコンポーネントの提供、AndroidManifest.xmlテンプレートでのActivity遷移定義、拡張Activityクラス、拡張Applicationクラス　→　単なるAPIライブラリではない
・シングルサインオン　phase1 GREEのSNSアプリをSSO認証のハブ化、phase2 SNSアプリ以外でもSSO　→　AcountManagerを使わずに独自実装
・スクショ付きひとこと投稿　SurfaceViewをExtendしたクラスを提供
・AppActivity Activity自体の管理はSDKが担当、Activity内のViewをディベロッパーが担当

●Unity Plugin for GREE Android SDKによるソーシャルアプリ開発
・Unity Plugin for GREE SDK　差異の吸収：スマートフォン開発を簡単に　特徴を活かす：スマートフォン/リッチプラットフォーム
・Unitアプリケーションに対するAPIはUnity Pluginが共通化、スクリプトとして、JS，C#をサポート。Unityのネイティブ連携機能を用いている

（感想）
・mixiはmixiサーバを利用することで、GREEは認証ライブラリの生成をCで行うことで、クレデンシャルの隠蔽を行う等、各社の対応の差異は面白い。この分野は益々進歩を遂げていくのだろう。

15:00〜基調講演　GREE　伊藤直也さん
・エポックメイキングな出来事
　1995　windows95の発売
　2001.9.11 　Traffic過多となったYahoo!が911事件を伝えるために、ビジネスの損得を度外視いしてAkamaiへTrafficを流すことを決断
　2005年頃　Web2.0
　2010年頃　GoogleからFacebookへ
・Web2.0群雄割拠の終わり　終わりは、始まり
・2007年　iPhone、2008年　Android
・時代は、モバイル・ファースト。代表例：Path
・現在のWeb開発技術要素
　JavaScript、HTML5、mongoDB、Ruby、iPhone、Android、Safari/Firefox/Chrome
・第2世代クラウド　heroku、dotCloud　dotCloud + node.jsのような組み合わせ

・instgram　なぜ、社員4名の会社が、700万人ものユーザを獲得するに至ったのか？
　LAMP、オープンソース、チープレボリューション　→　Web2.0
　ソーシャルプラットフォーム、クラウド、スマートフォン　→　今の変化
・2011　デバイス、メディア、グローバリゼーション　
　10年に一度の変化がやってきた
・2011年3月東日本大震災　インターネット、ソーシャルメディアの役割　それを作る我々エンジニアの役割　インターネットを通じて、世界をより良くする
・技術者としての誇りは、高度な技術を与えられることで得るものではなく、自らが使命とする問題領域をより高度な技術基盤で扱う世界に発展させることによって、自ら創造することができる

（感想）
・時代の象徴として、instgramを捉えられていたのが印象的
・エンジニアとしての理念は大切

16:00〜　ngcoreを用いたAndroidアプリケーション開発　DeNA　岸 弘倫さん
●ngCoreの紹介
・ngCoreの特徴　SG開発に最適なAPIの提供、JP/WWのmobageのSocialAPI※WW mobageは近日、Live updating
・ngCoreの利点　JavaScriptのみ、Android環境での更新の容易性、WebView/Canvasを使うより高パフォーマンス、ソーシャル・課金機能、1つのコードでiOS/Android

●ngCoreを使ったSG開発事例について
・忍者ロワイヤル、アクアコレクション、牧場ホッコリーナ
・ngCoreの調査　1ヶ月、仕様検討〜α版　1.5ヶ月　エンジニア2名＋プランナー1.5名、α〜β版　2.5ヶ月　エンジニア2名増員　デバッグ＆ブラッシュアップ
・JavaScriptベースのゲーム開発
　言語が強力　GC、プロトタイプベースのオブジェクト指向、動的型付け、WWWとの連携の容易性、デバッグが容易　alert、FireBugs
・ngCore JS Module設計思想　
　オブジェクト指向の徹底、ModuleシステムはCommonJSModule1.0準拠、一部ESHarmonyの機能も利用可能
・ngCoreを利用してみて
　多解像度対応　アスペクト比の種類　7種類　iOS 2種類
　①アスペクト比を固定して、解像度に合わせてフィット　ex 忍者ロワイヤル
　②解像度に合わせて動的に座標を計算
　③代表的な全ての解像度にレイアウトの設定ファイルを用意

●ngCoreの今後
・現状の課題　制作物のやり取りの効率化、開発の効率化のため最小公倍数的な要素が取り出せないか？
・解決策　nggo、ngbuilder
・その他の取り組み　ngserver　node.jsベース

（感想）
ngCoreの今後として、ngCoreファミリー？については注目かと思う。

Ruby Kaigi 2011 初日レポート

・いつもはPHPを主戦場としていますが、Ruby Kaigi 2011に参加して来ました。初日レポートです。
・公開プロポーズあり、Ruby2.0に向けたRubyコミッターの方々の公開内輪話あり、等、話題豊富な初日でした。
・中学生でコミッターとは凄い。（sora_hさん）

14:40 - 15:40 Ruby を利用した大規模ウェブサービスの開発・運用
・Cookpadの舘野さんによる講演。
・定石をきちんと行うということで、レスポンスを確保しているとのこと。
・”GOODはやらない””Bestのみ行う”ことで、シンプルさを保っている。
・Unitテスト：Functionalテスト：Integrationテストの割合は、3弱：7弱：僅か、であったのが、4:2:4となっている。（比率はスライドの印象です。）
・Continuous Integrationテストを通ったコードのみリリース
・ユーザの反応をみて、取り下げるサービスもある。
RailsのExtensions機能を利用することで、ディレクトリを分けておくことで、取り下げ易い構造となっている。

（感想）
・JavaScriptのテストツールとして紹介されていたCapybara、Continuous Integrationテストで紹介されていたJekinsは使ってみよう。
・RailsのExtensionsは便利そうな機能。サービスが上手く行ったらマージを行うという運用？

14:40 - 15:40 Shipping at the Speed of Life
・GitHubのCorey Donohoeさんの講演。
・2週に1度の新しいサービスの出荷ではスピードが遅いということで、いかに早くリリースを行うかというお話。
・そのための取り組みを数多く紹介
　Nagios（監視）、Redis（NoSQL）、Campfire（Team collaboration ）、Hubot、Haystack、Silverline　

（感想）
・馴染みの薄いツールが数多くあり、後で調べてみよう。

16:10 - 17:10 Issues of Enterprise Rubyist　〜SIerのなかのRubyistが考えるべきこと〜
・アクセンチュアの相澤さんの講演
・SIerの中のRubyistとしてこの3年間に渡って、どのような取り組みを行って来たかということをご紹介。
・1. Rubyの楽しさを社内での認知→2.Rubyが実務にどう役に立つかを開発ツール等の分野で立証→
3.Rubyが活用しやすいビジネス領域として、営業・広報等企業内の中でも攻めの分野を中心に開拓

（感想）
・私も昔SIerに在籍していたので想像が付きますが、一般的には、ネット企業に比べると保守的である企業が多いのではないかと思います。
　その中で、1つずつ課題を解決して着実に成果を出されていて素晴らしい。

書評：ウェブオペレーション

DevOpsカンファレンスで取り上げられていた本書。
サイト運用管理について述べた書籍は数が少ないと思いますので、
開発者の方も運用者の方にも有益な書籍だと思います。

アプリケーションの開発とインフラの運用の緊張関係は、
恐らく様々なサイト運用管理の現場にて存在していることかと思います。
個人的には、16章で述べられているような、バージョン管理、構成管理、監視、等は、有用な策だという実感があります。
問題が発生する度に、何が原因でどう改善していけば良いのか、
組織的に考えて行動するように出来るとなお良いですね。

16章　アジャイルインフラストラクチャ
　1.インフラはアプリケーションである
　2.バージョン管理：正気の土台
　3. 構成管理と自動デプロイ
　4.監視
　5. 開発のライフサイクル・継続的統合・障害復旧
　6.情報ラジエーター
　7.内省的プロセス改善
　8.漸進的な変化とリファクタリング
　9.可能な限りシンプルに
　10.関心の分離
　11.技術的負債
　12.継続的なデプロイ
13. ペア
　 14.流れを管理する

最終章のクックパッドさんの事例も参考になります。
確かに、アプリケーションの開発とインフラの運用間の情報共有の困難さについては、個人的にも試行錯誤しています。
結局は、地道に、定常的な会議体や連絡手段以外に、細かにフェイス・トゥ・フェイスで、
方針検討やレビューの場を確保して、両者で実現を図っていくということがやり方が良いのかも知れません。

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

書評：エリックエヴァンスのドメイン駆動設計

Symfony2勉強会にて取り上げられていた本書。
本書は、概念的な話も多く、読み進めるのが大変でしたが、
内容としては、ドメイン駆動設計についてのバイブルとしての評価に相応しい内容だと思います。

取り入れてみたいと思ったのは、開発サイクルの中でどう設計を進めて行けば
良いかという点についての以下の章。

第15章　蒸留
1.システムの全体的な設計と、設計同士がどう関係するのかを、チームメンバ全員が把握できるようにする
2.ユビキタス言語に入れやすいサイズのコアモデルを識別することで、コミュニケーションを促進する
3. リファクタリングの指針となる。
4. モデルで最も価値がある領域に作業を集中させる
5. アウトソーシングと既製のコンポーネントの利用、その割り当てについて決定する際の指針となる

チームメンバ全員が把握ということでは、レビューワによるレビュー以外に、
チーム内のメンバー全員が参加する場として設計方針レビュー（紹介？）という項目を、
開発プロセスを追加してみていますが、それは良い試みだと思っています。
コアモデルについても、俯瞰図を作成してみる予定です。
実践可能な箇所を取り入れていければ良いですね。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

DevOpsカンファレンスへ参加（するつもりでした）

6/24(金）にDevOpsカンファレンスが開催されました。
http://partake.in/events/b5472f43-5bc0-42d0-9469-dc70d7d95b24
「ウェブサービス運営各社における開発運用のノウハウ共有を目指したカンファレンスです」との事。
最近、邦訳が出版された、ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)もその切掛となっているそうです。
ただ、急遽、予定が入って、残念ながら欠席、、。

publickeyの記事を抜粋させて頂きます。
http://www.publickey1.jp/blog/11/devops.html

運用も目的はシステムの安定稼働ではなく、ビジネスの実現ではないか。
そしてビジネスを進めて行くには変化が必要である（だから開発部門は新機能を作り続けている）。
しかし変化・変更はシステムダウンの原因でもある。どうすればよいか？
変化・変更によるリスクを、ツールと社内文化によって低くすればよいのだ。
そのためには開発部門と運用部門は愛し合わなければならない。

私はオンラインゲームのプロジェクトを担当していますが、
現在は、ディレクション、更新、ユーザーサポート、システム開発、運用が一箇所で協業するという形態を取っています。
（iDCは別となっています。また、運用部門とは、広義には、更新やユーザーサポートも含まれるでしょうか。）
1つのビジネスに向かって対応するという意味では、最適な形態だと思います。
ただ、このままだと全社最適という観点が薄くなるため、技術部隊は全社で横串での部門にも所属しており、クロスファンクショナルな組織構成となっています。
ここ1年でもそれなりに進化を遂げつつはあると思うのですが、
この主題にあるように、開発部門と運用部門が愛し合うというレベルに達しているのかというのは自問自答するところです。

いくつかまとめページを拝見させていただきました。
marqsさんのまとめには各種リンクを貼って頂いています。
http://d.hatena.ne.jp/marqs/20110625/1308973680
前述の書籍も購入してみたので、読んでみたいと思います。

Linkedin、Githubにアカウント登録

Linkedinにアカウント登録してみています。
http://www.linkedin.com/
未だ名前と社名程度の情報しか登録してみていないのですが、
早速コンタクトを取って頂いた方もいました。
（すいません、きちんと後で情報を更新します）

Linkedinは、ユーザの履歴書情報を中心に、求人や商談を行ったり、専門家とコンタクトを行う
ことを目的として作られた、ビジネス向けSNSです。
履歴書情報を公開してしまうという事で、Facebook以上のインパクトがありますね。
ただ、確実に日本でも利用者が多数となりそうなサービスではあります。
詳しくは、Taniguchiさんのエントリーをご覧になって頂くのが良いかと思います。
http://taniyang74.blogspot.com/2011/06/linkedin.html

もう1つは、Githubにアカウント登録してみました。
https://github.com/
Githubとは、自分のリポジトリを公開できるサービスです。
私は日曜プログラマなのですが、機会を見つけて、利用して行きたいと思います。
こちらは、モジログさんのエントリーをご覧になって頂くのが良いかと思います。
http://mojix.org/2011/03/09/github-open-source

いずれにせよ、採用に際して、Linkedin、Githubというのが、
ここ数年後には、少なくともネット業界では、当然のツールとなるかも知れませんね。