ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

なれる!SE4から技術ネタまとめ

「我々はイグゼク・ソルさんが島ハブまで配線すると聞いてたんですけど。今のお話だと御社は各階のディストリビューションスイッチまでしか構築しないということですか?」

発注元がいろんなベンダに(PMさえも)振って調整は知らんぷりとなるパターン、本当にあるんですね。

「我々はもともとその条件でBM(ベターメディア)さんに見積もりを出してますよ。というか立て管配線も御社──扶桑通建さんで行われると聞いてますけど」 「はっ? いや……ちょっと、ちょっと待ってください。立て管の工事費なんてこちら見積もってませんよ。え? 仮に四階から十一階まで配線するならCAT5じゃ足りない。ファイバーを手配しろってことですよね。全然コスト感変わってきますよ」 「それは……知らないですよ。というかディストリビューションスイッチはメタルのインタフェースしかないんで光で出されても困るんですけど。メディコンなりなんなり噛ませてRJ45で出してください」 「いや……いや何ですかそれ。無理です、ちょっとベターメディアさん、これどちら作業のイメージなんですか?」

CAT5はLANケーブルの企画。5eでも最大伝送距離は100mなので、足りないと言ってるんでしょうね。で光ファイバーにするとコスト変わってくると。というかこんな用語あえて使うかな。RJ45はいわゆるイーサネットケーブルの端子、光ファイバとは端子が異なるのでメディアコンバータで変換しないといけないと。なんかいやらしい専門用語の使い方な気がするけどきっとわざとでしょう。

どうやら今回のプロジェクト、LAN部分をイグゼク・ソリューションズと扶桑通建の二社で分けて構築するらしい。具体的に言うと基幹部分(コアスイッチ、ディストリビューションスイッチなど)はイグゼク・ソリューションズ、島ハブやフロア配線など(物理・L2部分)は扶桑通建という感じで。で、お互いの繋ぎ部分をどちらがやるか合意が取れていない模様だった。

「外部DNSはどちらの担当になるんでしょう。我々はあくまでコネクティビティのみの提供という認識だったのですが、先程のサーバ管理会社者様のお話だと内部DNSしか用意しないということだったので」 「え? インターネット向けサーバは今回御社のホスティングに集約するから、全部撤去して構わないと言われてたんですが。プロキシと、あと公開WEBも」 「いや、いやそんな話は聞いてませんよ。そもそもホスティングのお見積もりなんて出してませんし」 「そんなこと言われても……新オフィスのサーバ台数はもう見積もり済みですよ」 「待ってください、ちょっと待ってください」扶桑通建の薬院加奈子が眉を更に吊り上げた。 「ラックの収容台数が変わるんですか? 今ギリギリで押し込んでますからサーバが増えるならラックを増設する必要がありますよ」 「え、それはまずいですよ。もうフロアレイアウト決まってるんで」

外部DNSの話はどこの会社が言ってるんだっけな… サーバの代数が変わると、フロアデザイン設計のひとが困ると言っています。

商流とプロジェクトのレポートラインがズレちゃってるのよ。まぁ、よくある話ね」

発注の流れ。普通は発注元⇒PM⇒各ベンダになるところが、今回は発注元からPMを含めた発注先が平行線で調整役が誰もいないのでこうなっている。

「直接取引したいなら顧客がきっちりPMまで含めてやるべきなのよ。プリセールスから入って各ベンダーの提案範囲に重なりがないか、抜け漏れがないかチェックする。そこを金額だけ基準に選定して、あとは各社ご自由にって投げ出すからおかしなことになる。認識ズレが発生する」

「すみません。スケジュールと仰いますが進捗管理はどのようにやられるのでしょう。ガントチャートですか? それともPERTですか?」

PERT(Program Evaluation and Review Technique)
丸と線のアローダイヤグラムを作って最短どれぐらいでいくかーみたいなのを洗い出す作業ぽい。

「アクションリストのフォーマットはないんですか? 最低限必要な項目だけでも提示していただかないと、あとで二度手間三度手間になりかねないですが」 「結局本件のステークホルダーは誰なんでしょう。一旦そこを定義しないと、どこに何を調整してよいか分からないですよ」


よく統合、とか呼ばれたりしますね。

「御社は本件のWBSさえ作られないんですか? プロジェクト計画書は? 成果物リストは?」

EAC(完成時コスト予測値)=AC(発生済み実コスト)+(BAC(プロジェクト総予算)─EV(出来高))/CPI(コスト効率指数)』。見慣れぬ計算式とともにS字カーブのグラフが書かれていた。定期的に出来高と予算を比較することで作業の遅れやコスト超過を洗い出せるらしい。

発生済み実コストに、総予算から出来高を引いたものを効率指数で割ったものを足す…
2つ目の項が何をさしてるんだろ、

「他にもクリティカルパス法といって、複数業務の最短スケジュールを見つけるやり方とか、デシジョンツリーっていう確率論的な意思決定のやり方とか、とにかく意外に科学的──論理的なんですよ。僕、PMってもっと感覚的なものだと思ってたんで、結構新鮮でした」

とはいえ結局はひととひととのコミュニケーションなんですけどね。

「誰にだって最初の一歩はある。つまづくことを恐れて動かなかったらどこにもたどりつけないわ。失敗したって恥をかいたって、成功するまでチャレンジし続ければいいのよ。丁度、今の私達みたいにね」

サーバ〉タイプのメンバーはPMを顧客として扱う。彼らは原則としてPMの指示に従順で管理の手間を減らすように動く。要件変更や納期調整についても可能な限り柔軟に対応してくれる。このタイプはある程度まとまった仕事を渡しても構わない。自分で判断し必要があれば報告・相談をしてくれる』

『〈ツール〉タイプのメンバーは完全に作業員として振る舞う。彼らはPMの指示に従順だがプロジェクトの成功には一切責任を持たない。言われたことを愚直に実施し、結果問題が起きてもそれはPMの指示が悪かったためと考える。彼らに臨機応変な判断や検討を求めてはならない。細かく指示を与え状況をトラックすべきである。〈サーバ〉タイプのメンバーに慣れたPMはこの点で失敗しがちだ。以前のメンバーなら言わずともやってくれた内容がどうしてできないのかと考えてしまう。〈ツール〉タイプのメンバーにエンジニアリングを任せる際はPMのサブにテクニカルリーダーをつけるべきだろう(主にチェック/トラック要員として)。余談だが外資系企業のエンジニアには〈ツール〉タイプが多い。注意が必要である』


メンバーを3タイプにわける話。サーバタイプは、ざっくりとしたお願いでもいいようにしてくれる。プロジェクト全体の最適を考えて行動してくれる。ツールタイプは細かい作業レベルで指示しないといけない。つまりプロジェクトがどうなろうと知ったことではない(エンジニアにはこのタイプが圧倒的に多い気がする)

最後にクライアントタイプ、PMに作業を最適にすることを要求するタイプがありそれに対する対策は明かされないままだったなぁ。

「藤崎さんにとって……プロジェクト管理ってなんですか?」 「みんなが気持ちよく仕事できるようにすること」

結局はひととひとのコミュニケーション、そういうことだよね。