久しぶりにデスマーチな案件を引く


2017年11月 矢向が久しぶりに本業でヤバイ案件を引いたのでメモしておきます。

今までは、自分がメインになって全行程に携わってきましたので、前工程で不明点があるから進めないでくれなと伝えていましたが前工程がわからない、顧客要望がわからないなどのなか対処する珍しい案件でしたのでブログにメモしておきます。

ブログを読まれている方で今後ITインフラ系で何が危ない案件化の見極めになればと思い利用いただければと思います。
2017年11月時点でネットワーク系を中心としたエンジニアの案件対応法(手法)をいかに記載します。

世間一般的な工程と作業概要

1.要件定義
ユーザーの要件やシステム要件を定義する

2.基本設計(概要設計、機能設計、移行設計)
ユーザがレビューするためユーザが分かる内容を記載する。

3.詳細設計

基本設計、ユーザレビュー内容を元に装置への実装のためのパラメータをまとめます。

4.コンフィグ作成
詳細設計を元にルータのコンフィグやプログラミングを作成する

5.単体テスト
作成したプログラムを単体で動作試験を行う

6.結合テスト
結合テストでは、単体でのテスト済みのプログラム同士を結合させる

7.システムテスト
システム全体を対象とした動作テスト

 

各工程を引き継ぐ

2017年11月に矢向が対応した最悪のパターン、ケース3からの引き継ぎです。

ケース1:「2.基本設計」 から引き継ぐ場合 安全

  • ITゼネコンでよくあるパターン
  • 販売機器の確定、構成の確定、冗長性の確定、スケジュールの確定など
  • 前提条件:要件定義を理解していることに成ります。

ケース2:「3.詳細設計」から引き継ぐパターン 安全

  • ITゼネコンでよくあるパターン2
  • 基本設計の中での引き継ぎを確認する必要がある。
  • 前提条件:「基本設計」を理解していることに成ります。

ケース3:「4.コンフィグ作成、5.単体テスト、6.結合テスト」から引き継ぐ場合

  • 絶対に受けてはいけないダメ工程パターン
    最終的なお客様向けコンフィグも矢向さん側で出来ますか?と言われ矢向が切れて、「設計者じゃないのに細かい資料もわからないし出来ない」と一蹴しましたが、酷いプロジェクトでした。
    (お客様先出荷3営業日前の出来事です)
  • 「4.コンフィグ作成」は、詳細設計の延長です。お客様に導入する要件を確認しているのは設計者です。
  • 前提条件:「詳細設計」を理解していること。(これは大事です)

つまり、体制の中に「設計チーム」と「検証チーム」の2チームが存在している場合ほぼ「デスマーチ」が始まります。検証を進める必要がありますが通信で必要な経路が決まっていないなど何が決まっていないかを明確にする必要があります

矢向も正直ここでハマりました。組み始めたと思ったらこういう経路を通して欲しいなど設定を作りながら言われると通信経路を作り直す必要がありますのでそれまでの内容が「無」になります。

ケース4:「5.単体テスト」のみ行う

  •  ものすごい簡単で、テスト仕様書通りに行うだけ

ケース5:「6.結合テスト」まで行う

  • 「詳細設計書」の内容理解する必要がある。
    ルーティングはOSPF・BGPを使っているか?通信団時間に問題はないかナドの判断力が求められるため、詳細設計書の読み込みやは基本設計書の読み込みに1週間などかけて読み込んだほうが良いこともある

また、設定方法がわからない機器は、誰か窓口に成ってもらえるか?

 

今回書いてみて何を感じたか?

その他の案件も同じですが、設計チームとか検証チームと体制が別れた時に工程が違うチームが存在することはありえない話であり、「ちゃんとおかしいと言う」ことが大事になってくる。

前工程で決まっていないものが明確でないなか作れないことを「ちゃんと言う。」などチャント出来ないとグループ全体へ波及してしまう。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です