すのふら

すのふら

日々の備忘録

リードとしてスケジュール立てるときの生存戦略

今のプロジェクトで、テストチームリードをやっている。
リードになってかれこれ半年くらい経つが、俺の力不足と外部要因によってテストスケジュールがきちっと出せず、
最初の話だとヌルゲーだと思っていたのにこんなにもサバイバル能力を求められるプロジェクトなのかと戦慄している。

生存戦略をきっちりとっていかないと、降りかかる考慮不足によるスケジュールの引き直し。
遅れるスタート。
完了タイミングはある程度決まっているため間に合わせるための人海戦術、疲弊する俺含め作業者。

万策尽きる俺。

*1


そんな中、計画を立てるときにどう対応するべきだったのか、乗り越えるために考えたことをメモしておく。


俺のロール

俺の具体的なロールとして、データレイク基盤の構築を主にやっていて、基本バックエンド側のデータベースやバッチリソースに触れている。
テストフェイズ別では結合テストに該当するテストを主に担当している。
プロジェクト的には既存の横展開に近い作業で、個別仕様はあるが基本アーキはそのまま流用していく形。
結合テスト含め全体のテスト計画自体は俺はやってなくて、それはもっと上のテストリードが実施している。


きつかった外部要因

一番きつかったのは、

  • カットオーバーまでのマイルストーンが陳腐化している
  • 守れていないVモデル
  • テスト計画がいつまでも決まらない

ガイドラインが全く定められていない状態。

だが、カットオーバーの日時は変わっておらず、そこに何としてでも納めなければならいという点。

マイルストーンが陳腐化されていて、指摘事項のひとつが「今のスケジュールは古い。議事録読んでなぜ拾わないのか」でさすがにそれは痺れた。
俺より上の人は一体何をしているのか?そう思っても仕方ないと思う。*2

それでもなんとかスケジュールは立てねばらない。

Vモデルの仕組みが破綻していて、結合テストの裏で要件定義、設計中で全然個別要件が拾えない。
結合テスト自体は何度か実施しているので、その実績からやっていくしかない。

そんな寄り掛かるところがいまいち見えない状態でやるしかなかった。


スコープ

上で書いている通りテスト計画が未決定の状態で、詳細スケジュールを引かねばならない。

その状況だとスコープが全く見えず、いったいどこからどこまでが結合テストの範囲で、別の領域とどこで合流するのかっていう点が見えない。
また要件が分からないので、合流の要否もまったくわからない状況。

おそらく前回と同じなのではないかという感覚でテストスコープを出したが、やはり別の領域とどこで合流するのか、する必要がないのであればその根拠を示せと言われてそんなの俺が知りたいわ!

ここの指摘背景は、おそらく今回の結合テストではその領域間のつながりがキー。
正解回答は、内部結合テストでは自領域しかしないが、外部結合テストに向けて内部結合テストのデータを流用できるように連携する。

外部結合テストであれば適当にできたデータでもよいが、その工数の削減やデータの構成がよりあるべき姿であるほうがよいということ。
外部結合テストで必要で結構変わる箇所は、特にエンドユーザ・ほかの対向システムに影響がある機能であるので意識すべきだった。

意識できなかったので結合テストが必要で、影響が大きい結構変わる箇所」が一体何なのかを判断できなかったのが問題だった。

スコープは前回と同じだったけど、要件変更で変わって影響を受ける範囲が広範囲であるという点をスルーしていたための指摘。

まあ、要件が決まってなかったんや!って言い訳はできるが、スコープ立てる上で「今回の用件で、自領域以外で影響があるところって今のレベルでわかったりします?」という話を自チームのリードと話せていなかった。

リスクを事前に確認せずに、前回と同じで閉じてしまったことに問題があった。

次回以降も絶対にスコープは決まっていないので、「現状分かっている範囲で外部影響があるのかあるのであれば、どのあたりか」をできるだけ拾っていけるようにしないといけない。


テスト計画が分からないなら素直にいつまでにできそうかどうかは聞こうな、って話でもある。


スケジュール

上で書いている通り全体のマイルストーンがおかしかった。
そもそもそこちゃんと更新しろよって話である。

ただ、俺の落ち度としてはテスト計画を立てている人の議事メモくらい読めよって話。それは単純に俺の怠慢だと思う。

それはさておいて、スケジュールを立てるときにリスクは以下2点なんじゃないかって

  1. テストのデッドラインはいつなのか
  2. テストの期間中の環境面のリスク

結合テストのデッドラインはいつなのか

いつまでテストを引っ張れるのか?って話。

指摘された内容のひとつとして、本当に完了見込みをそこに置くべきなのか?環境融通まで強行してまで引っ張る必要があるのか、ちょっとずらせば環境問題も解決するしwinwinじゃないの?

f:id:snofra:20181029011305j:plain
全体リードはこんな笑顔じゃなかったっす。


その指摘はおそらく環境融通は結局しなければいけないのであれば、OKが出ていたはず(現に出た)。ただ、結合テストをいつまでに絶対に終わらせなければらないのか。

何かあった時のことを考えて結局どこに落とすのか。その理由。
そこからリソースもとに逆算していって、スタートすべき場所があって、それが結果的に環境融通しなければならない状況であれば文句は言われない。

そのいつまでに絶対終わるのかという軸から、ある程度余裕を持たせられる場所を見定められていなかった。


テストの期間中の環境面のリスク

上記でも書いたけど、環境を融通しあわなければならないタイミングがあった。

ただそこについて、どこがリスクで、それはいつ頃で、関係者とは認識合わせたのか。その外堀がきちっと埋められてなかった。

ただその外堀を埋める作業がリッチすぎるんじゃないかっていう話をする人もいたので、正解はいまいちわからないが、俺は外堀でもなんでも埋められて武器になるものは武器にしたほうが結果混沌としないのでよいかなと。
極力自チームの人に時間とりすぎないように考慮は必要だが。


環境

テスト工程が複数あるということは、実施環境も複数面あるということ。単純に作業者の時はDBMSの情報もらって何も考えず接続していた。

実際にスケジュール立てていくと結合テストの環境はどこなのか、結合テストの最中に同環境に相乗りしてくるテストはいないのか、相乗りしてきた場合のリスク。逃げることはできないのかなど。
環境だけでスケジュールがひっくり返るレベルの話だってある。

上記と共に環境の話で絶対に考えなければならないのが、「環境にコストをどこまでかけることが許されているのか」。コスト意識を正しく持てているのかだ。
指摘事項でかなり言われた観点であり、完全にそこは無視して話していた。

具体的な例のひとつが、
複数テストのバッチサーバ同居する。だがユーザ1つしかないので環境変数が同じになる。でもバッチリソースが違うので環境変数の向き先を分けなければならない。という問題。

そうなると当然

  1. 他のテストと同居できないのでバッチサーバ分けて並行で行く案
  2. 他テストと同居できないのでスケジュールをずらす案
  3. 素直にユーザを複数作る案

こんな感じな案がでてくる。


他のテストと同居できないのでバッチサーバ分けて並行で行く案

やろうと思えば一番簡単にできるパターン。ただ、この案は主にコスト面の心配をしなくてはならない。
環境を新しく作りまーす、に対する最初に立ちはだかる壁であり、一番大きな壁のひとつ。

単純に環境同居するから、みたいな簡単に考えただけでは絶対に突破できない。なぜなら金がかかるから。
そりゃあAWSインスタンスはかなり安くなってきた。ただ開発サーバみたいなのとはわけが違って、データ件数やインスタンスの稼働時間*日数で見たときに少なからず金がかかる。

本当にどうしようもないときは通るだろうが、それはリード陣が事前にそのプランで推し進めているはず。
そうではないときにひっくり返したいのであれば、それ相当の理由が必要であることだ。

上記の2や3がどうしても技術的、日程的にに突破できず他案も考えたうえで、どのくらいのコストがかかるのか「インスタンスタイプ(サーバ容量1h当たりのコスト)*稼働日数時間」でしっかり見積もる必要がある。

以前のプロジェクトでサーバを新しく立てたいとき、上記の説明をしてファイナンス的にOKであるかどうかは、レビューしてもらった*3

俺たちはお客さんの金を使って仕事しているということは忘れてはいけない。*4


環境で注意すべき箇所

なんとなくの肌感覚に近いが、環境で注意すべき箇所は以下かなと思っている。

まずはハード*5面や、スケジュール上関連しそうなテスト系の観点

  1. サーバやバッチリソースを共用するのはどこのテストなのか。
  2. サーバ系(DBサーバ・バッチサーバ・ジョブサーバなど)
  3. (対向システムがあれば)対向との接続先サーバ(SFTPサーバやS3のブランチなど)
  4. バッチリソースを共用するなら、configで分割できるのかできないのであれば、どう合流していくのか。

上からさらに詳細レベルに落とす。

  • (DBサーバ)どのテストがどのスキーマを使うのか。
  • (DBサーバ)同じDB、同じスキーマを使用する場合、影響はどの程度あるのか。回避可能か。
  • (ジョブサーバ)接続先はどこか。JP1であれば同じ接続先でイベント連携で拾ってしまう設定していないか
  • (対向との接続先)接続先はどこか。
  • (対向との接続先)サーバは1つだけか。結合テスト用に閉じた接続先環境を構築することはできないのか。できた場合、あるべき接続先に戻したテストは必要か
  • (バッチサーバ)環境変数系(みなし日など)は考慮されているのか
  • (バッチサーバ)接続先はどこか。資源の格納先は確定しているか


最後に

正直このプロジェクトはスケジュールはめちゃくちゃだし、Vモデルも守っていないし、寄り掛かる場所が全然なくて一体どうしたら、って思うことが多い。

計画がプランされていないときの生存戦略は何というか、裏技に近いような感じではいる。

新人の制作も入ったんです。最初に裏道を覚えたらどんどん間違った方法に頼るようになると…

f:id:snofra:20181027153742j:plain

これって裏道だよなーっていつもそう思っている。


じゃあ正攻法って何よって、指摘されているときにいつも言われているこの2点に尽きるんだろうなと。

スケジュールは面倒くさがらず、上から順番に固めていく。どうしてもピンとこないなという観点は少しブレイクダウンして細かくかみ砕いてみてから組んでいくとそんなにずれた工数にならない。

常にコスト意識を持て

めちゃしんどいが、
チャンス貰えるなら…ありがたいです!頑張ります
f:id:snofra:20181029011644j:plain


生きるってつらい!

*1:後半ずっとこんな感じだった

*2:スケジュール資料のタイムスタンプ上、レビューの1週間前でさすがにずれはないと踏んでいたがそこ違うのかーみたいな

*3:ガバガバだったので二つ返事でOKだったが

*4:当たり前の話だが戒めとして書いておく

*5:とは最近言わないか