見出し画像

読書レビュー「情シス企画・開発・運用107のルール」


本書を読む目的・きっかけ

 一般的にIT関連の本はプログラミング、データベース、サーバーなどなど特定の技術にスポットを当てた本や、プロジェクトマネジメントやプログラムを書くエンジニアに当てた本が多い。

 そんな中、情報システム部門向けの本はほとんどないのが現状になるが、本書はそんな事業会社の情シス部門で働く人向けに書かれた本となる。
 私は事業会社の情報システムで働いているわけではないが、100%内販となるユーザー系Slerで働いており、そういう意味では広義な意味で情報システム部門と言えるため、本書を読んでみようと感じた。

読書感想

 まず、最初に明記しておいた方がいいのは、この本は情シス部門向けの本だが、参考になるか否かは人によるだろう。
というのも、事業会社の情報システム部門の仕事は会社によってまちまちであり、プロジェクトの旗振りや企画をやるような仕事がメインの会社もあれば、ネットワーク管理や業務部門からの照会対応、PCのキッティングなど要はITに関することならなんでもやります的な「何でも屋」の仕事がメインという会社もある。ざっくり分けると前者は大企業が多く、後者は中小企業が多い。

 本書で書かれている内容はどちらかというと、プロジェクト起案〜リリースとプロジェクトを進める上で情報システム部門のSEがどのように考え、行動していくかというマインドに関する部分とプロジェクトの各工程で情シス部門として、何をしていかなくてはいけないかということが書かれている。
 主にプロジェクト起案・プロジェクト立ち上げ・要件定義・基本設計&開発・システムテスト・移行・リリースと運用で章立てされており、それぞれの段階でどのようなことをしていかなくてはいけないかということが記載されている。

 個人的には要件定義〜リリースについてはすべて経験があったので、どちらかというと初見の内容は少なく、復習するような感じであったが、プロジェクト起案やプロジェクト立ち上げは経験がない(正確には事業会社のシステム統括部や情報システム推進部がやることになるので関わることがない。。)ので、初見の内容ばかりで勉強になった。
 また、各工程で必要となる成果物にどんなものがあるか、事業部門と開発ベンダーとの役割分担についてはどのように考える必要があるか、さらに事業会社と揉めた時はどのように対処すべきかといいった事も書かれており、実際にプロジェクト案件で起こりそうな内容について、大まかに書かれているため、参考になるケースは多いのではないかと感じた。
 特に、システム開発で揶揄される「丸投げ状態」については「こういう奴は丸投げSEだ」と言わんばかりに「丸投げ」状態とはどんな状態かという、他の本ではあまり書かれていないような内容も記載されているため、「ああ、いるよね、こういう人。。」と自分のことを棚に上げて納得するように読んでしまった。(いや、ほんと自分も気をつけないとね、、)

実践すること

 私の会社は大型プロジェクトが常に走っているので、私のキャリアのうちの半分は中規模、大規模プロジェクトに関わっている。そのため、本書の内容に近いことを経験しているせいか、割とすんなり理解することができた。
 その一方で、忙しさにかまけて「丸投げSE」に該当する部分も一部あるような気がしており、その辺りは気をつけないとな、、と強く感じたので今後、プロジェクトに参画する場合は「プロジェクトの目的と意義を理解して、自分に求められている役割を常に意識した行動」をとるようにしたい。
 また、要件定義やシステムテストは大きな山場になるが、その際に取るべき行動(特に事業会社や開発ベンダーとの役割分担やコミニケーションの取り方)や、各成果物についての理解や作成内容などわかっているようで理解していないこともあったので、その辺りの勉強を再度やり直すようにしたい。

まとめ

 まとめとしては本のサブタイトルに社内SE1年目向けと書かれていたが、1年目というよりは3年目以降の社内SEが読むべき本であり、15年目の自分が読んでも勉強できる内容だと感じた。(私のレベルが低いだけもしれないが)
 ただ、一点注意点を書くとすると、先にも記載した通り、事業会社の情報システム部門は会社によってやる仕事が全然違うので、内容をパラパラ見てから購入した方がいいのと、情報システム部門は企画寄りの仕事が多いこともあり、基本設計以降はあまり関わらないことが多い気がしているため、本書はどちらかというと、私のような100%内販となるユーザー系Slerの社員が一番タメになるのではないかと思う。
 そういう意味では100%内販のユーザー系Slerで働いている人に最もおススメできる本だと言える。

この記事が気に入ったらサポートをしてみませんか?