1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

忘れないうちに上流工程戦略会議のメモ

Posted at

私は誰?(?)

IT部門がある企業でチームリーダーをやっています。
まだ3年目、かつ一時期炎上とかなんとかいろいろあったので、すごくおっかなびっくりの状態で日々仕事してます。
つまり経験値がなさすぎる。

上流工程戦略会議

TECHPLAYさん主催、バルテス株式会社さん登壇のこちらのイベントです。
アーカイブは限定公開のため、私のメモ書きをなんとか体裁整えて書いていきます。
ゆえにメモが誤っていたら申し訳ありません…(´・ω・`)

ちょっとの手間で手戻りを減らそうって話

上流工程であいまいな仕様を減らす

テスト終盤になってから致命的な不具合があってやばいことになった。
そんな人は多い気がします。私もがっつり経験してます。
そりゃまあ、先にしっかりした仕様書書ければそれでいいんだろうけど。
本人的にはできてるつもりだったりするんです。(いかんせんノウハウが蓄積途上)
じゃあどうやったらええの?って話。

ざっくり書くとこういうことだそうです。

  1. 「見えない仕様」を可視化
  2. 「できないこと」を考慮
  3. 「図表」を活用

3つありますが、根本的には同じことだそうです。
このあと、各要素に関して事例を交えて説明してくださいました。

「見えない仕様」を可視化…できなかった例

ECサイトでクーポン機能追加!クーポン対象商品の検索機能も追加!

クーポン対象商品がないときの記載がない

検索機能が働かずリリース延期に(´・ω・`)

デシジョンテーブル」で整理するといいよ!
どの条件が書かれていてどの条件が書かれていないか一目瞭然!!

「できないこと」を考慮…できなかった例

サブスクリプション機能を追加するよ!1契約につき1端末ね!
2台以上で使えたらダメだよ!

PC2台同時で使えないことを確認したよ!ばっちり!

スマートフォンのこと忘れてたからPCとスマートフォンで2端末使えてしまうじゃん…(´・ω・`)

Must/Never法で「できるのが正しい挙動」「できないのが正しい挙動」を切り分けよう!
バグを叩きにいってしっかり潰そう!

図表を活用…できなかった例

タクシーにSOSボタンを設置したよ!押すと会社に連絡が飛ぶよ!

「空車」「賃走」のときはいいけど「支払」のときにSOSが機能してなかったよ…(´・ω・`)

このときの資料が

  • 文字ばっかり
  • 書き方が統一されていない
  • 運用と動作が一緒になって書かれている

ばかりに考慮漏れが発生したんだとか。

状態遷移表」を書くといいよ!
登壇してくださったボルテスさんのQbookに詳しい記述があるよ!

というか普通にQbookさんにはお世話になっております。ありがとうございます。

こういう手間をちょっとかけると良くなるよってまとめ

問題 対策手法
範囲が曖昧 同値分割・境界値分析
条件が複雑 デシジョンテーブル
全体が見えない・逆に細部が見えない 状態遷移表・画面遷移図
できることしか書いてない Must/Never法
非機能要件 品質特性(ISO/IEC 25010のうち殆どが非機能要件)

Must/Never/Want を横軸に、
ISO/IEC 25010の各項目とかを縦軸に表を書いて埋めるという戦法とか。

質疑応答

「Must/Neverの切り分けに特別な訓練って必要ですか?」

いきなりやるのは難しいので、テレビのリモコンとか身近なものでMust/Neverを洗い出してみるといいよ!
MustとNeverは必ずセット
ほかの人と見せ合うと、意外と一致しないからおもしろいよ!

仕様を理解するという点だと、新人さん相手とかなら特に過去の不具合の共有もおススメ!
危険地帯の把握ができるからね!

「デシジョンテーブルが肥大化するんですが…」

環境条件とかは別で分けたり、特殊なケースは抜いておいたりしてもいいよ!
ただ、考慮しなかったものは何なのかドキュメントに残しておくこと
後で不具合が見つかった時に特定が早くなる率が上がるよ!

「品質が低いものができてしまったときの考え方を教えてください」

怒られたり査定に響いたりはするでしょうけど、いい学びの場だと思いましょ。
「ればたら分析」で「こうしていればマシになったよな」って感じで原因を探って振り返る感じ。
完璧は存在しないから求めなくていいよ!!!

「バグを叩きに行くコツを教えてください」

期間や工数は限られていると思うので、
何ができたらOKなのか優先度をつけて叩くといいよ!ここでもMust/Never!

テストには

  • 普通に動かしてバグがないか確認するもの
  • バグを積極的に探して潰しにいくもの

の2種類があるよ!
「このシステムでやばそうなバグはなにか?」
→「どういう状況でそのバグは出そうか?」
という順に考えて、やばそうなバグが出そうな挙動をぶっ叩きに行くよ!

数的にたくさん洗い出したいなら、過去の不具合を参考にしよう!
バグは均等にあるわけじゃなく、「でやすい場所」というのがあるので、そこを叩くといいよ!

雑感

いやー出てよかった。ありがとうございました!!!!
おおまかにはこんな感じですが、普通に何度でも見たいのでアーカイブが公開されたら嘗め回すように見ます()

第2回とかもやるかもしれないとのことなのではちゃめちゃに楽しみにしています!

…忘れないようにと興奮とで記事の文体が若干荒れてますが大目に見てください…
大豊作だったものだからつい……

1
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?