PR

 IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。(毎週月曜日更新、編集:日経情報ストラテジー

ITベンダー社内で“システム屋”同士の会話
ダメな“システム屋”の会話 若手“システム屋” 「先輩、例の情報システムのドキュメントについてなのですが、ここにあるのが最新ですよね?」
先輩“システム屋” 「ああ、それが最新だけど、たぶん3年間ぐらい修正されていないな」
若手 「えっ!3年って私が入社する前ですよ。それでは、最新の意味がないのでは?」
先輩 「ドキュメントをざっと読んで概要をつかんだら、次にソースコードを読む。これが“システム屋”の基本動作だよ」
若手 「そうですか・・・基本設計書はありますよね。あの方がソースコードより分かりやすいかな」
先輩 「そうかもな。ただし自慢ではないが、基本設計書もメンテナンスされていない。3年前のままだ」
若手 「あれ、基本設計書はお客様も使っているものですよね?」
先輩 「最初だけ、な」
若手 「最初だけ、というと?」
先輩 「情報システム構築プロジェクトが立ち上がる当初、開発承認は基本設計書でやるもんだろう?」
若手 「はい。基本設計書の内容をお客様が確認し、承認したうえで次のステップに進みます」
先輩 「そう!そのためのものなんだよ、基本設計書は」
若手 「しかし、システム稼働後に修正等をする時の確認には使っていないのですか?」
先輩 「それはタテマエだよ。うーん、お前もまだまだだなあ。そろそろ大人の“システム屋”の作法を教えてやらないといかんな」
若手 「はい」
先輩 「いいか。『お客様は常に、我々にタダ働きさせようと画策している』ことを肝に銘じよ」
若手 「えっ?」
先輩 「お客様はいったん決めたことを頻繁かつ気軽に、追加料金なしで変更したがる。だから、我々は対策を講じないといけない」
若手 「はい」
先輩 「だから、当初の構築時は要件定義書やら基本設計書やらで逐一確認を取り、決めた後での変更に対しては追加料金を取れるように担保しておくんだ」
若手 「はい、そこまではよく理解できます。我々も企業としてきちんと利益を出さなければならないですから」
先輩 「しかしこれは当初構築時の話だ。稼働後については、追加や変更に対する追加料金を決めることが重要なんだ。それがドキュメントを修正しないことに関係している。これ、分かるな?」
若手 「いえ、まだよく分かりません」
先輩 「稼働後の追加・変更時の追加料金を見積もるための資料は、その時々で作成するが、これは基本設計書などとは別物だ。見積もり資料を作ることが重要なんだよ。基本設計書などのドキュメント修正は、それ自体にはお金が出ない。だから我々がやる必要はない」
若手 「しかし、ドキュメントが最新状態になっている方が、我々自身の生産性が上がりますよね?」
先輩 「いいか、よーく考えてみろ。ドキュメントが最新状態でないからこそ、中身を知っている人間が必要になる
若手 「え?」
先輩 「ドキュメントが最新状態で、誰が読んでも完璧に理解できるようになっていたら、俺やお前という人間は不要だろう。当社との取引関係が“リプレース”されないためには、ドキュメントは役に立たない方がいいんだ。下手すると、俺やお前が“リプレース”されるかもしれないんだよ」
若手 「それは・・・なんか悲しいです」
先輩 「そんなもんなんだよ、大人の世界というのは!」

前回に戻る

ダメな理由:自分の“リスク管理”に必死

 情報システムの構成要素として、ハードウエアやソフトウエア・プログラムのほかに、要件定義書や基本設計書といったドキュメントが重要です。重要なはずなのですが、どういうわけか日本中の情報システムのドキュメントはなかなか更新されず、2~3年前のものが「最新版」ということも少なくありません。

 冒頭の先輩“システム屋”のような確信犯は少数派かもしれません。ただ、私は古いドキュメントを目にするたびに、何か裏の理由があるのではないかと勘ぐってしまいます。

 情報システムの設計手法や開発手法は次々と新しいものが生み出され、それに伴って“システム屋”が書くドキュメントのあり方もずいぶん変わりました。しかしながら、稼働後になかなか更新されないという点と、ユーザー企業(=お客様)からの評判がいまひとつという点では、昔とあまり変わっていないように思えます。

 私が知る限り、ITベンダーやそこに所属する“システム屋”たちはこの30年間、自らのリスクを小さくすることを最優先として、取引契約やドキュメントのあり方を考えてきました。そのとき、ユーザーの立場に立って考えたことがあったか。“リスク管理”を徹底し、自分を守ることばかり考えた結果、ユーザーの信頼を失ってはいないか、というのが今回の問題提起です。