2016/5/18(水) "「アジャイルがダメだと思う7つの理由」について議論する会"に参加してきました。
connpass
http://connpass.com/event/28977/場所はグロースエクスパートナーズ株式会社 オープンスペースです。
参加者は80人くらいでしょうか。
このイベント、
AEP読書会でいつもご一緒している藤村さんがFacebookで企画して、凄い早さで定員が埋まりました。
発端は鈴木雄介さんの
「アジャイルがダメだと思う7つの理由」というブログです。
当時、けっこー話題になってましたね。私も当時読みました。
- 全体スケジュールにコミットできない
- アーキテクチャ上の無駄が生じる
- コーチって何だよ
- 変化ヲ抱擁スルために固定化している
- 実証主義的な説明に過ぎない
- 手段が目的になっている
- アジリティはアジャイルだけのものではない
この日は、このブログネタをテーマに改めて議論するという趣旨だそうで、７つのテーマ毎にスペースを分けて議論しました。
また、鈴木さん自身の講演もありました。
鈴木雄介さんによるプレゼンテーション
鈴木さん曰く、アジャイルについて批判的に議論したいとも思いからブログを書くに至ったそうですが、酔った勢いもあったとか。
「７つの理由 ≒ 現場が超えないといけない壁」とのことです。
アジャイルの考え方は、「プロマネがやることをアジャイルのプロセスの中に組み込んでいる」点に着目されているようです。
計画ができないならアジャイル、計画できるならウォーターフォールの方が良い、とのこと。
テーマ毎に分かれての議論
議論したいオープンスペースに各自参加して議論しました。移動は自由です。
私は１つのテーマを議論したい、というより、７つすべての議論の内容を聞きたかったので、各テーブルを回ってました。
１．全体スケジュールにコミットできない
- ウォーターフォールでもアジャイルでも、途中のパスが違うだけで同じものができるのでは。
- ウォーターフォールとアジャイルで、それぞれ向いてる向いてないがある。
- 変化を許容できないものはアジャイルに向かないのでは。
２．アーキテクチャ上の無駄が生じる
- ウォーターフォールでも、アーキテクチャをしっかり決めても失敗するよね。
- バックログだけじゃなく、インセプションデッキとかも作らないとアーキテクチャは決まらないよね。
- アーキテクチャの無駄とは、最初にアーキテクチャを固めたのに、変化しまったことでは。
- Twitterの開発だって、最初はRailsで後でScalaに変えたけど、Railsを採用したのは開発スピードを重視したかったからなので、失敗ではない。
- アーキテクチャを決めるのに、最初にビジョンを決めるのが大事。（どう使ってもらいたいか）
- 小さく失敗できたほうが、アーキテクトとして成長できる。
３．コーチって何だよ
チームディスカッションの時、ペンを持ってないと発言出来ないルールを定めているようでした。
誰に発言権があるかを明確にする工夫ですね。
- 第三者的な人の方が、経営者とかにズバッと意見を言いやすい。
- アジャイルだとアーキテクチャについても小さな失敗から学べる。
- ウォーターフォールのようにアーキテクチャの設計が１回きりだと、自分のアーキテクチャが成功／失敗したのかさえ見届けることができない。
- 「コーチ」って言葉のイメージが、みんな共通ではない。
- コーチは、必要になったら呼ばれる位置づけなので、監視者のイメージで、押し付けと感じる人が多いのでは。
４．変化ヲ抱擁スルために固定化している
- 目の前のスプリントの見積もりさえ守れないなら、信頼なんて得られない。
- ２週間も予定どおりできないのに、半年とかのスケジュール立てても意味が無い。
- 信頼を上げていかないといけない。変化と信頼は両輪。
- 計画どおりに行くことが大事なのか、ゴールに到達することが大事なのか。
- 新しいものをチームに吹き込むのは、アーキテクトが言い出すのが効果的。開発チームは顧客のためだけに頑張っていると、新しいものを入れようとする暇がない。
- メンバーを固定すると、
- 同じ方向を向けない場合、人を変えたほうが上手くいく。
- 変化を拒絶する人に、どう変化を持ち込むか？
- 人とか技術より、文化を変えないといけないんじゃないか。それは１人では無理なので、仲間を見つけることが大事。
- 新人教育をアジャイルでやって、アジャイルが当たり前だと思わせるように教育するのが有効では。
- 外部の人から「アジャイルは良い」と言ってもらうのが効果的。外圧をかける。
５．実証主義的な説明に過ぎない
- アジャイルってハイテンションな人が多いけど、どうなの？
- 実証主義的に振り返るタイミングを作って改善していく。
６．手段が目的になっている
- お客さんから「アジャイルでやってほしい」と言われることがよくある。
- アジャイルという言葉が広まったせいで、後から撃たれることが多くなってきた。
７．アジリティはアジャイルだけのものではない
- アジリティとは「意思決定から、それが届くまで」とした。
- アジリティはアジャイル単品では無理。業務とかいろいろ関わるよね。
感想
見知った顔も非常に多く、あちこちで熱い議論が交わされていて、とても楽しいヒトトキでした。
あと鈴木さん、講演から場所の手配から懇親会まで、何もかも手配されていて、すごい行動力。
JJUG_CCCでも満席の部屋に自分で椅子を増設したりと、自分が先頭に立って行動する姿が目につきました。
こーゆう姿勢も、こーゆう盛況なイベントに繋がる一要素なんだと思います。
関係者の皆様、ありがとーございました。
5/17(火) 「要求の変化とマイクロサービスアーキテクチャ」に参加してきました。
DoorKeeper
https://redajp.doorkeeper.jp/events/44052場所は新宿の日本総合システム株式会社さんです。
参加者は40人くらいでしょうか。
最近、弊社でもマイクロサービスアーキテクチャがキーワードによく上がります。
個人的にも↓の本を読みつつ、
MSA読書会にも参加しているところなのです。
Sam Newman
オライリージャパン
売り上げランキング: 6,391
そんんわけで、この日の講演タイトル＆講演者が鈴木さんということで参加してきました。
以下、復習用に当日のメモを書き起こす。
講演「要求の変化とマイクロサービスアーキテクチャ」
SoRからSoEへ （P.6）- SoR： 情報を記録する
- SoE： ユーザー同士の関係を作り出す
サービス運営モデル （P.7）- ユーザの「価値」は複数ある。
- ITサービスの後ろには機能（コード）がある。
- その後ろに構造やプロセスがある。
- 一番右の「価値」から、コーディングする、「プロセス」を決める、まで距離がある。
- いろんな関係者がいろんな関わり方をしている。
「作る」から「運営する」へ （P.9）- 要求は価値から生まれる。
- 要求を変えて価値を出す。要求も変化し続ける。
要求は変化する （P.10）- 変化との戦いに勝つにはこーしたらいいんじゃないか、というフォーマットをとして、マイクロサービスアーキテクチャが最近注目されている
プロジェクトマネジメントの基本 （p.12）- 計画する
- 実行する
- 計測する
- 調整する
ウォーターフォールの失敗 （p.13）- そもそも見積もりが正しくできてないから計画も正しくない。要員通りにできない。
- ズレの調整が、プロマネの腕の見せ所。
アジャイルの考え方 （p.14）- アジャイルの誤解：計画を適当にせよ
- リソースを固定して、期限も固定して、スコープしか調整できないようにするのがポイント。
- → 計画が正しく立てられるように短期にする。
- 計測：動くか動かないかで１００か０しかない。
- プロジェクトマネージャがしそうな調整ごとをプロセスに織り込んでるのがアジャイル。
- 計画はどうせうまく行かないので調整を重視しているのがアジャイル。
- 長期の計画を正しく立てられるのなら、ｗｆのほうが早く確実に安く上がる。
- アジャイルはいろんなことを犠牲にした上で、みんなで考えながら一歩一歩進む手法。
- 技術でなくプロセスに柔軟を持ち込んだのがアジャイルの重要な考え方。
クラウド （P.18）- 2005～2015年はクラウドやDevOpsという言葉が中心となる時代。
- クラウド：所有でなく利用
- 資産から従量課金へ
- コンピューティングリソースにおける規模の経済
- 電力と一緒。人が発電所を持つのでなく、電力を使わせてもらってる。
ソフトウェア化するハードウェア （p.19）- SDx （Software Defined ..） ・・・ ソフトウェア定義されるハードウェア.
- これが大きな変更点だった。
- 非機能要件がコーディングできる
- 性能を上げたいなら、サーバを足すというコマンドを実行すればいい。
- コードを変えれば非機能要件が変わる。
Platform as as Service （p.21）- PaaSに特に注目すべき。
- OSSのフレームワークを利用するのに似てる。
カナリアリソース （P.28）- 鉱山で鳥かごのカナリアが死んだら毒ガスが出ていると判断する。カナリア＝部分的な犠牲。
- 部分的な犠牲（カナリア）を許容することで、無停止で昼間に切り替えられる。
- やってみればいいじゃん、という考え。いいか悪いかは別として。
- 金融とか病院とかはできないので注意。
必要な技術群- ルータとかもカナリアの挙動をするような新しい製品を使う。
- 各技術群の一番右に書いているのはNetflixが公開しているOSSである。
ダークカナリアリリース （P.36）- システム間連携が多いのでステージング環境でテストするのがすごい大変。
- 連携先のモックなんて用意してられない。
- 開発者にしか見えないリリースを、本番環境でやる。
- 本番環境のデータを使ってテストする。
Chaos Monkey （P.37）- ちゃんとハードウェアがソフト化されて自動化されているかを確認する。
- ダウンさせても影響なくいけるか確認する。
- カオスキングコング ・・・ リージョンまるごと落とす。
- Monky関連のいろんなツールがある。SSLチェックとか。
マイクロサービスアーキテクチャ （P.38）- サービス＝それだけで単体で稼働する仕組み
- APIで連携し、互いは疎結合
MSAの２つの側面 （p.41）- MSAの9個の特徴は技術的な話と組織的な話に分けられる。
- 技術面： 分散配置と統合
- 組織面： 持続性と分権
MSAの組織面：持続性と分権 （p.42）- ドメイン＝業務、という言葉が近い
- サービスそれぞれは好きな技術で作って良い。自主性を認める。
- 標準化なんて意味がない。
- 技術は多様化しているので、ドメインに特化した技術がある。
- 尖った仕組みを作れるように。エンジニアがやる気が出る技術使えばいいじゃん。
- ドメイン個別のライフサイクル。自分のタイミングでリリースしていい。
- 犠牲的アーキテクチャ。どうせ変わるんだからあとで作ればいい。
変化するために分割する （P.43）- 変更で大変なのは事前調査とテスト。
- サービスに分割されていれば、変更の影響はサービス内部にとどまる。
- データベースも共有しない。
変化とサービス分割 （P.45）- サービスをうまく分割するのが重要。業務別にサービスを割っていきましょう。
- サービス分割どうすればいいか、というのは正解がない。業務を知ってるあなたが考えることです。
- 全体視点で誰がやるの？は日本の課題。ユーザ企業側に優秀なアーキテクトがいない。
- 日本はSIerにエンジニアがいて、ユーザ企業側のエンジニアは少ない。
- ドメインに従ってサービスを分割するのが大事。
MSAは目的ではない （P.51）- MSAに「する」、ではなく、「なる」
- あなたドメイン知ってるんですか？ドメインを理解してないとMSA導入を先導できない。
- ドメインを知らない技術屋が、MSAやりたいんです、は怖い。
- MSAは技術論と組織論のバランスがうまく取れている。
- 建築業界では、工法と構造はセット。itは別々。MSAで両方がセットで語られるようになってきた。
感想
マイクロサービスにみならず、アジャイルとウォーターフォールの比較などを交えていろんな視点からサービス開発を俯瞰していました。
とても勉強になります。
講演者の鈴木さん、関係者の皆様ありがとーございました。
