#3:よく訊かれることをつらつらと書いてみる。その２：謎の認定資格と、中身に触れる諸々を少しだけ
ディシプリンド・アジャイルのコミュニティ立ち上げに呼応した、「これまでのFAQ」の第2弾。頼むから同じ質問を、もうしないでくれ（回答するのにも、飽きているのだw）…と願っている私。
「質問と、それへの一次回答」であることは、その１と同様。
質問）DAの役割モデルには、スクラムマスターがないのに、認定資格ではどうして「ディシプリンド・アジャイル・スクラムマスター（DASM）」あるいは「ディシプリンド・アジャイル・シニア・スクラムマスター（DASSM）」と、”スクラムマスター”がついているのですか？
回答）よらば大樹の影、日和ったんです（w）
…この疑問を持ったあなたは、正しい。DAとの付き合いが長い私ですら、「役割モデルに挙げられていない役割を資格認定するってどういうこと？」と思ったくらいだから。
＃ただ、昔の認定制度では、違う名前だったような気もしている。そもそも認定制度に全く関心がないので、自信はないが。
当初、DAでは、「すでにチームにはそれをリードするリーダーがいる。そのリーダーがアジャイルを学び、自身のリーダーシップスタイルをサーバントリーダーシップへ転換すればアジャイル開発はできる。なのに、チームをリードする役割として新たに”スクラムマスター”を追加することがかえって混乱につながる」として、役割モデルにスクラムマスターを入れていなかった。
つまり、チームリーダーとスクラムマスターは、ほぼ同じような役割であった（厳密には完全に同じではない）。
ちなみに、この「アジャイルのためにわざわざ新たな役割を導入する」のではなく、「既存の役割が振る舞いを変えることでアジャイルは実践できる」という考え方の代表格は、エクストリーム・プログラミング（XP）だ（だからXPの方が好きなのだ、私は）。
余談だが、よく「アジャイルではプロジェクトマネージャーがいない」という人がいるが、それは「スクラムが役割モデルの中で言及していない」というだけで、手法が変われば言及しているものもあるのだ。
DAが時を経て、特定のフレームワークに依存しない（＝どんなフレームワークとも共存できる）”ツールキット”としての性格が強まるにつれ、「スクラムでもネタ帳として使われること」を想定して、最近の資料では「チームリーダー／スクラムマスター」という両論併記になっているものもある。
＃でも、厳密にはチームリーダー＝スクラムマスターではない。
え？だったら、「ディシプリンド・アジャイル・スクラムマスター」じゃなくて、「ディシプリンド・アジャイル・チームリーダー」でもいいじゃないかって？
…
…（………..）…
…ちょっと後で体育館の裏に来い…
質問）DAには2種類のスクラムマスター（DAスクラムマスターと、DAシニア・スクラムマスター）がいますが、それはなぜですか？
回答）単一のスクラムマスターだけでは現実的ではないから
いうまでもないが認定される資格の種類が増えれば、
○ 同じ人が複数の認定を受ける→それだけ受験料が振り込まれ、客当たり平均単価が上がる
○ より多くの異なる役割の人が認定を受ける→資格維持のための上納金が増える
だから、資格の種類は、増えることはあっても減ることはないのだ。もちろん、これらがあるから、人員が投入され、手法がより拡充サレ、ワレワレハ、ベネフィットヲ、キョウジュスルコトガ、デキルノダ！！（ト、信ジタイ…）。
…が、こんな自明な回答を期待しているとも思えないので、技術的な視点で回答すると、
単一の役割に担わせるには、大変になっちゃったから
に尽きる。
DAで元々提唱されている役割の考え方には３つの特徴がある。
XP寄りのアプローチに近く、現場に存在する役割をベースにしている。
後述するプロセスブレード毎に、その専門領域毎の役割が定義されており、DA全体で見ると、役割が結構多い。
「ソフトウェア開発も企業活動の一環」という視点で見ると、異なるプロセスブレード間の役割同士でコラボレーションが行われることも珍しくない…というより、それがないことの方が珍しい。
スクラムガイドでは、スクラムマスターがチーム内の他の役割（開発者やプロダクトオーナー）をどうサポートするかと共に、組織との関係性が議論される。DAでは、チーム内のコラボレーションに加えて、チーム外に存在するさまざまなステークホルダーとのコラボレーションが、より具体的に議論される。それら全てを単一の役割で規定するには、やることが多すぎるし、求められるスキルも違うので分けよう！…ということで、今の２種の”スクラムマスター”が生まれた。
主にチームの一員となってチームを育て上げるのがDAスクラムマスター、DAスクラムマスターをサポートしつつチーム外のステークホルダーとの円滑なコラボレーションの促進や、組織的な展開に重きを置くのがDAシニア・スクラムマスターと、雰囲気理解していただければ、大きく外れてはいない。
質問）「その１」で、今のDAツールキットの全体像の図が出ましたが、あれを全部知らないといけないのでしょうか？
回答）必要な要素だけ、選択的に使えばいいのです。
…私たちは、とてつもなく複雑なものを扱うときに、モジュールやコンポーネントといった中間的な構造を導入して、詳細はその中に隠しつつ俯瞰的に全体像を捉えたり、必要があればモジュールやコンポーネントの中にダイブして詳細を把握するという手段を使って、複雑さをコントロールしてきた。LSI、構造化手法、オブジェクト指向等々…
この見方でDAツールキットの全体像をみると、個々の知識領域が「全体を構成するコンポーネント」と見え、それゆえ一部が欠けると全体像が成立しない→全部知らないとできない、という印象につながるのは無理からぬところだ。
ここで、DAツールキットが、個々の要素を”コンポーネント”ではなく、”
プロセスブレード”と称している理由がわかる。
DAがバージョン2.0となり、それまでのDADから知識領域をさらに拡充していた時期は、ブレードサーバーが注目を集めていた時期と重なる。ブレードサーバーは、一枚の基盤上で完結したコンピュータである”ブレード”を複数枚使い、処理能力に応じて追加したり抜いたりできる。もちろん、ブレードを抜いても最後の１枚がある限りはコンピューターは動いている（ただ処理能力が落ちているだけだ）。
DAではバージョン２.0以降、知識領域をこのブレードに見立てて、必要な領域を選択的に利用しても成立するように考えられている。
ということで、全部を知らなくても、全然問題ない。必要になったら勉強すればいいのだ。
質問）「判断のネタ帳」ということで、DAブラウザを見てみましたが、選択肢がたくさんあって、とてもじゃないけど、全部覚えられません。選ぶのが大変ではないですか？
回答）DAのゴール図は、たくさんある（あり過ぎる）選択肢の中から、少しでも選びやすくするように工夫がされています（だからといって、ちゃっちゃと適切な選択肢が決まるわけではない）。
…DAの説明をすると、この類の「全部知らないとダメなんですか？」さんが意外とたくさんいることを知る。一度は「ダメです」と突き放してみたい衝動にも駆られる（我慢がまん）。
「選択肢がたくさんあって大変」という点には、次のような知識の構造化と表記法によって、絞り込みやすいように工夫されている。
さまざまな選択肢が、プロジェクトのどのタイミング（フェーズ）やテーマ（プロセスゴール）で議論されるかという観点から、あらかじめ分類されている。
選択肢は、「アジャイルの観点でより効果が期待できる」という視点で順序づけされていたり、「非常にポピュラーでよく使われるものは太字＆イタリックで表記される」といった、視覚的にわかりやすい方法で表記されている。
各選択肢には、選択にあたって考慮すべき点がトレードオフとして記載されている。利用者は、自分の置かれたコンテキストと、このトレードオフを入力にして、「今の自分達に適した選択肢」に到達する。
とは言いつつ、「今の自分が置かれたコンテキストを理解する」ってのが、なかなか厄介なのだ。一口に「バグが多い」といっても、その要因は複数からなっていることも珍しくなく、それを解きほぐしていくことが必要であり、簡単ではない。これが、「ちゃっちゃと決まるわけではない」という理由だ。
DAの選択肢が多いのをみて、選択肢が少ない方がいいという人もいる。が、それで減っているのは、選択肢の側であって、解決すべき問題の因子が減っているわけではないのには、注意が必要だ。
もちろん選択肢が少ない方が、選択する方は”楽”だ。選択肢が一つしかなければ（それを選択肢と呼ぶかどうかは疑問だが）それをやれば良い。でもそれは、「他の人に言われたことをやっている」のとなんら変わりがない。そしてその一つしかない選択肢が、自分の置かれたコンテキストに合う保証はどこにもない。その結果人々は、自分に合った選択肢を外部に探しに行くのだ。「事例、事例…」と呪文をつぶやきながら。
まぁ、現場の裁量を活かすというのは、現場自らが考えるということであって、考えるためには、材料が必要だ。その材料が、整理された形で提示されたのがゴール図のコンテンツであるといえる。
ということで、一気に２つ目も書き終わったぜ。これでまた、しばらく間が開きそうな予感がする…
2022.09.01記