システム担当者

大手の会社でシステム構築する場合、大抵は現場担当者とシステム担当者が相手となって機能を業務を詰めたりします。
ちゃんとしてるところは打ち合わせごとにシステム担当者がでたりするが、システム部に人が足りてないようなところは最後の承認時とかにでてくる場合もあります。
たぶん打ち合わせ時の役割として
<業務担当者>新業務にあわせて必要な画面や帳票を洗い出す。また操作性やレイアウトに対してあれやこれや言う
<システム担当者>新業務に対して機能がマッチしているか検証する。他システムへの影響についてあれやこれや。実現方式や保守時の想定。
みたいな感じで企業側は期待しているのかな(?)と思います。
業務担当者についてはほっといてもいろいろ出てくる。いや、止めないと溢れ出す。システム担当者については、ピンキリなんですよね。すごい人はすごいし、ダメな奴は駄目。
で、今回のシステム担当者はどうも業務担当者によりすぎるかなと。悪い人ではないのですが、保守や改修時の費用についてもうちょっと考慮してくれてもいい気がする。
たとえば業務担当者が「無いよりはあった方がいい」って発言すれば、がんばって要求を通そうとする。その姿勢はよいと思うのですが、あきらかに費用対効果に見合っていないものも見受けられます。
業務担当者が必要なものに費用をかけるのはあたりまえだ。と思う方もいるかもしれませんが私の考えはちょっと違います。
開発費用が予算内であればかまわないかもしれませんが、この「あった方がいい」レベルの機能を追加すると、今後この機能のまわりに改修があった場合、費用や期間がかかってしまいます。
それでも改修時の費用が捻出できればいいかと言えばそうではないはずです。なぜなら、期間がかかってしまうからです。期間が延びるということはサービスの提供時期が延びてしまい、その間の利益を逃してしまうことになります。
これは企業にとっていいことではありません。
業務担当者からみるとちょっと便利になったと思うことでも実は保守費用を膨らませる結果になり、利益まで逃してしまうこともあるのです。
で、私が考えるにシステム担当者は業務担当者の要件より企業の利益を守るべきだよなーと思ったりしています。
でも上記の考えは誇大妄想っぽいので現場では「それって金かかる割には意味ないですよ」ぐらいでシステム担当者を説得してます。これって弱い?

ツール(PMBOK)より会話

IT Pro:「PMBOKは必要十分条件ではない」※ログインが必要かも
つまりプロジェクトマネジャの仕事の8割はコミュニケーションということになる。
この記事でも書かれているようにコミュニケーションありきですね。やはり盲目的にPMBOKを押したところでそれだけでは成功しないということなのでしょう。
そもそもプロマネとは顧客と会議が終わったら現場を離れ、チームとの会話は進捗報告だけ。顧客しか見ない捏造されたスケジュールを書くことが仕事では絶対にないはず。
でもほとんどのプロジェクトってPM(もしくはリーダー)って、愚痴りながら何時間もスケジュール表を書いて顧客との進捗会議に出席して終わっちゃうんだよな。(これは自分にも当てはまる)
うむ、どこかにお手本になるプロマネいないかな?

やつら=俺?

失敗しない情報システム調達
こんな顧客希望なのだが、難しいだろうな。でもこれって、目的と予算と決定権と仕様が分かる担当者が必要なのでは?
しかし調達するときこんな感じで見られているんだろうな、きっと。
この記事書いたの天野さんなのかな?ぁまんによニッキ:失敗しない情報システム調達でなぜ「やつら」としたか