システム開発(アジャイル・スクラム)とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

ファシリテーションの教科書のまとめと具体的にやること

はじめに

こんにちは!某金融機関でスクラムマスターや開発エンジニアをやっている@damyo404です。

今回はスクラムマスターのスキルを高めるため、『ファシリテーションの教科書/グロービス 吉田素文』を読みました。

ディスカッションしようと会議招集されたものの、 イマイチな感じで終わってしまったり、逆に自分が開催する側になったときに 上手くできなかったなと後悔することがあったり。

今後そういったことを繰り返さないためにも、 本書はとても勉強になったのでこんな記事で時間を浪費せずに是非買って読んでいただけたらと思います。

本記事は書籍のまとめ、そしてファシリテーションの場(以下、会議とします)やその前準備で取り組むべき活動について考える2部構成でお送りします。

書籍のまとめ

ファシリテーションの本質

ファシリテーションというと、 会議等を上手く進行させたり小手先のテクニック感のイメージが先行するかもしれません。

しかしそうではなく、「引き出し、決めさせ、自ら動くことを助ける」この3点がファシリテーションの本質。

自ら考え自分で納得させる、ファシリテーションのスキルこそ、リーダーに求められるスキルなのではと述べています。

議論の目的

議論の目的は以下の通り。

  • 決定内容の合理性を高めこと
  • 決定プロセスの納得性を高めること

人間だもの、必ずしも1人で合理的な判断ができるとは限りません。また、決定に至るまでの過程をきちんと共有できることが目的という訳ですね。

仕込みとさばき

本書では、会議の前準備を仕込み、実際の会議での立ち振る舞いをさばきと呼んでいます。

全体像

流れは以下の通り。

  • 議論の出発点と到達点をおさえる
  • 場の目的の共有・合意
  • アクションプランの理由の共有・合意
  • アクションプランの選択・合意
  • アクションの確認・共有

別途以下に注意する

  • 議論すべき論点を具体的に把握する
  • 参加者の認識、態度、特性を把握する

ポイントについて具体的に見ていきます。

議論の出発点と到達点をおさえる

よく会議のゴールを決めろとは言いますので、 この場が終わったときに参加者がどういう状態になっているのか考える人が多いと思います。

ただそれだけではなく出発点、つまり参加者が現状どのような認識レベルでいるのかを丁寧に掴む必要があります。

そのため、この議論が終わったら何がどのようになっている必要があるのか、いきなりこの話を初めて参加者に違和感はないのか、というのを徹底的に考える必要があります。

論点を具体的に把握する

よくわからない議論のファシリテーションをするのはかなり難しいです。

〇〇さんどうですか?となってばかりで議論の方向性をどのように持っていくべきなのか不明確なままファシリテーションをしてしまう。

それではダメで、専門家でなくともファシリテーターとして議論の内容をきちんと把握するべきとのこと。

そのためには、議題に対して事前に論点を出しまくる。 その後関連の高いものはグルーピングし、抽象度の高いものから具体的なものへ階層構造を作る。そしてどのようにすれば議論が活性化するのか考える必要があります。

こういったときにフレームワークが役に立つかもしれませんが、フレームワークの適切な使い方を理解せずに使ってはいけない。

また、専門家であると逆に議論に口出ししたくなるかもしれませんが、 そこは一歩引いてファシリテーターとして振舞うべきとのこと。

問題解決のステップ

最初になぜそうなのか、どうすればよいのか、といったWHYやHOWから始めると問題解決から遠くなる。

最初にWHERE、つまり問題に対してどのような傾向があるのかを掴みつつ、何が解決すべき問題なのか、なぜとどうすれば良いのかを考えていくべき。

それができたら、具体的なアクションプランの選択やアクションの実行といった流れに進める。

さばきについて

よく下手なファシリテーターが「ざっくばらんにどうですか?」みたいな的を得ない振り方をすることがあると思います。関係性が出来ていれば良いのかもしれませんが、聞かれた側としては戸惑ってしまうことは多いですよね。

そのため、「○○さん、○○の立場からすると反対意見かもしれませんがどうですか?」や「○○さん、入ったばかりのフレッシュな目線でどうですか」など一言添えるだけで回答のしやすさが変わってくる。

あとはあえて反対の意見を出せますか?なども有用とのこと。

訊く重要性

発言者の目を見る、うなづきや相槌などをして相手の意見を真摯にきく。 わかりづらかったら要約しつつまとめることが重要。

誰よりも論理的に

会話は意外と抜け漏れがあったりして論理性が欠けるもの。そのため、主張→根拠→結論や、前提→事実→結論といったステップが機能しているのかなど、演繹的、帰納的になっているのか頭の中で考える。

本書やそれ以外の情報から実際に取り組むことを考える

会議の前

準備は以下の順で取り組んでみる。

  • 招集通知、オフラインなら各人の物理距離が3m以上とならない広すぎない場所を選ぶ
  • 会議のテーマ・ゴールを考える
  • 参加者の名前を書く
  • 参加者それぞれのテーマの前提理解度や知識レベル、なぜこの場が開かれるのか理解しているのか書く
  • テーマの論点を挙げまくる、抽象度高〜低へグルーピング化して階層構造にしてみる(使えるフレームワークあれば利用する)
  • どうしたら議論が活性化するのか考えてみる。いきなり答えを考えるのではなくWHERE、問題の傾向は何なのかという点に注目して考える。
  • 会議のテーマ、ゴール、アジェンダを展開する

実際の会議では以下に気をつけて取り組んでみる。

  • 会議室の机などの配置を変える
  • 関係性ができてない場合は軽いアイスブレイクの時間を設ける
  • 最初にどういった理由で会議に呼ばれているのか、議題対して参加者がどのような関係性があるかを説明する
  • 相手の話は相槌、目線、体の向きなどきちんと「訊く」
  • 発言者の主張、根拠、結論のステップなど論理的なのか都度判断
  • 分かりづらければ要約して確認する
  • 事前準備した議論の活性化について話を広げてみる
  • 発言が少ないメンバーに対しては「○○さん、○○の立場からすると反対意見かもしれませんがどうですか?」などと発言しやすい形で投げかけてみる

参考文献

ファシリテーションの教科書: 組織を活性化させるコミュニケーションとリーダーシップ | グロービス |本 | 通販 | Amazon

親子の住まい方教室

スクラムにおける2つの遅延

はじめに

こんにちは、内製開発の推進とか色々やっている@daimyo404です。 社内向け勉強会という名の好き勝手喋る会をするのでそれに向けてのメモです。

今回はスクラムにおける2つの遅延について考えてみました。

ひとつ目の遅延 - 決定の遅延 -

バックログの受入れ基準

開発チームが着手する前にバックログはReadyである必要があるという話があります。 ちなみにDoRみたいな考え方もあります。

www.infoq.com

ここで言うReadyとはビジネス要求が明確になっていることとか色々ありますが、そのなかに明確にモレなくダブりなく受入れ基準が記載されてたりする必要があるんかなーとイメージをする方もいるかもしれません。

決定を遅延すること

リーンでの考え方ですが、決定を遅らせるというものがあります。

不確実性が高い状態で決めるよりも、あとでより明確になってからの方が精度上がるよねってものです。

これプロダクトバックログの受入れ基準に当て嵌めてみると、必ずしもみっちりびっちり書かれているものが必ずしも良いとは言えないと考えています。(また会話のための道具という側面から考えても)

プランニングの段階でもまだリスクが残っているものとか、 実際に着手して作りつつこうした方が良いかもねってものもあるかもしれません。要は日々のデイリーで検査・適応ができる訳ですね。

他にもエンジニア側の裁量が大きいので自己決定感が高まり自己組織化が促進されたりするかなあと。 あとはプランニングの決めなきゃいけないことが減るので時間短縮になるメリットとかもあるかもしれません。

ふたつ目の遅延 - 遅延コスト -

遅延コスト(Cost of Delay)

以下の数式で成り立ち、 PBIの優先順位付けのアルゴリズムとして使われる場合があります。

CoD = ビジネス価値 + 時間価値 + リスク低減・機会創出

結構イメージ湧きやすいと思いますが、 例えば遅れれば遅れるほど利益が失われる(機会損失)があると高くなったりします。

体力かかるので実際にやったことはないですが、 PBIの優先順位ってビジネス価値やリスクを鑑みて決めなくてはないので、 それが明確に説明できるという点ではステークホルダーマネジメントの観点では良いかもしれません。

参考文献

意思決定の正しいタイミング

アジャイル開発は決定を先延ばしする – プロダクト・マネジメントの要諦 The Rules of the Game of Product Management

遅延コスト回避中心のPBIライフサイクルマネジメント - mtx2s’s blog

スクラムマスターに必要なコーチングスキルとはなんなのか(NLP編)

はじめに

こんにちは!某金融機関でスクラムマスターや開発エンジニアをやっている@damyo404です。 今回はスクラムマスターに求められるコーチングスキルについてです。

スクラムマスターに必要なスキルセット

スクラムマスターに求められるスキルは、 ティーチングやファシリテート能力など多岐に渡りますが、 そのなかにコーチングスキルというものがあります。

www.odd-e.jp

コーチング、自発的行動を促進するコミュニケーションで、色々と流派があったりするようです。 ですが、「スクラム コーチング」とかで調べてもどういったジャンルのものを勉強した方が良いのか、 イマイチ的を得たサイトがなかったりしたので、色々なものに触れつつ何がいいのか見つけていきたいと思っています。

今回はNLPコーチング)についてです。

コーチングの流派

一言にコーチングといっても派閥があります。

yasushi-watanabe.com

note.com

NLPとはなんなのか

NLPとは、Neuro-Linguistic Programmingの略で神経言語プログラミングと訳されます。 神経とは五感、言語とは意味付け、プログラミングは思考や行動のパターンのことです。

70年代頃、心理療法家で成果を上げていたミルトンらの手法を研究し、言葉の使い方などパターン化したものです。

スクラムに役立ちそうなもの

ここでは紹介しきれないくらい様々な手法が存在するのですが、 いくつかピックアップしていきたいと思います。

バックトラックとページング

上記の紹介の前に少しだけ。

コミュニケーションを取るにあたって、相手が心を開いている状態であることが重要なのは、 言わずともわかると思います。

相手が心を開いている、打ち明けた状態のことをラポールといいます。 この状態を作るために有効な手法がバックトラックとページングです。

バックトラック

人は違う意見をぶつけられると心を閉ざしてしまうので、 おうむ返し、つまりバックトラックを使う。

バックトラックは言ったことをまんま繰り返すだけではなく、 直前の語尾や、要約、キーワードを返すなどがあります。

ページング

これも有名なやつですね。色々な要素を相手に合わせることです。

その中でも見た目や姿勢や身振りなど身体の動きを合わせることをミラーリングと言います。 よく相手と同じ仕草をする〜みたいなものが散見されますが、 それだけでなく、姿勢や話し方(声の大きさ、速さ、トーンやテンポ)、言葉(パソコンを相手に合わせPCにするなど文言) 呼吸や感情を合わせます。

キャリブレーション

非言語の情報を観察することをキャリブレーションと言います。 視覚、聴覚、体感覚から状態の手かがり(もちろん人によって違う)を探します。

メタモデル

言語化した情報は、省略や歪曲、一般化といった変形が起きます。 これは質問によって回復することができ、メタモデルと言います。

メタモデルは情報を回復することで、原因を探るものなので、なぜはありません。 なんかコーチングを学んだ人ってなぜ?を多用する気がしていたのでここは少しギャップがありました。

アンカリング

パブロフの犬的なやつです。 刺激と反応を組み合わせること。

自分が体験したある経験に没入し、その強さが最大限になる前にアンカーをかけ、ブレイクステート(深呼吸して中立状態に)します。 刺激を与えることで、自分の望ましい状態になることができるというもの。

肯定的意図

一見マイナスと思えるような行動でも意図があります。 スケジュールを詰め込むことでもそれによって自己肯定感が得られたり、 何かしらプラスの理由があるのです。

そのほかキーワード

  • サブモダリティ
  • フレーミング
  • スウィッシュ
  • ミルトンモデル
  • タイムラインシフト
  • チャンク
  • アソシエイト、ディソシエイト
  • ポジションチェンジ
  • ディズニーストラテジー
  • モデリング

さいごに

相手と信頼関係構築にあたってはページングやキャリブレーションが役に立ちそうですね。 他にはコーアクティブコーチングについて少し勉強したのですが、ちょっとスクラムからは遠そうなので、 次はポジティブ心理学とかそのあたりのまとめをしたいと思います。 あと切実にスクラムマスターのコーチング論を聞きたい。

出典

このあたりを読みました。

www.amazon.co.jp

エンジニアがザ・モデル(THE MODEL)を読んだのでマーケティングや営業の基礎とか用語とかまとめる

はじめに

こんにちは!
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

最近プロダクトをリリースしたのですが、バックオフィスの業務について深く考えられてなかったりで、 新たに出てきたステークホルダーから「作る人って売ること考えられないことが多いよね」とマサカリ投げられ大怪我を負いました。

SWEだろうがビジネスサイドの視点も持たなきゃいけないよねってことで、 ザ・モデル(THE MODEL)/福田康隆を読んでみました。

内容としては成功体験に基づく営業手法みたいな色が強いのですが、 調べながら読み進めていくとマーケティングから営業まで幅広に知識がつくのでおすすめです。 インサイドセールスとか最近のモノの売り方よくわからんって人も最初の1冊に良いかもしれません。

本ブログでは、事前にインプットしておいた方がいい用語とざっくり内容をまとめていますので、 これを読んだうえで是非書籍を読んでいいただけると良いかと思います。 (すいません前置きが長くなりましたが本題に入ります)

ザ・モデルの内容

営業の多様化

従来のいわゆる営業マンがやっていた領域を考えてみると、 ファーストコンタクトのための電話や外回り、顧客と発注書のやりとりまで実に幅広でした。

それだと効率的にできなくなってきたり、 最近は特にネットで調べてからコンタクトを取ってくる関係上、 フィルターかけた後に営業と会話することになるため、そもそも選定初期の土台に立てなかったりと環境が変化してきました。

段階毎に役割を変える

自分個人が1消費者として購買行動を取る場合でも同じですが、 商品購入までに、商品を認知して、興味を惹かれていって、実際に購入するといったいくつかフェーズがあります。

その各フェーズを担当するロールに分けて、効率的にマーケティングや営業活動を行おうというのが最近の潮流というわけですね。

認知段階では色々なツールを用いて顧客分析してリードを獲得するマーケティング、 興味や関心を持ったリードをナーチャリングして営業に繋げるインサイドセールス、 実際に購入に繋げる営業、そして購入後に継続的な利用をサポートするカスタマーサクセスといった役割です。
※ 既に何言ってるかわからんって人は用語集あるのでもうちょっと我慢してください

上記の役割の人がどのように顧客管理をしていけばいいのか、 体系的にまとまっていますのでとても理解がし易かったです。

図で理解したいって人は、下記サイトに載っていますので参考に。

salesbase.salesrobotics.co.jp

用語集

カタカナが多い

純日本人の自分だと厳しいものがあったので用語をまとめました。

  • リード:見込み顧客のことであるがいくつか分類あり
  • MQL(Marketing Qualified Lead):マーケティング活動によって生み出されたリード
  • SQL(Sales Qualified Lead):確度の高い営業がフォローするリード
    ※ 参考(もうちょっと詳細に分割できるらしい):リードとは?MQL/SQL/TQLの違いは?意外と知らない「リード」の意味と分類方法
  • オブジェクションハンドリング:応酬話法や想定問答のこと(いい感じな反論)
  • アップセル:上位なモデル等に乗り換え
  • クロスセル:現在利用しているものとは別のセットや商品を買ってもらう
  • ナーチャリング:育成のこと。インサイドセールスの文脈ではリードをより確度の高いリードにすること
  • BDR(Business Development Representative):インサイドセールスのこと、ADR(Account Development Representative)とも
  • コンバージョン:商品購入や資料請求などの最終的な成果
  • ファネル:直訳で漏斗。興味持った顧客が最終的な購買活動に至るまでに数が減ってきますのでその形から。パーチェスファネルとか言いますね
  • ファストパス:認知レベルの顧客がいきなり買うと言い出すなど、プロセスの階段を飛び越えること
  • デッドエンド:リサイクルの対象外
    ※ 書籍に詳細に書いてありますが、例えば商談に至らずとなった場合でも、 継続的にアプローチする等で再度リードに戻ってくる可能性があり、リサイクルせよってことを言っていました
  • MCP(Mutual Close Plan):営業が受注(注文書受領)までのスケジュールを細かく区切ってアクションを顧客と合意する
  • (購買検討フェーズにおける)4つの不:不信・不要・不適・不急のこと。購買までの心の壁
  • BANT条件:Budget、Authority、Needs、Timeframeの頭文字。営業のヒアリング項目でよくあるやつ
  • ロイヤルカスタマー: 簡単に言うと優良顧客。ある企業やサービスに対して忠誠心の高い顧客のこと
  • CAC(Customer Acquisition Cost):顧客獲得コスト。マーケティング費用とか

その他勉強になったことメモ

マーケティングの役割

新しい施策を打ってリード獲得数主義ではなく、見込み客を次のステージに進めることが大事。

インサイドセールスについて

平日日中という限られた時間で業務効率を上げられるかが成果に直結する。 (こう考えると営業って本当に効率が重要ですな、、)

100人の壁

有名なやつ。

hosokawaeiji.com

最後に

ぜひ書籍をどうぞ。

雑多なお勉強メモ(AzureFrontDoor、IPベースとSNI、SANs証明書)

今日のお勉強メモ

主にAzure FrontDoorのドキュメントを見てたのですが、 色々知らないところあったのでメモ。(主にSSL周りかもです)

Azure FrondDoor

Azureで可用性向上のため、東西の日本リージョン分散させたいとかなると出てくる選択肢として、 FrontDoorというサービスがあります。

個人的にへえと思った機能は以下の通り。

  • 「ルールエンジンの構成」で合致した条件に応じて任意のリクエストやレスポンスヘッダを付与できる。 例えば、デバイスの種類がモバイルだったらとかメソッドがPOSTだったらなどの条件に合致したらX-xxxヘッダ付けたりとか。
  • FD裏のバックエンド達は別にオンプレでも他のクラウドプロバイダーでもOK

docs.microsoft.com

IPベースとSNI(ネームベース)のSSL

一昔前の話っぽいですが、基本的に1つのサーバ(パブリックIP)に対して証明書は1つの制限がありました。

これの影響で、1つのサーバに色々なユーザ(ドメイン)が乗っかると、いきなりURLが変わったりとか不都合が生じていたそうな。 それがIPベースの方です。

それを解決するための技術がSNIであり、 単一のIPアドレスと複数のドメインのそれぞれで別のSSLサーバー証明書を使うことができる。

www.idcf.jp

マルチドメイン(SANs)証明書

ワイルドカード証明書は利用している方も多いのではないでしょうか。 サブドメインをカバーする*.がついているものですね。

対してSANs証明書の方は、「異なるドメイン」のWebサイトを1つのSSL証明書でカバーができる。

www.geotrust.co.jp

次勉強すること

まだFrontDoorのDoc読み切ってないので概念あたりから読む。 AzureのWebApplicationFirewallについてまとめたい。(多機能!)

開発者とQAチームを分けるということ

はじめに

本日は開発者とQAのチームの在り方についてのメモです。

理想はQAの能力も兼ね備えた1つのチームで開発するのが望ましいとは思っていますが、 プロダクト巨大・複雑化してくると俯瞰して品質に目を向けてくれる人が欲しくなることがあります。

そうなったときどうすれば良いのか考えてみたいと思います。


シェリフの泥棒洞窟実験

1954年、アメリカの社会心理学者であるM・シェリフらが『泥棒洞窟実験』というものを行いました。

3行でまとめるとこうなります。

  • チームを分割させることによって敵対心を持つようになる
  • チーム分割後に一緒に食事したり行動しても関係解消には至らなかった
  • ただ、協力して共同作業されることによって改善が見られた

高い仲間意識の危険性とその解決法についての社会心理学実験~泥棒洞窟実験~

チームが分かれることによってこういった経験は無いでしょうか? 個人的には別れているチームが見えないところにいればいるほど、やっていることがわからないほど敵対度の高さは顕著な気がします。

開発者とQAを分けるということ

上記からもチームは分けるべきではない!と言いたいところですが、 冒頭にもあるようにQAチームが欲しい場合はどうすればいいのだろう。 スクラムにおいてのやり方は以下の3つがあると考えています。(単純に同時にやるのか、あとでやるのか、最後にまとめてやるのか)

※ 便宜的に開発チームスプリントとQAチームスプリントと表現します
※ 前提として開発とQAのスプリントは同じ期間で実施します

① 開発チームスプリントとQAチームスプリントを同時に回す

1スプリントのなかで、開発しつつテスト(計画/)設計〜テスト実行までするもの。

スプリント毎にリリース判断可能な成果物、Undoneを残さないという意味ではこれが理想なのかもしれません。 ただ、QAとして磐石じゃないと厳しいかもってことで当社チームでは採用せず。

② 開発チームスプリントから1スプリント遅れでQAチームスプリントを回す

開発チームスプリントが開発をしている間にQAチームスプリントではテスト設計などの上流工程を実施。 開発と1スプリント遅れでQAチームがテスト実行を行うもの。

このあたりはブロッコリーさんが紹介していたりするので比較的一般的になっていたりするのですかね。

当社チームでもこの方法を採用しており、リズムとしていい感じです。 また、テスト設計段階で開発者と積極的に関わり、1つのゴールへ目が向かうので、チーム分割的な意識が薄くなるように思います。

③ テストスプリントとしてやる

これは個人的にはアンチパターンだと思っているやつですが、 別途テストスプリントとしてQAがテストします。

デメリットしかないなって思うので是非やって体感していただけると良いかと。

まとめと最後に

コンテキストによるので何かベストプラクティスとは言えないですが、 QAチームとして存在させたい場合は①か②になるかとは考えています。 別のこんな方法でやっているよ!って方がいたらコメント等いただけると嬉しいです。

それと前から考えているのは、ウォーターフォール文脈におけるQAチーム、 要はゲートキーパー的なイメージが先行してしまうのがとても悪だなって思います。 同じプロダクトを作っているので1つのビジョンやゴールに向けて協力してやっていきたいですね。

スクラムのスプリントゼロでやること

はじめにのはじめに

自分がいつ死んでもいいようにチームメンバー向けにノウハウを色々書いていたのですが、 見直すとほとんどryuzeeさんのブログで書かれていたことの焼き直しになってしまった、、

ただ、そこそこ具体的なところまで書いているので参考になったって人がいたら嬉しいです。 (スプリントゼロ以降は欲しい人いたら公開しようかな)

以下より本題になりますが、何かここ違うんじゃないかって人いたらコメントください!

はじめに

スクラムチームを組成し、いざ始めるとなったとき、スクラムガイドにはいわゆるスプリントゼロについて詳細に書かれているわけではなく、困ることが多い。

本記事では、具体的にどう進めると良いのかプラクティスレベルで記載するものである。なお、これは筆者の経験に基づいたものであり、カーゴ・カルト(積荷崇拝)にならないで欲しい。

その時々の現場や状況に合わせて、取捨選択してください。

参考記事:ryuzee.com:スプリント1を始める前にどんな準備をするか)

スプリントゼロでやるべきこと

プロダクト・プロジェクトレベル

プロダクト・プロジェクトレベルでやるべきことは以下の通り。

  • インセプションデッキの作成
  • クネビンフレームワークによるプロダクトやプロジェクトの置かれている状況の理解
  • 全員のスクラムに対する理解度を統一する(勉強会・研修など)
  • チームビルディングのイベント開催
  • DoDの作成

インセプションデッキの作成

まず初めに、インセプションデッキの作成を行う。やり方的には、プロダクトオーナーが雛形を作成しスクラムチームで認識を合わせる方法や、ある程度全員の認識が揃っている状態であれば、各個人で作成しすり合わせしながら1つのものへ収斂させていく方法などが考えられるだろう。

インセプションデッキは抽象的な表現が多いのでさらっと作成完了となってしまうこともあるが、1つ1つのテーマにきちんと取り組んで考えていくことを推奨したい。また、各ページでディスカッションすべきことについて補足する。

  • 我われはなぜここにいるのか:プロダクトビジョン、プロダクトゴールの明確化
  • パッケージデザイン:明確にデザインが決まっているものであれば良いが、そうでない場合、カンプまではいかないがある程度固まったもの、サイトマップ等があると望ましい
  • やらないことリスト:作成するドキュメント、しないドキュメント
  • 夜も眠れなくなる問題:ネイティブアプリ審査のリジェクトなど、ここで出されたものはリスクバッファとしてプロダクトバックログにあげるのが望ましい

パッケージデザインに関しては、全体像が不明瞭なままだと開発者としても不安なため、できる範囲で可視化することが肝要だと考えている。

クネビンフレームワークによるプロダクトやプロジェクトの置かれている状況の理解

ここは参考サイトに記載の通りであるが、この段階であればスクラム以外の手法で開発することも考えられる。そのため、今一度プロダクトやプロジェクトの不確実性について議論し、開発手法を再検討することも重要だと考えられる。

全員のスクラムに対する理解度を統一する(勉強会・研修など)

スクラムマスター主導のもと、基本的な用語、各セレモニーの進め方、ロールの役割の共通理解ができている状態にしておく。一朝一夕でスクラムの本質的な価値や原則について理解することは難しいかと思うが、特にプロダクトオーナーはプロダクトの成否を決める重要な役割なので、理解度が低いようであれば、反復・継続して教育し続けることが望ましい。

チームビルディングのイベント開催

星取表とドラッガー風エクササイズなどのプラクティスが利用されることが多いように思う。

働き方や各個人の強みが明確化されていない場合は実施すること。

閑話:AgileTechExpoでの永和システム平鍋氏の講演で印象に残っているチームビルディングの話がある。オンサイトでは最初にチームビルディングイベントを行って一気にレベル底上げを図っていたが、リモートになって中々対面でのイベント開催が難しくなる昨今では、継続的なチームビルディング活動が重要になってくると。例えば、打ち合わせやスクラムセレモニーの5分前には集合するようにして、雑談する時間を増やすなど、直接顔を合わせられない分、違ったアプローチでのチーム成熟度を高める必要があるとのこと。スクラムマスターはこのあたりも目を配るようにしたい。

DoDの作成

ここは色々なサイトを参考にチームで考えたものを導入すればいいと思うが、テストについて補足しておきたい。自動テストをどのレイヤーまで進めるのか、いわゆる連結テストレベルのテストはどの段階で担保していくのか。テストを先送りにすればするほどUndoneは増えていく。リリース直前になってバグが頻発してリリースの見通しが立て辛くなる。スクラムではスプリントが終わった段階で「リリース判断可能な品質であること」という前提を忘れず、こういったリスクについては、きちんとチーム内で検討したうえで、DoDを作成して欲しい。

プロダクトオーナーレベル

プロダクトオーナーレベルでやるべきことは以下の通り。

  • プロダクトビジョン・プロダクトゴールの作成
  • プロダクト全体像がわかる資料の作成
  • ユーザストーリーマッピングのイベント開催(PBIの作成)
  • スケジュールの作成
  • プロダクトオーナーというロールへの理解

プロダクトビジョン・プロダクトゴールの作成、プロダクト全体像がわかる資料の作成

こちらは先ほど記載したので割愛。

ユーザストーリーマッピングのイベント開催(PBIの作成)

横軸に時系列を取り、利用者毎にアクティビティとタスクに分割、どういった開発が必要なのかを整理するもの。その後、縦軸をスプリント1〜3等、スプリント毎のブロックに分け、いつどのような開発を行うのか議論する。ここは会話量が多く忘れることもあるため、議事録か音声録音しておくことを推奨。電子的にバックログを管理することが多いため、その後チケット管理ツールに転記することとなる。

また、インセプションデッキの夜も眠れなくなる問題で記載したリスクバックログはバッファとして積んでおくことで不確実な問題にも対応できる。

補足:PBIの書き方について

ユーザーストーリー形式で記載することが多いと思うが、その場合、「〇〇(誰)として〇〇(アクション)したい、それは〇〇(理由)だからだ」というもの。

あくまでも会話のインプットとなるものレベルではあるものの、プラスアルファで「理由」部分の一言で網羅できないストーリーの背景などを記載するのが良いと考えている。

AcceptanceCriteria(受け入れ条件)に関しては、デモが行える粒度で書くこと。経験上、ストーリーのACは5〜10程度はあると手戻りなく、開発側との会話が活発になって良い。

ツールにもよるが、エピック等の運用ルールについては予め決めておいた方が良い。(後々の管理のし易さ)

スケジュールの作成

現段階のスケジュールをきちんと立てる。

スクラムアジャイル)は行き当たりばったりではない。(変化への適応はするが)

プロダクトオーナーというロールへの理解

例えば以下を問うと良いかもしれない。(この段階では回答が難しいものがある可能性あり)

  • PBIはReadyReadyになっているか
  • PBIは優先順位通りになっているか
  • 次スプリントのゴールは明確になっているか
  • ベロシティを参考に先々のスケジュールを立てられているか
  • バックログに記載されている項目のWhyを1秒以内に答えられるか
  • スクラムセレモニーに時間が割けているか
  • バックログのHowにまで口出ししていないか
  • POとしての決定権を持っているか、ステークホルダーのただの中継役になってないか

これらに迷うようなことがあれば、ロールやバックログの理解が足りていない。

スクラムマスターを中心に理解を深める手伝いをすべきである。

開発者レベル

開発者レベルでやるべきことは以下の通り。

  • 開発者目線でのプロダクトバックログの作成
  • PBIの見積もり

開発者目線でのプロダクトバックログの作成

やらなければならない、なおかつタスクとして大きいものが抜けていることは後々のリスクや見通しが悪くなることに繋がる。以下のようなバックログが抜けていないのか確認すること。

バックログをDoneとするためには、ACとDoDの両方をクリアする必要があるため、Undoneとして残しているものがバックログ化されていないのは矛盾していると考えている

  • 開発環境の構築(ローカル端末へのツールインストール、Dockerファイルの作成、チケット管理ツールのプロジェクト作成、リポジトリの作成・設定(コミュニケーションツールへの通知設定、プルリクの承認下限数)、ユーザの作成・追加、インフラの構築(Development、Staging)、CI/CDの構築)
  • 移行計画・テスト・リハーサル
  • テスト計画・実施(デグレ確認(内部連結テストレベル、外部連結テストレベル)、総合テスト、非機能テストなど)
  • 非機能要求グレード等を参考にした非機能関連のタスク
  • 社内標準やガイドラインの対応(ガイドラインチェックリスト、PCIDSS、CIS Controls等の対応)
  • 脆弱性診断の実施、指摘対応
  • 社内説明・承認用のドキュメント作成

PBIの見積もり

プロダクトオーナーが作成したPBIと開発者が作成したPBIの優先順位を並び替え、相対見積もりでストーリーポイントを付けていく。3〜6ヶ月程度先であれば全てのバックログにポイント付けた方が後々の見通しが立てやすくなる。また、優先順位が低いものに関してはざっくりポイントで問題はない。