最近は情シスが取引先でない場合が多くなり【たまプラビジネス余談放談】20220422
以前は、ITの仕事を受けると、発注先には情報システム部門がいたものだ。多くの場合、情報システムそのものや手順にも精通していて、時には、本来なら自分でもできるが、コスト削減のため、あるいは、別の作業や思考、企画をするために外部に依頼をする場合がある。
だから、情報システム開発者同士の暗黙の了解が前提にあった。
・この仕事をするにはどんな作業が必要か、
・どれくらいの手間が必要か、
・問題の生じるのはどういう場合か、
・それを防止するには何をすべきか、、、
などだ。
依頼する費用もそれらを前提に、見積もられて、それを吟味することもできた。同じ前提の上で。
こうした取引構造は、情報システムが多くの場合、その企業にマッチするように製作されていて、システムが動作する機器が情報システム部門によって管理されていて、保守されている場合には必須だった。しかし、コンピュータの歴史は、エンドユーザーコンピューティングが多少なりとも進み、システムはクラウド上で管理され、情報システム部門や専門家がいなくてもなんとか運用できるようになってきた。一般の部門のIT専門家でない担当者からの情報システムの発注も多くなってきたのだ。
その結果、暗黙の了解だった事項が共有されていないこともでてきた。
例えば、あるシステムの「改造」などを行う際の基本的な作業手順でも、情報システムに関わった人でないと疑問に思うようだ。例えば「改造」作業で、ごく通常の作業手順として、大まかにいうと、１ 影響調査 ２ 改造作業（テストサイト） ３ 本番環境への反映とテスト という基本手順を経る。だからそれぞれの作業、位置付けを説明する必要がでてくる。例えば次のように。
１ 影響調査
行う作業や改造によって、その影響がどこにでるか、その場合の関連作業が必要かどうか、などを見極めるための調査を行う。これを行わないと、該当作業を実施した結果、思わぬ影響がでてきて、その影響を吸収したりする追加の作業となり、見積もりしていない作業が発生することになってしまう。
２ 作業実施
いきなり、消費者やシステム利用者に公開している部分に手を加えると思わぬ悪影響が出てしまうこともあるので、まず非公開サイトの部分に手を加え、動作を確認する作業である。
３ 本番環境への反映とテスト
動作内容に問題がないことを確認できたら、消費者のアクセスに影響がでない時間帯で本番環境への反映を行う。公開されているシステムの場合、夜間に行う場合もある。
１をはぶいたり、２を３と同時に行うことも考えられるが、その場合の影響に対する対応でさらにコストが発生することもありえる。（うまくいけば発生しないこともあるが、、、）
依頼者からすれば、やってほしいのは２だけなので、なぜ１、３をやらなければならないのか、１はすでにわかっていないのか、２と３は問題が出ないように同時に進められないのか、などと思う場合もある。こうした作業の根拠説明は改めて丁寧に行う必要がある。
もっとも、”わかっている”はずの情報システム関係者の場合でも、わかっている上で値引き材料として交渉される場合もあるので、永遠のテーマといったところかもしれない。
