システム・インテグレーションという仕事

過去システム開発をしていて、そして今は発注したり内製したりをリードする立場からシステムの開発に携わっていてあらためて意識しているのは、システムはアプリとインフラを用意したからといって動くわけではなく、インテグレーションが必要、ということです。

仮にウォーターフォール方式で開発した場合、要件定義書をアプリチームとインフラチームに渡して別々に作業をさせた場合、絶対にシステムはできあがりません。

そもそも要件定義書が間違っていたり、アプリ・ミドル・OSのどの機能を使う・連携させて実現するかなど設計になってからわからないことがでてきたり、ユーザーの立場に改めて立つとこんな機能はいらないんじゃないか(付け加えたほうがよいのではないか)、このままだと性能が出ないんじゃないかな・・・とか、いろんなことがあります。それらをまとめ上げてきちんとシステムとして動かすのがインテグレーションの仕事です。

インテグレーションの仕事には、それぞれの分野で固有のフレームワークの知識や、最新のCPUの使い方などの尖ったスキルはなくとも、コンピューターの基本動作や、ユーザーの関心事、業務プロセス、運用などを幅広く知っておくことが大事になります。そして、

  • ユーザーは何をシステムに求めているか
  • 共通化できる部分は何か、個別にする部分はどれか
  • 機能をどう分コンポーネントに分割するか/分割した評価の機能はどうするか
  • AをしたらBができないといったトレードオフはあるか
  • メンテナンス性は確保できているか
  • などなど

といった問いを自分やチームに投げかけてシステムをちゃんと動くように進めていきます。

インテグレーションの仕事は、PMやプロジェクトリーダーがマネジメント業務の傍らに行ったり、PMOなどに専門家がいる場合もあれば、各担当分野のプロジェクトメンバーが合議して行っていることもあります。ただ、どんなチーム構成でも、メンバーひとりひとりにインテグレーションの意識がないとうまくいかないのでは、と思います。ある担当の詳細部分が他の担当に影響する、といったことは、実際それを触っている人でないとわからないものです。

f:id:siiseku:20180108212703p:plain

私は幸運にも「インフラを束ねるインテグレーション」「インフラとアプリを束ねるインテグレーション」といったインテグレーションを意識する仕事を経験できたので、すぐに個別機能に落とし込んで単純作業化にしてしまいがちな人に対しては、プロジェクトのゴールをよく理解をしてもらうようになるべく心がけるようにしています。

 

あっ、これは自分が思いついた考えではなくて、プロジェクトマネジメント実務に関する名著の「実務で役立つWBS入門」という本に、WBSで成果物をブレイクダウンする場合には必ず構成要素だけでなく結合プロセスを定義すること、といったことが書いてあるのを愚直に従っていただけです。
(例えば、本を書く場合、内容の執筆だけで製本する作業があるように) 

実務で役立つWBS入門 (プロジェクトマネジメントマガジン)

実務で役立つWBS入門 (プロジェクトマネジメントマガジン)