2013年05月09日

アジャイル×パターン=ぼくたちの現場


『アジャイル×パターン=ぼくたちの現場』に行ってきました。mixiの会議室で行われた勉強会です。

床はライトブラウン、フローリング調のビニル素材。スクウェアの白い4人掛けテーブルが並べられ、後ろにはバーカウンターがある、さらにその後ろには様々な自動販売機が並んでいる。奥の壁は上から下までガラス張りになっていて、高所恐怖症の人にはちょっとしたアトラクションとなっている。

いつものように周りは全員Mac&私服・・・。

この勉強会のベースになっているのは書籍『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』。そしてその書籍のベースになっているのはIPAの調査報告『非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査』。

IPA関連情報

  1. 非ウォーターフォール型開発
  2. 非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書(非ウォーターフォール型開発の海外における普及要因編)

というわけで、この資料を熟読しましょう。

アジャイル方式が取り入れられているのは多くが会員向けサービスです。基幹システムの事例は1件でした。

手法としてはスクラムがわずかに多いですが、XPも同じくらい使われていました。

開発プロセスの中で目立つ点としては、大半がデイリースタンドアップミーティングを行っており、大半が反復プロセスとは別にテスト工程を設けていた点が挙げられます。


ただし小規模開発においては、メンバが少なく十分な担当者がいないなどの問題点があります。今回のワークではこの件について考えることとなりました。解決策としては、必要性の低い役割は切り捨てること、一部の役割を開発者以外の関係者に割り振る、リーダ的存在の人がPO・マスターを兼任するという方法があるという結論に至りました。

これは一種の開発パターンとなっていて、往々にして発生するものです。『アジャイルプラクティス』には45のパターンが記述されていますが、各開発現場には現場独自の特性があるためパターンの一部は変更が必要な場合もあります。むしろIPAの報告書ではほとんどが40-100人の開発現場であるため、『アジャイルプラクティス』を適用する際には大幅に変更が必要かもしれません。

そこで現場でパターンを作ってしまいましょう、というのがこの勉強会の提言です。パターン作成には下記資料を利用します。上述の小規模開発についてのパターン検討でも利用しました。

弊社の話になりますが、現段階ではテストフローをパターン化できればと思っています。


当日資料の一部

http://www.slideshare.net/masanari/ss-20821189

posted by けんじ at 10:46 | Comment(0) | 勉強会履歴
2013年04月25日

1000人の上位1%に入るエンジニアの秘密


「【ヒカ☆ラボ】エンジニア必見!1000人の上位1%に入るエンジニアの秘密とは? エージェントがこっそり教える、最高額を叩きだしたフリーランスエンジニア達の共通点!」に行ってきました。

できる人の共通点

いなくなると困る存在になる。

  • 開発のコアメンバになる。(立ち上げに携わったり。)
  • インフラ構築を中心となって行う。

市場の原理を利用

技術のニーズ、市場の方向性などを理由にして自分の単価を上げる。

  • 単価を上げてください、市場が○○ですから。

表情を変えない

エージェントとの交渉で優位に立てる。(エージェントが不安になるため。交渉相手のメンタルを崩す。)

フリーランス流のコミュニケーション

  • よくしゃべる。
  • ふところは深い。
  • ゆるぎない技術がある。

売れるものを作ってほしい、面白いものを作ってほしい。→そうですね、私も売れるものを作りたいです。がんばります。

無理なスケジュールを組まれたら→じゃあN人で分担して進めましょう、N人でM日やればできますよ。(結局ひとりでやることになったとしても、「一緒に考える」姿勢を見せることができる。)

社長の下で働く場合

社長の事業成功、売上アップ、社員の能力の底上げがカギ

部門長の下で働く場合

その人の満足度向上、決裁者の地位の確立がカギ

必ず通るプレゼンは、プレゼン前に決まっている

  • プレゼンの前に最終決定者を見極める。向かっている方向、好きなものを調査する。
  • 社長以外のプレゼン参加者(できれば全員)に話を通し、協力してもらう。
  • 断片的な情報を読み取る。ホームページ、パンフレットなどを見て方向を見定める。

終わった後で聞いた話ですが、フリーランスには週末だけやるという形もあるそうです。それだったら勤めながらでもできるなと思いました。また、トップエンジニアは個人でモノを作って売ったりしているとか。


posted by けんじ at 09:55 | Comment(0) | 勉強会履歴
2013年03月18日

全員プロダクトオーナーに行ってきた


2013/3/15に、リクルートで行われた「全員プロダクトオーナ」という勉強会に行ってきました。

出てきたのは主にAgileにのっとった開発の話でした。

私の勤務先ではいろいろとAgileをやろうという話はありますが、まともにやろうとしている人はいません。というのは、チケットさえ使えばAgileだと思っている人がいたりで・・・。

世間とのかい離を強く感じた勉強会でした。


posted by けんじ at 13:19 | Comment(0) | 勉強会履歴
2013年03月15日

インフラエンジニアとしてのスキルアップに必要なこと


本日は19:30からレバレジーズ本社で講演を聞いてきました。

話してくださったのは高岡将さんという方で、10社以上の企業を渡り歩き、数々の問題を解決してきた人です。雑誌の連載もやったことがあり、100台程度のサーバの管理を難なくこなすすごい人です。高岡さんは slideshare に過去の資料をアップロードしていたりします。

彼をエキスパートにしたのは「実績へのこだわり」なんだと思いました。


posted by けんじ at 09:29 | Comment(0) | 勉強会履歴
2013年03月06日

圧倒的生産性を生み出すテスト技法


昨日レバレジーズのヒカラボへ行ってきました。「圧倒的生産性を生み出すテスト技法」ってことで、テスト自動化の話かなーと思って聞きに行きました。

実際は、テスト自動化に集中した話ではなく、折田 武己 さんというものすごい人ものすごいことをしゃべっていました。

折田さんは、テストで使用するデータを動的に生成する仕組みを作ったのでした。しかもその仕組みは、データベースのスキーマ情報が変わっても、一つのファイルを変更するだけですぐに対応できるものです。

折田さんという人はどのような人かというと、いろんな企業からの依頼を非常に高い金額で受注している方です。基本的に依頼側企業はレバレジーズに依頼して、レバレジーズが開発者を選んでアサインするのですが、折田さんの場合は「折田さんでおねがいします」っていう直接の指名がレバレジーズに来ることがあるそうです。

(そして歴史に詳しい。)

折田さんのテストデータの仕組みはこんな感じ。プロジェクトの関係上、JSONで作ったとか。データの基本ファイル、データベースへのマッピング、特定のデータをINSERTする定義ファイル(データセットファイル)、実行スクリプトの4つのファイルで構成されています。

// 基本ファイル
user {
  id: "1100@users",
  name: "テスト 太郎",
  memo: "a,b,c"
}
// マッピング
// スキーマ変更があった場合はこれだけ変更。
user {
  id: simple DB_NAME@TABLE_NAME.COLUMN_NAME,
  name: ...,
  memo: multiple DB_NAME@TABLE_NAME.COLUMN_NAME,
}
// データセット
INIT {
  @import ロードしたいデータのID
  @import ロードしたいデータのID
}
PATCH {
  "データを更新するためのアップデート処理など"
}
// 実行ファイル
setup() {
  // デフォルトで必要な処理
  load ...
}
void テストシナリオ() {
  load シナリオごとのデータ
}

書き写したのが間違っているかもしれませんが・・・こんな感じです。ちなみに今は、このデータ作成の仕組みをもっと別の書き方に変えようと尽力されているとのこと。だからもうしばらくしたらもっとすごいものができるはずです。

以下が私のメモでし。


  1. 情報ブローカーになっていない?
  2. 求められるのは問題解決能力
  3. テストの自動化なんて当たり前でしょ?
  4. ローマは一日にしてならず
  5. いったい誰のためのテストなのか?

1.情報ブローカーになっていない?

フリーランス: 特定の企業や団体に専従しておらず、自らの才能や技術を提供することにより社会的に独立した個人事業主もしくは個人法人


新しい技術は日進月歩。新技術を吸収することは必須だが・・・ 自動テストのフレームワークはたくさんあるが、Google で検索できなかったとき・・・あなたの考えた付加価値はなにか? 検索して情報を伝えるだけのブローカーになっても仕方ない。それよりも、成熟・安定した技術だけを利用するようにしたほうがよっぽど楽。

エンジニアが気に入るものは残念な結果になることが多い。技術者として正しい技術が生き残るとは限らない。新しいものには面白味があるが、そこにコミットしすぎると本末転倒。 コミットしているプロジェクトの問題解決をメインにするべき

2. 求められるのは問題解決能力

SVN から git に変えたところで・・・すごいものができるわけではない。 git は後から出てきたので、機能的に優れているのは当然ともいえる。

新しい技術は書籍が出た段階で読めば十分。

テストデータはテストデータを見た瞬間にその属性がわからないといけない。 assert で説明を書くこともあるが、テストデータはテストデータとわかるように書くべき。

テストデータを「1ばん」「2ばん」としてみる 「2ばん」が「1ばん」より先に表示されたら、人間の目で見て、「ソートがおかしい」などの見当をつけることができる。

3. テストの自動化なんて当たり前でしょ?

テストコードは出来レース。 自動テストは自分が本来テストしやすいところをテストしているに過ぎない。

テストの条件として、カバレッジを挙げた場合・・・ try catch をつかって数字としてのカバレッジを達成する人が出てくる。目的が変わってくる。

  • 単体テストのデータは開発者自身が書く場合が多い。テストファーストの場合も、そうでない場合も。
  • 単体テストと結合テストでは調査するパターンが異なる。
  • 単体テストでは、正常系、異常系をテストするため、バリエーションが多い。
  • 結合テストでは、正常系のパターンを増やす。

日本のSIはだいたい論理削除を行う。この場合、論理削除後に月次の計算をすると金額が合わなかったりする。異常系のテストをしないから。物理削除をすればそんなことにはならない。

テストデータは劣化速度が速い。 スキーマ変更が入った場合、翌日にはエラーが大量に出ることがある。

単体テストと結合テストのデータを一緒に管理すると・・・ 単体テストをさぼるか、膨大なデータを泣きながら管理するかに陥る。

4. ローマは一日にしてならず

ローマがほろんだ本当の理由は、インフラ整備(道の整備など)が財政を圧迫したことらしい。 = 作った後のメンテナンスがまわらない。

テストを自動化するのは簡単だが、作った後で維持・メンテナンスをするのが大変。

スクリプト、データ、リソースを別に管理する。特定のリソースに依存する部分を外に出す。ハードコーディングをしない。たとえばボタンをボタンIDで指定するなど。 そうすることでスキーマ変更などが発生しても、リソースの定義で逃げられるようになる。リソースを使って、どのテーブルのどのカラムなのかを指定する。

5. いったい誰のためのテストなのか?

多くの場合単体テストは開発者に任せられる。 単体テストデータを結合テストデータに流用することがある。

テストデータは天然ものと養殖ものがある。 テストデータに天然ものを使用すると、後で悲劇になる。スキーマ変更などが発生した場合。

天然ものはデータの精度が高いが、それを使った場合、論理削除をしてしまうとデータを元に戻せないことがある。テストデータは我々が完全に熟知しているものにするとよい。

ただ、天然ものはなんのテストにでも使える。


テストデータの劣化は避けられない。できるのはそのデータを1日でも長く延命させること。

テストデータはExcelで書くことが多いが、データをメンテナンスするのは大変。そこで、テストデータを動的に作る仕組みを作るべき。


posted by けんじ at 09:30 | Comment(0) | 勉強会履歴
2013年03月01日

クラウドインフラを考える勉強会に行ってきた


クラウドサービス

Azure
Paas から初めて今はたぶん Iaas
Amazon
Iaas
rackspace
popular in America
Nifty
GMO

メリット

値段

Aws 6-7 で月額30万。昔ながらのレンタルサーバを借りたら60万ほど。プラットフォームとして維持していくということを考えると安い。AWSは昔は東京よりもアメリカのリージョンのほうが安かったとか。

サービスイン・サービスアウト

バーゲンなど瞬間的に負荷が上がる場合に、ボタンひとつで高負荷に対応できる。一時的な高負荷に対応できる柔軟性。(計画的にサービスイン・サービスアウトがあるならクラウドのメリットは薄れる)

(AWS は一旦止める必要があったような・・・。)

デメリット

サーバの故障

自分ですぐに対応できない。サービスレベルは97%以上でだいたいOKというなら大丈夫。でも、もっと高いレベルを要求するなら無理。

通信障害

業務系のシステムを利用している際に、NTTの回線マシンが止まったりしたら、クラウドが動いていても使えなくなる。

(俺の勤務先では NTT にお金払ってなかったから使えなくなったっていう悲しいことがありました。)

クラウド活用のポイント

複数サーバを使う前提でアプリを作るべき。(クラウドのよさを活かそう。)

サーバを簡単に増やすシステムを考えよう。例えば、バックの処理とフロントの処理を一緒にしてパッケージ化しておくと、増やすのが簡単。仮にフロントだけ、バックだけ動かすサーバがあったとしても。

本当に必要なのか? 繋いだら繋いだだけ利用料がかかる。開発環境として使うのはちょっと・・・。


DeNA、gree も利用している。イベントのときだけフロントサーバを増やしたりする。

Amazon の良さ: aws のほうが、利用者が多く情報も多い。書籍も多い。ツールも多い。管理コンソールも充実している。Azureの本はあまり・・・。DBMagazine とか参考にするといいかも。

フレッツのサービスで外に漏れないVPNサービスがある。専用回線。(一般回線には出ない。)


レクポート株式会社 代表取締役 中丸 孝一さん が講師でした。

講演そのものもよかったのですが・・・レクポートの就業管理が結構使えそうな感じで、そっちのほうにも興味が・・・。

felica など、各自のカードをかざせば打刻が可能。データはクラウドにあるから、月末になったら、社労士が勝手にデータを持って行って、勝手に計算をしてくれる。これは結構便利だと思う。

たとえば 勤次郎 なんてのもあってそういうのでも同じことなんだけど、導入コストの仕組みが違っていて、初期投資を抑えられる。

もちろん、なぜか手作業ですべてをやろうとする経理担当者がいるからそう思うのだけど・・・。


いろんなサーバ構成のパターンや今後のクラウドでのサービス展開の仕方について聞けて、私にとって有意義な会となりました。


posted by けんじ at 11:46 | Comment(0) | 勉強会履歴

Distributed Systems #2


Distributed Systems の読書会へ行ってまいりました。分散システム本読書会。

場所はフォースクーナ株式会社です。

1回目より人が多かった気がするw

今回は Processes というタイトルでし。資料作るの大変でした、そしてあまり出来はよくなかったですw

だいたいみなさん疑問を持つところは一緒で、PDA, THINC のプロトコルの違いの点とか、Composite Documents の節とか・・・。

MIPv6 についてはあまりわかっていなかったのですが、エキスパートの方に助けていただきました。ありがとうございます。

Chapter 3 で1.5時間(問題部分省略)かかった。Chapter 4 もがんばろう。


posted by けんじ at 00:00 | Comment(0) | 勉強会履歴
2013年02月27日

SQL アンチパターン レトロスペクティブ


SQL アンチパターン レトロスペクティブ の勉強会に行ってきました。書籍「SQLアンチパターン」を監訳された、和田卓人さん、和田省二さんによる講演です。

こういった勉強会をオライリーやマイクロソフトが支援したりするのは、書籍を買ってほしいからなんですねw ようやくわかってきましたw

さて、アンチパターンの内容は・・・正直あまり気にするほどのことではなかったです。SQL勉強したての人は買ってもいいかなと思う本でした。アンチパターン25種類は以下の通りです。

  1. ジェイウォーク(信号無視)
  2. ナイーブツリー(素朴な木)
  3. IDリクワイアド(とりあえずID)
  4. キーレスエントリ(外部キー嫌い)
  5. EAV(エンティティ・アトリビュート・バリュー)
  6. ポリモーフィック関連
  7. マルチカラムアトリビュート(複数列属性)
  8. メタデータトリブル(メタデータ大増殖)
  9. ラウンディングエラー(丸め誤差)
  10. サーティワンフレーバー(31のフレーバー)
  11. ファントムファイル(幻のファイル)
  12. インデックスショットガン(闇雲インデックス)
  13. フィア・オブ・ジ・アンノウン(恐怖のunknown)
  14. アンビギュアスグループ(曖昧なグループ)
  15. ランダムセレクション
  16. プアマンズ・サーチエンジン(貧者のサーチエンジン)
  17. スパゲッティクエリ
  18. インプリシットカラム(暗黙の列)
  19. リーダブルパスワード(読み取り可能パスワード)
  20. SQLインジェクション
  21. シュードキー・ニートフリーク(疑似キー潔癖症)
  22. シー・ノー・エビル(臭いものに蓋)
  23. ディプロマティック・イミュニティ(外交特権)
  24. マジックビーンズ(魔法の豆)
  25. 砂の城

posted by けんじ at 01:06 | Comment(0) | 勉強会履歴
2013年02月20日

ビルド中心の開発 - タイムボックスと継続的インテグレーション -


ビルド中心の開発 - タイムボックスと継続的インテグレーション -』 へ行ってきました。

Microsoft のテストエンジニア 津田さんによる講演でした。

今回のおはなしは実践 反復型ソフトウェア開発 という書籍に基づくものです。この本は津田さんの書いたものです。会場で10%引きぐらいで売られていたので買いました。学ぶ部分が多いです。

あまりまとまっていないですが以下がメモになります。発表資料はどこかにアップロードされているので、それ見てもいいかも。


エッセンス

反復開発とは?

アジャイル にはパターンがある・・・スクラム、XPなど

インクリメンタル開発、インテグレーション開発、ウォータフォール開発

キーワード

  • Timebox
  • CI

Timebox and Timeboxing

Timebox

プロジェクトの全期間を時間で区切る。

Timeboxing : 入り口と出口を決めて、タスクを箱に入れること

必要なこと

作業の大きさを見積もる。

しかし、作業の大きさを正しく見積もっても、作業があふれることがある。その場合の解決策は・・・

1. がんばる
品質を落とす、残業
2. 箱を大きくする
同じことが起こる
3. 全部入れることをあきらめる
正解。優先度を考慮して、必要性の高いものから実装していく。 作業の範囲を減らす

ちょうどいいタイムボックスの長さ

入れたい作業の大きさに依存する

イテレーション... XPでは2週間

スクラムではスプリントと呼ぶ

タイムボクシングの手順

入り口と出口の作成

バックログの定義 : 時間を使うものはすべてバックログに入れておく

残りの作業一覧

工数の見積もり

優先度・・・どの順に箱に詰めていくか

タイムボックスの途中で作業項目を増やす場合

基本的にはやらない

走っている最中にゴールを変えるとゴールに到達できない

次のタイムボックスの入り口で作業を計画する

ただし、行わなければゴールに到達できない場合はバックログに足す。その場合は優先度の低い作業をバックログから消す

ゴールがおかしいと気付いたら、プランニングからやり直す。

バックログから作業項目を減らしたい場合は、その作業から次のタイムボックスに繰り入れる(パントという)

パントしてどうなるかは後回しにして、とりあえず今はパントする。

出口条件 exit criteria

バックログの作業をゼロにする

残作業をゼロにする ZDD

ゼロバグ: マイルストーンのところでバグをゼロにする。

出口条件を出口になってから確認するのでは遅い。 出口条件は継続的に観察、追跡していく必要がある。

ゼロバグ関数の日付をあらかじめ明確にする必要がある。

優先度の低いバグの修正については次のタイムボックスへパントしてもよい。

出口条件を満たしたビルド

マイルストーンビルド

スプリントビルド

フィーチャーボックス

どれも重要なので優先度はつけない

最後の日付を決める(優先度をつけないとこうなる)

CI 継続的にインテグレーションを作る(継続的統合)

XPのプラクティスの一つ

ビルドをする際の重要ポイント

いつ行っても同じ: いつだれがやっても同じものができる, ビルドの再現性を確保することが大切

環境 ビルドマシン

サンドボックス:子供を入れて遊ばせておく環境

  • 開発者がテストできる環境
  • これが原因でリポジトリが壊れることはない
  • きれいなものだけを取り出してコミットする
  • ウイルスのテストを行うこともある
  • サンドボックスは汚い環境
  • サンドボックスでビルドをして、ビルドを完了させ、顧客に渡すとアウト: ビルドの再現性が確保できない
  • インテグレーションビルドは、ビルドマシンを使って行う

バディビルドの自動化

修正したファイルをバディに渡してバディ内のサンドボックスでビルドする

リポジトリを清潔に保つために・・・

開発環境で開発→コミット→ビルド→エラー通知

ではなく

開発環境で開発→ビルドサーバへ送信→エラーがなければビルドサーバからコミット

バグ修正スプリントはおすすめしない : ソフトウェアが安定するまでには時間がかかるため、バグをすべて修正することに時間を使うのはマイナス

コードコンプリートの時にはテストはすべて書かれているようにする?→その必要はない

CIビルド・スプリントビルド

計画駆動なアジャイル実装、テスト、レビューでテストする?→イテレーションごとのテストはできても製品としてのテストは難しい

テストの4象限 ツールとの関係性をチェック!

ビューは薄くして人手でテスト、ほかは自動テスト

テストデータを作るが、メンテナンスは大変だから手動でテストする部分もある

開発していくことをサポートするテストはうまくいく

開発が楽になるテスト自動化

最初からテストを作っていないと苦しい

テストスクリプトも、作っている中で Makefile の中に入れる

  1. ビルドをした段階でエラーが発見される
  2. 変更するたびにテストを作りこんでいく。
  3. 誰かが新機能を追加した際にエラーが出たらデバッグ
  4. ビルドのリズムを身に着けるとテストが心地よくなる
  5. 仮想環境をつくる→スナップショットを作る→いつでも同じ環境でテストできる


    今後の予定: 4/19, 20 CI conference


posted by けんじ at 00:00 | Comment(0) | 勉強会履歴
2013年02月01日

Distributed Systems #1


Distributed Systems の読書会へ行ってまいりました。分散システム本読書会。

場所はフォースクーナ株式会社です。

日本語訳版はあまりよくないという評判の英語の本です。僕は英語版を買いました。1冊で1万円超えました(TへT)

こんな感じで章が並んでいます。

  1. IntroductionArchitectures
  2. Processes
  3. Communication
  4. Naming
  5. Synchronization
  6. Consistency and Replication
  7. Fault Tolerance
  8. Security
  9. Distributed Object-Based Systems
  10. Distributed File Systems
  11. Distributed Web-Based Systems
  12. Distributed Coordination-Based Systems
  13. Suggestions for Further Reading and Bibliography

1回目は Introduction, Architecture をやりましたが、超ハードです。とはいっても、知識を身に付けるには積極的に参加せねばと思い。2回目のスピーカーをやることにしました。

だから2月も超ハードです。

Architecture を詰め込んで勉強するのは難しかったですが、復習を怠らず前進していきます。


posted by けんじ at 09:06 | Comment(0) | 勉強会履歴
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。