Skip to content(本文へジャンプ)

MENU

プロジェクトの流れ

  1. HOME
  2. 採用情報
  3. プロジェクトストーリー
  4. プロジェクトの流れ

プロジェクトの流れを「新人SE」としてヴァーチャル体験

NSSOL関西におけるシステム開発プロジェクトの流れを、代表的なスクラッチ開発案件を題材に紹介します。

場面は、一次リリースを終え、追加開発フェーズから新人SEが参入し、先輩PL(プロジェクト・リーダー)が、そこまでの経緯を説明するところから始まります。

 

プロローグ

  • あなたが参入する、このプロジェクトの経緯から説明しますね。まず、クライアントは、関西地場の電機メーカーA社。案件内容は、既存の生産管理のサブシステムを、スクラッチで開発するというものです。

プロローグ

  • スクラッチ開発ということは、何かしらのパッケージを導入・開発するのではなく、ゼロからオーダーメイドでオリジナルのものを作るってことですよね。

プロローグ

  • その通りです。生産管理のシステム群は、ものづくりの企業における「秘伝のタレ」のようなもので、差別化・競争優位を実現するためには、既存パッケージではどうしても力不足。だからこそ今回、約100人月規模を投じ、このサブシステムによって、関西発でグローバルに戦っていくためのさらなる増強を図っていくというわけです。

プロローグ

  • つづいて、システム開発プロジェクトの流れの全体像から現在の状況を把握してもらいます。一般的なシステムライフサイクルは新人研修で学びましたよね。

プロローグ

  • はい、基本計画フェーズ→基本設計フェーズ→詳細設計フェーズ→製作フェーズ→テストフェーズ→本番移行フェーズ→保守・運用フェーズという流れでしたよね。

プロローグ

  • そうです。そして、現在は、一次開発の本番移行を完了させて、保守・運用フェーズに入っている段階で、同時に、追加で二次開発に進んでいるという状況です。つまり、私たちのチームは、一次開発でしっかり技術的にも業務的にも知見を蓄えている状態。ですから、参画にあたってわからないことがあれば、安心して何でも聞いてくださいね。

基本計画

  • ここからは、各フェーズで、どのような立場のプレイヤーが、それぞれどんな役割で動いてきたかをおさらいしていきますね。まずは、基本計画フェーズ。ここでの登場人物は、システムの発注側である、電機メーカーA社の情報システム部門のお二人、そして、プロジェクト側は、営業担当とPM(プロジェクト・マネージャー)、私を含むPL(プロジェクト・リーダー)3名という体制です。

基本計画

  • 今回のプロジェクトの体制はわかりました。営業担当は、まさにお客様への提案から契約までの窓口を担い、PMはプロジェクトの責任者としてプロジェクトやシステムの構想をまとめあげたり、プレゼンしたりしてすり合わせていく。ここまではわかるのですが、PL3名はどのような役割を担っているのでしょうか。

基本計画

  • 良い質問ですね。そもそも基本計画フェーズの目的は、「プロジェクトの成果・作業を確定させ、業務要件定義・システム全体のアーキテクチャ(システム構造)の概略を設計し、それらに基づくプロジェクト計画を策定すること」。プロジェクトの種類や規模によってPLの人数も役割分担も異なるのですが、今回のケースでは、プロジェクトを実際に遂行していく計画部分を主に担うPL1、システム全体のアーキテクチャを主に担うPL2、そして、業務要件定義を主に担う私という分担になっています。

基本設計

  • 基本設計フェーズでは、基本計画で定義した要件に基づいて、システムに実現する機能を明確化・具体化します。具体的には、画面のレイアウトや動作、アーキテクチャの構成やハードウェア調達に必要な仕様等を確定します。今回のプロジェクトでは、このフェーズから新たな登場人物として、ここからSEが2人、パートナー(外部協力会社)のSEが1名が参画しました。

基本設計

  • システムの具体的な部分に入ってくるので、各パートの詳細設計や製作を見据えた体制に増員していくのですね。

基本設計

  • PMとともに、それぞれの専門性を発揮しながら、仕様を固めていくフェーズ。検討の抜け漏れがないように、ホワイトボードを使って議論したり、ドキュメントを次々とアウトプットしたりして、まだ「世の中のどこにもないシステム」という見えないものを「見える化」したうえで、定期的にお客様とすり合わせていくことが大事ですね。

詳細設計

  • 詳細仕様フェーズでは、基本設計で定義された仕様をもとに、プログラム製作へのインプットとして、プログラムの挙動や出力結果等、詳細な仕様へと落とし込んでいきます。ここでは基本設計のメンバーに加えて、パートナーのSEを2名アサインして、設計書を書き起こしていきます。

詳細設計

  • この段階になると、PLが中心になってプロジェクト運営を担っていくのですね。ですから、SEも、自ら設計書を書きながらも、パートナーSEへの業務依頼やとりまとめも重要になってきますね。

詳細設計

  • そうですね。PMには、定期的な進捗会議で報告を上げたり、お客様との打ち合わせに同行してもらったりはしますが、論点が詳細レベルになってくることもありますので、私たちPLとSEが「ものづくりのプロフェッショナル」として、リードしていく立場になるのです。

製作

  • そして、製作フェーズ。詳細設計書に基づいて、ソフトウェアのプログラミング、インフラ・ハードウェアの環境構築を進めて、システムを具現化していきます。

製作

  • これまで想定していたシステム開発のイメージ通りの仕事ですね。集中作業も増えてくるので、パートナーを含めた私たちSEの仕事が捗りそうです。

製作

  • この製作フェーズに至るまでの工程が、はじめはなかなかイメージできないでしょうね。なお、私たちPLは主に管理や仕様・設計の調整をします。とはいえ、担当が書いたコードのレビュー等もしますので、プログラムの知識も必要になります。

テスト

  • 製作の後工程はテスト。作りっぱなしではなく、作ったものが正しく動くかどうか、その品質がシステムの生命線です。はじめに言った、「差別化・競争優位」の源泉にしていくためにも入念なテストが重要です。

テスト

  • それぞれ実装した、モジュール単位での単体テストから始まって、ソフトウェアやシステム全体の結合テスト、業務と合わせてのシステム総合テストまで、ステップを踏んで品質を確認していくのですよね。

テスト

  • その通りです。ものづくりに没頭していると、どうしても作ること自体が目的になりがちですが、システムは課題解決のために作るので、作ったものが目的通り使えて、効果を発揮してはじめて成功と言えるわけです。ですからテストフェーズでは、PLも総動員で業務面・技術面、あらゆる角度で検証・対応を重ねていきます。

移行・追加開発スタート

  • こうして、お客様の受け入れ確認・検収が済み、一次リリースを無事終え、お客様の本番環境へ移行して、現在に至るわけです。一次リリースしたシステムを保守・運用しながら、追加でシステムを開発するにあたり、基本計画から始まるプロジェクトにあなたがアサインされたわけです。

移行・追加開発スタート

  • このような経緯を知ると、より一層、気を引き締めてかからなくちゃと思います。ただ、先程仰っていたように、一次開発の先輩たちが残っているのは心強いです。

移行・追加開発スタート

  • さらに言えば、実は一次開発の段階から、日鉄ソリューションズ(以下、NSSOL)のシステム研究開発センターから技術的な支援をもらったり、NSSOL関西の生産技術部隊(PMOやアーキテクト)が支援してくれたりと、私たちには、NSSOLグループの知見を活用できる土壌があるのです。

移行・追加開発スタート

  • NSSOLとともにグループの力を結集して、地場関西の新しいプロジェクトを開拓し、その後はNSSOL関西が地の利を活かしつつ、主体的に地盤固めを担っていくというイメージですね。

移行・追加開発スタート

  • また、今回追加開発にあたっては、ウォーターフォール型開発ではなく、アジャイル型で進めることになっており、プロトタイプを開発していきながら、ともにPoC(Proof of Concept: 概念検証)を担うというプロセスで進めていきます。そういう意味でも、あなたのような新鮮な感性による意見が重要になってくる場面も多くなりますので、期待しています!

移行・追加開発スタート

  • ありがとうございます!がんばります。さっそく、本日のお客様との打ち合わせに向けて、要件定義ドキュメントのまとめ作業に励みます!