こんにちは、こじろうです。
ITに限りませんが、多くのビジネスはプロジェクト単位にチームメンバーや予算が設定されて、期日までのコンテンツを作り上げる、というスタイルがほとんどです。
といった思いをお持ちの方も多いと思います。
この記事では、ITコンサルを目指す文系SEやITビギナーの方でも理解できるよう、プロジェクトマネジメントが何なのかについて紹介していきたいと思います。
【この記事でわかること】
- プロジェクトマネジメントとは、ざっくり言うと何なのか？
- 具体的に何をするのか？
- プロジェクトマネジメントによって何が変わるのか？
ITの仕事における「交通ルール」
ITの仕事ってプログラムをゴリゴリ書きまくって、スティーブ・ジョブス張りのプレゼンで聴衆をあっと驚かせる！みたいなイメージありますが、それだけではありません。
むしろプロジェクトの開始から終了までの期間においてプログラムを書く作業は、50%あるかないかだと思います。
では残りの50%は何をしているのか？
この記事では、IT業務における”交通ルール”ともいえる「プロジェクトマネジメント」をキーワードとして、「ITの仕事って結局何をやっているのか？」「どんなことに気を付けながら進めているのか」を紹介していきたいと思います。
全部やろうとすると無理なので、最低限やらなければならない、もしくは条件付きでやらなくてよいものを明記していきます。
管理項目は10個あるけど…
大まかにいうと、10個のステップがあります。
- 提案
- 要件定義
- 基本設計
- 詳細設計
- 構築(プログラミング)/単体テスト
- 結合テスト
- システムテスト
- ユーザテスト
- 納品・稼働開始
- 運用開始
5個目の構築/単体テストからは、構築したプログラムがちゃんと設計・要求通り動くかどうかの確認になります。最終的に、「要件定義」した内容がちゃんと実現できているか「ユーザテスト」にて、ユーザ自身に確認頂き、問題なければ「稼働」スタートとなるわけです。
「稼働したら自分の仕事は終わり」と考えるSEの方がいらっしゃいますが、言葉は悪いんですがハッキリ言ってその考えは「三流」です。
システムを作ったところで、ユーザが期待している成果が出なければ作った意味はありません。
なので、「稼働」後の「日々の運用」含めて、「提案」した内容がちゃんと実現できているかフォローしていくのも非常に重要です。
提案
多くのIT案件は、オーダーメイドです。
中には、既製品のソフトウェアを導入する(MicrosoftのOffice(Word、Excel、Power Point)などが当てはまりますね！)という案件もありますが、そういった場合でも導入する際に様々な設定が必要で、それらは各クライアント毎に異なります。
そのため、IT企業は最初に「我々に作業を任せてくれたら、こんなものをご用意できますよ」という「提案」をします。
提案には以下の項目を記載することが多いです。
参考：良い提案書を書く方法（システム開発）@barcarunrun
- 御社の課題は◯◯と××と△△です
- これらを整理すると「こう」なります
- これらの解決策は「こう」です
- それぞれのメリット・デメリットはこうです
- よって「これ」がいいです
①の”御社の課題”については、クライアント側に現状をヒアリングする必要もありますが、「質問に答えているほど暇じゃないから、我々の現状を記したドキュメントを渡すので、あとは自分達で考えて書いてきてください」という会社もザラにあります。
この”現状を示したドキュメント”を、「提案依頼書ーRequest For Proposal」と言います。提案する側はこの文書に沿って提案書を作成、提案するという場合が多いです。
また、上記のbarcarunrunさんの記事の最後に”この辺の作業を効率よくやるためにコンサルが必要”と書いてくれているので、いずれコンサル目線からの提案のやり方を書こうと思います。
要件定義
提案後、見事受注できたらお客さんが本案件で実現したいことを明確にするため、「要件定義」を実施します。
「お客さんがやりたいことって、提案する時点で分かっているんじゃないの？」と思われるかもしれません。
確かにそうなのですが、提案段階でのクライアントの要望は、受け取り方によっては解釈が1つに定まらないことがほとんどです。
この「要件の解釈が定まらない」状態でシステムを作り始めてしまうと、後から「こんなはずじゃない」「いや、我々の認識では要望通り作成しましたが…」といった具合に大揉めします。
参考：https://pm-rasinban.com/rd-write
上記をみると、「わーこんなにたくさん書かなきゃいけないのか…とてもじゃないけど無理。。」と思われる文系SE、ITビギナーの方もいらっしゃると思います。
上記のサイトは、理想的なドキュメントを記載されているので、実際の現場では必ずしも上記で案内されている内容を全て羅列しなくとも問題ありません。
参考までに、極限まで簡素化した要件定義書を提供いたします。下記のリンクからダウンロード頂き、効率の良い要件定義を実現してください！
(参考：要件定義書サンプル) ※作成中
基本設計
要件の定義が終わったら、次は設計です。
IT関連の本を読むと、設計には「外部設計」「内部設計」「DB設計」「方式設計」…と山ほど”～設計”という言葉が出てきますが、捉え方としてはまずは具体的な日常業務の中で、このシステムを利用して、業務をどのように変えたいのかに関して記載する業務設計。
このシステムをどのように利用したいのか？という観点から必要な機能を洗い出す機能設計ー機能が実行された際のスピードや量などを設計する「非機能設計」ー続いてデータの流れとユーザからの見え方を設計(外部設計)ー更に各機能内の処理をどのように設計するか(どのようにプログラミングするか)を設計する内部設計といった具合ですね。
こちらについても、極限まで簡素化した基本設計書サンプルを提供いたします。下記のリンクからダウンロード頂き、効率の良い基本設計を実現してください！
(参考：基本設計書サンプル) ※作成中
詳細設計
基本設計にて「内部設計」の項があったと思いますが、これを更に細かく設計したものを「詳細設計」と言います。
流れとしては、実施される処理を一挙手一投足記載する「アクティビティ図」、プログラムファイル単位でどのような順序で各機能が実行されるのか記載するシーケンス図、書くプログラムファイル内にどのような記載を実施するのか記載するクラス図、処理機能記述書、モジュール構造図、といったところです。
こちらについても、極限まで簡素化した詳細設計書サンプルを提供いたします。下記のリンクからダウンロード頂き、効率の良い詳細設計を実現してください！
(参考：詳細設計書サンプル) ※作成中
構築/単体テスト
詳細設計に沿ってプログラミングを実施していく作業のことを構築と言い、その動作確認を単体テストと言います。
単体テストは記載したプログラムの一行一行が設計通りに動くかどうか確認していいきます。
こちらについても、極限まで簡素化した単体テスト仕様書サンプルを提供いたします。下記のリンクからダウンロード頂き、効率の良い単体テストを実現してください！
(参考：単体テスト仕様書サンプル) ※作成中
結合テスト
基本設計の内容が実現できているか確認します。
こちらについても、極限まで簡素化した結合テスト仕様書サンプルを提供いたします。下記のリンクからダウンロード頂き、効率の良い結合テストを実現してください！
(参考：結合テスト仕様書サンプル) ※作成中
システムテスト
要件定義の内容が実現できているか確認します。
こちらについても、極限まで簡素化したシステムテスト仕様書サンプルを提供いたします。下記のリンクからダウンロード頂き、効率の良いシステムテストを実現してください！
(参考：システムテスト仕様書サンプル) ※作成中
ユーザ・テスト
提案した内容通りのシステムとなっているか確認します。
納品・稼働開始
1day対応、2day対応、銀行とかは大変です。
運用開始
出来上がったらそれで終わり！ではありません。システムは不具合を起こしますし、それに対してどういった頻度やスピードで、誰が対応するかあらかじめ決めておかなければなりません。
うまく「プロジェクトマネジメント」できるようになった僕の現在
どんなプロジェクトに放り込まれても、自分でやるべきことを見つけられる
自走できるようになりました。どんなに炎上しているプロジェクトでも、自分のやるべきこと、目標が定まると、精神的にはそこまできつくないものです。逆に、あれやれ、これやれと指示を待つばかりになると、人間耐えられません。
それでは、Tchau◎
こじろう
※冒頭のイラストははむぱんさんによる写真ACからの写真でした。
