中小企業に最適なITソリューションって何？

さて、運用設計をなんとかかんとか終わらせて、 ほっと一息ついていると、今度はBIチームから相談を持ち掛けられました。 ただ正直、これまでBIチームと絡んだことは一度もなかったので 「何故、私？」と思ったのが第一印象でした。 だからといって、ここで「それは私じゃないと思うので、別の人当たって下さい。」 とお役所のような対応をするのも野暮なので、とりあえず話は聞いてみました。 質問の内容は、 「BIのデータ元であるシステムの事を聞きたいのだが そもそも誰に聞けばいいのかわからない。 とりあえず知ってそうな人を捕まえてみたいのですが、貴方でよいですか？」 という事でした。 とりあえずこの場合、聞く相手は私で外れではなかったです。と同時に、 何故この会社の人たちはみんな（私も含めて）問い合わせ先に悩んでいるんだろう という何か根源的な疑問も持ちました・・・。 が、一旦それは脇に置いておいて、私の方で応対をしたところ、データソースの問題ではなく、BI側で完結する問題だったので、一旦、この話は解決することが出来ました。 しかし、その話をしている中で新たな問題も確認されました。 データ元のシステムとBIの間には、その２システム間にデータを流し込むプログラムがあるのですが、その部分の担当者が不明確になっているという問題でした。 （ 何かと不明確なことも多い会社です・・・ ） これも、直近私が困るという話ではないのですが どうも誰に聞いてもこのあたりがグレーになっていて しかも、誰もそこに触れようとしない という状況でしたので、ゆくゆくはかならず顕在化する問題だな と判断して、私の方で少し調べることにしました。 まず、おそらく現時点での担当者はこの人ではなかろうか？という人を捕まえて、状況確認をしたところ、 どうも 元々は協力会社さんがその部分の機能のアレコレを担ってくれており、 プロパー社員はあまり関与できていなかった。 という事がわかりました。 しかも現担当は入社2年目の新人で、その協力会社さんはチームから離れてしまっているという状況です。 なので、その現担当も「何をどうしたらいいのか困っています・・・。」と有様で困り果てていたので、私も乗り掛かった舟です。 「へー、そうなんだ。大変なことになったね。じゃあ、あとはよろしく」 とも言えないので、 じゃあ、 何とかできるようになるた

過去の記事に書きましたが 【あわせて読みたい】 システムの運用保守の難しさ：初めに システムは導入だけではなく、運用保守も非常に大事な仕事です。 システム導入後、運用保守として 最初に直面する問題は、導入直後に起こります。 その代表的な問題は ・導入メンバー離脱によるノウハウの喪失 ・保守を意識していないシステム構築による運用手法の再構築 等が挙げられるのですが、 システム導入しかやっていない人にとっては、運用保守の難しさがわかると思いますし、導入チームが本来意識しないといけないこと、自分たちで予測出来ないのであれば運用チームを巻き込まないといけないことが意識できると思います。 また、運用保守しかやっていない人にとっては、何故自分たちのタスクがこんなに難解になっているのか？の気づきになると思います。 まず、一つ目の ・導入メンバー離脱によるノウハウの喪失 これは凄くわかりやすいですね。 大体どこの会社もシステム導入にはある程度お金をかけますが 導入したら、突然予算をギューーーーっとしぼり始めます。 その為、導入に携わったメンバーは大幅に削り取られ、 稼働後に動いている機能のそもそもの目的であったり、機能の詳細が不明確になってしまったりすることが起こります。 勿論、導入と同じだけのコストをかけ続けると いつまでたっても効果を享受できなくなるので、ある程度抑えていくのは必要なのですが、それにしてもよく考えて、リソースを調整していかないと、 きちんと引継ぎが出来ず、導入の時に考えていた仕様や目的が伝わらないまま 追加改修されてしまい、当初の目的を果たせなくなってしまったりしまいます。 システムに本来の目的に見合った成果を出してもらいたければ、 ・導入が終わったからメンバーを削る という単純な発想で調整をかけることは相当危険です。 そもそも導入が終わるとメンバーを引きはがすというのは 会社の中で導入ができる人と保守ができる人 と区別しているからだと思うのですが、 この発想がそもそも間違っています。 この後にも述べますが、 運用保守を意識しないで導入を行うと、ランニングコストがかかってしょうがないシステムが出来上がってしまいます。 コンサルタントやSIerであれば、導入の事だけ考えればいいですが 社内SEであれば、どちらも考えれる人を育てないとダメです。 なので、人をアサイン

さて、 チーム内のコミュニケーション不全 と チームの外とのコミュニケーション不全 について、対策を打ちながら、なんとか情報共有が円滑に進むように 整理整頓をしてきましたが、ここまではチームとしての課題でした。 次に立ちふさがったのは私個人のタスクでした。 （実際は順番に問題が起きているわけではなく、コミュニケーションの問題と同時に発生していたのですが。） その問題というのは、4月にカットオーバーを迎えるにあたり、 システムの運用設計を行う というタスクを与えられたという事です。 ここでいう運用設計は具体的には サービスの提供体制であったり サーバーの稼働時間であったり といったものです。 問題は入社したばかりで1か月も経っていないにもかかわらず、 これを任されたという事です。 普通、 ・自社ではどのレベルのSLA（サービスレベル）を定めているのか？ ・他のシステムはどういう基準でサーバーを動かしているのか？ ・体制としてどういった人員体制を組まなくてはいけないのか？ ・カットオーバーするにあたり、どういったドキュメント類をどこまで用意しなくてはいけないのか？ などといった事を事前に知識として持っている人がやるような仕事なのですが 何故か、前提知識のない中で私がアサインされ、これらを決めていかなくてはいけなくなりました。 勿論、今までにもこういったことをやってきた経験はあるので やろうとしていること自体は特に違和感もないのですが 何しろ、転職した直後ですので、この会社における常識というものがありません。 基本的にこういったものはべき論というよりも、既存システムと足並みをそろえないとおかしなことになるので、周辺システムがどうやっているか？ を把握している人間が設計しないと、 このシステムだけ、とびきり厳しい稼働条件になっていたり、 ゆるゆるのサービスレベルになっている というようなことが起こりかねません。 どちらかというと、このプロジェクトに古くから参画している人間が総仕上げとしてやるようなタスクなのですが・・・・ これをひょっと入ってきた人間に任せるという時点で このプロジェクトの異様さというのを感じ始めたのはこのあたりかもしれません。 私がプロジェクトリーダーなら決してこのようなアサインはしませんが、 この運用設計に着手し始めて、その理由というか、何故私がすること