替え玉バリカタでお願いします

お仕事と、お仕事そうでお仕事じゃない、少しお仕事な備忘など。

デブサミ2014に行ってきたのでメモ書き

やっとデブサミに行けた

ずっと行きたかったデブサミですが、やっといけました。
今回はコーヒースポンサーという形で身銭を切ったので、時間を空けるモチベーションが働いたのだと思います。来年もコーヒースポンサーやりたい。結局なんだかんだで時間を捻出できたのは1日目の半分だけ。そしてマイブームなところだけ聞いてきてしまった気がする…。来年はもっと幅広く参加したいな。

 

参考:デブサミ2014、講演関連資料まとめ:CodeZine 

 

以下はメモ。基本的にズレてないと思いますが、同セッションに参加した方など、おかしな点がありましたら訂正します。ご指摘ください!

 


 

Session:【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする

最終的にはそもそも論で終わってしまったけれど、そもそもが出来ていないプロジェクトがたくさんあるので、正しいと思いますw 

イントロ

Coverity Connectの自動テストの例でのプラクティス。C社がユーザサポート、自社開発で得たものなど。今回は製品の話はしません。静的解析・コードレビュー自動化、画面系・UTの自動化の話しをします。画面系は難しいね。5つの観点で話します。

5.本当に自動化が解決策?

4回回せればペイできる、と言われている。バグ修正は、担当者が決まらないと30%遅い。いろんなグラフが出てきた。

Firefoxの例

上のバグ修正フローと各フローにかかる日数 2,376件からのデータ。アサインされないと平均9.9日、アサインがあると7日で終わる。そもそも開発プロセスを変えないといけませんよ!※データはH21のもの

Linux開発の例

バグがどれぐらいの日数でFixされているか分析した。新担当「見つかったバグをすぐに解決する方がいいのでは?」と考えて実施。平均120日→20日以下になった。※データ2013

  • 客観的なデータをみるべき
  • 経過時間(ほっとかれ時間)を見るべき
  • コンポーネント別など切り口で問題を洗い出す
■Coverityの開発

6ヶ月サイクル、3ヶ月のリリース計画。100人、Agileスクラム)2Wのスプリント、スタンドアップミーティングやってる。Jira, PivotalTracker, bugzilla, jenkins-CI。

ステータスミーティングは1Wごと。サポートフラットフォームが多いのが特長。テストサーバ215台でjenkinsで回してる。jenkinsの画面見せてくれた。

  •  明確な理由を持ってテストしよう

4.担当者のスキルセットは正しい?

アウトソースしても自動化うまくいかなかった。スキルセットがずれていた。自動化スクリプトが書けなかった。時差の問題もあった。そこで、自動化テストチームを作った。時差も減らした。インターンで就職してもらうなど、人の要素が大きかった。やっぱり人なんですね。

3.コードカバレッジの罠

Coverityはコールグラフ、分岐条件をツリー展開、自動化でやっていまう。dead code, unreachalbeも分かる。Coverityはそういうツールを出してるので、ユーザから「C1カバレッジ100%といえますよね?」という問い合わせがあったりする。カバレッジは本質じゃないよ。 

自分メモ:
  • ReSharperはこのあたりやってくれるけどjenkinsで回したら気持ちよさそう
  • おかしな品質を合意しない(こわいこわい)
  • 目的を持ってテストしよう。本質は?を追求すべし! 

2.優先度を設定していますか?

Coverityは「チェンジセットにフォーカスしたテストポリシーを評価する単純な試み」を行っている。差分と影響範囲だけカバーしなおせば良い。やみくもにテストしても本質にフォーカスできない。差分による影響からテストを始めること。効率が良い。テスト自動化の優先度も考えたほうがいい。 

1.クリーンなコードになってる?

結合レベルでクリーンになっていないと、テストにかかるコストを償却できない。実装→UT→静的解析→コミット→テスト(できれば差分テストだけやる)。結局これが一番大事。

まとめ

コーディング、UTを作る→解析→UTレベルはOK, を担保。最新リビジョンで自動ビルド、自動テストを実行。これからやるときは、新規コードから自動テストをはじめたらいいと思いますよ。 

 


 

Session:【13-B-4】事例から学ぶDevOps実現のためのプラクティス

気持よくDevOpsを実現するためには、人に気持よくコラボレーションツールを使ってもらうことなんだろう。効率と感覚の両方から考えなきゃならないなと、改めて感じました。

イントロ

DevOpsが叫ばれるようになって、CI/CD/Infrastracture as code(chefとか)が出てきたが、現在は少し状況が変わってきたと思っています。事例を2つ述べます。

基調講演でのキーワードで

  • ワクワク感→開発者が「何のためにこのアプリを作るのか」分かる
  • 「ユーザのために何をするか?」により企業価値を高める

がありましたが、これからの話でも共通する事柄です。

事例に入る前に整理

  • CEOへのインタビューによるとITの位置づけとして、2003はコストセンター、2013は重要な要因と捉えられている(ソース忘れた)
  • Agileの普及度→実施中・取り組み予定が増えてる(数字忘れた。かなり多かった)※データはAgile Conference 2009-2013
  • 失敗事例が増えているのが良い点(普及してるともいえる)→DevOpsにも同じ流れが来る
  • スピード感が求められている(social, mobile, analytics, cloud, securityの観点でもっと早く!)
  • dev・opsだけでなくユーザ・事業部門も含めた形のDevOpsにより継続的なイノベーション、フィードバック、改善が必須
  • リーン・スタートアップ(おなじみエリック・リースさんのやつ)
    ideas->build>code->measure->data->learn->ideas....を回す
  • リーン・スタートアップをDevOpsが支える

事例1

  • デモ
    端末から障害報告→端末からのフィードバック→開発者→すぐにバグ修正
    デバイスを振る→バグ報告画面→送信→起票→開発者は管理画面で確認(スタックトレース・メモリなどデバイス情報も取得できる)→バグ修正がすぐに出来る
  • 要点
    運用品質のモニターおよび検証
    ループバックを拡大する(直接フィードバックの仕組み)
    ★継続的なモニタリング
  • 仕組み
    コードをコミット→構成管理ツール/CIツールが自動処理→テスト担当者に自動配布→テスト
  • ユーザにフィードバックを送ってもらうための工夫
    操作が直感的であること(送りやすいこと)
    デバイスやソフトウェアの情報を自動収集。クラッシュ時も詳細が分かること。チケット管理システムとの連携があること(すぐ対応できること)
  • 品質メトリクス
    リリース・デバッグ版の品質データをトラッキングしていく
  • センチメント分析
    ユーザの心情・感情を分析する(肯定的・中立・否定的)
    Googleもやろうとしたけど、公平性からやめた
  • 品質メトリクスとセンチメント分析を組み合わせて、マーケティングに使う
  • 開発者として
    補助するライブラリも使いやすいことが大事。開発者としてもソレを意識していくことが大事。※デモを見た感じ、Crittercismと同じ感じか

事例2

本事例の課題
  • モバイルはtime to marketの早さが最重要課題
  • 要求変化に柔軟に対応しなくてはならない
  • お客様との摩擦。地理的分散・コミュニケーションロス・成果物が散在
  • 早期にプロジェクト立ち上げたい

→コラボレーション環境が必要→クラウドの利用(Saas)を検討。

JazzHub(SaaS)

開発、課題管理など。Web上で開発。Eclipse Orionエディターが使える。デプロイ、確認、別の基盤(DBサーバとか)との兼ね合いも含めてデプロイできる。

BlueMix(PaaS)

この辺よく分からず。

ポイント
  • コラボレーティブ開発 On developper cloud
  • 早くアプリケーションを見せることが出来ることが大事
  • すぐにフィードバックがあることが大事
  • ライフサイクルマネジメント大事。SOAは作るのが難しかったけど、Web APIは楽だし普及してる。
  • トレーサビリティー確保しましょう。
  • 「何のためにこのアプリを作るのか」を意識できる開発環境を。要はDevOps。
コラボレーションツールの利点

各メンバーのアクティビティが分かる。「誰が何をやってるか分からない」の解消。継続的なモニタリング・継続的な改善をDevOpsが支える。コラボレーティブ開発をSaaS/PaaS上でやる流れになっていく。 

宣伝(IBMの)

 


 

Session:【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント

相当クリティカルな案件でなければ、技術面はよほどヘマをしない限りなんとかなると思っています。一方でどんな案件でも、政治的なことや人との調整はいつまでも難しい。今回参加してきたセッションの中で、最も心にズシ~ンときた。

 

 

マネジメントって何?

  • マネージャーがやる、というものじゃないよ。
  • 特定の誰かだけでなく、全員が何らかのマネジメントに関わるのがAgileのチーム。
今の時代は…
  1. 正解が分からない→フィードバックが必要。
  2. 意思決定が遅れると死ぬ→タスクではなく課題発見から
  3. 偉い人が全てを知っている訳ではない→経験がじゃまになることもある
もっとうまくやる方法は?

沢山のマネージャーを作ろう(なんちゃらマネージメントをいっぱいやろう)

期待マネジメント

期待マネジメントとは?
  • 関係者が互いに持っている期待を明らかにし適切に調整する
    (高すぎず・低すぎず)
こんなことありませんか?
  • 「ここまでやってくれる"はず"」
    →ソレってお互い話し合ってる?同じ思い?理解してる?
ドラッガー風エクササイズ
アジャイルサムライ読んでね!
  • 自分は何が得意なのか?
    コーディング?テスト?調整?無い?プロとして考える必要がありますよ。
  • 自分はどうやってチームに貢献するつもりか?
    じゃあ得意なテストをやることで、どう貢献するんですか?
    ゴールを理解した上での答えを出そう。
    チームのゴール、ビジネスのゴールを理解している必要があるよ。
  • 自分の大切な価値って何ですか?
    モチベーションに関わる(家族・お金・キャリア・きれいなコード…)。
  • チームメンバーは自分にどんな成果を期待しているか?
    お互いの期待を表明してすり合わせよう!
    例)ホームランバッターがホームラン打つことだけ考えてる→周囲曰く「いやいやチームをまとめてくれよ」
誰と期待を調整するの?

関係者全員だよ!自分とチーム、自分とリーダー、自分と経営者、それぞれに聞くと、きっと違うよ。それを調整していこう。

1度やればOKなの?

ずっと同じじゃないよね?実はもう当たり前になってて、もっと求められているかもしれない。ずっとオレンジジュースを出す親を思い出そう。定期的にやろうね。

【事例1:顧客との期待マネジメント】
  • 前提
    制約が多かった&信頼貯金はあった
  • 良い意味でお互い線を引いた
    「俺はこっちはできへん、おまえはこっち頼むわ」→相手の立場で考える
【事例2:上司・チームとの期待マネジメント】
  • シンプルな期待が分かりやすい(うまく表現しよう)
  • あれもコレもやってほしいとか、矢継ぎ早に求めてませんか?
  • やっていることではなく、どう貢献できるか?
  • 自動化やります〜じゃなくて、それをやってどうなるかをもっと説明した?
【事例3:組織との期待マネジメント】
  • 「言わなくても分かってくれる」は存在しない
  • 計測できるもので見せる必要がある

モチベーション・マネジメント

モチベーション・マネジメントとは?

関係者のやる気(式)安定して、目標に向かうように調整すること。

  • モチベーションの特性
    何気ない一言で乱高下する
  • 人によって鍵穴は全然違う
    「ボーナス」でモチベ上る人、「新技術に挑戦できる」でモチベ上る人。いろいろ。
  • 他人がその鍵を持っているわけではない
    周りは手助けできるだけしかできない。
  • あくまでモチベーション・マネジメントするのは自分だよ!
成長しやすい土壌を作る

ちょっとずつ変えていこう(社内の環境:やる気の出るデスク、イス、空調、とかね)。変えていくことで、モチベーションを高められるようにしよう。

自分の調子と相談

無理なときはすっぱり諦めちゃえ!1日かかってできないけど、5分で出来るときがあるよね。日によってパフォーマンスが違う。でも、良いプレイヤーは不調な時期が短いんだよ。

調子を上げるスイッチ

自分のスイッチを知っておこう。周りもあの人のスイッチが何か、気遣っていこう。

  • 上から目線で褒めるのではなく、一緒に喜ぶ
    「できました」→上から目線で褒める
    「できました」→一緒に喜ぶ
  • その先に有る光景を一緒に見に行く、語る
    この開発、このアプリケーションでユーザが、社会が、世界がどうなるかを語る
  • 共感できている?
    プロジェクトの目標を共感している?
  • サーバント・リーダーシップ
【事例1:モチベーション・マネジメント】
  • 前提
    上司が高圧的
  • やったこと
    若手のチームで頻繁な振り返りをした。
    Good!を出しまくった。プラスのフィードバックで自信を回復した。
  • 要点
    シンプルな承認欲求を満たす
【事例2:モチベーション・マネジメント】
  • 前提
    大規模プロジェクトで一部だけ噛んでると、ぼやけてくる。
    なにしてるんだろう自分?
  • 成功体験が少ないなら、つくる
    自信〜打席に数多く立つ。もっとバットを振っていこう!
    一緒に練習しておこう!
  • Rubyのプロジェクトやりたいんですよ」
    「いいじゃん、じゃあ何かやってるの?」
    「やってません」
    「じゃあ一緒に練習しておこう!」
【事例3:モチベーション・マネジメント】
  • 前提
    メンバーが指示待ちだった
  • やったこと
    「自分たちでやること考えてみようぜ」→自分たちで導き出す習慣に変えていこう。やってみると…「あれ、あれ何でだっけ?なぜやるんだっけ?やってるんだっけ?」がわかってくる(※WHYからはじめよ!)
  • 前のめりの失敗歓迎!
    「ここは失敗するかもしれません、損失はこんぐらいです」
    「いいじゃん、前のめりの失敗歓迎!」→チームの安心感
  • まずは少しだけやってみる
    「新しいことをやりたい」
    「え、いままでのやりかたかえるの?めんどうだな」
    「じゃあ並行でやってみませんか?私がExcelからRedmineに転記するんで」
    →意外とこっちのほうがプラスアルファあるよね、がわかってくる
    →サンクコスト(これだけやってみたんだから、もう少しやってみようぜ)
    →改善を止めない
【事例3:モチベーション・マネジメント】
  • 前提
    「お客様の顔が見えないんです」だから転職したいんです。
    (3次請け…4次請け…)
    ハンコと紙の世界
    チームが毎回離散するストレス
  • やったこと
    組織の外にロールモデルを求めても良い
    デブサミにはすんごいひとがいいぱいいるよ、一緒にやってみたら?
    社内にロールモデルがほんとに必要なの?そこを考えてから転職するか決めたら?

まとめ

このセッションを受けた人はActionしましょう!

Action1
  • 周囲への期待を明らかにしてみてください
  • 周囲からの期待を聞いてみてください
    →擦り合わせるきっかけとしてやってみてください
Action2
  • 自分とメンバーそれぞれのモチベーションの源泉を考えてみてください
  • なにがあるとあがる?なにがあると下がる?どうやって回復してる?

 


 

その他:他に気になったけど参加セッションのまとめで見送ったものメモ

Xamarin と Visual Studio でまとめて作る iOS / Android / Windows アプリ

これは知らなかった。Android - Xamarin(ザマリン) とはなんぞや - Qiitaなどを読んでみると、ある程度幻想があるもののiOSAndroid・.NETが書ける人に取っては選択肢になるのかしら。でもお値が張るので、個人では無理っすね。

Cocos2d-x によるスマートフォンアプリ開発のこれまでとこれから

ずっと気になっているけど、ずっと試せていない。ゲーム作ってみたい。

 

広告を非表示にする