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

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

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

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

「派生開発」を成功させるプロセス改善の技術と極意

posted with amazlet at 16.07.02

清水 吉男
技術評論社
売り上げランキング: 50,551

Amazon.co.jpで詳細を見る

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

---

オープニング

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

主催が「NaITE（長崎ＩＴ技術者会）」となってますが、東京でやっている勉強会だそうなｗ

---

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

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

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



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

派生開発とは？

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

派生開発の課題とは？

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

---

ワークショップ１： 「XDDPゲーム」

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

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

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

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

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

---

再度、講演

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

新規開発崩し

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

部分理解

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

見付け次第コーディング

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

ワークショップの結果

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

清水さんの言葉

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

変更プロセス

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

• 完全なプロセスはXDDPは謳ってない。

XDDPの３点セット

• USDM、TM、変更設計書

USDM

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

変更設計書

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

TM

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

---

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

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

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

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

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

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

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

---

感想

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

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

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

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

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

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

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

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

シェルスクリプトマガジン vol.37

posted with amazlet at 16.07.02

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

Amazon.co.jpで詳細を見る

---

ハンズオン

今回は講師の @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

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

先日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とアジャイル、どっちがいいかは後半のディスカッションで。
• アーキテクチャの話はちょっと入れて、最後に例の牛尾さんのブログに触れる。

プロジェクトマネジメント

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

失敗あるある

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

PMBOK

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

ウォーターフォールの表　（P.11）

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

PMBOK： ５つのプロセス

• 計画プロセスにやることがいっぱいある。

PDCAをフェーズで管理する

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

ウォーターフォールあるある

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

アジャイル

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

逆転の発想

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

PMがいない、フェーズがない

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

制約というか前提

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

ウォーターフォールとの違い

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

PMBOKとアジャイル

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

アジャイルあるある

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

アーキテクチャ

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

アーキテクチャは選択肢を残す

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

MSA

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

例のあれ

• 牛尾さんのブログ：　私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い
• 牛尾さんはと知り合いで、仲良くやってる。
• マイクロソフトの見解ではない。
• Windows10の自動アップデートも、マイクロソフトがアジャイル化した例。あれだけのことができるようになった。

ウォーターフォールのメリットは？

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

質疑応答

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

ディスカッション

雄介さんと参加者全員とで、「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」か？について議論しました。
議論で上がった意見はスライド後半（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を採用する場合のシチュエーションとして「規模が大きいこと」という意見が出なかったのは意外でした。
（期間に対して規模が大きいこと、という前提付きの意見は出たが）
確かにボーイングの航空機開発やマイクロソフトの大規模ソフト開発でアジャイルが使われている、という事例紹介などを目にすることが多くなりましたが、「規模が大きい　＝　ウォーターフォール」というイメージは無くなりつつあるのかなぁ、と思う次第でした。

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