この記事は、11/30夜に書いたのだけど、
書いている途中で眠ってしまったので再度、
手を入れて、アップロード。
-----
今日は、朝早く目が覚めたのだけどまた眠ってしまった。
月曜の朝はよく死にたくなるけど、とりあえず仕事に行く。
-----
１）ＮＷ（ネットワーク再構築）ＰＪ
今週一週間の滞在期間中は、ＮＷＰＪのヒアリング・調査・
打合せのオブザーベーション・進捗管理の実態把握と
報告資料の形態の一部改善提案などを続ける予定。
Ｘさんにはこれから数カ月の間、滞在してもらう。
（場合によっては数年。）
神戸に来てもらっている派遣さんにも今日から１週間
だけ、変更管理やライブラリ管理のほか、細々とした
プロジェクト管理方法の導入のため、それぞれ滞在して
もらう。
-----
Ｘさんには
「やるのは調査です。
あそこらへんの若いのを紹介するので、一度、動きを
どう進めていくか、自分で決めて行ってください。
あと、いろいろ動かしてどたばたしてますから、
その作業と並行するような感じで、動かしている
機器類の操作方法等を覚えて行ってください。
若い連中は、正社員ですけど、どんどん使っていいです。
僕が権限委任されてるので。
あと、やりたいこととか、ちょっと調べてほしいことを
この紙に手書きで書いといたので、ちょっとずつで
いいんでわかるところから、みてもらえませんかね。」
とだけ言って、作業を始めてもらった。
メモには、
・普通の電話も一部は残したい。
・ＩＰ電話引きたい。
・ネットワーク回線太く。＋QoS（大まかな計画ほしい。）
などなど・・・
こんなメモで動いてくれる人はあんまりいない・・・。
Ｘさんだからやってくれるのだと言える。
-----
派遣さんは、神戸でやっている構成管理や変更管理手法など
をこちらで雇い入れた派遣さんにスキルトランスファーしていく
役目。
プロジェクトの性格が違うので、一日一度程度は、現場のリーダー
も交えて、方針確認をする予定。
とにかく１週間しか時間がない。
派遣さんは時間契約なので、迂闊に残業もさせられない。
-----
ネットワーク機器・回線等の調査に関わっている２０代の
若いメンバは、その言動や取り組む姿勢を見ていると、
「どうしても、今の姿にこだわって、そのまま使える構成や
機器を温存したがっている」
ような感覚を覚える。
まあ、少しは自分たちが関わった部分もあるし、
それまで含めて全面的に見直す必要はないんじゃないのか。
できればそこは残しておいてほしい。
というような気持ちが読み取れる。
エンジニア達は、誰でも、自分の作ったものを、簡単に取り
壊されたら、プライドが傷つく。
しかし、私は他方で、彼らが、
・ビジネスの様々な側面を無視して、
・無節操に将来性の検証をすることなくして、
目新しい技術を半ば試験的に採用したがったりする
面があることも知っている。
－－－－－
昼過ぎに軽く寝ていた後、起きてデスクに座ると、
彼らが、私の近くで話し込んでいて、
話しかけてきた。
「あそこは去年の初めに、やったばかりのところなんですよ。」
私にお願いするような口調だったので、
私は考えを、細かく話した。
「フロア内・域内・国内、それぞれの全体最適はまず考えな
あかん。それは分かってると思う。」
「そして、同時に今回の取り組みは、パイロット的、もっと
言えばミニチュア盤のプロトタイプを作り上げて、
その評価をとおして、全体を置き換える計画を練り上げ
ようという算段でいる。」
「それで、そのあと、各拠点間を結ぶ基幹回線のリプレース
と主要なサービスの性能向上策を計画する。」
「それを考えるときに、個別に増設・代替した個所に拘って
たら、正直きりがあらへん。
もちろん、その機器が要件を満たすものなら、既設のまま
利用することは大いに検討すべきことやけども。」
「でも、無理やな。
もともと、ぼくは、全部できるなんて夢物語は全然考えて
ない。頭にあるのは優先度だけや。。」
「優先度を考えて、まず出てくるのは、メールとかＤＮＳ。
だけど、こいつらは、まず性能よりも、落ちんことが
最優先や。
だから、性能の向上は後回しや。
とにかく、ＲＡＩＤ１＋０にしたり、ストレージを共有化して、
バックアップをバックグラウンドタスクにしたり、
回線を多重化したり、すぐ手が打てることで
落ちへん仕組みを１日でも早く入れて行く。
そういう意味でもＸさんは役に立つ。
あの人は、アイデアマンで、頭の回転がめちゃめちゃ速いから。
なんか思いついたら、話を聞かしてくれる前にもう実現できるか
どうか検証が終わっている。
そういうレベルで仕事ができる。
方針的なところは、もう少し細部を全体で話そう。
案としても、こういうのが一番通りやすい。
会議中に、「そうですね。今頃落ちてるかもしれません・・・」
そう言うたら、予算そっちにつけるやろ。
ビビらしといたら数字なんかどうでもええんや。」
ただ、今やってほしいのは、ミニチュアがどんな
もんなんかってこと。
そのデザインはＸさんもいるし、君らもどんどん意見を
言って、計画を練ってほしい。
「ざっくり１か所をフルスペックなもので置き換えて、
それをじっくり評価する。
それを成功モデルにして、多地点展開を
繰り返していく。それがプロジェクトの要になる。」
あとはそれをつなげること。
各サービスを順次増強していくこと。
ベンダの使い方もポイント。
必ず、計画を作り上げて→ＲＦＰ→そのフィードバックを
受けて、計画書の修正で、作業の委任から発注して、
納品→保守まで、とことん付き合わせるのがポイント。
「１台サーバ買ってそれで終わり」って話じゃないから、
「地獄の底まで、付き合ってもらいますよ」って最初に
言っとくべきだよね。
-----
私が最後に言ったこと。
「今回のプロジェクト計画書はＪさんがほぼすべてまとめる
んだけど、計画書で一番大変なのって、
「外部委託（委任・請負）」
「購買」
なんだよ。
ほかにも
「内部統制」とか
「セキュリティ」とか
今回は厄介なのが、目白押しだけど、極端な話そういうのは
やれる人間の工数だけ確保して、あとからやってもいい。
だから、構成図とかみたいに君らで書けるところは、できるだけ
君らで書きあげてほしい。
リーダーのスタンスはレビュアー、
Ｘさんも手伝ってくれるかもしれないけど、手書きで鼻歌歌いながら、
メモ書くことくらいしか期待できないから。
あの人には。
あの人に品質の伴ったドキュメントは期待しないほうがいい。
-----
んで、Ｊさんが一番大変なのは、人を雇ったり、物を買う
計画の部分なんだけど、今回は物を買う部分が圧倒的
に厄介だよ。
資産台帳をぱらっと見ていて、すぐそう思った。
このプロジェクトで一番大変なのは、ネットワークを敷く
ことじゃなくて、その会計処理を適切にやれるかどうか
だよ。
まず、
●１つ目は、
LANケーブルや・小型のハブなどの記載がない。
こいつらは費用処理できるから会計上の現物照合の
必要性がない。
もちろん資産管理という意味では、現物照合は重要や。
ただ、実体として、今どれだけあって、それがちゃん
と動くかという信頼できる情報が全然ない。
だから予算組む時、どんだけ金額積めばいいか
わからない。
（まあ、これはだいたい概算で済むレベルの話だけど。）
●２つ目は、
細かい話で、機器に機能拡張のために増設した
部品がある。増設自体は構わんのやけど、問題は、
本体の保守期限より短いものがあること。
その部品だけ壊れて、リペアパーツが在庫切れして
いたら、アウトだ。
さらに増設で問題なのは、適切な会計処理。
例を挙げる。
ルータをケーブル等込みで３００万で買う。
これは付帯品も含めて１個の資産として台帳に登録
して、減価償却し、また、固定資産税を払う。
その後、必要に応じて、そのルータにI/Fを部品取付料
等込みで５０万で増設する。
どちらも償却資産だけど、ものとしては一体になって
しまっている。
でももともとある本体はすでに、償却してきている。
他方増設した部分はこれから償却が始まる。
物としては１つ、会計上の資産としては２つ。
こういうケースがかなり多い。
既存資産を使う場合はこういうのが厄介で、
１個ずつ計算していかないといけない。
経理部門がこういう厄介なことにどれだけ手を
貸してくれるかだけど、おそらく、もの一つ一つを
みても彼らじゃ何もわからん。
かといって、個別の会計処理を全部このＰＪ
で背負ったら、大変なことになってしまう。
これはもう、経営判断が入らんとあかん領域
やと思う。
●３つ目は
予算を出すとき、税務上の支出と制度会計上の
費用（償却費）の比較を求められるような場面が
多々あるということ。
５００万でルータを買ったとき、
制度会計上の費用は、５００万。
税務会計上の費用は、償却費用だけだ。
（もちろん、どちらの場合も購入時、バランスシートに
固定資産が載って、現預金が減少している。）
購買計画でポイントは投資対効果をどういう指標で
図るかだ。
単純に費用の減り方が少ないのがよいのか。
キャッシュアウトに着目するのか。
機器を複雑に構成していると償却方法も
変わってきて、余計に計算がややこしくなる。
その上で、制度/税務の両面で投資対効果を
算出するという作業がいる。
他に考慮が必要なのは、
・固定資産の強制減損処理
・繰り延べ税金資産
・さらに平成19年から21年にかけて始まった、固定資産の
償却方法の制度変更
だな。
会計上の伝票は経理が入れてくれるとしても、
物としての管理（現物照合）や、経理で処理できるだけの
材料は現場のプロジェクトが責任を持ってやらんとあかん
だろう。
●４つ目は、
ＮＷは資産に関わる数値の算出が大変なんや。
償却年数とか耐用年数とか経費処理できるものかどうか
とか、予算を考えるときに、そういう数字を試算して出さんと
投資対効果が見えへん。
単純なキャッシュアウトなら、簡単だけど、制度会計と
税務会計は分けて考える必要がある。
-----
「正直、ざっと、この辺のことをフラグメンツだけ考えても、
めちゃくちゃ大変や。
プロジェクトの遂行より、計画のほうが何倍も大変で
しかも出した数字は大半は「ふーん」て切り捨てられる
ようなもんや。」
「僕の感覚やけど、
このプロジェクトって、ほんとにやりとおせるの
って、いう目で社内から見られてる。」
特に経営層の感覚と、現場のギャップが激しい。
まあ、最初はどんなプロジェクトでもそう。
アサインされている人の信頼感とかそういうもので判断
されてしまう。
でも、違うんだよ。今まで山ほどのプロジェクトが
世の中で失敗してきているから、少々”ぬけさく”君
でもうまくいくようなメソドロジーができてきてる。
それにメソドロジーなんて、あっても”ぬけさく”君には
何にもならないけど、会社として成功させる意思
を持たせる対象として、「プロジェクト」という概念ができた
のはすごく大きいことだよ。
敵がいなくて、金がどんどん出てくるプロジェクトなら、
誰だってできるから、若いうちは失敗しても許されるし、
どんどん難しいプロジェクトにチャレンジしたほうがいい。
何なら会社の１コくらいつぶしてもいい。
潰れた責任は経営者にあるんだから。
いっぱしに若くてもネットワークのこと勉強してきてるわけだし。
まあ、今は、IPv6とか、普通の電話、IP電話、無線、電話会議、
テレビ会議、多地点会議、動画配信/受信なんて感じで、
どんどん、「ネットワーク」って言葉でくくれるサービスは
膨らんでるけど。」
「金のことは後で考えればいい。
今、全部調べるわけでもない。
ちょっと調べれば、総コストが１億か、
１０億か、１００億かの違いは出せる。」
「そっからが考えどころ。
経営者ってのは、コストと納期だけで判断する。
技術者出身の経営者でも、２タイプあって、
・単純にある分野の技術に詳しくて、その分野にだけ口を
挟みたい人と、
・全体最適にまで考えを及ばすことができたり、
こちらの方針を細かく精査して、成功要因に
考えをめぐらせられる人と
いる。
でも、大半は経営者は納期とコストで判断する。
だから、
「今こんな状態や。」
「こういうことをいついつまでに実現するには
それぞれ、こんだけ金がかかる。」
っていうのを、いろんな案を交えて話をするしかない。」
「リーダーのJさん見ても、やらなあかんことが
分類できてない。
単純に考えてええんや。
世の中、
・金
・人
・モノ
・情報
ってふうに分類する。」
金もざっくり切って、概算でまとめて行くほうが無難や。
バッファをつけて、あとの誤差は適当にいじっとけば済む。
散々けしかけられて、やれやれ言われて、ふた開けたら、
金の話で「なんでそんなかかんねん」とかいうて翻弄される
のはあほらしいやろ。
だったら、やり方とできる範囲を突き付けたほうがいい。
まあ、あとは代替策がないかどうかの話でもめる。
今後はいかにシンプルに話をまとめて行くかだな。
・まずはいかにシンプルな案を複数あげて
予算の承認を得るか。
・次はＲＦＰでベンダーに話を振る。
・ＲＦＰはベンダーをひっかきまわして、仕事させるための
道具や。
これだけやってください。 って話じゃない。
こんだけは絶対やってもらう。
その前提で提案してもらう。
・その後はいろいろテクニカルなアイディアや方策
なんかも聞きたいし、そういう面でベンダは使わなきゃ
いけない。
機器の導入・保守もあるわけだし。
プリセールスエンジニアを一人随行させて、
金の事は別にして、アイディアを聞くぐらいの
動きはしていこう。
奴らはしょせん、モノが売れれば、喜ぶ単純
な連中だから、うまいこと利用すればいい。
問題は、ベンダマネジメントを完全にこちらの
コントロールの配下に置く前に、彼らに動かせて
しまうこと。
要件・コスト・品質・納期なんかの管理が
ごちゃごちゃになってくると収拾がつかない。
・そこはシステム開発と違うところだよね。
システムは要件がないと設計→開発と進んで行けない。
それに紐づけて人も委任/請負を考えていくから、
まあ、成果とか品質は別として、一定の歯止めは利く。
でも、機器納入は、
「物を納める」
「機器構成を決めて、それどおりに敷設する」
っていう点が動いてしまうと、もう、後戻りがきかない。
絶対にベンダに主導権を握らせちゃだめだよ。
例えば、品質テストなんかはベンダ提案なんかは
ほとんど却下してもっとレベルの高いものを提案
させる。
所詮奴らも、やっつけ仕事でしか仕事しないから。
いい加減にスループットとか、帯域幅なんか
決めて、資料持ってくる。
だから、
「この回線が必要とする帯域幅、と業務要件との
関係は？とか言って、つっ返せばいいから」
それで、次ちょっとまともな資料作ってきたら、
「そんなの頼んでない。ってまた突っ返せばいい。」
うちは、これだけの材料をベンダ選定と機器選定の判断
基準にするつもりでいる。とかって
いじめぬけばいい。
まあ、そこで、あとは、
「価格はいずれにしてもそんなもんだよね。」
とか言っとく。
価格交渉とか、コストに見合ったプロジェクト規模の
作り方とかは、交渉相手をどこに向けるかで決まる。
絶対的な数値の値段じゃ決まらないから。
そこはこれからだよね。
僕は見てるだけだけど。（笑）
雑談レベルでそんな事を話して、あと、リーダとは、
ここのメンバとの面接で感じたことで、ジョブアサインや
注意点などを共有しあった。
概ね共有できている部分もあったが、対処が出来ていなければ
意味がない。
その後、プロジェクト関連の資料の整備を説明した。
今日から、XさんにNWPJに参画してもらっているのと、
プラスして、神戸で契約している派遣さんを１人連れてきて、
いろいろと説明させた。
１週間程度はNWPJの支援のために働いてもらうのと、僕の
雑用を全部彼女にふって、なんとか、東京滞在中に仕事に
目途をつけたかった。
東京で雇った派遣さんの育成も進めないといけないが、
こちらは、次週以降も神戸からサポートせざるをえない。
一人で不安だろうが、我慢してやってもらわないといけない。
両ＰＪをともだおれにするわけにはいかない。
NWチームのリーダには、
「来週１週間猶予期間とするので、仕事は放っておいて、
プロジェクト推進や、課題・進捗管理体制の整備を
完全に軌道に乗せてほしい。
上司にはプロジェクト運営は年明けから、と伝える。
ただし、僕向けには猶予は来週だけ。これは必達。
ただし、サポートは最優先にするので、いつでも電話してほしい。」
そう伝えた。
特に問題点になりそうなところをレジュメでまとめるので、
「解決策」を考えよう。
まともに考えると
１０年経っても終わらない。
-----
他方、神戸ＰＪは、
ユーザ参加の進捗会議は
「打ち合わせは中止。」と事前連絡済み。
後で、状況把握後、私からメールすると伝えた。
各リーダには、
「リーダ会の資料を作って、明日の午前９時までにメールしてください。」
と伝えた。
「資料の閲覧後、今週水曜日向けの資料もまとめて、
目をとおして、先週の金曜日以後の進捗を総括します。
水曜日リーダ会は、
15:00～21:00（途中２回休みアリ）で予定しておいてください。」
とメールした。