技術関連の覚書

案件でやったり自宅で試したことの覚書、自宅Redmineから移行

無茶振りへの対応

技術と離れるかもしれないけど、マネジメントとしてはちょっと書き残しておこうかなと言うことを

客先から1週間前倒しでお願いしますという無茶振りを水曜日に言われた時の話

リーダーから、休日出社して欲しいと言われましたが、期限は金曜日 休出したところで完成するのは月曜日になります 休出して遅れ出したと怒られるので無意味なことはやりたくはありません

普通なら間に合わないんですが、やり方があまりに効率悪いと思っていたので 間に合わせろというのであれば、お客さんにも手伝ってもらう手はずをつけない限り無理という提案をしました。

リーダーが動いてくれたと言うよりはお客さんの方も上から言われてのことで 無理はわかってるからできるだけ協力すると言ってくれたので実現できた感じもあります。

今回の納品物はドキュメントで、更に修正担当は他のチーム。 自分のチームに関わるところをチェックして実装と相違がないか確認して各担当に渡すというものでした。

これまでの手順 すべて紙の上で行って赤入れされたものをレビュー記録表に記入して担当者に渡します。

  1. 内部で打ち合わせてチェック

  2. 修正後、内部で再びチェック

  3. 内部レビューでOKが出た後客先に提出してレビュー

  4. 客先からNGがあれば修正、これを1からやり直す

  5. 客先OKとなったものを納品

ちなみにレビューは紙です

今回の手順

間に合わせるために内部レビューと客先レビューを一緒にしてしまえばいいので 会議室にノートPCを持ち込み

  1. チェックする人とお客さんは紙に慣れているので印刷物を用意して読んでもらった上で指摘部分を出してもらう

  2. 洗い出したものは、全てレビュー記録表にその場でお客さんと合意した内容で書き込み

  3. レビュー記録表を各担当の窓口に渡す

この方法にしてどうにか木曜日にレビューを終わらせて金曜日の納品に間に合わせることができました。

ただ、今は普通は後者のやり方のではないかと思いますが、全社のやり方も少なくはないかもしれません。

どうすれば早く終わるかというのは精神論ではなくいかに無駄な作業を省くかにあります。

ウォーターフォールが悪いというわけではなく、ウォーターフォール開発で失敗する多くのパターンは テスト工程をテストの実施時間しか取らないこと。

テストしてバグが見つかれば当然、修正が必要ですが、大昔、まだソースを紙に書いてキーパンチャーが入力していた時代の話(私も聞いたことしかありません) 机上でのチェックで全てバグは取り除かれていて、テストは完全に動くことをお客さんに提示するため というものだったようです。 だから、バグが出ると大騒ぎになる、隠すといったことがあったようです。

テストというのは、本番までにバグをなくすための作業なんですけどね。

そんな大昔のやり方を今も守り続けているところもあるので、そういうところに対しては文明の利器 自動テストなんてものはその信頼性とかを問われます。

登場してから15年以上経ち、やり方も公表されていて成功例も数多くあるのでそれを見せてあげることが良いのかなと思います。

ITについては伝統を守ることはあまり良い言葉ではないですね。