長編書きの為の連載フレームワーク提案

01_05:スクラムとはなんなのか

　ようやく本題に入りつつあります。

　すみませんね、ナンチャッテでも技術文書なんです。

　さて、今回基底とするアジャイルのモデルは『Scrum（スクラム）』と呼ばれるものです。

　ラグビーを思い浮かべた方。大体あってます。

　もともとは『１つのチームでゴールを目指す』ための仕組みで、プロジェクト管理を主体にした開発プロセスがスクラムと呼ばれるものです。

「まって私一人なんだけど？」

　大丈夫、私も一人です。というかリアル周辺に創作してる人がいません。まさにリンボ！

　でも昨今はツイッターですごい人と連絡取れたりするので、孤独感がないですね。まさにエデン！

「どの程度の人と協力できるの？」

　標準のスクラムモデルでは１０人程度迄は許容します。

　壮大な合作とかじゃあない限り問題ないでしょう。

「嫁or旦那の二人なんだけど」

　十分可能です。そして末永くお幸せに爆発しやがれませ！

　ではスクラムについて、まずはざっくり説明していきましょう。

　まずスクラムが認める価値です。

　いわゆる社是みたいなもんです。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　・確約:Commitment.　:約束（≒締切）は守る。

　・集中:Focus　　　　:約束を守ることに尽力する。

　・公開:Openness.　　:己に不利でも事実として包み隠さない。

　・尊敬:Respect　　　:己と異なることを認め、敬意を払う。

　・勇気:Courage　　　:上記４点を満たすために勇気を持つこと。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　つまるところ、自分に言い訳しないで、仕事に真摯にありましょうってことです。

　当たり前っちゃ当たり前なんですが、人間すぐにラクな方に傾くので肝に銘じましょう。

　続いてチーム開発というからには人物が出てきます。

　この役割（ロール）は全部で４つあります。

－－－－－－－－－－－－－－－－－－－－－－－－－

　　１．顧客　　　　　　　　　⇔　読者＆著者

　　２．プロダクトオーナー　　⇔　著者＆読者

　　３．スクラムマスター　　　⇔　著者

　　４．開発チーム　　　　　　⇔　著者

－－－－－－－－－－－－－－－－－－－－－－－－－

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【１．顧客】⇔　読者＆著者

　所謂『お客さん』です。エンドユーザーとは違うのですが、今回の場合は直結して読者です。

　ただし著者もある意味、読者なのでここに記載しています。

　作成する物語（しょうひん）の売込みを行うべきターゲットであり、その結果を要求する立場……つまり読みたい話、アイデアの要求をする人です。

【２．プロダクトオーナー(PO)】⇔　著者＆読者

　執筆する物語の責任者……編集者に相当します。

　要求に対して必要な設定、構成などを纏めて明確なビジョンにします。

　ビジョンは関係者全員に共有する形で残す必要があります。

　POはあくまで執筆に関するスケジュールとコストの管理をします。

　（この場合時間そのものをコストとして扱います）

【３．スクラムマスター(SM)】⇔　著者

　執筆を円滑に進めるための調整役です。つまり制作における女房役ですね。

　ルールを決めたり、効果的な運用を促します。

　本来はPOや顧客の無理な要求に対する緩衝として機能するロールです。

　つまり無理なく動くために、全体の面倒を見る『リーダー役』です。

　なので開発チームとの兼任が可能なロールでもあります。

【４．開発チーム】⇔　著者

　実際に開発……つまり執筆を行うあなたのことです。

　本来であれば苦手分野は別のメンバーに移譲ができますが、一人しか居なければ全部やる必要があります。

　そうなると無理が出るため、無理なく運用するためにSM的なスタンスでの調整が必要となります。

　なおチームのメンバーは全員が平等であり、一切の上下関係はありません。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　続いて実際の開発……執筆サイクルです。

－－－－－－－－－－－－－－－－－－－－－－－－－

　　１．プロダクトバックログの作成　　⇔　プロット作成

　　２．スプリント計画　　　　　　　　⇔　あらすじ

　　３．デイリースクラム　　　　　　　⇔　実施計画

　　４．開発の実施　　　　　　　　　　⇔　執筆

　　５．スプリントレビュー　　　　　　⇔　プロットの確認

　　６．振返りチェック　　　　　　　　⇔　実施内容の確認

　　７．プロダクトバックログの詳細化　⇔　実施内容の確認

－－－－－－－－－－－－－－－－－－－－－－－－－

　簡単に言うと

　１と２で執筆の計画を立てて、

　３と４で実際に書き始め、

　５と７で次の準備をして、

　６でシメの作業をします。

　この周回を繰り返すことを『Sprint（スプリント）』と言い、

　スプリントを重ねることで完成を目指すというものです。

　執筆に関して言えば、『○○話を作るスプリント』を重ねて、

　一つの物語を完結させると言う仕組みになります。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【１．プロダクトバックログの作成】

　執筆単位に分けた設計概要……つまりプロットです。

　ただし執筆で分割可能な単位に切り分けてあります。

　またこのプロットは詳細に決定する必要がありません。

　あくまで必要な機能とシチュエーションを箇条書きした、本当の骨組みです。

【２．スプリント計画】

　プロダクトバックログの優先順位が高いものから、

　今回のスプリントで執筆するプロットを選別します。

　この時発生する仕事（タスク）をスプリントバックログと言います。

【３．デイリースクラム】

　その日の作業を確認します。

　前日までの作業実績と、本日の作業予定、問題と成っているタスクを洗い出します。

　また問題を共有する場であり、解決の場ではない点に注意してください。

【４．開発の実施】

　その日の執筆作業をします。

　無理しない範囲での作業を心がけましょう。

　基本的にはスプリント計画で決定したプロットのタスクを執筆する作業となります。

【５．スプリントレビュー】

　所謂成果物に対する脱稿前の最終確認、及び脱稿となります。

　レビューの名の通り、本来は第三者が確認するものです。

　一人しか居ない場合はツール類を使った検証を導入します。

【６．振返りチェック】

　今回のスプリントの進捗や、上手く行った点、悪かった点をチェックします。

　私が普段やっている『ＫＰＴ（けぷと）』や、『ＰＤＣＡ』が該当します。

　社会人の方なら後者は聞いたことが在るのではないでしょうか。

【７．プロダクトバックログの詳細化】

　今後のスプリント計画のために、曖昧なプロットを詳細化します。

　１の段階で箇条書きになっているものを、あらすじにするのがこのフェイズです。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　さて、このサイクルで重要なのは『計画通りに進行させる』のではありません。

　常に『最適化を行い、結果をつみあげていく（インクリメントする）』ことです。

　あなたは常に進化し、運営が多少傾いても前に進む事ができます。

　故に『スクラム』が『連載』に適しているのです。

　それでは次から、本格的にＳＷの説明に移りたいと思います。

　興味が在る方はそのままページをめくってください。