00:04
はい、9月13日火曜日、地獄浅久寺を回りました。
寝起きで頭がすごいボーッとしている中、ちょっとやっていこうと思います。
おはようございます、memekeethの桑原です。
では、本日の朝活を始めていきたいと思います。
本日は、何を向かって、まず悩むんですけど、技術的な記事をいくつか見つけたんですが、
どうしても、ちょっとプロジェクトとかチームディレベルのところで、
アストリードとしていた記事でずっと残っていたものがあって、
こっちの方を早く解消したいなと思ったので、
今日は、技術じゃなくて、プロジェクト系のお話の記事を読んでいこうと思います。
「いまこそ良い仕様書がチームの生産性の鍵となる。
仕様書に含めたい14のポイントについて。」という記事を読んでいこうと思います。
では、いきたいと思います。
ネブさんとプテルノさんですね。おはようございます。ご参加いただきありがとうございます。
最近、なかなか技術的な記事じゃなくて申し訳ないですけど、早速やっていきたいなと思います。
はい、いきましょう。こんにちは、フリッツです。
今回はプロジェクト、プロダクトマネージャーのニッカともいえる仕様書について、
自分にとってはPM業の施行、実行フェーズにおいて最も重要な仕事の一つであり、
最も心躍り、最も興奮する瞬間です。
ほう、なるほど。
PMになってかなりの時間が経ちましたが、
仕様書への力の入れようは減るどころか、もっと気合入れなければと感じる一方です。
在宅勤務が多分IT業界のニューススタンダードとなっていく今、
なおさら仕様書の重要性を訴えたい今日この頃です。
ということで今回は、
良い仕様書がもたらす5つの効果、
仕様書の重要性が増していく2つの理由、
仕様書に含めたい14の項目実践編、
仕様書作成時に心に留めたい3つのこと、
具体的な仕様書サンプル、後日追加公開予定などを復習してみました。
超ニッチですけども、仕様書のみについてここまでマニアックに考察した記事はないはず、笑いだろう。
だからこそ、どなたかのお役に立てる記事になっていると信じてやっていこうと思います。
今日の記事はですね、めちゃめちゃ長いんですよね。
これ日本語の記事なんですけど、かなり長いので。
今日こそ、たぶん1日で終わらないなと思っています。
今のでゆるーくやっていくので。
いきましょう。では1つ目ですね。
黙示の1つ目、前置き仕様書フォーマットに正解はないよというところからです。
仕様書の書き方に当然正解はなく、
仕様書のテンプレートというのは、以下に挙げたような変数もっとあるけど、
によって全く違うものになります。
例えば、1、2、3、4、5、6個ありますね、変数が。
プロダクトに関わる人数は5人ですか100人ですか?
2つ目があなたはPDM1年目ですか?それとも10年目ですか?
3つ目、プロダクトがリリースされてから何年経ちましたか?
4つ目、関わるチームメンバーは1人ですか?それとも20人ですか?
5つ目、チームメンバーは百戦錬磨のベテランですか?それともジュニアですか?
03:01
ラスト、そもそもPDMは何人いますか?1人?もしくは20人?みたいな。
他にもいっぱい変数があるけど、こんな感じのような変数があるので、
全く違うものになりますよねということです。
とある会社では、ざっくり書き詳細は現場に任せた方が良いという場合が正解で、
ある会社ではアニメーションの動きも文言もデータベースの設計も全部定義するというような、
いわゆるギッチギチの仕様書が正解だったりします。
どれも一長一短だし、置かれている状況によって選ぶべき仕様書フォーマットというのは間違いなく異なるはずですよね、
という風に言っています。
まあそうですよね、メンバーの順度というか、ベテラン勢なのかそれともジュニアなのかとか、
関わるPDMリリースからの経過年数とかチームメンバー数であったりチームメンバーの熟練度だったりとか、
全然変わりますよね。
元Googleの方が言ってましたけど、こうするといいよみたいなアドバイスする仕様書、
所属する会社の社員がまだ10名程度しかいなかった頃に僕が書いていた仕様書、
チームメンバーが20人の場合に書く仕様書、
さらにはチームメンバー全員が会社に通勤できていた頃と、
誰もが在宅金も余儀なくされている今の仕様書、
どれも注力すべきポイントが異なるかと思います。
ただ、One fits allですね。
すべての場合に適応できる理想の仕様書みたいなものが存在しなかったとしても、
含めた方が良いものの最大公約数というのはあるはずだと。
これをまとめてみたのが今回の記事ですということですね。
そうですね、One fits allは言うてないでしょうと思いますけどね。
最大公約数という言葉を使っているのは結構僕はいいなと思いましたね。
では具体的にいきましょう。
2つ目のセクションですね。
良い仕様書がもたらす5つの効果です。
さて、仕様書ってなんでそんなに大事なの?
適当な仕様書だとなんでダメなの?
仕様書の良し悪しはどんなインパクトをもたらすの?
こうしたいくつかの疑問について自問自答してみました。
ミイシーじゃないけど許してくださいということです。
ミイシーは無理じゃないですかね。
今言った変数のよっては環境によって全然違いますからね。
ひょっとしたらセクション4の冒頭に添付した14項目の画像をざっと見ていただいてから読んだ方が
もしかしたらしっくりきやすいかもしれません。
ではいきましょうか。
仕様書がもたらす5つの効果という画像が貼られていて
先にそれだけざっといっちゃいましょう。
5つの効果の1つ目。
コミュニケーションコストの削減。
2つ目。
コントロールされた開発。
3つ目。
チームモチベーションの向上。
4つ目。
最終的な品質の向上。
5つ目。
リリースまでの後期の削減。
説明が入っていきましょうか。
1ですね。
良い仕様書というのはコミュニケーション、もしくはサーチコストというのを削減しますよと言っています。
1つ目。
PMとチームメンバー間の無駄なコミュニケーションが減りますねと言っています。
事前に確認できる可能な限りの機能の振る舞いというのを記載しておくことで
チームメンバーがいちいちPMにここはどうしますかと聞きその回答を持つというコミュニケーションの無駄が削減できます。
06:03
プロジェクト開始直後からそんな概要が始まっているようなのも要注意かもしれません。
また仕様書というオープンフォーマットで事前に内容が明記されていることで
質問が重複するといった無駄も防げるようになります。
これよくありますよね。
地律もなんですけどここどうしますかの質問って
規模が大きくなったりプロジェクトの人数がかかるほどPMにかかるコースもどんどん上がっていきますからね。
それでいてPMがプロジェクトのボトルネックになるというのは最悪のケースなので
これは本当にいい話だなと思いました。
続いて関連ドキュメントを探す手間も省けますよねということです。
プロジェクトにおいては過去の使用、発行されたチケット、デザインファイル、QAプラン、関連ドキュメントなどなど
多くの付随ドキュメントが発生します。
あのドキュメントどこだっけごめん教えてといったような発言が頻発しているようならやっぱり要注意です。
これらすべてのリンクを一箇所にまとめるべき場所として
使用書以上のものは本来ないはずです。
これを周知することでチームメンバーそれぞれのコースを削減できます。
もう完全同意って感じですね。
続いて頻繁な使用変更が起きてもスラックの海に潜る必要がなくなる。
スラックの海という言い方がなかなか面白くて、でも確かに海だなっていう感じはありますね。
プロジェクトのスラックはだいたい海ですからね。
余談でした。
予想しきれなかった使用の抜け漏れであったりとか
使用変更の決定というのはスラックもしくは口頭で決めることが多いかと思います。
これ時代は仕方ないんですけども
良い使用書はこうした変更を全て捉えていてしかるべきであります。
結果チームメンバーが最新の使用を把握するためにスラックのスレッドを探ったり
エンジニアPMQA間での使用伝達していたつもりだった
していない等の混乱が起きたりといった時間的ロスを防ぐことができます。
また使用変更について周知的にいなかったメンバーからの
同じ質問という類似のロスも防ぐことができます。
まあそうだよね。
何か変更あったり何か決め事があったらちゃんと使用書に書くという癖を
チームメンバー全員につけておくっていうのは結構大事なことですよね。
本当に細かいところですし
これはエンジニア的なスキルじゃなくてビジネスマン的スキルにはなるんですけど
なかなか注目されないというか
みんなが当たり前にやって見落としがちなスキルこそ大事だったりしますよね。
以上1つ目でした。
続いて2つ目の効果です。
良い使用書というのは開発がカオスになるのを防ぎます。
追加で開発される機能が減って終盤のカオスを防げるということが
その具体的な話ですね。
エッジケースなど後半になって発生する
もしくは発覚する仕様の抜け漏れというのはどうしてもありますが
事前にきちんと様々なケースを記述し尽くしている使用書というのは
こうした追加開発を事前に削減する効果があり
特に開発終盤における追加機能のラッシュ
もしくは奔走状態みたいな
つまりチーム全体の過剰なストレス
09:00
カオスというのをかなりの割合で軽減できる媒体になっているはずです。
続いて自分が何を開発しているのかを誰もが把握しているというところです。
度重なる使用追加であったり
使用変更が使用書においてきちんとアップデートされていない場合
終盤にはチームメンバーの誰もが何を開発しているか
把握できなくなり
PMもバータリ的な反応が増え
QAも何が正しい振る舞いであるべきなのか
把握できなくなります。
まさしくカオスって感じですね。
その結果本来ならばユーザーに提供される
エンドプロダクトがどのようなUXを提供しているのか
本当に良いのか悪いのかを把握しているべきである
PMですら使用書についてチームメンバーに聞かないといけなくなる
本末転倒って感じですね。
良い使用書は常に更新され続け
チームメンバー全員にとってのワントゥルーソース
ここにいけば全ての真実が書かれている
こんな言い方するんですね。
ワントゥルーソースをもたらすことができ
メンバー全員がユーザーに届く体験がどのようなものになるのか
っていうのをきちんと把握できている状態をもたらせるはずです。
何を開発しているのか
PMもエンジニアもわからないようなプロジェクト
多分やばいと思いますね。
燃えるんじゃないかなと思いますけど
そういうことを防ぐことができますよねということでした。
続いて3つ目のコーナーの説明ですね。
良い使用書はリリースまでの後期を劇的に短縮すると言っています。
強い言葉を使いますね。
具体的なところにいきましょう。
エンジニアの開発設計というのがすごく正確になりますよと。
開発する機能についての詳細な可能な限りを事前に記載しておくことで
エンジニアが機能の全体感を把握した上で開発プランを設計することができるようになり
結果的に構成の削減につながることが多々あります。
おざなりなしを追加開発が乱発された場合と
最初から開発内容が定義されている場合では
結果的に同じものが開発されていたとしても
その開発構成には天と地のような開きが生じます。
それもそうだよねって感じですね。
続いて
すみませんね。
リリース直前のQAの工数が削減できるというのが次の具体的な功能ですね。
特に大規模機能の開発になると
どうしてもエッジケースと記載漏れであったりとか
エンジニアと口頭で決めてしまったQAに周知されていない機能などが出てきます。
これが反映されていないと終盤におけるQAのコストは平気で倍を超えるようになります。
しかし良い仕様書がそういったケースをきちんと追加で記載しており
QAメンバーが何が正しい振る舞いなのかっていうのを
PMへの質問とかNGIの質問等なしに
ストレスゼロで把握できるようになっているはずです。
結果的に全体のQA工数削減をすることができて
リリースが当然早まることになりますということですね。
とても良い話だなというところでした。
僕今気付いたんですけど
今日僕のマックのマイクが良くないですね。
12:03
マックそのもののマイクを使っている気がするので
今日音声の質が悪い気がします。
続いていきましょう。
4つ目ですね。
良い仕様書というのは最終的な成果物の品質を向上させるよという風に言っています。
具体的に言いましょう。
適当な機能の振る舞いが世にリリースされるのを防ぐというところですね。
良い仕様書は細部まで機能の振る舞いを明確に定義しています。
これはお隣にしてしまうと実際に発言されることはなくとも
仕様書に書いていなかったので適当に決めましたとか
仕様書に書いていなかったのでこのバグは見逃してしまいましたとか
仕様書に書いていなかったのでここは開発しませんみたいな。
全然ありますね。
特に一番最後ですね。書いていなかったので作っていません。
そんな認知していないんだから作りませんでしたっていうのは一番あるケースだけど
多分PMからするとイラッとするでしょうね。
でも書いてないのは良くないよって話しなきゃいけません。
などなどのケースが頻発し結果的にリリース後こんなはずじゃなかった
こんなUI UXをユーザーに提供したわけではなかったんやみたいな
PMとかもリードによる追加開発がパッチワークのように行われてしまいますと
ちなみにこれが何度も繰り返されるとチームメンバーからの信頼が損ない
故に追加開発もスムーズにいかずというトリクルダウン的な被害をもたらします。
トリクルダウンって言うんですね。
100%ではなくても良い使用書はこういったケースをかなりの量削減することが可能なはずです。
第5つ目ですね。
良い使用書はチームのモチベーションを増大させるというところですね。
適当な使用書というのはチームを疲労させモチベーションを下げる。
良い使用書はチームのホワイワッとハウを定義しモチベーションを上げることができますよと言っています。
だいぶ長いな。
お隣なし使用書というのはなぜこのプロジェクトが発足したのかを伝えない。
伝えず細かい機能の振る舞いを定義しておらずPMのバータル的な追加依頼が再現なく続き
開発コースを初期の2、3倍にまで肥大化させてしまい
それがいつ止まるかもわからない状態になり出口が見えないチームを疲弊させ
チームのモチベーションを下げ結果開発が遅延しまた機能の振る舞いが適当になり
最終的にエンドユーザーに届くUIXを悪化させ
リリース後も追加開発がさらに必要になりというデススパイラルを招きます。
これに対して良い使用書はこの機能を開発することで期待されるインパクトを明記し
社外のユーザーのみならず社内にとってもそれがどれだけ期待されている
もしくは意味のあるプロジェクトであるかというのを伝え
プロジェクトのスコープを開発前から明確に定義することで
不必要な仕様の膨らみというのを防いで区切りをチーム内に明確にし
チームメンバーがPMに対してそれ使用書にはないので次にしましょうと
反論できるのが健全な態勢じゃないかというのはそもそもありますけど
区切りをチーム内に明確にし
細かい部分などで機能の振る舞いを定義することで
開発中もしくは後の大量の修正チケット
終わりが見えないトンネルなどを防ぐことができ
15:00
余裕が生まれたチームメンバーから
仕様に記載されていないUI UX追加修正案を受け取るまでになる
といったプラスのスパイラルを生み出すことができますと言っています。
まあツッコミどころはたくさんあるんですけど
おおむね通りだし本当にそういうケースを僕も体験したことがあるので
いや本当そうだよなと思いますし
ドキュメントはエンジニアこそちゃんと書いてほしいなという気はします。
最後のチームメンバーからUI UX改善アイデアを受け取るというケースは結構稀ですけど
非常にスムーズにいくプロジェクトにおいては
エンジニアやQAから開発が良いペースに進んでますと思ったんですけど
余裕があるのでこのUI UXを追加しませんかといった提案を受け取るまでになる可能性もありますと
個人的には自分のプロジェクト進行中に起こる最も嬉しい出来事の一つです。
めちゃくちゃテンション上がります。
確かにマネジメント僕もやったことがあるんですけど
メンバーからこういう提案をされるってすごく嬉しいですし
お客さんとかプロダクトの依頼をした側もかなり嬉しいんですよね。
開発者なんですけど開発者側からそういう提案をしてくれてなかなかない経験なので
僕の経験でいくと開発者側からそういう提案をすると
余計なこと言うなって怒られたこともあって
ビジネスむずいなって思ったことありますけど
でも言ったほうが絶対いいと思います。
そういう反応される方ももちろんいらっしゃるんですけど
絶対にいいなと思うところは別に
メンバーとか開発者とか関係なしに言ったほうがいいなと僕は思ってます。
以上今のがセクション2でした。
次はセクション3ですね。
仕様書の重要性が増していく2つの理由というところです。
さてなぜ今後仕様書の重要性がさらに増していくのか
個人的に思っている2つの要因についてちょっと短めにいきたいと思います。
1つは当然今全世界が影響を受けているCOVID-19の在宅勤務の加速です。
もう1つは今は全社の影に隠れてしまっているものの
グローバル開発もしくはアウトソーシング開発の拡大が
今後も開発し続けていくもしくはして欲しいとこの人がおっしゃってますね。
開発し続けていくことに他なりませんと言ってます。
まあグローバルな話だと言うとそうですね。
ではこれもちょっと具体的に切り分けていきますけれども
1つ目ですね。在宅勤務においてコミュニケーションコストが増大しているというところです。
在宅勤務が加速したことによりエンジニア、デザイナー、救援人は
PMの〇〇さんちょっと5分良いですかといった対面での仕様確認が面倒くさく正直困難になりました。
対話であればモックアップと同時に参照しながら5分で終わるものが
スラックによる文字だけのコミュニケーションの場合
一つがうまくいっていないと何十もの繰り返しの質問もしくは回答が
連なるスレッドとなってしまいます。
逆にPM側としても本当は5分の口頭確認で済むのなんだよなと
ミーティングを設定するのも気が引けてしまうようになりましたよねと。
さらにはオフィスでは気軽にエンジニアどこに行き今の陣地を確認したいといった
気軽な確認も昔はできていましたが
18:00
現時点ではいちいちスラックでの確認が必要となってしまう
事態になりましたと言ってますが
ここについては僕はちょっと疑問があって
そもそも僕もエンジニアだから分かるんですけど
対面であろうがいきなりエンジニアにちょっと
5分の時間くださいとか確認させてくれって話しかけて
良いのかどうのかのか正直エンジニアの僕も
エンジニアの気持ちは分からんので
スラックで位置を確認してから僕は話しかけてましたね。
本当に今開発に集中していたりとか
脳全力とか自分のCPUの100%
ほぼ100%を開発とか設計に注力しているメンバーに対して
話しかけるってめちゃくちゃストレスなんですよね
エンジニアとしては。いちいち思考を止めなきゃいけなくし
どこまで考えたかって思い出さなきゃいけなくて
これって自立ものなんですけどめちゃめちゃ腹立つんで
あんまり直接いきなり話しかけるっていうのは
僕としては体験良くないので
エンジニアとしてもなるべくはスラックとかで
今話しかけていいかって聞いてから話しかけていくようにしてましたね
本当になんかのっぴきにならないとか
切羽詰まってる状態では仕方ないんですけど
今だとスラックもハドルがついたので
軽くハドルで画面共有しながら話しませんかっていうので
割と十分いけるんじゃないかなと思ってます
少なくともうちの会社のチーム
いろんなチームはハドルを気軽に投げて
そこでやってたりしますね
なのでリモートになったけど
割とそこの問題は解決してるような僕は印象ありますね
ZoomだとちょっとわざわざURL発行して
ほけほけってやらなきゃいけなくて
ちょっとだるいんですけど
一応僕なりの勢いでした
続いて
時差の出勤が当たり前のグローバル開発っていうのが
増えているはずだというふうにおっしゃってます
自分のPM経験の80%は2国間もしくは3国間にチームが分散していました
そりゃすごいな
その際チームの最も大きなよりどころとなったのが
実は使用書でした
時差がある開発環境において
使用書の重要性というのは3,4倍に膨れ上がるというのが
個人的な感想です
これは本当そうだと思いますね
使用書がお座りプラス時差が存在すると
寝てる間に質問が来て朝起きて慌てて返事を返し
さらに夜になるまでそのエンジニアからの返事を待ち
という時差がない場合に対して
信じられないほどにスピードが鈍化します
まあそうだよね
非同期コミュニケーションになるんだから
正解を持っている人依存になった開発体制は
つらいものになりがちなので
日本企業はでも主にアジア等にオフショア開発を
しているところもあるかと思いますが
こうしたグローバル開発は今後もどんどんと増えていくはずです
寝て起きたらプロジェクトがめっちゃ進行してた
というような経験こそがグローバル開発の醍醐味
もしくは楽しさだと思うんですけど
使用書の重要性というのはこうした環境において
今後さらに重要になっていくはずですよ
というふうにおっしゃっています
その通りだと思いますね
マネージャーとしても寝て起きてたら
すごい開発が進んでいたりとか
機能がどんどんできていましたと思ったら
そりゃワクワクしますよね
でもグローバルにおいては本当に
21:00
正解は何ですかというところを
やっぱりドキュメントに落とし込んでおく
ということはかなり重要で
それができているから
ちゃんとジョブディスクリプションを明確にできますし
かつ非同期コミュニケーションだとしても
メンバーが勝手にどんどん進んでくれるよ
というところがあるので
ここは完全同意という感じでしたね
続いていきましょう
セクション4ですね
使用書に含めたい14の項目実践編です
今日の記事のタイトルにある通り
これが多分本題だと思いますね
あと今日は僕がスタート何分だっけ
5、6分遅れた気がするので
大体35分くらい目処にいきたいと思います
さて、良い使用書のメリット
及び使用書が今後重要性を増してくる理由について
ツラツラ書いてきましたが
ようやく本題ですと
個人的に定義している良い使用書とは何か
どのような項目を使用書に含めているかについて
ガッとまとめてみました
画像にするとこんな感じで
今画像1枚のバンと画像があるんですけど
まあ長い
縦長の画像ですけど
一応項目分けにちゃんと書いてあるので読んでいきますね
これが具体的に今から語られることだと思いますけど
いきます
まずタイトルがあって
次で最上位のチケットエピックを書いてますと
その下に関連チケット
全てですね
ストーリー、タスク、バグ、エトセトラ
っていうのがガーッと書いてある
続いてその下にプロジェクト発起の背景と
解決したい問題ですね
その下に達成したい状態
検証したい仮説が入ってきます
続いてプロジェクトサマリンですね
ここでサマリンが来る
さらにその下にKPIが来て
その下にエクスペリメントフラグなど
実験周りのところが入ってきます
検証結果とダッシュボードへのリンクなどが
貼られると
あとデザインファイルへのリンクですね
この時点でかなり細かいんですけど
ここからまだ続くんですよね
もしあれば関連する過去の仕様へのリンクなど
書いておきますと
現在のUI UXのメモとか
現在の仕様というのを書いておきます
バックエンド側の仕様も書いておきますと
続いてフロントエンド、クライアント側の仕様ですね
っていうのをガーッとひたすら書いていきます
その下にトラッキングの仕様ですね
トラッキングをちゃんと書くんですね
QA関連のメモとQAとの質疑応答など
っていうやり取りのことも
大事なものであれば書いておきますと
口頭で話されたこととかが一応書かれるんですかね
続いてその他の備考があって
最後関わっている関係者
メンバーリストというのを書いて終了
というところですね
これはあくまで例ですけど
繰り返しになりますが
本項目はあくまで僕が考える
最大公約数の良い仕様書です
僕が過去に働いていた会社
もしくは今働いている会社とも
割と違うフォーマット、項目を使用ですね
存在しない場合もありますし
していますので
PDMの環境それぞれで
良い仕様書の定義がやっぱり異なるはずです
っていうのが大事だからもう1回言ってますね
ただどれか1つでも
これ入れた方が良さそう
明日からこれを含めた仕様書を書こうと思っていただければ
24:00
筆者、妙利に就きますねと
一部前の記事からの転載ですと言ってます
この記事自体が前の記事の続きなんですね
じゃあその14項について
具体的に書かれてますので
それを読んでいきますが
多分中途半端に終わる気がします
1つ目ですね
プロジェクト発起に至った背景
もしくは解決したい問題を伝えるというところです
仕様書の先頭には
プロジェクト発起に至った背景
解決したユーザーの問題を記述します
実際の仕様レビューでも
冒頭5分、締めの2分で
なぜこのプロジェクトが大事で
意義はどこにあるのかっていうのを
チームメンバー全員に可能な限り伝え
会社の成長を左右する重要なプロジェクトに
参加していると
意識してもらえるようにします
続いて
検証したい仮説
もしくは達成したいことを簡単にまとめます
解決したい問題に対して
どのような仮説を持って
この機能を開発するに至ったのか
ユーザーがどのような状態になるのが理想なのか
っていうのを記載します
特に仮説を証明するために
実験的に開発するような機能の場合は
後者をきっちりと書くようにします
はい、というところです
続いて3つ目ですね
プロジェクトの概略を1、2行でまとめます
使用書そのものが何スクロールにも当たり
使用レビュー回も1時間を超えるみたいな場合ですね
こんな場合は全体像が最後になるまで
わからなかったという事例が起きえますと
まあそうでしょうね
ほとんどの場合
全体を把握した後
詳細を把握するという思考フローの方が
各自の理解力を向上させます
あと認知
認知コストがかかりますのでね
全部を把握して最後に答えを言われると
まあ多分人間の認知としては限界が来ると思いますので
しかも何スクロールも言ってしまったら
余計にそうだと思うんですよね
なので最初に全体をガッと概略把握する方がいいと思います
このため自分の場合は
できるだけ冒頭でざっくりで言うと
このプロジェクトはこんなことをやるよというのを伝えて
使用書及び使用レビュー回の冒頭で
チームメンバーにそれを伝えるようにしていますと
またこれは以下のようなメリットもありますと
使用書を読むのは
開発に携わるチームメンバーのみでは当然なく
VPOPやエグゼクティブメンバーBJM
自分が退社した後に関連仕様を探して
あなたの仕様に辿り着いた別のPDMなどなどですね
はあ確かに
様々な人が訪れるはずです
なので冒頭一二行でプロジェクトの概略を書いておくと
こうした人が使用書をすべて読ますと
全体感を把握することができ
その先を読み続けるべきかどうかというのを
判断できるようになりますということですね
はい確かにそういう目線はありますね
今後自分が離れてしまったとしても
辿り着けるように
使用書というのをしっかり書いておくというのが
かなり大事ですね
これいいですね
続いて四つ目ですね
計測するKPIと期待する動きというのをまとめます
開発機能をリリース後
どのようなKPIをプロジェクトの製品のために
検証するのかというのをまとめておきます
特に上がると期待しているKPI
下がるかもしれないKPIの二つの項目に分けて
記載しておくとはよいだろうという風に
27:00
この人はおっしゃってますね
続いて一つ目の項目です
実験用フラグ名とかバリアント情報だったり
振り分けパーセント等を記載しましょうと言ってます
実験用フラグ名などは
頂戴な仕様にちょろっと書いてあるような状態だと
割とエンジニアに何度も聞かれてしまう項目となるので
これは体験なんです
冒頭の目立つところにしっかりと記載しておきます
なるほどね
フラグ名がもう決まっているのであれば
確かにそれは書いておいた方がいいかもしれません
じゃなきゃエンジニアが各自
開発者が勝手にフラグの名前を付けていくことになります
これは詳細設計に近いイメージがあるので
この実験用フラグ名というのは
変数的な名前じゃなくて別の何かな気がしますね
プロジェクト的における
分岐のためのフラグ名なんでしょうね
続いて6個目の項目です
全てのリンクを仕様にまとめますということですね
仕様書を見れば
全ての関連ドキュメントのリンクが載っている状態を目指します
メンバーがデザインファイルへのリンクはどこ
チケットはどこだっけ
あのドキュメントはどこ
というようになってしまう
無駄な時間コミュニケーションの時間を極力削減します
単純なように見えてきちんと気を付けないと
すぐにこの状態に陥ります
開発チケットエピックストーリータスクと
デザインファイルリンクQAプランへのリンク
追加できた質問に答えた内容
関連ドキュメントですね
ちゃんと口頭でなくて
喋った内容も逐一逐一ここに書いていくんですね
決まったことについては
などなど全て余すことなく
仕様書ページの適切な部分に記載します
個人的にはQAプラン追加仕様等は
仕様書の末尾へ
それ以外は先頭に記載しています
いいですねそれは確かに
QAの人は多分全部把握してからだと思うので
最後の方のプランなんか言う気はしていますし
追加質問等というのは仕様書の末尾でも
これもいいと思います
あくまで追加なので
というところでした
では14個なので7個か
7個までいったら半分なので
あと1個だけ読んで終了にしようと思います
7個目ですけど
結果欄
ローンチ後の検証結果というのを記載しましょう
チームメンバーの多くは
リリース直後から
効果はあったのだろうかと
やきもきするようになります
アクションに対するフィードバックが早い方が
モチベーションの維持にも良いとされています
したがって仕様ページの前半に
検証結果欄を空白で用意しておき
ダッシュボードのURLや
BIからの検証結果が上がり次第追記します
メンバーが気になった場合には
自ら途中結果を見に行けるような環境も
型作っておきますと
プロジェクト終了後というのは
その検証結果を後日
仕様ページの先頭に記載しておきますと
これを行うことで
1,2,3年後に入った新しい社員が
同期、同実験の結果を
容易に知ることができ
結果がどこにも起こっていないから
もう一度やってみようと
言ったら無駄なコースを削減できます
個人的にはここを一番忘れがちなのということですね
確かに
エンジニアならもう一回
検証結果してみないとか
実験してみたりすることはあるんですけど
そのコースは確かに無駄になるので
なるべく削減できるようになした方がいいですよ
というところで
すごい中途半端で
大変申し訳ないですけど
ここで一旦区切らせていただき
また明日ですね
この続きを読んでいこうと思いますが
もう今一時点で
30:00
かなりこのドキュメント素晴らしいなと思ってます
このノート記事自体が素晴らしくですね
これはマネージャーだけじゃなくて
エンジニアもやっぱり読んでほしいな
というふうに僕は個人的に思いました
じゃあ明日もこの続き
ちょっとゆるーっと読んでいくので
もし興味ある方はご参加いただければ幸いです
では今日の朝方こちらで以上にしたいと思います
本日も参加いただいた方々
大変にありがとうございました
火曜日ですね
今日また一日お仕事頑張っていけたらなと思います
では終了します
お疲れ様でした
