No.81 朝活「続・いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。」をダラダラ読む回

00:06

はい、9月14日水曜日ですね。

えー、2週間のお抜き開始です。

ちょうど朝9時を回りました。

えー、今日も東京いい感じの天気ですね。

なかなか、まだまだ暑くて残暑が続きそうな感じですね。

おはようございます、夢見のkeethことくわはらです。

で、本日も朝活を始めていきたいかなと思います。

えーと、昨日からですね、タイトルにある通り、

今こそ良い仕様書がチームの生産性の鍵となる。

のて、仕様書に含めたい 14 のポイントについてまとめました。

っていう記事ですね。

それの続きを今日も読んでいこうかなと思います。

いや、これ、昨日前半というか半分くらい読ませていただいたんですけども、

昨日時点でかなり良い記事でして、

これパート2らしいんですけど、

パート1の記事もちょっと逆転してしまいますけども、

読みたいなと思ったくらいですね。

朝活で読むかちょっと分からないですけど、

一旦、この朝活中ではこのパート2の記事を読んでいこうと思います。

昨日はですね、セクション1、2、3、4つ目まで行った記憶があって、

で、違う、3つ目ですね。

本題となる14のポイントっていうところにやっと昨日入りまして、

で、そこでその14の項目1個1個について語ってられたやつを読んでたんですけど、

そのうちの7個目まで確か読んだかなと思います。

一応その14のポイントを改めて1からずらっと読んでいって、

その続きから行こうかなと思ってます。

フィジカルさんとネブさんとプテランドさんですね。

おはようございまーす。

ご参加いただきありがとうございます。

今日もダラダラと読んでいくので、ごゆるりと聞いていただければと思います。

じゃあ行きましょう。

14のポイントですね。

使用書例ですけども、14のポイントを1個読みます。

1つ目がプロジェクトの発起に立った背景、もしくは解決したい問題を伝えるというところです。

2つ目が検証したい仮説および達成したいことっていうのを簡単にまとめます。

3つ目、プロジェクトの概略を1、2行でまとめる。

4つ目が計測するKPIと期待する動きをまとめる。

5つ目、実験用フラグ名とかバリアント情報、振り分けの何パーセント等を記載する。

6つ目、すべてのリンクというのを仕様にまとめる。

7つ目、結果欄のところにローンチ後の検証結果を記載する。

8つ目、現在のUI、UXを軽くまとめます。

9つ目、開発仕様、バックエンド側とかを記載する。

10個目、開発仕様のフロントエンドおよびクライアント側を記載する。

11個目、開発仕様トラッキングを記載する。

12個目、QA関連のドキュメントおよび質問事項をまとめるスペースを作る。

13個目、その度行および関連部署への周知スケジュールなどをまとめる。

03:06

ラスト、メンバーリストを追加する。

これら1個1個を昨日ザーッと読んでいって、7個目まで読んでいたので、

今日はその続きですね。8個目からいきたいと思います。

現在のUI、UXを軽くまとめるというところですね。

開発する機能に関連する画面。

リニューアルの場合はリニューアル前の画面などのスクリーンショットと、

ざっくりした振る舞いというのを記載します。

そこまで細かく書く必要に迫られたことは今のところないんですけども、

もしくはアドに続く人にUI、UXの変遷を伝える、

およびざっくりした現状の全体感をチームとして共有しておくくらいかなと思っています。

そこまで大きなメリットはないかもしれないですけど、

ないよりかもしれないぐらいの温度感かなと思いました。

今のが8個目です。

ここの2つ目ですね。開発時はバックエンド側を記載するというところです。

経験上、バックエンド側で必要な仕様を先に記載、もしくはブリーフィングすることで、

プロジェクトの全体感および規模が伝わりやすくなり、

後半のクライアント側の仕様のレビューがスムーズになります。

また、中大規模の開発におけるバックエンド側の開発規模、

および仕様がボトルネックとなることが多いため、

仕様レビュー会の後半で鈍電返しが起きてしまうことがあります。

が、前半にこれを持ってくるだけで結構その時間が過ぎるようになるはずですよ、

というふうにおっしゃってますね。

割とありますよね。

バックエンド側の何かがボトルネックになってしまうことは往々にしてあるので、

一方でバックエンド側の仕様とかは先に決めていくことも多いと思いますので、

その仕様レビュー会がちゃんとあること自体は素晴らしいと思うんですけど、

それの後半で鈍電返しが起きるのは確かにあるので、

先に逐一記載したり、レビューをするのがいいなと思いましたね。

続いて10個目ですね。

開発仕様フロントエンド側を記載するというところです。

完成したデザインのスクリーンショットを左に置いておくと、

その右に画面の振る舞いというのを可能な限り細部まで記載します。

その画面でユーザーが取り扱える、

もしくは取り得るアクション全てに対してクライアントの振る舞いというのが

書いてあるのが理想ですよと言っています。

いわゆる画面設計上と言われているようなものに近いところかな。

そこまで細かく書くかわからないですけど。

大規模開発になってきた場合は、

UI、UX、Column、それぞれに対応するチケットへのリンクなどを記載すると

ものすごくシンセス。

めったにやらないけどと書いてますね。

仕様が長大になっている場合は、

絶対に見逃されたくない内容などがあった場合は、

赤字、もしくは太字等にしておきます。

そういうようなことがあったらということですね。

続いて11個目の開発仕様トラッキングを記載するところですね。

これちょっと短いですね。

開発機能に関連するトラッキング、

いわゆるイベント名だったり、プロパティ名だったり、

発火条件などなどというのを記載します。

僕の場合は割とBIに助けていただいてます。

はー、なるほどね。

トラッキングまで仕様書に書くことは、

06:02

僕は実はあんまなかったので、

ここはちょっとヘヘーと思ってますけど、

まあ内容かもしれませんね。

引きの要件とかにたまに書くことはあったりしたかなというぐらいの感じですね。

続いて12個目ですね。

QA関連ドキュメント及び質問事項まとめるスペースを作る。

ここはほぼQAメンバーの独壇場です。

QAプラン、構数等のQAメンバーが必要とするドキュメントを

自由に記載してもらうスペースを用意します。

またQAとの仕様確認が数十回にもわたるような

大規模開発の場合、

そして時差開発が起きる場合ですね。

というのはQAとの質問及び回答スペースを用意しておき、

随時適当に更新していきますというところでした。

はい。

言った言わなかったとか、あれあそこで言ったんだけどっていう

そのスラックの海に潜らなきゃいけないっていうことを

前回の前半の方で言ってましたけど、

そのスラックの海に潜らなくて良くなるように

ここに書いておくっていうのがすごく大事かなと思いますね。

はい。

スラックはどんどん流していくものですからね。

あくまでチャットツールですからね。

はい。

スレッドにあるかもしれないですけど、

スレッドを探すって結局潜ることに効果ならないので、

ドキュメントにガッとかまとめてあるんだったら

それはそれで分かりやすくていいんじゃないかと思いますね。

はい。

続いていきます。

13個目。

その他備行及び関連部署への周知スケジュールなどを

まとめるってところでした。

その他特記事項、カスタマーサポートとの

連携すべき事項とかプロジェクトが成功した場合に

次のフェーズでアップデートを行いたい内容とか、

QAから質問が来てフェーズ1では見逃すことにした

次形成の理想の対応方法などなど、

多くはプロジェクト終了直前および終了直後に

見直したくなるような内容っていうのを

記載しておきますよってことですね。

はい。

これを何ですかね、

使用書としてまとめておくっていうのは

僕は今までやったことがなかったんですよね。

プラスアルファの関連ドキュメントとして

ページ作っておいて、

リンクとかを貼ってたことはありますけど、

っていうのがあるんですけど、

スター

メッセージを送信

Keeth Kiyohito Kuwahara

スター

コメント

こちらもおすすめ