認定スクラムマスター(CSM)研修でまなんだこと

もうかれこれ何ヶ月なんだというところですが、2013/6/20〜21で認定スクラムマスター研修を受講してきました。

自身のブログになにも残しておかないのもおかしな話だということで、遠い記憶を手繰り寄せながら、今の時点での思いを踏まえて振り返りたいと思います。

ちなみにセルゲイさんの回でした。

研修参加の経緯

私はとある受託請負開発がメインの大規模SIerに所属してます。

残念ながらアジャイル開発が現場で利用された実績はないのですが、適用が現実の範囲内ともいえる案件パターンも存在していました。(新規ビジネスのベンチャー相手だったり。)

個人的に興味を馳せていたアジャイル開発(特にスクラム)を机上で学ぶにしたがって、やはり熱病さながらに、現場への適用を夢見たのです。

適用を夢見て、所属部課内でのアジャイル勉強会の主催や、個人的な妄想(コレが主。)をしていたのですが、やはり組織が大きいこともあり「これはハクをつけねば」と思い立ち、「よしならばCSMだ」とそうなった次第です。

その後の戦略については特になにも考えず、「取れば胸に輝くCSMバッジ(そんなのはない)の輝きが何とかしてくれるさ」という無謀な気持ちで受講しました。

研修への全体所感

テクニックやチップスのようなものよりも、スクラムの根幹を深く考え、刷り込ませるような内容に徹底されているなと感じました。

ワークショップもやっている時は「インパクト重視で、少し物事を単純化しすぎでは?」と思わせるもの(チョコレートの生産とか)もありましたが、刷り込むという意味では、振り返る今では、そのシンプルさとインパクトの大きさが刷り込みへとつながっていると感じています。さすがよく考えられています。(今思い出すと大のおとなが真剣にチロルチョコをリレーしている姿は、ぜひ傍から見てみたいです。)

おそらくテクニックやチップスは、文献からに得られるもの、そして何よりチームが実際にスプリントを繰り返す(カイゼンを回す)ことで得られるものが最良なのでしょう。そのための芯になる考え方を叩き込む。そのように感じました。(スクラムマスターですしね。)

そして、スクラムを実践していない私にとっては、実践する人の体験談を聞けることはとても有意義でした。

まなんだこと1:根幹

スクラムの根幹。 (壮大にずれてたらどうしよう・・・。半年たった今も刷り込まれているのはこれなのです。)

  • 「速く、そして変化に強い=顧客、ソフトウェアの重要な価値」である、という価値観。もちろんその前提には顧客やソフトウェア自体が持つミッションやビジョンがあるはずです。(重量級開発へのアンチテーゼとして「速さ」が誇張されがちですが、あくまでもバランスの話といえるのかなと。)
  • すべての役割(PO、SM、チームメンバー)が、システムと、開発へコミットすること。(特筆すべきは、チームメンバーのコミットである「自己組織化」。)
  • タイムボックス。厳格ともいえるほどのタイムボックスが生み出すものはいかに・・・。(これは正直体験してみないとワカンナイ・・・。)

これらがすべてそろって初めて、スクラムチームが円滑に回るのだろうと感じました。

そしてやはり、各所で再三言われ尽くしていることかとは思いますが、アジャイルスクラムは、ITサービスデリバリやチームビルディングのための思想/フレームワークであることも再認識しました。(もちろん開発プロセスではない。ウォーターフォールと並べて比較するものではない。)

まなんだこと2:示唆に富んだセレモニーやツール、ルール

上記の根幹を体現したり、人間の心理をうまく活用したセレモニーやツール、ルールに満ちあふれているようにも感じました。 一般的でないものもあるかと思いますが、話に聞いたりしたものなどなど。

  • 立ってやるデイリースクラム
    • 立ってやることで「長引く(時間のムダな浪費)を防ぐ」。
    • ホワイトボード、タスクボード、バーンダウンチャートなどを指さしたり、書き込んだりもすんなりとできる。(座ってると、立つのが億劫になったり、気が引けたり。)「皆の参加意識」が高まるような気がする。(机や椅子の隔たりって、案外心理的に大きい。)
  • 遅刻罰金制のデイリースクラム
    • 少し極端ですが、「チームでコミュニケーションする時間、タイムボックスの重要性」を思い起こさせます。たまった罰金で、おいしいもの食べに行くとか、いいな。
  • バーン“ダウン”チャート
    • なぜ線を上では無く下に伸ばしていくのか。人間の心理として、「頂上に到達しなければ!」と思うとつい諦めてしまうのかも?(「あとちょっとで頂上にとどいたけど、まぁがんばったよね!」という心理?)「何かをすべて無くさなければならない」という心理の方が「心残り感」(罪悪感に近い)を煽っていいのかもしれない。
  • みなでやるプランニングポーカー
    • これまで見積もりを全員でやったことなどあったかな?「全員が同じ見積り値とその根拠にコミット」する事が、精度/生産性/チームワークに大事なのだなぁ、と。
  • フィボナッチ数列で構成されたプランニングポーカー
    • もちろんフィボナッチ数列である事自体には意味は無い。けれど、精緻な見積もりがそれほど重要な意味を持つのか?を考えさせてくれます。(というよりこれまで幾度と無く無意味だったかを思い出させてくれる・・・)
  • コーヒーブレイクカードの用意されたプランニングポーカー
    • 日本人にはなかなかない感覚(偏見恐れずいえば実にアメリカン)だなあと感じました。そもそもカードでやること自体が遊び心たっぷりなのに、こんなカードを出されたらなんとなく笑ってしまうかもしれない。「開発楽しむ」という思想を如実にあらわしているな。

ほかにも、

  • 全員が把握するプロダクトバックログ
  • 相対見積もり
  • チーム外からの徹底防御
  • Demo or Die
  • スプリントレトロスペクティブ

などなど、シンプルで一貫性があり、示唆的で感心しっぱなしでした。

その後

みっちり2日間何かひとつの事(それも業務にすぐに直結しないこと)についてじっくり考える、ということは日々の仕事の中ではなかなかありませんでした。そういう意味でもこの研修を受けた甲斐はあったと思っています。アジャイルの価値について揺るぎない確信を持てたと思います。(熱病、盲信ではない、冷静なものだと思っています。)ちなみに修了試験は、英語にビビりながらも無事にCSM取得できました。

しかしCSMバッジの後光なんかはないので、これから自身の行動をもって変えていく必要があります。

顧客契約の問題、実績の問題、チーム固定化が難しい文化、マインドの問題、などなど障壁は数知れずですが、アジャイルが顧客、会社、業界、そして自分を幸せにするケースがある以上、そこに目を向いて進むし、別にアジャイルにかかわらずそれ以外が幸せに生み出すのであれば、そこにも尽力していきます。なんにせよ、できることは無数。これからも日々邁進していくことにします。

JUGG CCC 2013 Spring

当日殴り書きメモ

14:15~ Java Small-Object Programming

はじめに

  • 9つのルール、DDDなどを総称してSmall-Objectとしている

S-OPって?

  • 小さくつくろう
    • テストしやすさ、可読性
    • Javaの冗長さ
    • FWの定番化
    • DDD、9つのルールなどの出現
  • S-OPの実現

APの現状

  • FWは安定している(SpringMC、MyBatisなど)
  • BLが理解しづらく変更容易性がない。テストしにくい。(1000行、意味不明なクラス名)
  • ビジネスの変更への対応 → BLの変更
  • システムは変わり続ける

Javaの抱える問題

  • オブジェクト指向的でないPGが容易にできてしまう。(C言語チック)
  • 冗長な構文(アクセサ、toString、equals、close、trycatch)
  • よくある問題:検証処理がちらばる。

S-OPの具体例

  • プリミティブ型、Stringはすべてラップする。
    • String code; って誰が桁数知ってるの?
    • Codeクラス。(フィールドクラス)
    • Validationもドメインクラスにはかかず、フィールドクラスにかく。
  • フィールドクラスを利用しないデメリット
    • たとえばStringとした場合、修正箇所を探すこともできない。(shohinCode, shohinCd)
    • バリデーション処理が重複。全部直さなきゃいけない。
    • 仕様書がないと、商品コードの仕様がわからない。
  • フィールドクラスを利用するメリット
    • 利用方法と仕様がひとめでわかる
    • 検索が楽
    • 修正は常に一箇所
    • 仕様書がなくても保守が楽。
  • 不必要なアクセサは記述しない。
    • 不必要なSetterでは? 不変だったりしない?在庫は減らしたり、増やすものじゃない?
    • 不必要なGetterでは?
  • FWを利用する。
  • 例外やログなど、本質的でない処理はSpringなどのFWに。
    • close, trycatch, log

9つのルールとDDD

  • 設計と実装をみなおす9つのルール
    • エクササイズ
  • DDD
    • ドメイン層 → フィールドクラス
    • フィールドクラス → ValueObject
    • Employeeクラス → Entity
  • DDDやらないといけない?
  • S-OPはトランザクションに不向き?
    • 所謂、入れポン出しポンのBLがないAPに最適
    • 少ないフィールドクラスで実現できる。

自動生成への道

  • DDDのモデルからフィールドクラスを自動生成。
  • ExcelやテキストベースUMLから。
  • SpringWebFlow。

3つの世界:エンタープライズ、ソーシャル/ゲーム、スタートアップ

デブサミ2013 1日目

10:00〜 (14-B–1) 3つの世界:エンタープライズ、ソーシャル/ゲーム、スタートアップ

玉川憲氏(司会)/三谷慶一郎氏/伊藤直也氏/孫泰蔵

IT業界は2つの世界に分かれたのか?

エンタープライズ、ソーシャル系で全然文化がちがうように見える。

  • エンタープライズ
    • 資本力、業務系、IT=インフォメーションテクノロジー
  • ソーシャル/ゲーム
    • 新技術の採用を厭わない。IT=インターネットテクノロジー。
  • ワーク・シフト(書籍)
    • 今までの常識を見直さなければならない。
    • 変化に目を閉ざすな。
    • 過去の成功にとらわれない。
    • 働き方を予測する。
    • 未来について後回しにしない。
  • 自分の属する世界から距離をとって見る。

三谷さんより(エンタープライズ

自己紹介

エンタープライズのいままでとこれから

  • いままで
    • 省力化、自動化中心
    • バックオフィス業務中心
    • 信頼性、安全性、高品質を重視
    • 成功要因は、要求仕様収束と大規模PJの安定的推進
    • 領域としては今後も存在
    • グローバル化
      • グローバル企業への対応
      • グローバルリソースのマネジメント
  • 民間投資の伸び
    • 日本はほとんどない。1995年から横ばい
    • 米国は5倍
  • IT投資と効果(生産性の向上)
    • 米国:80年台は効果があまりなかった。00年台で相対的に大幅に伸びた。
    • 日本:80年台は効果がとても上がった。00年台で相対的に下がってしまった。
    • 日本に80年台に効果があがったのは、現場レベルの高さ。(省力化、自動化が効果的)
    • 2000年台は、企業を変革する方向に変化している。
      • 日本ではそもそもこの「付加価値向上」に方向が向いていない。
  • これから。
    • バックエンド×自動化 → フロント×付加価値創出
  • CIOミッションの変化
    • 「ITを活用して新たなビジネスを創出する」
  • IT人材ケイパビリティ
    • システム設計、開発 → PM → ITマネジメント → 業務改革 → マーケティング
      • これらは積み上げである。
  • これから。
    • ITでしかできないことをやらなければならない。
    • フロント業務中心
    • 迅速性を重視。Quick & Dirt
    • ユーザとともに構想する「デザイン型人材」
      • 言語化されていない課題の発見
      • 解決に向けた集合知の活用
      • 評価を繰り返すことによる成熟化
    • 新しいパラダイムへシフトしていくために、スタートアップ、ソーシャル/ゲームと協調していく必要がある
  • アメリカができて日本ができなかった理由
    • 文化、組織。ダメなら潰す、トップダウンの文化がアメリカにある。

伊藤さんより(ソーシャル)

自己紹介

  • niftyはてなGREE
  • サーバ/インフラを支える技術 (書籍)
  • 大規模サービス技術入門 (書籍)

WEBサービスの世界

  • 2つのB2C
    • 既存のビジネスをITで提供
      • EC、交通予約とか
    • ITそのもので価値提供を行う。
      • 検索、SNS、コミュニティ、ゲーム
  • これまで
  • PostPC
    • PCインターネットは終わった。
      • 儲かったのはGoogleだけ。飲み込んだのは広告ビジネスの資本のみ。
    • WEBの理想が相対化された。
  • 開発トレンド
  • 現状の課題
    • モバイルプラットフォームの寡占、アプリストアの飽和
    • 国内市場の相対的縮小・飽和
    • WEBの大衆化
  • 地域別利用者
  • Consumerization
  • 成功例
  • あるべき姿
    • 建前のないベストプラクティス
      • WEb開発が生み出した最良のものを使う。
    • モバイルインターネットの波には抗えない。
    • WEBはインターネットになった。(ホッテントリ

孫さん(スタートアップ)

自己紹介

  • Yahoo 創設者との出会い
  • 元・学生起業家
  • パズドラ

スタートアップ

  • 年間投融資総額
    • 2006年の半額。アメリカの20分の1
  • 悲観的になる必要はまったくない。
    • 統計に表れないものがある。ちゃんと盛り上がってる。
  • 誰でもスタートアップできる時代に
  • EXIT戦略は、M&Aが主流に
    • いまやIPOは殆ど無い。
    • マネタイズの話はナンセンス。
      • 客を集められるだけで、買収される。
  • ベンチャーのカジュアル化・大衆化
    • スタートアップムーブメント
  • シリコンバレー
    • 300万人人口
    • 17,000社/年 - 12,000社/年 = 5,000社/年
    • ベンチャー生態系がある。
      • 起業家育成、融資プログラム、起業支援、投資家育成、産学連携、再起業支援、ネットワーキング
  • 目標
    • 2030年までに東アジアの世界一ベンチャー生態系をつくる。
  • 能力のあるプログラマー、エンジニアはスタートアップに引っ張りだこ。
  • バンドを組むようにスタートアップすればいいのでは。
    • 役割が集まったら、スタートアップ。
    • うまく行かなかったら解散

パネルディスカッション

ウルトラエコシステムでどんな影響が?

グローバル化で働き方はどう変わるの?

  • スタートアップにおけるグローバル化(孫さん)
    • 最初からグローバル視野
    • 先に英語で開発することを推奨している。
    • グローバルは強制ではなく、チャンスだ。
    • 日本語で作ってしまうと、日本文化の暗黙の了解で作ってしまう。
  • エンタープライズにおけるグローバル化(三谷さん)
    • 国内に閉じた開発は無理がある。目と目の会話はない。ネットワーク越し。
    • グローバルに攻めるエンタープライズ開発も。
  • ギークはどうする?(伊藤さん)
    • github では当たり前。英語で作れば英語でpullrequestがくる。
  • インド人の英語は独特だが、欧米人が理解しないと仕事にならない。逆転現象。
    • そういうものを日本でも起こす。

参加者質問:三谷さんからデザイン能力の話があったが、ドメインを理解し俯瞰できるウルトラマンがいればスタートアップするのでは?エンタープライズに必要?

  • 三谷さん
    • お客様に入り込み、顧客の見えないニーズ/課題を見つける。一緒に考える。というのをデザインと表現。
    • 問題発見、問題発掘の能力が重要。
  • 伊藤さん
    • 役割分担が重要。
    • オバマの件も、CIエンジニアがキーマンになった。
      • 別にその人はオバマに興味がなかったはず。

参加者質問:ソーシャルへの人材流出がある。エンタープライズでの開発者へのフォーカスの手段は?

  • 三谷さん
  • 伊藤さん
    • SIerからの転職のモチベーションは、8割が「自分の作ったものに対するフィードバックがほしい」。
    • まっとうなフィードバック。使われている実感。が必要。

まとめ

  • 働き方を予測しながら、幸福と豊かにする働き方を。
  • 所属する世界における本質を見るには?
    • 違うフィールドを見る。自分のフィールドを距離をおいてみる。
  • 三谷さん
    • Open, Speciality, Professionalism
    • 自らのスペシャリティを確立が必要。
    • どこのために何をやるのか。をいまいちど。
  • 伊藤さん
  • 孫さん

たのしい自分戦略 -セカイとカイシャと自分の仕事を考える-

http://devlove.doorkeeper.jp/events/2503 参加時の殴り書きメモ

まず

  • 自分戦略を踏まえて「会社」を考える。
  • アジェンダ
    • 会社とはなにか
    • 会社と自分との関係を考える
    • スタートアップと目標設定
  • 会社はツール
    • 使われるものじゃなくて使うもの
  • 使いたい会社とかかわる
    • なければ使う。作らせる。

前振り

  • 自分戦略をやりたくない。。。
  • ソフトウェア技術者の戦略
  • 客観的でもなければ、実力勝負でもない。
  • 個別ケース以上は話しづらい
  • 起業
    • 全力でリスクを取れるか、リスクを下げられる事情がある場合にはいいけど
  • 成功した人はバイアスがかかる。
  • 失敗した人は語りたがらない
  • 現実から全力で目をそむける
    • (現実がみえなくなるくらい)マクロの視点で

会社とはなにか

法人とは

  • 民法(一般的な話) + 会社法(会社固有の話)
  • 民法での規定
    • 権利を有し、義務を負う
  • 法人 = 人間みたいな人の集まり
  • 自然人 = 普通の人
  • 任意団体
    • 銀行口座がもてない
    • 団体として会場が借りられない
    • 何かあったら個人に責任が降ってくる
  • 法人
    • 営利法人、非営利法人、法人以外
    • ポイント;営利
    • 営利団体は、構成員に利益を還元できる。→非営利はできない。
  • 営利団体
    • 合議制だと、意思決定がやりづらく、冒険がしづらい

会社の問題点

会社と自分との関係

会社とどう向き合うのか

  • 目的があったほうがはやい
    • お金が欲しい、は実現方法が難しい。結論が出づらい。
  • 何かやりたいという動機
    • ひとりではできない、
    • 会社はツール
    • 会社なら平日の昼間からできる。
    • うまくいったら利益
    • 組織を大きくしやすい
    • 個人では扱いづらいこともできる
  • 問題
    • 「やりたいこと」は都合よくみつからない。
  • 体験談
    • はじめるまで1年
    • 利益がでるまで3年と数百万
    • 簡単ではない。
  • やりたいことの実現方法
    • 社内の事業
    • 他社と組む
    • 個人でやる
    • 非営利団体でやる。
    • 自分の会社
      • 時間を投入できる、しばらく赤字でもOK、関係者にも安心感、本気度は伝わる。
  • 「あったらいいな」から始める
    • あったらいいなを考える。
    • 実現方法を考える
    • 実行する。

スタートアップと目標設定

  • 大きい言葉(「世界を変える」)
    • 開発現場とのギャップ
    • ついうっかりつかってしまう
    • 本当に変わるの?
  • なんで大きい言葉を使うのか?
    • 会社は遠くの目標がほしい。
    • 会社は何をやってもいい。
      • 何をしていいかわからなくなる。
    • 適用しないと死ぬ
      • 迷走と区別がつかない
    • 変わらない目標は、遠くの目標になってしまう。
      • 多少ブレても誤差の範囲
      • 無限遠点の目標
  • でもすべてがそうではない。
    • 「Social Change」
    • ケント・ベック XP入門
      • 「ソフトウェアは新たな社会構造を創る機会がある」
    • オブジェクト指向PGのためのパターン言語
      • 25年前
      • ずっとブレない
    • 本気で変えようとしつづける。

ダイアログ

すすめ方

  • 新しい事業に思いを馳せる
  • 共有
  • 付箋に書いて貼る
  • 全員で話す

共有

  • Sunにはピープルマネージャーという役職がある。
    • 部下を売りこむ。
    • タレントとしてどうするか。
    • コミュニケーション担当マネージャーもいた。
    • エンジニアはコミュ力なくていい。

まとめ

  • 会社に負のイメージがないか?
  • でも会社ってよくできてる。
  • 「会社」ができること。可能性。
  • 会社はツール