なみひらブログ

学んだことを日々記録する。～ since 2012/06/24 ～

「Developers Summit 2014」に行ってきました。【2日目】

品質 チームビルディング 教育 セミナー 書籍 リンク プレゼン 開発プロセス

１日目に続き、日本最大級のソフトウェア開発者の集い「Developers Summit 2014」に行ってきました。

「Developers Summit 2014」に行ってきました。【１日目】 - なみひらブログ
Developers Summit 2014：開発者のためのITカンファレンス
デブサミ2014、講演関連資料まとめ：CodeZine

セッションメモと雑記

Team GeekによるFearless Change

  • 翻訳をたくさんされているヒト。角征典さん
  • 以下の本の内容をざっくり説明
  • ヒトとの対話時、機械論的自然論ではうまくいかない。
    • 相手のことを機械だと思ってしまうこと。
  • 対話をとってもそれまでのイベントの連続と考えるべき。点と点をつなげる。
  • お菓子を食べながら対話をすると、案が通る。
    • 何もしないと良い案であっても無視される場合がある。
      • ヒトによって受け取り方が違う。状況によって意見が違う。
    • 決めるのはアイディアの良し悪しではないという傾向がある。
  • フード三原則。
  • パターンの例
    • 「チーム名を決める」など。
  • 自分の組織のパターンを作るべき。
    • 「⚪️⚪️さんに訊くパターン」など。
  • HRTを大切にしよう。
    • 謙虚（Humility）：自分が間違っているかもしれないと考えよう。謙虚であっても衝突せよ。
    • 尊敬（Respect）：一緒に働く人のことを大切にしよう。
    • 信頼（Trust）：自分以外に仕事を任せよう。
  • チーム作りでまずやるべきこと。
    • まずは弱点を公開すること。
    • スキルよりも価値観の共有すること。
  • ハッカー文化を大切にしよう。

伝統的な品質管理モデルをアジャイルに適合させる処方箋

  • ヒューレットパッカードの品質管理モデル（HPQM）について。
  • 失業対策に非自動化。
  • まず、2つの幻想を消すこと。
    • 全機能について保証できること。
    • 全件テストができること。
  • テスト計画を積極的に前倒しすべき。できるところからどんどんやってしまう。（テストを成長させるイメージ）
    • 仕様の不備発見、ブラッシュアップできる。
  • トレーサビリティの必要性を見直すべき。
    • 進捗管理が目的となって、トレーサビリティを確保しようとすると、開発者のオーバヘッドを生み出してしまう。
  • 全件テストは実施できないため、効率的なテストを実施するために、テストの技法の勉強すべき。
    • テストの優先度にはビジネスのインパクトを考慮すべき。
  • 以下はあとで調べる。
    • DAD
    • ISTQB/JISQB

IMPACT MAPPING～インパクトのあるソフトウェアを作る

  • チェンジビジョンの平鍋さん
  • 要件定義の仕方と、マインドマップの使い方の説明
  • 以下の書籍の紹介。
  • 開発「なんでこの機能が必要ななんだろう」と企画「もっと機能背景をわかって欲しい」のギャップ埋めるべき。2つの意図を結びつけるべき。
  • アジャイルの外側の世界の話。「要求はどこから来て、機能はどこに行くのか」
  • 仕様を例で書く。
  • 以下の順序で機能実現の優先度をつける。
    • 「ゴール」→「アクター（動かさなくてはいけないヒト）」→「ビジネスインパクト」→「成果物（機能）」
      • 例：「カーレースに優勝する」→「レーサー、メカニック」→「早く走れる、車の設定が調整しやすい」→「エンジンは開発する。ツールを開発する。」
    • アクターを最初定義することが大切。
    • 開発者から見ると、誰がなんで欲しいのかわかる。
    • 誰にどう使ってもらうかを明確にすべき
  • マインドマップについて。

デベロッパー戦国時代！ストーリーをつなぐ開発環境と3つの秘訣

  • アトラシアンの中のヒトの説明。
  • 開発では心技体のバランスを大切にする。
  • 統制よりも環境を重要視にすべき。
  • 環境構築の秘訣
    • モチベーション
    • 目的
    • 規律
    • 良いものを積極的に取り入れる勇気
  • 情報は段階ごとに粒度が違う。

iOSアプリケーションの継続的デリバリー～エンタープライズ品質のiOSアプリケーションを目指して～

  • リコーの中のヒトの発表
  • iOSアプリを継続的にリリースするための仕組みの紹介・テスト技法の紹介
  • お客様にとって無くてならないモノ・サービスを提供すべき
  • 「継続的なデリバリー」を行うのは、ビジネスの主導権を握るため。
  • 価値を生み出せるチーム自体が価値である。
  • 役割の定義
    • テストエンジニア：製品価値を考えて受け入れているテストを自動化する。
    • 開発者：製品価値の高いものから開発する。
  • MMF（Minimum Marketable Feature）
    • 最小の機能で市場価値を生み出す。
  • 以下はあとで調べる。
    • frank：iOSの複数台のテストする仕組み
    • instruments
    • calabash iOS：iOS7で操作系APIを叩ける。

ソフトウェア工学からコンピューターサイエンスへ - 今後のシステムアーキテクチャーに必要な技術的切り口とその裏側

なぜ、システム開発は必ずモメるのか？　プロジェクト見積もりから契約作成まで

  • 東京地方裁判所のIT調停委員を迎え、議論形式
  • 最近ITのトラブルが多いので、その知見で手伝う仕事。
  • トラブルがあると、ITスキル高いITベンダが問題管理できていなかったとして、ITベンダが裁判に負けることが多い。
  • 追加費用、仕様変更について。
    • 窓口を決めること。
    • 体制表を明確にすること。
    • お客さんを見極めること。誰が肝なのか？（プロジェクト開発は綺麗な体ではできない。）
  • プロジェクトの中断について。
    • ITベンダーは、シェルパであるべき。シェルパは昔は地位が低かったが、今は尊敬されている。※シェルパ：登山時に登山家に付き合う地元案内人。
    • ITベンダーはユーザに、スペシャリティを認めされるべき。
    • プロジェクトの開始基準、終了基準、再開基準の合意すること。
    • うまくいっていないプロジェクト開発を続行する場合には、リスクの数値を見せるべき。契約すべき。場合によっては、第3者/客観的なコンサルを入れる。
    • 経営層の教育すべき。「相談」という言葉を使うといい。経営層に対策を打たせる。エスカレートし続ける。
  • 契約書の不備について。
    • 曖昧な言葉は避ける。ITスキルの高いITベンダが書くべき。
  • IT裁判は「ADR」を利用すると結論が早い。調停になってしまうと、裁判は1年かかる。

所感と雑記

  • 2日目は、プロセス系のセッションに多く出ました。
  • 普段の仕事の進め方についても、ちょっとやり方を変えるだけでも試す価値がありそうなノウハウが得られました。
  • 何事も自分の意識から変えることから始まることを強く感じました。