カテゴリー: 勉強会

データサイエンスの始め方・データ分析のデザインパターン

日時:2013/08/09

場所:株式会社リクルートテクノロジーズ

Twitterハッシュタグ:#ds2013

Togetter:http://togetter.com/li/548111

Ustream:http://www.ustream.tv/channel/td-channel

イベントページ:データサイエンスの始め方・データ分析のデザインパターン on Zusaar

WEB業界は出席者の半分程度

誰も語らないデータ分析の3つの現実

Video streaming by Ustream

入力データがごみだと結果もゴミ

「データを集める人」と「分析する人」の接点がない

データをあつめるしくみが複雑

インフラ技術が会社のコアでないかぎり、データ基盤の内製は必ずしも正しくない。時間的な意味で

スキーマレスなログデータの収集と集計のためのデザインパターン

Video streaming by Ustream

ログを集めたり集計したりするのは大変である。知り合いがMongoDBでやったが大変だった。

ログをどう集めるのか

ログの設計について

ログデザインパターン

スキーマーレスといえどログ設計はきちんとする

リクルートグループにおける情報活用事例

Hadoop:リサーチ段階として3,4台で初め、現在は100台以上で構築

各種機能はエコシステムで簡単に使用 Hiveとか

ビッグデータの取り組み
リクナビ→学生の閲覧・行動履歴を元に100件企業をレコメンド

Persuading customers : insights into emotional value from big data
(お客様を説得する:データサイエンスで読み解く感情価値)

Video streaming by Ustream

A社と楽天のサイトデザインの違い→Topページはそんなに違わないが、顕著なのは商品ページ。

A社は理性にアピールつくり、楽天は感情にアピールするつくり(国民性の違い)

良いサービスはユーザーの深い欲望でできている

ユーザの深い欲望をどうやって理解すればいいのか

顧客の声を聞くのではなく、行動を見る

広告

第64回PHP勉強会@東京

日時:2013/01/31
場所:VOYAGE GROUP様セミナールーム

phpstudy#64 – Togetter

CakePHP2+BDD Pluginでカンタン受入れテスト(kaz_29)

CakePHP2+BDD Pluginで カンタン受入れテスト // Speaker Deck

BDDとは?

振舞駆動開発(ビヘイビア駆動開発)

なぜBDDなのか

受け入れテスト
→テストツールとして、Seleniumを使っていたが、テストケースのメンテナンスが面倒だったので挫折。

主なPHPのBDDツール

シナリオを作るときの大きさは画面一枚くらい
大きすぎるときは分割を検討

BDD Plugin for CakePHP2

導入後のテスト

  • TDD/BDDはしていない
  • 単体・結合テスト→CakePHPで書いてPHPUnit
  • 受け入れテスト→BDDでストーリーベース

受け入れテスト

  • 開発/CIはHtmlUnit(GUIレスなブラウザ)で実行
  • ブラウザごとのプロファイルを用意
  • ブラウザテストは手動実行

CI(jenkins)でやっていること

  • UniTest (Code Coverage)
  • 受け入れテスト
  • コード解析(phpcs/phpmd/phpcpd)

デモ

実際にプラグインを実行しているところをデモ。
ブラウザが自動的に立ち上がってスペックのチェックを実行していった。
バックエンドでSeleniumが動いており、プラグインがSeleniumのコードを吐き出し、Seleniumがブラウザを動かすとのこと。

注意点

  • window.confirm()/alert()はHtmlUnitでは認識できない
    →jQueryでラッパーしてダイアログ化
  • ブラウザによってはタイミングによってエラーになることも
    →waitを入れる

DietCake (halt)

DietCake – Fastest MVC framework skeleton for PHP

特徴

  • 高速動作
    CakePHPで書いていたが、大量のアクセスを裁く必要のあるソーシャルゲームを実装するにあたっては不都合が生じた。
  • 学習コストが低い
    多くの人が関わり、流動性もあるので、早く正しく書けるようにする。
    →bakeやoilコマンドを使って雛形を生成する事自体、学習コストがかかっている

DB処理

  • 多くのフレームワークはO/R マッパーを使うor内蔵している。
  • DietCakeに標準ではO/R マッパーはない。カスタマイズとして組み入れることは可能。
  • 昔はO/R マッパーを使っていたが、年月がたった今はSQLの知識は必要と思う。

    秒間数千アクセスがあり書き込みが多いソーシャルゲームでは生のSQLの知識が必要である。
    例)SELECT … FOR UPDATE と SELECT … LOCK IN SHARE MODEの違いなどのロックの知識
    MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.10.5 SELECT … FOR UPDATE と SELECT … LOCK IN SHARE MODE ロック読み取り
  • 簡単なものでもSQLを書くようにしている

学習コスト

  • Symfony,CakePHPの機能を知るのにどれくらいかかるか
    例)とあるSymfonyを使った案件で、あるコードがヘルパーがあるのに、それを使わずに書いていた。(そいういうヘルパーがあることを知らなかったから)
  • コントローラー肥大化問題
    本来モデルが行うことをコントローラーに書くことでコントローラーが肥大化していく。
    コントローラーの責務はモデルから値を取得してビューに渡す。
  • 協力会社の人が3日程度で書けるようになった。

コア部分の最終更新は1年前

サボっているのではなく、当初から高速動作などを前提に設計しているため、1年間変更する必要性がなかった。

Developers [Social Enterprise] Summit 2012

日時:2012/07/27
場所:東京コンファレンスセンター品川
URLDevelopers [Social Enterprise] Summit 2012

B-3 社内ソーシャルメディア開発トライ&エラー おれたちの4tate(株式会社インターネットイニシアティブ 原島 法子 氏 / 岩永 義弘 氏)

開発の契機

会社を合併し、人員増加
→使っているツールなどが合わず水と油のように

そこで、社内コミュニケーションツールの開発指令が下る

プロジェクトゴール

  • 組織を横断
  • スタッフがコラボレーションできる
  • 社内コミュニケーション基盤で
  • イノベーションを起こす

しかし、いままでコミュニケーションツールは流行らなかった。

  • システム自体の問題
  • 心理の問題

そこで、システムを提供すると同時に実例・実績も提供することにした。
→開発チームがコラボしてイノベーションを起こすことにした

開発チーム

4人チーム(2人+各人の上司)
生きた事例となるように

やるからには効率良く

  1. ファシリテーション
  2. アジャイル
  3. UX

1.ファシリテーション

仕様を詰めたいが時間が足りない

ミーティングでファシリテーションを採用

課題の共有
ふせんを書いた 1時間
課題の分類
みんなで話し、付箋を分類 1時間
課題から機能を抽出
課題を解決する機能をイメージしてもらい、詰めた 2時間
機能の優先度をつける
縦軸に重要度を3段階・横軸に難易度を3段階の9分割して仕分け 2時間

実質6時間であっさり決まった。この過程はまさにプロジェクトのゴールでやろうとしたこと

「これをシステム化したらいいのでは」

2.アジャイル

しかし問題発生

チームは2人

  • 経験がまるで違う
  • スキルは未知数

⇒少し進めては調整してみよう

お試し期間で3週間。実質38時間でどれくらいできるか測った

その後3ヶ月かけて本格開発

本格開発ではお試し期間のふりかえりから以下を実践

  • 開発する際には一緒に作業
  • とにかく連絡しあう
  • やるやらないをきっちり分ける

リミットから60日を残して、必須機能が実装できた。

でもチーム2人での開発はお勧めできない。(多数決がとれないから)

3.UX

50人でアルファリリース
→最終的に使い続けた人は1人

期間中にもらったフィードバックを取り入れるとアクティブユーザは増えるのか
→ユーザ数は増えない

そもそもどうしてこうなった?

  • ふせん方式は馴染みのないコンセプトだった
  • 機能の見せ方(あったら便利だが邪魔。作った機能が使われない)

つまりUX視点が欠けていた

そこで、UXのプロの力を借りて、UX強化

フロー
a.いつ、どのように使われるかを調査
コミュニケーションの手段と内容・人数
そのコミュニケーションがどうなったら嬉しいか

b.ペーパープロトタイプテスト

c.実システムで使用感テスト

結果、UX改善でアクティブが30人に

このプロジェクトで得られたもの

  • これらの実績が注目された(勉強会で聞く方から話す方へ)
  • 同じ志の仲間に出会えた
  • システムを面白いと言ってもらえた

B-4 グリーを支えるソーシャルコーディングのすべて(グリー株式会社 大場 光一郎 氏)

greeの開発の課題

  • 急激な増員
    • 2010年から毎月50人増えた計算
    • 1人あたりskypeのチャットルームが200個とか、1チャットルームの最大人数を上回るように
  • 業種の増加
  • 国際化
    • 世界に9拠点

周辺の動向

バージョン管理がSubversionからgitへ

GitHubの登場。forkとpull request。
これらにより従来はコミッターしかコードを修正できなかったが、誰もがプロジェクトをforkでき、変更を還元できる

greeの開発

Subversion→Gitosis

gitは分散repoによって複数人開発をより良くしたが、プロジェクトを超えて開発するための機能が足りない。

Gitosis->GitHub

github導入の目的
  • OSS開発で良いソされている手動の導入
  • プロジェクト間のコラボレーション
  • 埋もれているプログラムの発掘
  • 国際化対応
導入効果
  • Gitosisは管理者が必要でリポジトリ作成の申請が必要だったが、GitHubは各人が好きなようにリポジトリ作成可能になった
  • 誰が何を開発しているのか(メンテナやチームメンバーがわかる)
  • 手元で書き捨てるようなコードも共有できる(Gist
  • メンテされないプログラムも使いたい人が修正して使い続けられる
    →プログラムの寿命が伸びる
現在の課題

業種を超えてのGitHubの使い方

GigHub導入の壁

ソースコードを外に置くということ

GitHub Enterprise – Install GitHub on Your Servers

githubのオンプレミス版
自分たちで運用する

Q&A

pull requestの使用頻度は

プロジェクトによるが、ワークフローで取り入れているところもある

pull requestのマージ方法は

メンテナは置かずチームでレビューする

ツールを作っているところもある

Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers’ Blog

GitHub Enterpriseでの成果物はgithub.comので公開することは?

greeというOrganization名でunityプラグインなどを公開中 → gree · GitHub

yumdownloader

パソナテックエンジニアカフェ Lord of Knights の裏側見せます! ~Unity + PHP + MySQL で作るスマートフォンゲーム開発~

【エンジニアカフェEvent】エンジニアカフェ×Aiming (#aimingstudy 出張所)#2
Lord of Knights の裏側見せます!
~Unity + PHP + MySQL で作るスマートフォンゲーム開発~
Lord of Knightsのクライアント開発事例紹介

日時:2012/04/10(火) 19:00~
場所:パソナグループ 本部 8F

Lord of Knights
http://lordofknights.jp/
iPhone向けストラテジーRPG

発表資料

クライアントサイド(iPhoneアプリ:Unity)

開発プロセスの前提

  • チームみんなで楽しく開発
  • 工夫や改善を頑張る
  • なにがあっても楽しくあわてず

チーム規模

クライアント側:3〜8人
サーバ側:5人
企画:3人
デザイナー:3人

8.5ヶ月で作成

開発プロセスでの問題と対策

認識のすれちがい、部署の区切りによるコミュニケーション不足

対策:

席をまとめる
リーダのそばにセクションリーダー、運営を配置
新人はセクションリーダのそばに

結果:
必要な人にすぐ判断を仰げる
関連する話題が自然に耳に入る
新人が放置されにくい

他のメンバーが何をしているのがわからない

対策:
朝会を行う

結果:
全体の動きの把握
問題をチームで共有できた

朝会で言ったことを忘れる、報告遅れ、残業多い

対策:
夕会を行う
その日のことを忘れないうちに報告・共有
残業の必要性を判断

結果:
朝会の時短につながる

協力企業とのやりとりがチャットとメールだけだと進みが見えず、問題発見が遅れる

対策:
ビデオチャット会議を行う
30分程度
進捗報告。問題共有
雑談を交えつつ

結果:
合意が作りやすい
見えていない問題がぽろっとでたりする
仲良くなれる

どの実装を優先すべきか、仕様抜け

対策:
UXを Googleドキュメントにリスト化
ユーザーストーリーをリストアップ
それをマイルストーンごとにまとめる

結果:
次にやることが明確に
リスト化の段階で抜けに気づける

ただし、フローを工夫しないと管理が大変

スケジュールどおりに終わらない

対策:
タスクの増加・消化を可視化(グラフ)

結果:
遅れがすぐに分かる
終了予測がわかるように
遅れた理由が分かる

まとめ

アジャイル開発になっていった

現在の問題点

リリース後の割り込みが多く優先度がころころかわる
中長期スケジュールが立ちにくい

対策を試行錯誤中

大事なこと

  • 早期発見と改善が大事
  • チームみんなで作るという意識
  • 何でも言えるチーム
  • 何があっても楽しくあわてず

開発技術

UnityとHTMLのハイブリッド

UnityだけではUIが大変…40画面以上
→リスト系など動きが少ない画面はHTMLの方が作りやすい

メリット
  • UIとしては自然に実装できる
  • リリース後のUPDATEがしやすい。審査なしで可
  • 自由文字入力(chat,bbs)ができる
    フォントに使えるテクスチャサイズに制限がある(EZ GUI)
デメリット
  • ローディングが長い
  • 反応遅い
  • メモリー消費
    連携部分はエディタのみでは確認できない
Unity・HTML 連携

HTML側からUnityの関数を呼び出す

つかっているところ
  • クエストの達成判定
  • サーバとUnity内のデータ同期
  • Unityの画面遷移やUI操作
実装方法

native pluginとして実装。UIWebViewを利用

ブラウザが操作不能になるバグがある
→Unity側が自動生成する描画フラグを変更

C#の非同期通信

通信の実装を気にしたくない

通信実装コードの自動生成するようにした
→定義ファイルからコードを自動生成

処理を直感的に書きたい

メソッドチェインで書けるようにした

呼び出し().成功時callback().成功時callbackが完了した際のcallback().それが完了した際のcallback()

エラーをあまり気にしたくない

すべての非同期処理を共通化。根っこでtry〜catch。個別エラー処理も可能に
エラーはすべてキューに入れてあとで処理できるように
結果VIewは正常系のみの記述ですむ

サーバの実装に依存したくない

Mockを使う
ソースの変更なしで、本実装との切り替えを可能にする

簡単にViewに反映させたい

モデルからのイベントをVIEWでListenするようにした

VIEW作成時のモデル変更イベントをListen
VIEW破棄でListen解除

Q&A

  • Unitテストは?
    →クライアントは今回はやっていない
    今後は、ロジック部において、Unityエンジンのネームスペースを使わずにしてテストできるようにする予定
  • チート対策
    →クライアントで重要な処理はせず、VIEWのみ、サーバへはリクエストのみ
    リクエストの可否はサーバが判定
  • 通信切断からの復元
    →クライアントのデータの再同期メソッドをつくっておき、それを呼び出すようにしている
  • HTMLのチェック
    →コミットしたらパック化してすぐ実機確認できるようにした

サーバサイド

  • サーバはクラウドを利用、負荷に合わせてサーバの追加が容易
  • WEBサーバはApache+PHP5.3系 各ワールド共通
  • PHP
    • アプリのリクエストを受けJSONを返すAPI
    • アプリのリクエストを受けHTML返すAPI
    • 内部処理のバッチ処理
  • DB(MySQL5.5)
    • 各ワールドごとにMaster1台、スレーブ2台
    • バージョン5.5により、デッドロックが以前の版より減った感じ
    • MySQL MHAを利用した自動フェイルオーバー
  • ログはrsyslogで集約
  • デプロイは専用自作スクリプト(rsync)

対負荷設計で気にかけるところ

  • ソーシャル要素が強いのでユーザ間での関わりが強い
    • ユーザ単位の水平分割は難しい
    • ワールドでサーバを分ける(今回はゲーム仕様上可能だった)
      →1ワールドあたりの人数制限がかけやすい

MyDNSで名前解決

使い方

  • デプロイ先サーバの決定。サーバの追加に対応
  • 2台あるスレーブの参照率を変更できる(クラウドのインスタンスにむらがあるため、必ずしも同じ性能を示すとは限らないため)
  • DBバックアップ時にスレーブの参照を0にしてダンプ終わったら戻すという運用ができる

運用

監視

  • 死活
  • アプリレベル(ログイン数、同接数) ← 重要
  • アプリログ

問題があればMLにメール、携帯へ
ガラケーの電話帳機能でfrom判定 着信音を鳴らす
アラート専用PCを設置。メールの振り分け機能とPlaySound機能でアラートを鳴らす。
再起動レベルの簡単なインフラ障害の一時対応は24時間監視のサービス会社に委託

ソーシャルアプリのサーバサイドと既存案件との違い

  • サーバサイドはWEBアプリケーションそのもの
  • 設計や共通部は知識と経験が必要
  • API応答が主で地味な作業
  • VIEWがクライアントに移ったと言っても工数は減らず
    →調整などでむしろ増える
  • 分業作業(設計を受けて開発)をすることでWFモデルに近くなった
  • Appleの審査が大変(専用環境の用意やクライアントアプリとのタイミング)

ポイント

  • ソーシャルゲームは難しい
  • 規模が大きくなりがち
  • コーディングルールや教育スキーム 枠組みが大事
  • 自動化できるところは自動化
  • ノウハウの共有と短サイクルの改善
  • DBの深い知識
    • 設計
    • インデックス
    • ロック
  • 高負荷に耐える
    →仕様どおりつくっても負荷に耐えられるとは限らない
  • 負荷対策
    • リクエスト数が多い、SQL複雑
    • 急激な負荷
      →サーバのスケールアウトで負荷を軽減できるように

DBサーバの負荷対策

  • よく行われる参照はKVSへ
    →ただし、更新が多いデータはクリア忘れのバグにつながりやすい

負荷試験と性能試験

  • 各APIの実行速度と利用回数を記録
  • 実際のAPI利用率を社内テストから割り出し、試験シナリオを作成
  • 実際のレコード数を再現する
  • APIの呼び出し回数を減らす検討をする
    →処理速度UPと合わせてウォーズマン理論を形成
  • たいていはインデックスとSQLチューニングで改善

開発チーム

  • PHPエンジニア4
  •  DBエンジニア1
  • テスター1
  • インフラエンジニア1(他案件と兼務)
  • 見習い1

チームに見習いを入れることで、仕事を覚えていく。

開発プロセス

  • 進行はSkypeチャット
  • 朝会
  • 週一のふりかえり
  • 週一のクライアントとのビデオ会議
  • とかく楽しむ
  • 基本を大事に

Q&A

  • バッチによるDB負荷対策は?
    →ひたすらにインデックス、SQLチューニング

関連資料

第3回渋谷Unity技術勉強会

 

shinagawa.redmine 第2回勉強会

日付:2012/01/21

URL: 第二回勉強会 – shinagawa.redmine – Redmine

場所:IPA様会議室

shinagawa.redmine 第二回勉強会 – Togetter



数千人が利用する楽天redmineの過去と未来

ご本人によるコメント付きスライド↓
数千人が利用する楽天Redmineの過去と未来 #47redmine | 世界

2008年に導入

最初は1人、そして2~3人
10人で使ったら失敗して当時は全く相手にされなかった

2009年4月

空いている仮想サーバにインストールして利用(mem 516M)
64ユーザ
たまに固まるのでcronで再起動していた

プロジェクトを細かくすると、重みのかけかたで放置されやすくなるので、プロジェクトを分けすぎるのはダメと気づく

進捗が見えるプラグインを作成・導入した

redmineの活用、進捗の見える化、ユーザが拡大

2009年9月

ユーザ数拡大によりWEBRickの限界が見える
340ユーザ

問い合わせをredmineで管理するようにした。
具体的な利用方法はwikiに書いた(wikiはredmineのではなく、別のを利用)

細かい工数入力を実践→めんどくさいので半年でやめた
そのかわり成果を見ることに(どれだけチケットを消化したか)
バーンダウンチャートプラグイン
パーキングロットチャートプラグイン → 社内でも成功したプラグイン

プラグインは見てすぐわかるシンプルさが重要

2010年

告知しなくてもクチコミで広がっていった。結果、登録ユーザが1000人超える(所属エンジニアの60%を占める)

redmineのバージョンアップをこまめに行った。

仮想サーバでは処理しきれなくなったため、リアルサーバに切り替え
WEBサーバの2台化やSVNの負荷が問題になり、SVNサーバのスケーリングを行う

1つのプラグインで全員を止めてしまう事象が発生する
(プラグイン内でのSQLによっては固まってしまう。そのプラグインを見ないようにすると正常に動く)
全文検索を使うのは厳しくなった

最近

アジャイルコーチとなって教えることとなり、redmineは問い合わせ管理ぐらいしか使わなくなった。

タスクボード+バーンダウンチャート(手集計)+日めくりカレンダーのアナログツールを使用

タスクボードの写真を撮って記録。ローコストで手軽

徹底的に見える化を行うこと

2011/秋頃:4,100ユーザ、160,000チケット、2,500プロジェクト
redmineがあると使ってしまうが、本当に必要かを考えるようにした

予想以上に広まった結果、無茶な利用をしないようにルールを決めて利用することに

融通が聞かないようになる

独自redmineが使われるように

「個人の対話が重要」

redmineでも日本語全文検索

利用目的

チケットドリブンのサポートツールとして利用

OSS版ITILツールとして

商用でチケットドリブン型ツールもあるが、高い、技術が古い、機能が多すぎる

運用現場に導入した→状況の共有に効果がでた

欲が出て情報の共有をしたくなった
「ドキュメントの中のどこに書いてあった」を知りたい

→文書管理と紐付けたい→システムを統合へ

変更内容

DMSFの修正
Hyper Estraierを使用するようにした

linuxでやったら簡単に実装できたが、Microsoft Officeのドキュメントが扱えない
→OpenOfficeサーバで抽出させることに

少し遅くてもいいからインデックスなしでの検索がほしい

今回の方法は、大規模化やセキュリティに課題あり

プラグイン開発ガイド

プラグインタイプ

  • wikiマクロの追加
  • redmineの機能拡張
  • 管理データの追加

ALMinium

Redmineと便利なプラグインをまとめたインストーラー

3種の神器(yum, Git, ALMiniumのインストーラー)でらくらくインストール

LT

redmineチケットにおけるプロジェクト火消し戦略

ケーススタディ

  • 終了済みバグ、タスクが大量に残る
  • 優先度や期日が有名無実化
  • チケットのドキュメントがGoogle Docsなどで併用して存在する
  • 次から次へとタスクが追加
  • 大量のチケットが同じ担当者

対策

「トリアージ

納期を遵守するために、作業に優先・非優先の観点で順位付けをおこなう
機能・人員・時間・品質を調整

「効率化」

チケットの初期化時

  • ツールをRedmine一本化
  • 棚卸と全チケット化
  • 最小作業時間5分以上かかるものをチケット化
  • 1日以上のものは分割
  • 担当者名を「社名 未担当」という形で割り当てる
  • 優先度、開始日、期日を設定する
  • 優先度と未担当のカスタムクエリを追加して、一覧化

チケット運用時

  • チケット管理者を立てる
  • 理想は専任
  • チケットフローを簡略化
    完了時コメントはテンプレ化
    担当者が作業を完了したら管理者に担当を変更する。その後のステータスの処理などを管理者が一手に引き受ける

一番大事なのはモチベーション

redmineのPDF文字化け問題とその修正

資料参照

Redmine Graph Activitiesプラグイン

meumacha/redmine_graph_activities – GitHub

誰が、いつ(時間、曜日)、何回コミットや変更されたかを棒グラフで表示するプラグイン

時間別、曜日別のコミット量を視覚化することで、作業担当者の行動特性がわかるようになる(朝方、夜型など)

○○からのメッセージをお読みください。(仮)

管理者から利用者に伝えたいこと(バージョンアップ・メンテナンス)を周知させたかった

  • 専用ページを作ったが、見に来ないといけない
  • メールを送ってみたが、見てくれない

バナー表示ができるプラグインを作成した

System Notification – r-labs – Redmine

CandyCaneについて

Downloads for yandod’s candycane – GitHub

PHP製Redmine

  • PHPなので、だいたいどこでも動く
  • PHPなので、プラグイン導入時に再起動の必要がない

WordPressを参考に

  • インストール 1分以内
  • 管理ページからプラグインの管理(追加・削除)ができる

shinagawa.redmine 勉強会 第一回

URL: shinagawa.redmine – 第一回勉強会 – Redmine

場所:IPA様 会議室

日時:2011/09/08 19:00 to 21:00

Toggetter:第1回品川Redmine勉強会 – Togetter

1.障害管理からチケット駆動開発へ~ソフトウェア開発の3種の神器 (@akipii)

【公開】第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ~ソフトウェア開発の3種の神器」 #47redmine: プログラマの思索

Excelによる障害管理の課題

  • バグ情報が散在しやすい
  • バグ修正と検証のワークフローが複雑
  • リリース管理が大変

BTSの特徴

  • 障害管理のためのシステム
  • バグ情報をチケットで一元管理
  • チケットのステータスでワークフロー制御
  • 終了チケットをリリース履歴として残せる

BTSからITS(課題管理システム)

  • 障害だけでなく、課題や要望をチケットにする
  • チケット駆動開発が誕生
  • ワークフロー管理をソフトウェア開発全般に拡張
  • トレーサビリティでの変更管理をサポート
  • ツール連携で新しい運用方法を見出す
    →ITS+Wiki+SCM+CI

アジャイル開発でのチケット駆動開発

  • XPのタスクカードがチケット
  • XPのタスクボードがチケット一覧
  • XPのイテレーションがITSバージョン

2.RedmineのSCM機能(@marutosijp)

marutosi / redmine-shinagawa-20110908 / overview — Bitbucket

  • リポジトリブラウザ
  • タグやブランチ
  • ソースツリー
  • ファイル単位での履歴 など
  • 統計グラフ
  • チケットの関連付け

内部構造

  • SCMによらず内部データベーススキーマーは一緒
    →リビジョンをすべてDBに保管する
  • SCMにsubversionのリモートを採用していると少し遅い
    →ツリー表現処理にsvn listを使っているため
  • redmineのSCMにおいてgitよりmercurialが優位な点
    • リビジョン番号が存在
    • リビジョン番号の並び順が保証
      →内部的に取り込みやすいGitのブランチはリビジョンへのポインタだから、リビジョン間に何があったか表示するのが大変
    • Redmine 1.2から改善を行い早くした

Redmine開発での問題点

  • コントリビューター・ コミッタ不足
  • チーム内で英語に少し不慣れ

3.Redmineの実業務における活用事例紹介(@yohhatu)

アンチパターンあり

事例1

背景

  • メンバー全員初Redmine
  • Redmineの管理権限がもらえなかった
  • クライアントとの信頼関係あり
  • これまでJava開発をメインでしていたが心機一転Ruby On Railsを採用
  • イテレーション単位での反復開発

やったこと

  • WBSの1タスクを1チケットにした
  • ガントチャートと併用
  • カスタムクエリを工夫(前日に発行されたチケット一覧、未対応バグ一覧 など)

よかったこと

  • リーダーが楽しそう
  • 今やることに集中できた

課題

  • チケットの粒度が大きかった

改善点

  • チケット粒度を細かく(2.5〜4時間で1チケットを1日3個 消化する)

事例2

背景

  • 前回と同じメンバー
  • 納期が短い
  • リーダーを担当した

やったこと

  • 全面Redmine、ほぼチケット駆動開発
  • ガントチャートはマイルストーンのみ
  • イテレーションごとに動くものを見せた

よかったこと

  • メンバーがチケットを取るようになった
    (メンバーがチケットを書く、そしてそれをアサインする)
  • 余計な管理作業がなかったので実装に集中できた
    (進捗などはRedmineでわかるから)
  • 追加仕様がなく クライアントから高評価だった

課題

  • マネージャーからマイルストーンの提出を求められた
    →Redmineを見せてとにかく説明した

事例3

背景

  • 社内向けシステム
  • メンバー10人
  • 経験豊富なメンバー
  • 社内システムなので新しいものを挑戦できる環境
  • Redmineの管理権限が使えた

やったこと

  • TiDD(No Ticket, No Commit)の採用
  • スクラムで開発
  • 3種の神器を利用(@akipiiさんの発表参照)

よかったこと

  • トレースがしやすくなった
  • プラグインの導入で開発が早く、楽しくなった
    Code Review / Burndown Chart / WorkTime / Redmine Graph Activities
  • 3種の神器の連携は楽

課題

  • 他のチームへの展開が課題

 

Redmineはあくまでツール(銀の弾丸ではない)

 

LT1.Redmineを利用した定量的プロジェクト管理(@yohwada)

発表資料

ITプロジェクトの見える化

暗黙知(KKD:勘と経験と度胸)から形式値へ

見える化ツールの必要性

レポーティング、品質管理、課題管理 etc

 

IPAさんではオープンソースのツールを組み合わせた、定量的プロジェクト管理ツールを年内公開を目標に作成中

 

LT2.うちのRedmineの使い方(@tkusukawa)

 

インフラ運用の現場でRedmineを利用中

  1. wikiに議事録
    履歴で閲覧集計をチェック
  2. 朝会
    worktimeの日程メモを参照しながら
  3. 工数集計
    worktimeでチケット感の工数付け替え集計

LT3.プラグイン開発者への道(@haru_iida)

bpstudy #47

URL: BPStudy#47 : ATND

場所:R3C貸会議室 NOF新宿南口ビル4F セミナルームA

日時:2011/07/29 19:00 to 21:00

Togetter – 「BPStudy#47のまとめ」

XenServerによるお手軽サーバ運用(@tokibito)

業務の課題

  • 本番に近い環境
  • お客さんに見てもらう
  • 外部システムの連携
  • etc…

開発用のサーバがほしい

  • 前提条件
    • コスト(時間、お金)をかけすぎない
    • 今やらなくていいことはやらない
    • 必要以上に複雑にしない
      • メンテナンスコスト
      • 移行コスト

選択肢

  • レンタルサーバ
    • 共用
    • 専用
    • VPS
  • 自社
    • データセンター内に設置
    • 社内に設置

今後プロジェクトが増えたら?

  • 物理的に増やす
  • VirtualHost
  • chroot
  • 仮想化

検討

  1. プロジェクトごとに環境を作りたい
    →レンタルの共用は難しい
  2. 1プロジェクトの期間の平均は1〜3ヶ月
    →DCやレンタルの専用サーバは費用が高い

結果

社内にサーバを設置、仮想化で
→XenServer

なぜXenServerを選択?

  • VPSを借りるより自前サーバの仮想化は性能面、機能面で有利
    →いざとなればいろいろできる
  • KVMやXenは知識ないと大変そう
  • 8コアマシンを使いたかった
    →当時(2009.4)VMwareESXiは4コア上限
  • 無償だから

ハードウェア

  • 20〜30万の据え置き型
    (当時はオフィスが大きくなかったのでラックは置き場所や電源に困る)
  • CPU: Xeon
  • メモリ: 4GB

XenServerインストール

無償版ライセンスは1年毎に更新

XenCenter

GUIでXenServerを管理できるWindowsソフト

windows以外用にopenxenmanagerがある

Xenここが便利

  • 管理ソフトがGUI
  • VM(仮想マシン)のスナップショット
  • VMのテンプレート

運用後の課題

  • 設定が面倒
    • ネットワーク設定
      →スクリプトを作った
  • ユーザ管理
    →鍵認証にした

運用管理

  • VMの管理
    スプレッドシートで管理表(IPや用途)
  • VMの作成
    ルーチンワーク化

その他

  • XML-RPC形式のAPIがある
  • 物理3台で40VM程度運用

プロジェクトが失敗する要因+α(bash0C7)

プロジェクトとは?

プランニングオニオンの変形で
戦略→ポートフォリオ→プロダクト→リリース

プロジェクトの成功とは

予定通りの期間、予定通りの予算で最初に定義したすべてのフィーチャーを実現していること
『Extreme Chaos 2001. Standish Group International, Inc.』

失敗の要因

いっぱい

プロジェクトが失敗する1つの原因

見積もりミス
『ソフトウェア開発 55の真実と10のウソ』

見積の意義

  • 実施価値判断
  • 優先順位付け
  • 体制を検討

キーワード

  • 不確実性コーン
  • 規模と期間
  • 正確さと労力

不確実性コーン

プロジェクト初期ほど具体的なことが決まっていないので見積りの精度は不正確
プロジェクト終端は1つの点に見積りが収束

横をプロジェクト時間、縦を見積り(実績)にしてグラフ化すると、横に倒したコーン(円錐)になる
アジャイル開発にすることで、コーンを小さくなりブレが少ない見積りができる

規模と期間

例:東京大阪を移動するとき何時間かかりますか

かかる時間(期間)は
2時間40分(のぞみ)
1時間ちょっと(飛行機)
仮にのぞみがこだまとしたら
5時間

→条件によって期間はばらばら

でも距離500km(規模)はかわらない

→まず規模を決めよう
まず要求される機能の中から規模がわかるものを比較対象(基準)とする、その基準と他の機能を見比べて各機能の規模を決めていく。(これは基準の2倍だとか)

その後、基準を実装するのにかかる期間を見積もってあとは比率で各期間を計算する。(基準が1週間でできるからこれは2倍なので2週間だとか)

正確さと労力

見積もりをしっかりやっても確実性はあがらない

参考書:『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』
『アジャイルサムライ――達人開発者への道』