makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「エンタープライズアジャイル勉強会 2016年7月セミナー」に参加しました

2016/7/20(水) 「エンタープライズアジャイル勉強会 2016年7月セミナー」に参加してきました。

エンタープライズアジャイル勉強会 2016年7月セミナー
https://easg.smartcore.jp/C22/notice_details/VlRFSU5nPT0=

場所は品川インターシティA棟12階のオージス総研さんです。
この日のテーマはDADとSAFeの紹介でした。

ちなみに私、DADやSAFeの講演は何度か聞いたことありました。
ブログにも何回かメモ書いてた覚えがあるので纏めてみる。

DAD
SAFe
この日は両者揃い踏みということで、両者を比較するにはもってこいのイベントです。

以下、メモ。


コカコーラ vs. ペプシ・・・みたいな話なのか?的視点からみたDA2.0


20160720_01.jpg

講演資料のダウンロード



ご案内文より
  • DADは去年の半ばくらいからコンテンツが広がってきた。
  • Webの上でもSAFeを意識して公開ライブラリとしている。
  • SAFeと同じになっちゃうんじゃないの?という疑問もあるが、でもDADとSAFeは立ち位置が結構違う。

HPE(ヒューレット・パッカード・エンタープライズ)はSAFe推し
  • HPEでは、「テストだけじゃダメだよね」ということでポートフォリオとかをサポートしていこう、としている。
  • SAFeの認定を受けて、ゴールドパートナーとかになってる。
  • SAFeをやりながらこっそりDADをやる本を出した。

エンタープライズ・アジャイル実践入門(Think IT Books)
藤井 智弘
インプレス (2016-01-18)
売り上げランキング: 462,491



DADの歩み
  • DADは3段階で進化してきた。
  • 0.x
    • IBMのDB2とかWebSphereとかでDADをやっていた。
    • 当時、「アジャイルなんかやりたくない」という人ばかりだったが、CTOが「アジャイルでやれ」と言った。
    • IBMをアジャイル化するために外部からコンサルタントとしてスコット・アンブラーがやってきた。
    • スコット・アンブラーがメンターをやりながら世界を行脚して培ったのが0.x。
    • アンブラー曰く、早期バージョン。
  • 1.x
    • DAD本が出版されたのが1.0。
    • 6月にDAD本が出て、同時にアンブラーはIBMを辞めた。
    • DADのバージョンアップはWebの上のみで行われている。書籍ではない。
    • 2012年Disciplined Agile Consortiumという団体をカナダに作った。
    • DADのコンソーシアムであり、IBMの手から離れてメンテされている。
    • DADは500ページくらいあるので、読み物として100ページくらいのイントロダクションの本が出ており、翻訳中。
  • 2.x
    • Web上で今公開されているのは2.x。
    • 今まではDADは開発者中心だったが、IT運用とかシステム全体まで見ていこう、と広がっており、成長中。
    • 2.xの翻訳も今やっている。イントロダクションの翻訳も停滞中。

Disciplined Agile Consortium
  • スコット・アンブラーはCertification(認定)制度はやってはいけない、と言っていた。
  • でもDisciplined Agile ConsortiumがCertification(認定)を始めた。アンブラーは腹黒いけど好き。
  • Consortiumへの登録はお勧めする。無償で登録できて、簡単にメンバーになれる。
  • このサイトには大事な所があって、ガチな人のディスカッションがいくつかあって面白い。

Disciplined Agile 2.X
  • DA2.0の1枚絵はフラット。それに対してSAFeは階層化されている。
  • DA2.0自身は大規模向けフレームワークではない。スケールアップしていくためのファクターとアクションを整理している。
  • コンソーシアムのサイトでは、組織の構造に対する議論が増えている。
  • ガバナンスによる議論とかオペレーション、サポートまで入ってきている。

Desciplined Agile Manifesto
  • DA2.0で、 Desciplined Agile Manifestoを出し始めた。
  • ぱっと見、アジャイルマニフェストと同じフォーマット。
  • 「Consumable Solution」を「使用可能なソリューション」と訳した。
  • スコット/アンブラーは「コンシューマビリティを向上させる」と宣言した。使い倒す、という意味。
  • システムとして動いて終わりじゃない。
  • システムを使うために組織構造を変えないといけないなら、そこまでやることで効果が出せる、というところまで踏み込む。というのがコンシューマビリティ。特徴的なキーワード。
  • 「利害関係者」は、カスタマーより広い。影響をネガティブ/ポジティブに受ける広範囲の人。

Principals
  • PrincipalsのNo13とNo15は非常に特徴的。
  • No.13: 組織的な再利用を積極的に活用していこう。
  • No.15: 組織のエコシステムはアジャイルチームだけでなく、非アジャイルをサポートできる柔軟なものでないといけない。
  • エンタープライズアジャイルに対する見方としてSAFeとDADが一番違うのは
    • SAFe: 上から下まで含めてアジャイルの事業体を運営して\いこう
    • DAD: 今のエンタープライズはどうなっているかを見ている。みんながアジャイルというわけではなく、既存の技術で動いているチームもあるよね。すべてがアジャイルとは限らない混在の中で、どうやっていくか。
  • これがDADとSAFeの大きな違い。
  • DADとSAFeはペプシとコーラのように違うのか、というとそうじゃなくて、補完的なもの。
  • DADはステップを踏んでいくイメージ。きちんと現状を踏まえてやっていきましょう。というのがPrincipal No.15に関係がある。
  • これが典型的に現れているのがライフサイクルモデル。

DA2.0で頻繁にでてくるキーワード
  • 1.Context
  • 2."One size fit all."  または "Prescriptive" (NGワード)

4つのライフサイクル
  • DAD1.0ではプロジェクト期間をRUPから引っ張ってきている。
  • それにフェーズを3つ降っている。方向付け、構築、移行、の3つ。コードを書くだけでなく、教育とかもやってもっていく。
  • DA2.0になってから、このサイクルが大きくなった。
  • 「方向付け、構築、移行」の前に「コンセプト」が付いて、最後が「運用」になった。
  • コンセプト → 方向付け → 構築 → 移行 → 運用、となったが、5フェーズにはしてない。
  • 「Context」というのは、アジャイルやりましょう、と一言で言っても、置かれた環境によって変わりますよね、という考え。
  • 4つのライフサイクルがある。
  • 「DAD 基本/アジャイル ライフサイクル」では、真ん中の構築はスクラムと一緒。
    • その前の「方向付け」はRUPと同じ。
    • RUPは「方向付け、推敲、作成、移行」の4つ。
    • 4つ目の「推敲」を置くとそれに縛られるので置きたくない、とスコット・アンブラーは言っていた。
  • 最終的には「DAD アドバンスド/リーン ライフサイクル」と、リーンまで行く。
  • DADがWebでDA2.0になって、ライフサイクルが2つ増えた。
    • 継続的デリバリーライフサイクル
    • 探索的ライフサイクル (リーン的ライフサイクルと裏で言ってる)
  • みんなコンテキストが違う。その場合にとるべきアプローチは2つある。
    • 1.最大公約数を取って間引くアプローチ
    • 2.パターン化して肉付けしていくアプローチ
  • 前者はどかーんというのを知らないといけないので大変。
  • DADは、各場のアジャイルのコンテキストを理解しましょう、というスタンス。

キーワード2
  • "One size fit all."  または "Prescriptive" (NGワード)
  • DADはPrescriptive(規範的)ではない。ゴール駆動だ。

ゴール駆動
  • やりかたはコンテキストに合わせて変えないといけない。やりかたはお客さんによって変わる。
  • なのでDADは手順とかWBSを出すよりも、何を検討しないといけないかを定義して、オプションを設けている。折衷的なアイデア。
  • ゴールと、やるべき中身と、取り得る選択肢を定義して、みなさんに議論してもらって判断してもらおう、というのがDADの考え。
  • なのでDADはプロセスディシジョンフレームワークに名前を変えた。
  • 判断できないなら、判断要素を提供する。
  • How toはいっぱいいろんな本に書いてあるので、判断の仕方をDADは提供している。
  • 例えば、チーム編成を考えないといけないときに検討しないといけないことをバーッと書いている。
  • それぞれにメリデメと選択肢が提示されている。それぞれにWebで議論ががーっと書かれている。
  • 開発のところから少し範囲を広げようというのがDAD。
  • コンテキストに応じた調整。
  • DADは大規模向けではない。本の帯には大規模、と書いてあったが、翔泳社の人が書けというから入れただけ。
  • 可変要素=スケーリングファクター
  • Deliveryという開発のタスクではないので、DADからDeliveryという単語を削除した。
  • DA2.0はDelivery以外の要素がたくさん入ってきている。
  • Webの記述のレベルはムラがある。

Why DA
  • DA2.0が有効だとなぜチームが考えているか、9個の理由を挙げている。
  • No.2の「現実的」の趣旨は、みんながみんなアジャイルじゃないよね、というコンテキストを元に考えているという点。
    • Pragmaticを「現実的」と訳した。
  • No.5の「スケーリング」とは、「 状況に合わせて調整する能力」のこと。
  • No.8で、DADはワーキングソフトウェアだけじゃなく、ソリューションをデリバリーする、と言っている。
  • No.1の「スクラムが捨て去ったもの」についてだが、スクラムは開発だけにフォーカスしていて、準備や企画や移行がないが、DA2.0はそれを拾い上げている。


SAFeとの比較
  • スコット・アンブラーがDADとSAFeの比較について述べている。
  • 戦略 = 選択肢を多く提示して判断してもらう
  • DADとSAFeでは「エンタープライズ」の捉え方が違う。
  • 判断の材料を提供する(DAD)のか、流れを提供する(SAFe)のが、が違う。

私がなぜ未だにDADをやってるのか
  • 日本のお客さんは 「say agile」 が多い。
    • 上がアジャイルやれ、と言う。
    • 下が、何をやればアジャイルですか、と言う。
  • 怖いのは、言葉が独り歩きすること。 (例:アジャイルはドキュメント作らないんでしょ)
  • コンテキストとか判断を略してオペレートだけ残ると、それだけやって失敗する。
  • 自分たちで判断して改善していくというところまでは、そのやりかたでは行かない。

Links
  • DevOpsの中でなにをやらないといけないのかね、というのを連載で書いてる。
  • http://disciplinedagiledelivery.jp/tag/devops/
  • サンプルとして見てもらう。ぜんぜんツールの話は入ってない。



機敏な製品リリースを可能にする企業内の連携モデルを提示するSAFe (Scaled Agile Framework) のご紹介+α


20160720_02.jpg

講演資料のダウンロード

知識創造企業
  • SAFeは「知識創造のコンテキスト」を形成することを助け、アジャイル企業への転換を支援する
  • 野中さんの論文も開発だけフォーカスしてるんじゃない。

SAFe (Scaled Agile Framework)とは
  • SAFeの階層はこれまで3階層だったが、最新版は4階層になっている。
  • 戦略的な狙いを定めて、チームまでどう連携させていくかがSAFeの狙い。

SAFeの期限:過去、現在と将来
  • 2012年は書籍「アジャイルソフトウェア要求」が出版された年で、SAFe 1.0だった。
  • 今はSAFeは、日本語は3.0,海外は4.0になっている。

ゴール: スピード、価値、品質
  • SAFeの組織として共有すべき理念 = リーンソフトウェアの家
  • 屋根の価値を早く提供するのが共通の目標。リーンの大野耐一の考えを受け継いでいる。
  • 理念を共通化することによって、デリバリーサイクルを縮めていく。
  • 家の真ん中にある柱が「プロダクト開発フロー」で、チームで守るべき原則を定めたもの。日本語に翻訳されていない。

プロダクト開発フロー: 8つのテーマ
  • 本では省略されているので是非読んで欲しい。
  • 価値は早く提供するほどよい。価値は時間が経つほど低くなる。後追いはなかなか勝てない。
  • かんばんのWIPで数を抑え、スピードを重視する。

アジャイルリリース列車(ART)
  • ARTは開始終了日を全チームで合わせる。
  • 2週間の開発が終わると、システムチームが全コードを統合してデモ評価できるようにする。

体制
  • チームレベルではPMはいない。POとSMはいる。
  • プログラムレベルでは、POに相当するのがプログラムマネジメント。
  • 複数のチームを連携させてやっていくのがRTE(スーパースクラムマスター)

SAFe 4.0で変わった点
  • 4.0から、すべての階層でカンバンが入っている。
  • 単サイクルで開発することもあり。
  • 4.0で1階層増えている。


感想


DA2.0という新しいバージョンの概要を知ることができたのは収穫でした。
SAFeとDADの比較も興味深いですね。
DADは以前、読書会があったのでそれ契機で結構読んだのですが、SAFeの「アジャイルソフトウェア要求」は積読っぽくなっています。
どっかで読書会、やらないかなぁ (≒ 1人で読むの辛い・・・)

関係者の皆様、ありがとうございました。

スポンサーサイト

「第3回 マイクロサービスアーキテクチャ読書会 #MSA読書会」に参加しました

2016/7/16(土) 「第3回 マイクロサービスアーキテクチャ読書会 #MSA読書会」に参加してきました。

DoorKeeper
https://architect-club.doorkeeper.jp/events/48267

場所は住友不動産新宿グランドタワー14Fです。
参加者は40人くらいでしょうか。

以下の書籍をターゲットとした読書会なのです。

マイクロサービスアーキテクチャ
Sam Newman
オライリージャパン
売り上げランキング: 3,746


今回が3回目ですが、一応これまで全部参加してます。
ウチの部署で開発してるフレームワークがマイクロサービスを意識してたりするので、この本で勉強しようと思った次第なのです。

今回は4章が範囲でした。以下、個人的メモ。


第4章前半: @tenten0213 さん


Msa読書会#3前半 from Takehito Amanuma


4.1.1 破壊的変更を回避する
  • JAX-RSのObject Mapperの設定で、未定義のプロパティがあっても無視する設定を入れておく。

4.1.4 内部の実装詳細を隠す
  • case文やif文でサービスをスイッチさせるのは辛い・・・

4.3 共有データベース
  • DBスキーマ変更のタイミングでコンシューマ側を壊してしまう可能性がある。
  • ロジックが分散して凝集性と疎結合が失われる。

4.5 オーケストレーションとコレオグラフィ
  • 図4-3のオーケストレーションの例で、顧客サービスは「神サービス」と呼ばれることがある。
    • 神サービス = 各サービスのハブとなるサービス
    • 命令されたことだけやるサービス = ドメイン貧血症のCRUDサービス
  • コレオグラフィ = 各サービスが、顧客作成イベントを購読(subscribe)している。
    • ビジネスプロセスがシステムに暗黙的になってしまう。
    • 各サービスの監視が必要。
  • 監視をするプロダクトの例
    • Zabbix ・・・ 統合監視ソフトウェア
    • Zipkin ・・・ ネットワーク的に分散したAPIコールを分析して可視化
  • 読書会主催者の川島さんのQiita記事


ディスカッション No.1
 お題:オーケストレーションとコレオグラフィ、どちらを採用すべき?



各テーブルでディスカッション。私のテーブルや他のテーブルでは以下の様な意見が出ました。
  • コレオグラフィは各サービスがポーリングするので、ポーリング間隔が長いと遅延が発生するのでは?
  • コレオグラフィってオンラインバッチとかキューっぽいのかな。
  • 最初はオーケストレーションで設計して、サービスが増えてくるとコレオグラフィに切り替えるのが現実的では。

(つづき)

4.6.2 ローカル呼び出しはリモート呼び出しとは異なる
4.7.2 アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)
  • さまざまなRESTの形式を比較したリチャードソン成熟度モデル
  • Lebel 0(開始点):
    • URIとHTTPメソッドが1:1
    • 例:失敗してもStatus Codeは 200 で、レスポンスボディのXMLの属性名<appointmentRequestFailure>で失敗を知らせる。
  • Level3
    • 状態と振る舞いを公開する。
    • クライアントが次にやるべき振る舞いを<link>のrelやurlで示す。
    • HATEOAS

4.7.3 JSONか、XMLか、他の何かか
  • HAL(Hypertext ApplicationLanguage)が一番使われている。
    • JSON用のハイパーリンクの一般的な標準や規則を提供する。
  • その他の仕様としてSIRENとかJSON APIなどがあるが、デファクトスタンダードは無い。戦争になっている。

4.7.5 HTTP上のRESTの欠点
  • フレームワークによってはPUT/DELETEに未対応のものある。
  • スタブを簡単に自動生成、というのが使えない。とはいえライブラリでサポートしてくれるものある。(例: stubby4j)

4.8.1 技術選択
  • エンドポイント側で対処していきましょう。ミドルウェアに依存しすぎないこと。

4.8.2 非同期アーキテクチャの複雑さ


ディスカッション No.2
 マイクロサービスアーキテクチャに適用するならどっち? 
  • リクエスト/レスポンス
  • イベントベース


テーブルごとにディスカッションし、いくつかのテーブルに発表いただきました。出た意見は↓
  • リクエスト・レスポンスでも非同期にできる。イベントベースも非同期。なので使い分けは場合によるのでは。
  • 2択を出しつつも、両方とも使うんじゃないの。
  • マイクロサービス間は「イベントベース」にして、クライアントからの呼び出しはRESTで「リクエスト/レスポンス」にする。
  • 両方を同居させてマイクロサービスを作るのかなぁ。
  • 非同期でもリクエスト/レスポンスはできる。

(つづき)

4.10 Rx(Reactive Extentions)

第4章後半: @syobochim さん


第三回マイクロサービスアーキテクチャ読書会(後半) from Mizuki Wada



4.13.1 最大限の先送り
  • XPath ・・・ あいまいにデータを指定できるので、フィールド構造を曖昧にできる。
  • 耐性のあるリーダー by Martin Fowler

4.13.5 複数のサービスバージョンの同時使用
  • 有名なサイト「The Twelve-Factors App」に、2つを直すのはダメ、と書いてある。
  • 4.13.5は、エンドポイントもサービスも両方とも旧新2つをサポートする。
  • それに対し「4.13.4 異なるエンドポイントの共存」は、エンドポイントのみ2つ持ち、サービス自身は1つのみ存在する。



ディスカッション No.3
  • 現場で「バージョンが必要ないように」って実現してますか?
  • まだしてない人は、どうすればいいと思いますか?
  • サービスとコンシューマ間の情報共有で何か工夫していますか?


各テーブルでディスカッションし、その後いくつかのテーブルでその内容を紹介いただきました。出た意見↓
  • Googleや「駅すぱあと」が公開しているAPIは、URIにバージョンが入っている。
  • インタフェースが変わるなら、バージョンが上がる、というよりも、そもそも別サービスじゃね?
  • メジャーバージョンアップって、そもそも別サービスじゃね?(破壊的変更だし)
  • でも、セキュリティ対策で、Getでクエリパラメータで送っていたのをPostに変えたくらいなら、別サービスにするんじゃなくてバージョンアップだよね。別サービスとは言えなくね?

(つづき)

4.14.5 フロントエンド向けのバックエンド(BFF)


4.15.5 ストラングラー(絞め殺し)パターン
  • ストラングラーアプリケーション by Martin Fowloer
    • 上から下へ根を伸ばしていって、最後に絞め殺す。
  • Isomorphic Survival Guide
    • P.62で、フロントエンドをクライアントとサーバに置いている。
    • 初回はサーバで初期表示を作り、次からはクライアントで初期表示させる。でもサーバとクライアントで言語別だと辛い。



ディスカッション No.4
 ユーザインタフェースの合成、どの手法を使っているか


出た意見↓
  • UIを分けて人を割り当てると、少人数のプロジェクトだとキツイかもしれない。
  • etc


感想


事前に4章は全部読んでから参加したのですが、内容が結構難しくて、あまり理解できないところも多々ありました。
ですが読書会で説明を聞いたりディスカッションすることで、1人で本を読むだけでは理解ができなかった箇所の大半を解決することができました。

お二人の発表者さん、具体例で説明してくださったり、深入りして調べてきた内容を紹介してくださったりと、参加者にわかりやすく説明する姿勢が素晴らかったですね。
参加する前と後で、理解度が雲泥の差です。感謝。

あと、お二人ともスライドの作りというか、絵が個性的でした。
例えば書籍P.53で「コレオグラフィ」をダンスに例え、各サービスがダンスで自分の役割を全うする話が出てきますが、それを説明するスライドは「ダンスの絵」になっていたりw
スライドの内容に合った絵は、内容をイメージ付けると共に、和ませてくれます。

とても有意義で質の高い勉強会でした。関係者の皆様、ありがとうございました。

NaITE #15「えくす・でぃ・でぃ・ぴぃ概論&入門ワークショップ」に参加しました

2016/6/25(土) NaITE #15「えくす・でぃ・でぃ・ぴぃ概論&入門ワークショップ」に参加してきました。

connpass
http://nagasaki-it-engineers.connpass.com/event/31984/

場所は「エセナおおた」です。自宅から自転車で10分かからないくらい。
参加者は20名くらいでしょうか。

自社の業務で開発プロセスの整備・適用推進を担当しているのですが、その中に保守に関するガイドがあり、XDDPの要素を取り入れています。
清水さんの本もじっくり読みました。

「派生開発」を成功させるプロセス改善の技術と極意
清水 吉男
技術評論社
売り上げランキング: 50,551


そんなわけでXDDPに興味があり、会場も近かったので、ちょうど良い機会ということで参加しました。
今回は「派生開発カンファレンス2016」で実施したワークショップの再演だそうです。


オープニング


NaITE#15オープニング資料 from Akira Ikeda


主催が「NaITE(長崎IT技術者会)」となってますが、東京でやっている勉強会だそうなw


えくす・でぃ・でぃ・ぴぃ概論&入門ワークショップ


この日のワークショップ資料一式は↓でZIPが公開されています。
http://naite.swquality.jp/doc/NaITE15_doc.zip

派生開発カンファレンス2016の再演ということで、その時の資料は↓で公開されていますね。
http://affordd.jp/conference2016_program.shtml#subject9



以下、当日取ったメモ。
---

派生開発とは?
  • 世の中の93%が派生開発。
  • 母体の仕様欠落が特徴。派生開発には母体ソースコードがある、という特徴がある。ベースがある。
  • 往々にして母体の仕様の一部もしくはすべてが失われている
  • 短納期: 作る量があんまり多くない。なので納期が短いことが多い。
  • 合わないプロセス: 派生開発のやりかたが世の中にあんまりない。V字とかを少し改変してることが多い。プロセスがない。
  • 丸投げ: 「短納期」、「合わないプロセス」から、丸投げになることが多い。一人プロジェクトが多い。
  • デグレード: 新人とか他から来た人とかは母体の中身を知らないので、デグレードとか手戻りが起こる。
  • それで品質が下がって納期遅延になって、ヤル気が低下する。

派生開発の課題とは?
  • なぜうまく行かないのか。
  • 普段、我々がどうしてるか、を考えてみる。
  • 高品質で納期を守らないといけない。
  • そのためには部分理解でコーディングする。「部分理解」というのはXDDP提唱者の清水さんが好きな言葉。
  • 全部を理解する時間がない。なので見つけ次第コーディングする。



ワークショップ1: 「XDDPゲーム」


いったん講演を中断し、XDDPを適用する場合としない場合を体験してみるワークショップをやりました。
題材は派生開発カンファレンス2016のページに公開されてます。これが中々面白いw

まず「母体仕様書」が渡されます。

次に「変更要求仕様書①」が渡され、そこに書かれている変更要求を上から下へ順にやっていきます。
上から下に順にやっていくと手戻りが頻発するシナリオになっていて、なんども手戻りが発生して右往左往します・・・

次に「変更要求仕様書②」が渡され、合わせてTM(トレーサビリティマトリクス)も渡されます。
今後はTMを使って、変更箇所を先に洗い出してから母体に変更をかけていきます。

結果として、前者よりも後者の方が、時間は5分ほど速く、不正解の数も減りました。
こーゆうワーク、良いですね。
「見付け次第コーディング」の弊害について、楽しみながら本質に迫ることが出来ます。


再度、講演


ワークショップ終了後、再度講演の続きです。

新規開発崩し
  • 「品質を高めないとね」といくことで、「全体を理解してやりなさい」という話になる。
  • そこで「新規開発崩し」をやる。これは清水さんが好きな言葉。

部分理解
  • 納期厳守と高品質、両方はできない。XDDPは「部分理解しか無理」という思想。
  • XDDPは部分理解を前提としたレビュー中心の手法である。

見付け次第コーディング
  • 「ながら」作業なので無駄になる
  • 元に戻しにくい → コード劣化
  • 1個前にロールバックするのはそれほど面倒くさくないけど、3つ前ににロールバックとかは面倒くさい。
  • コーディングするのを少し止める、のがポイント。
  • すぐコードを触りたがる人が多いので、けっこう抵抗される。

ワークショップの結果
  • さっさやったワークショップで、XDDPを適用することでバグが2.8→1.93に減った。
  • 更に、時間が5分くらい早くなった。
  • つまり、コーディングを遅らせたりTMを作らせたりしても、時間は遅くなってない。

清水さんの言葉
  • 最後にやる「変更」にかかる時間を計測することで、数字として取れるはず。
  • 「変更」にかかる時間は事前に予想できるのだから、それ以外の時間は「分析」に当てよ。

変更プロセス
  • 変更プロセスは、V字の新規開発プロセスとは全然違う。
  • フロー右の「機能追加プロセス」は、クラスとかメソッドとかの単位で考える。
  • フロー左の「変更プロセス」は、コードの行単位で直す。
  • 完全なプロセスはXDDPは謳ってない。

XDDPの3点セット
  • USDM、TM、変更設計書

USDM
  • 動詞から仕様グループを出す。全部の動詞を書きましょう。
  • 基本的には処理なので動詞で書けるはず。必要な処理を動詞で抜き出して漏れを探す。

変更設計書
  • before/afterを書きましょう。afterだけ書くのはダメ。
  • 何を何に直す、と書く。
  • 認識のズレとかを無くす。

TM
  • USDMにTMをくっつける。
  • USDNとTMの粒度を合わせないといけない。
  • USDMがゆるいと、TMに全部○が付いてしまったりする。
  • TMの横軸に全部のモジュールを書く。全部書かないと漏れる。書く位置は、機能単位とかで固定する。
  • TMがでっかくなる、どうしたらいいか、というのがよく問題になる。
  • TMという名前もよくない。マトリクスを塗りつぶしたくなる人がいるので・・・。そうじゃない。
  • TMは、「私はここに影響があると思います」という調査の戦略を寝るためのもの。
  • 「そこ、ぬけとるやん」と言わせるためのもの。



ワークショップ2: 「明日からXDDPを始める」と想像してみよう


XDDPを導入に関して、「①良くなる点 ②悪影響 ③導入を妨げる障害 ④導入の中間目標」という4象限について考えるため、インジェクションマトリクスというものを作りました。 
各個人でいったん考えてインジェクションマトリクスを作り、それを1人1人発表していって、講師の八木さんが纏めてくださいました。
纏め結果はワークショップ資料一式( http://naite.swquality.jp/doc/NaITE15_doc.zip )の中に入ってます。

その中で出た意見をいくつかピックアップしてみる。

  • 変更時間の見積りを間違えると何もかもできてない可能性がある
    • → 確かに見積もりをミスると痛いので、パイロットをやるのがいい。

  • 「変更」の速度が出ないのは、前のドキュメントが悪い。そのまま進むとダメ。
    • 変更設計書の作りが悪いなら、変更設計書を作り直すべき。

  • 「全体」についてはXDDPの外枠で考えなければならない。XDDPはあくまで「差分のみ」に着目する。
    • 総合テストで全体をテストする。
    • 清水さんの本は、テストのことは2行くらいしか書いてない。
    • TMの右横に、テスト資産もつけておくと良い。
    • 全体感のあるテストが必要になる。

  • 保守性、リファクタリングの変更要求を入れろ、と清水さんは言ってる。



感想


講演もワークショップも充実していて、とても学びが多く楽しいヒトトキでした。
XDDPの本質を再認識する良い機会でした。

八木さん、関係者の皆様、ありがとうございました。

「Angularハンズオン#13 〜 Angular2でTodosくらいは作ってみたいという方向け 〜」に参加しました

2016/6/22(水) 「Angularハンズオン#13 〜 Angular2でTodosくらいは作ってみたいという方向け 〜」に参加してきました。

DoorKeeper
https://angularjs-jp.doorkeeper.jp/events/46362

場所は渋谷の21 Cafeさんです。
参加者は50人くらいでしょうか。

最近、Angularの勉強会をよく見かけるようになりました。
そんな私も仕事でAngular 1に触れているので、よく参加させてもらってます。
Angular 2のチュートリアルは↓の勉強会でお試し済み。

2016/4/27(水) Angularハンズオン#11 〜 Angular2を初めて触る人向け 〜
https://angularjs-jp.doorkeeper.jp/events/42335

こんときはAngular 2を扱った小冊子↓を無料で戴いて、ハンズオンで実際に実装してみて、とても勉強になりました。

シェルスクリプトマガジン vol.37
當仲寛哲 岡田健 佐川夫美雄 大岩元 松浦智之 後藤大地 白羽玲子 水間丈博 濱口誠一 すずきひろのぶ 花川直己 しょっさん 法林浩之 熊野憲辰 桑原滝弥
USP研究所 (2016-04-25)



ハンズオン


今回は講師の @albatrosary さんが用意してくださったToDoアプリをハンズオンで作りました。
https://github.com/albatrosary/ng2Todos

step1~step4まで、演習フォルダと解答フォルダ/解答例がきちんと用意されており、npmまわりの環境も整えられており、とてもハンズオンしやすいフォルダ構成でした。

makopi23もハンズオンの時間内にstep4まで実装できて、ちゃんと動きました。
ハンズオン中、随時GitHubにコミットしながら進めるようにしてしてました。GitHubのお勉強も兼ねて。
ハンズオンの成果は↓に上げてます。
https://github.com/makopi23/Angular2_Todo_Handson

Angular 1.5のコンポーネント機能は他の勉強会で学習していて、社内勉強会でも紹介したので、Angular 2のコンポーネント化もわりとすんなり頭に入りました。


感想


Angularの勉強会がだいぶ増えてきて、いつも参考にさせてもらってます。
ハンズオンやっぱいいですね。とても学びがある。

関係者の皆様、ありがとーございました。

「ウォーターフォールとアジャイルを考える」に参加しました

2016/6/21(火) 「ウォーターフォールとアジャイルを考える」に参加してきました。

connpass
http://ita-ws.connpass.com/event/32899/

Togetter
http://togetter.com/li/990231

場所は新宿のグロースエクスパートナーズ株式会社さんです。
参加者は80人くらいでしょうか。

先日5/18(水)、 "「アジャイルがダメだと思う7つの理由」について議論する会"に参加しました。
そんとき書いたブログはこちら。
http://makopi23.blog.fc2.com/blog-entry-214.html

たしかのこのイベントの後、雄介さんがこの会を提案していたように記憶しています。
ネタ的に繋がってますね。

あと、今回のイベントについて、後日、雄介さんがブログに書いてます↓

ウォーターフォールとアジャイルを考える
http://arclamp.hatenablog.com/entry/2016/06/23/172941

以下、スライドに無い口頭説明を中心に、当日取ったメモを書き起こしてみる。


講演


ウォーターフォールとアジャイルを考える #ita_ws from yusuke suzuki


はじめに
  • 今日は方法論の話に特化する。WFとアジャイル、どっちがいいかは後半のディスカッションで。
  • アーキテクチャの話はちょっと入れて、最後に例の牛尾さんのブログに触れる。

プロジェクトマネジメント
  • プロジェクトの定義で「有期性」がよく言われる。対として、「プロダクト」がよく言われる。
  • プロダクトのライフサイクルが終わるまで継続する活動。

失敗あるある
  • 計画の失敗
  • 実行の失敗 ・・・ スキルセットが合わなくて計画どおりに作れない。
  • 計測の失敗 ・・・ 進捗80%です、の報告のまま1週間経つ、みたいな。
  • 調整の失敗 ・・・ 明らかに遅れてるのに何も手を打たない。
  • PMはこのPDCAをどう上手くやっていくのか、というのが大事。

PMBOK
  • PMBOKは今年20年目。ソフトウェアのために作られたわけではなく、製造業のためにアメリカで策定された。
  • 90年代からプロジェクトマネジメントはこうあるべき、と整備されてきた。

ウォーターフォールの表 (P.11)
  • 横の5個(立ち上げ、計画、実行、監視・コントロール、集結)がプロセス。
  • 縦の10個(統合、スコープ、時間、コスト、品質、・・・、ステークホルダー)が管理領域。
  • PMBOKは今見ても面白い。網羅的に書かれている。ちょろっと見るだけでもおすすめ。
  • 計画・実行・調整を回していく。

PMBOK: 5つのプロセス
  • 計画プロセスにやることがいっぱいある。

PDCAをフェーズで管理する
  • PDCAをフェーズで管理するのがPMBOKで大事なポイント。
  • プロセスや知識領域よりは、フェーズというのが大事。
  • 大事なのは、フェーズを管理すること。
  • 要件定義、設計、実装、テスト、・・・
  • そのフェーズを決めて、フェーズごとに完了判定をしながら次へ進んでいく。

ウォーターフォールあるある
  • フェーズが完了していないのに先に進む
    • 計画が正しくない、実行に失敗、とかはあるが、フェーズが完了していないなら戻れ、は大前提。

アジャイル
  • ウォーターフォールへの反省が活かされている。時代背景もそう。
  • PMBOKが出たのが1996年なので、それより前の1980年代から議論があったはず。
  • 1990年代には「プロジェクトマネジメントはこうやるんだよ」というのが固まってきて、「それってイケてないよね」でアジャイルが出てきた。
  • ウォーターフォールは計画が失敗すると、実行、計測、調整は漏れ無く失敗する。
  • なので、ウォーターフォールは「最初の計画」がある程度正しい必要がある。
  • バイアスがどうしてもかかる。日付が来たら、終わってなくても終わってる、とするみたいな。
  • 最初にフェーズやプロセスへの分解を行う。分解されたものは、それぞれが、一番やるのに適切な人を連れてくる。
  • 分解を達成することを目的化しがち。そもそも何をするんだっけ、が抜けがち。
  • 分けちゃうことで頭使わなくなっちゃうよね。個々人の参加意識もなくなる。
  • PMがナレッジ職になってしまった。
  • 実行と計測の失敗は、PMの力量に関係ない。計画と調整がPMの力量により左右される。
  • 調整はぜったい出る。QCDSを調整する政治的な調整能力が大事。技術職でなく知識職。
  • PMの資格を取ってても意味がない。

逆転の発想
  • アジャイルは逆転の発想をしてる。
  • 失敗を前提にする。
  • 計画は、小さくして、精度を上げる。
  • 実行は、計画どおりに実行する。計画が小さいので実行リスクが下がる
  • 計測は、動くソフトウェアでやる。最終的な進捗の棚卸しは2週間ごとにやる。
  • 調整は、全員でやる。実行中はスコープ調整をやらない。
  • スコープ調整が粗くなる。
  • 失敗しても範囲が小さい。

PMがいない、フェーズがない
  • アジャイルはPMがいない、フェーズがない。
  • なので、PMがやることを全員でやる。結果として、PMの能力に依存しなくなる。
  • スーパーPMってなかなかいない。技術も最近は複雑で、ビジネスも複雑で、限界がある。
  • なので、一人で判断するのは難しいので、全員で分担してやりましょう。
  • プロセスそのものがマネジメント行為に織り込まれている。
  • 完了基準は時間。スプリント2週間の最後に、PMはいないので、みんなで計測する。
  • RUPとか、ウォーターフォールとアジャイルの中間にあるプロセスにはPMがいる。
  • アジャイルはPMがいないのが特徴的。あと時間駆動。この2つがアジャイルのすごく特徴的な部分。

制約というか前提
  • アジャイルには制約条件、前提条件がある。
  • PMには依存しないけどチームには依存する。なのでチームを成熟させていく必要がある。
  • ウォーターフォールは「調達」があって、その時々のタスクに応じて、スキルの出し入れができる。
    • ここには実装が得意な人をいれる、とか。
  • アジャイルはスキルの出し入れが困難になる。
    • 「知らない、できない」があると、「あの人ができるよ」としないのがアジャイル。
  • 全体の終了、という概念がない。できるところまでやるので、全体、というのが無い。
  • 「全体がわからないからアジャイルでやるんでしょ」という考え方。
  • プロダクトが終わるまで続ければいい、というのがアジャイルのゴール。
  • アジャイルの場合は、時間がきたか、プロダクトが終わるか、のどちらかまでは継続的に活動を続ける。

ウォーターフォールとの違い
  • 計画駆動(=ウォーターフォール)か、変化駆動(=アジャイル)か。
  • 調達もなにもかもうまくいくなら、理論的にはウォーターフォールの方が早く上手くいく。
    • ゴールが明確でない場合はゴールを探しながら進むしか無いが、作りながらウネウネと進む。
    • 時間がかかるかもしれないが、そちらのほうが効率がいい。
  • ケント・ベックはXP本で車のハンドルの例を上げている。
    • ハンドルをちょっとずつ調整して進む。ハンドルを見るんじゃなくて前を見て進んでいきましょう。
    • 道路の条件、まわりの変化にちょっとずつ合わせていく。
  • ウォーターフォールもアジャイルも、効率の良さを目指している。

PMBOKとアジャイル
  • PMBOKの第5版でもアジャイルに言及している。
  • ライフサイクルを3つ定義している。予測型、反復型、適応型(アジャイル)、の3つ。
  • PMBOKは予測型に最初からフォーカスが当たっているので、適応型でやろうとすると無駄が出てくる。
  • 3つの使い分けもPMBOKに書いてある。
  • 予測型は、最初になるべく決めましょう、決められるなら採用しましょう、というスタンス。
  • アジャイルは2週間とか短い反復でやる。
  • 予測型、反復型、適応型、と、下に行くほど変化に対応できるようになる。

アジャイルあるある
  • アジャイル、と言っているのにアジャイルじゃないもの。
    1. マネジメントがないもの ・・・ 計測とか計画をしない、とか。
    2. コミュニケーションが健全でないもの ・・・ チーム外に何かを説明するときにはドキュメントが必要になるので、作りましょう。
  • マネジメントはちゃんとしましょう。


アーキテクチャ
  • アーキテクチャはプロジェクトマネジメントの基盤。
  • 「構造」には「工法」がセットになる。
  • アーキテクチャを決める = 構造と工法を決める
  • スコープからタスクへの分解をする以上、必ずアーキテクチャがある。必ず誰かがアーキテクチャ設計をしている。
  • 最近は技術的複雑さが進んでいるので、アーキテクトが必要になることがある。
  • アーキテクトを不要にするには、前回のプロジェクトと同じアーキテクチャにすること。ERPとかパッケージとか。
  • アジャイルはPMもアーキテクトもいないが、プロジェクトマネジメントもアーキテクチャも必要。

アーキテクチャは選択肢を残す
  • アーキテクチャは選択肢を残す、というのが今的に重要。
  • 現在的なアーキテクチャは、決めない、ということ。
  • 大切なのはモジュール化。部品を交換可能にすることで、あとで取り替えられる。変化の境界線で分け、適切に組み合わせる。
  • 例:南北戦争における「銃」
    • 銃は壊れるところが決まっているので、交換可能にして、量産化が可能になった。
  • ゼロ戦が負けたのは部品交換ができなかったから、という考えもある。
  • 昔は銃とか大砲は一体型だったが、分解可能でメンテナンス可能になったのは、標準化とかが進んだから。
  • 成熟させてモジュール化していくことが大事。

MSA
  • サービスの分割
  • モジュールごとに、好きなタイミングでリリースしていいですよ。
  • システムごとにライフサイクルを好きに変えられる。
  • 昔は1個のシステムは1個のマネジメントでやるのが普通だった。
  • 今はサービスを分割することで、それぞれでマネジメントを合うようにやれる。
  • 必要なときに必要なものを割り当てるという思想。
  • ただし安全弁が必要。CIやカナリヤリリースなど。

例のあれ
ウォーターフォールのメリットは?
  • 特定の文脈ではメリットがある。
  • 「いまどきのシステム開発ではウォーターフォールにするメリットはない」はある程度そのとおり。
  • ウォーターフォールで考えられる領域は少なくなってきている。
  • リスクや変化をどう取り入れながらやっていくのは腕の見せ所。

質疑応答

  • 保守はインシデント駆動型なのでアジャイルっぽくなるのは当たり前。
  • アジャイルが安い、というのも嘘。
  • 全部決まっているならウォーターフォールのほうが安い。
  • 建築では構造と工法がセットなのは当たり前だった。

ディスカッション


雄介さんと参加者全員とで、「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」か?について議論しました。
議論で上がった意見はスライド後半(P.38~)に雄介さんが纏めてくださっています。
以下、個人的に取ったメモ。

そもそもWFは必要なのか?
  • 例のあれは、個人的見解では、正しい。
  • 今更「アジャイル、ウォーターフォール」を議論しても意味はない。
  • 個人的には、アジャイルの価値って、マネジメントもそうだけど、XPのライフサイクルを見るとわかるが「コードの共同所有」が挙げられる。
  • これが建築とソフト開発との決定的な違いを産んでると思ってる。
  • ウォーターフォールは中間成果物を作るが、それはなんの価値も生まない。
  • それを「コードで会話しようよ」としてが、それはソフトウェアでしかできないし、アジャイルのコアを活かした価値じゃないか。
  • 中間成果物を削減することで、アジャイルでも安くできる。
  • もしスコープを決められるのなら、それをインプットにしてアジャイルチームを作れば一番うまく行くんじゃないか。
  • WF型が合う局面もあるが、WFがアジャイルか、の2択じゃない。その間があるんじゃないか。
  • それはRUPでもない。RUPのイテレーションはミニWFなので。

とはいえWFを採用するケースは?
  • メンバーの力量が読めないなら、WFを選ぶ。
  • 基幹システム連携の場合、連携先の期間側がWFなら、こちらもWFでやるしかないかな。
  • 1年後の約束されたリリース(法律改正対応)とか
  • チームやプロジェクトが永続的ならアジャイルがいいのでは。
  • 発注者が公共(計画ありき/透明性の確保)ならWF。
  • 研究開発ならアジャイルが合う。
  • 期間に対してスコープが多い場合(大量リソース)ならWFがよい。
  • 保守開発でメンバーが決まっているならアジャイルがよい。
  • 請負契約だとアジャイルやりづらい。
  • ユーザ/開発者にヤル気がないならWF。
  • 発注側がスコープ確定を要求するならWF。


アジャフォール
  • 準委任で要件をアジャイルで決めて、スコープ確定したらWFで作る、というのアジャフォールと言う。


準委任契約
  • 準委任契約にしてもらった時は、お客さんが雄介さんの目を見て、「信じてるから準委任にするね」と言われた時。
  • この時、「下手な人は出せないな」と思った。
  • お客さんは準委任にするのに、稟議にすごい苦労していた。
  • 先行着手書でやる場合は、アジャイルで最初やって、状況が見えてきたらWFに変える。
  • お客さんがリスクを取ってくれている。

チーム編成
  • 素直な子を半分は配置する。
  • フロントエンドとバックエンドがぜんぜん違うアーキテクチャでは、おっさんはバックエンド、素直な子はフロントエンド、みたいにしてバランスを取ってる。
  • 素直だと、変なところを深堀しない。
  • タイムボックスで動いているので、わからないならすぐアラートを上げてほしい。
  • バックエンドは多少ベロシティ下がっても、しっかり作って欲しい。(なので、おっさんを割り当てる)
  • アジャイルでコードが書けない人は、テスターをやってもらっていた。
  • 教育のストーリーを入れさせてもらって、新人を投入した。
  • スクラムマスターはお世話係で、誰かが休むと穴を埋める

アジャイルの失敗のあるある
  • 細かい仕様変更に対応しすぎて、お客さんの要求を聞きすぎて、全体のコントロールができずに、プロダクトができない。
  • PMロス対応 ・・・ オレオレでやるのは、そもそも無理。コンサルやコーチを入れよう。

コーチは役に立つのか
  • ある程度のアドバイスは必要。
  • 週1回、ディスカッションに参加してくれると良い。メンターのような感じで。
  • いろいろ教えてもらった。「自分たちのことは自分たちで考えろ」という姿勢を教えてもらったことが一番大きかった。

感想


ちょうど、WFの経験しか無い、とあるプロジェクトへのアジャイル適用を支援しようとしている私にとって、タイムリーなネタでした。
最後のワークで、WFを採用する場合のシチュエーションとして「規模が大きいこと」という意見が出なかったのは意外でした。
(期間に対して規模が大きいこと、という前提付きの意見は出たが)
確かにボーイングの航空機開発やマイクロソフトの大規模ソフト開発でアジャイルが使われている、という事例紹介などを目にすることが多くなりましたが、「規模が大きい = ウォーターフォール」というイメージは無くなりつつあるのかなぁ、と思う次第でした。

こーゆうイベントは良いですね。また次回も参加したいです。
雄介さん、関係者の皆様ありがとーございました。

FC2Ad