１２月２１日に「スクラムの心」に参加した。
講師はセントラルソフト株式会社の林さん
以下にメモを記載する。
スクラムのロール
・スクラムマネージャ（SM）
→プロセスに責任がある
・プロダクトオーナ（PO）
・チーム
組織の関係性
様々なアクターや要素が絡み合い複雑
■階層型
リーダシップ
→大きな変化が必要なとき
マネジメント
→組織が安定状態にあるとき
■自立分散型（ファシリーテーション）
→絶え間ない変化が必要なとき
場を築き協働を促進する
「ファシリテーション入門」
エイブワグナーの言葉
・尊重の念をもって公平に接してもらいたいと考えている
・自尊の気持ちや同僚を尊敬する気持ちを率直に表現できず、他社との交流に悩んでいる
・多様性を活かして組織がうごくようにしたい。尊重によって職場の誰しもが成長しやすくしたい
・自分や他者が良い心の状態に変化するのを促進する方法をしりたい
アジャイルとは何か
・特効薬ではない
・アジャイルのためだけのものではない（マネジメント理論、PMBOK、コーチング、ファシリテーション、SWBOK）
・アジャイルは度合い
・アジャイルは道具（ゴールではない）
アジャイルソフトウェア開発宣言
＜４つの価値＞
・プロセスやツールよりも個人と対話
・包括的なドキュメントより動作するソフトウェアを重視する
・契約上の交渉より、顧客との強調を重視する
・計画に従うより、変化に対応することを重視する
アジャイル開発＝
十分な品質の動作するプログラムを短い単位で確認することでQCDなどのリスクを抑えながら、人やチームの工夫のモチベーションを活かし、今より良くなるような状況判断をし、適応のための自己改善の仕組みを持った統合的開発手法
(Twitterのつぶやき）
10つの質問（アジャイルに向く組織かどうか）
・現場のやり方を毎回変えているか
・笑顔がたくさんあるか
・安心して働けるか
・上下や横のコミュニケーションは活発か
・低いスキルのメンバーの力を活かせているか
・上司に気持ちよく改善の提案
・飲み会で上司や会社の悪口が無い
・組織の運営にグレーな所が無い
・無理を言ったり、怒鳴ったりする偉いひとがいない
・組織の運営の問題をオープンに議論できる
→組織文化とアジャイルの関係は深い
ポジティブ心理学
人は、自分の行動によって環境が変化しないと無気力を学んでしまう
（動物も一緒）
なぜアジャイルか
ソフトウェア開発環境の変化
３０年以上前のソフトウェア開発環境
パンチカードを開発計算センターに送る→計算結果を受け取る
（１）開発作業
（２）机上デバッグ、コーディング、先輩に質問、後輩の指導、仕様書の修正、息抜き
（３）計算結果の受け取り
市場→ビジネス→IT
＜ーーーーーーー 半年〜３年単位
なぜうまくいかないのか
契約した時から最後には要求が変わる
最後にはいらない機能多数
大量の工程間コミュニケーションコスト
リーンソフトウェア開発、ものづくり
リーンソフトウェア開発
・人間性の尊重
一人一人の存在価値や尊厳を認める
・科学的アプローチ
作業のムリ、ムダ、ムラを取り除く
・日本のものづくり
→トヨタ生産方式につながっていく
現代の経営
３人の石切工
仕事がうまくいかないときの反応
(1)文句をいう、無視する
石を切っている、生活のために仕事してる石切工
(2)自分で直す
聖堂をつくっている石切工
現場とQC
成功を導くマネジメントの基本原則は、部下に自己の能力をフルに発揮できる環境を与えること
会社とともに快適かつ幸福に感じることができるべき
自己の能力を発揮し潜在能力を実現することができるべき
ピープルウェア
われわれの抱える主要な問題は、そもそも技術的ではなく社会学的なものである。開発者は交換可能な部品ではない
リーダー
ボトムアップ型（開発型）、トップダウン（指示型）
一般的な管理技術、仕事内容の理解
ファシリテータ型
「みんなの力でやりましょう」
学習する組織を作る人
「目的と方向性はこうです。一緒にやろう」
官僚的管理者
「決まりに従いなさい」
スクラムの歴史的背景
「New new development game」→Scrum
スクラムの価値
・自己組織化→自発的決定を重視
・実測駆動型→その時の状況に適切に対応
・進捗ではなくて、あとどれくらいかかるかが重要。
スプリント
・１スプリントは大抵のプロジェクトでは１週間か２週間でやってる
・毎週、ミニデスマをつくる
スプリント＝疾走する
・スプリントの終わりにデモを実施する。
ユーザーストーリー
【フォーマット】
＜役割＞として＜機能、性能＞が欲しい、それは＜ビジネス価値＞のためである
プロダクトバックログ
プロダクトバックログを重要度で表すのではなく、デリバリーシーケンス（どの順番でリリースしていくのか）で示す方がわかりやすい
規模を抽象化したポイントで表現する（時間ではなく）。
（例）１機能などを１とする
理想時間で見積もったのをポイントにするなど
自分達のものさしをつくる
プロダクトオーナによる優先順位調整
→自社サービスの場合どうするのか
チームに意見を聞いて、プロダクトオーナが意思決定する
目的
目標というのは道しるべ 〜までにこの目標を達成する
目的 〜のために
目的と目標は混同しがち
要求の基本
ビジネス戦略(What)→(How)ビジネスオペレーション(What)→(How)システム要求(What)→(How)システム設計
いろいろな問題
・権限を発揮していた指示型マネージャが、権限のないスクラムマスターになるとどうしてよいかわからなくなる
→チームに権限があって、スクラムマスタに権限はない
・スクラムの矛盾構造
契約関係
・リーン開発の本質
リーン開発のあとがきより
ソフトウェア開発活動の本質は「発見」と「学習」であり、コーディングも含めて、常にトレードオフを伴う知的「設計」活動と位置づけるべきである。
〜中略
アジャイルに向いている組織文化
・意見が言えるオープンな文化
・ちゃんと改善される
・権威勾配がゆるやか
・多様性が尊重されている
どのように自己組織的チームに変えるか
SL理論 成長モデル
協労必要性、委任志向性
たとえスクラムでも、段階的に自律性を高めて行かなければならない場合がある
スクラムチームに必要なメンバーの質
→やや成熟、成熟
所感
よい開発をするためには、組織の文化とコミュニケーションが前提となる。
その上でどのように開発を進めていくか。
アジャイルにおけるさまざまな考え方を学ぶことで、チームによるものづくりの基本的な考え方を学ぶことができるとおもう。来年、アジャイル開発を再度突っ込んで学んでみようという気になった。
スクラムのスプリントに対する考え方を学ぶことが出来たことと、アジャイル開発に関する情報源を個人的に教えて頂いたのが収穫であった。
今年の目標１０３エントリー まであと３５
