スキル一覧にてシステム系、ビジネス系、ヒューマンスキル系の3つに分けられると書きました。
ここではシステム系について書いてみます。
仕事内容を記載しており、それらを遂行するスキルを身につけましょう、という感じです。
バリバリ開発や設計が出来ればそれに越したことはないです。
が、逆にそこまでできるなら企画になるのはもったいないですし、企画になりたい、と思わないでしょう。
IT業界で初めから企画をやりたいという人は少なく、開発の道を究めるのを断念し、企画の道へという人が多い気もしますし、そこまで求めるのは酷な気がします。
先に書いてしまうと、システム系としてのスキルとしては下記になるかと思います。
なぜ、上記5つなのかについて、システム開発の工程をベースラインとして記載してみます。
開発工程の名称は
Wikipediaに記載しているVモデルを採用しつつ、別名称も併記してみます。
★で重要度を記載しています。上限は★５つです。
要求分析（ビジネス要件定義）：★★★★
ITを使って何を実現するか、どんなビジネスをするか？
スタートラインですね。
本来、企画はここが大事なのですが、
・現実的には企画者に裁量がないこともある
・具体的には後フェーズで決めることもある
ため★を1つへらしています。
- ビジネスモデル設計
- 業務フロー設計
- 業務ルール設計
基本設計（システム要件定義）：★★★★★
システムに何を実現させるか？
システム構築に時間がかかる、リスクが高い、といった場合、要求分析で決めたことを変えることを検討しないといけません。
このフェーズでは大きなリスクを抱えていないかを見極めることが重要です。
システムとビジネスのバランスを考えることが大切で、両者を考えられる人は少ないたて、とても大切なスキルといえます。
このフェーズの成果物は次のフェーズに向けて開発者へ要件を伝えるドキュメントとなります。
このドキュメントは抜け漏れがないようにというよりも抜け漏れがあった時に気づけるように書かないといけません。
機能設計（外部設計・論理設計）：★★★
システムにどう実現させるか？
どんな機能を実装させるか？
このフェーズでシステム設計者・開発者へ主導権を移します。
成果物をすべて作れる必要はないです。
が、企画者が作成したほうが早いのであれば作成したほうがよいです。
か、要件が伝わりづらい部分だけは作成する手もあります。
最低でも成果物をレビューできるスキルは必要です。
ここでのレビューは要件が正しく伝わっているか？漏れていないか？を確認します。
- 画面仕様書作成・レビュー
- データ項目作成・レビュー
詳細設計（内部設計・物理設計）：
システム構築のための設計です。
企画者はこのフェーズはエンジニアにお任せでいいと思います。
コーディング（プログラム開発）：
プログラム開発です。
企画者はこのフェーズもエンジニアにお任せでいいと思います。
単体テスト：
プログラム開発したものが正しく動くかを確認します。
企画者はこのフェーズもエンジニアにお任せでいいと思います。
結合テスト：★
プログラム間、モジュール間、サービス間で連携して正しく動くかを確認します。
基本、エンジニアにお任せでよいですが、テスト漏れがないかは確認しましょう。
システムテスト（機能テスト）：★★★
欲しい機能が正しく動くかを確認します。
主に下記がタスクになりますが、テスト担当と分担してもよいと思います。
- 要求分析（ビジネス要件定義）で作成したドキュメントの見直し
- テスト項目の作成
受け入れテスト（業務テスト）： ★★★★
システムを使って業務が遂行できるかを確認します。
実業務は想定になることが多いため、想像力が必要となります。
ここまで各フェーズについて書いてみました。
2つ抜けている観点があります。
- プロジェクトマネジメント（PM）
実際に企画の人がどの程度PM業務を行うかはありますが、少なくとも何を実施するかは知っておくべきですね。
- 非機能要件
性能、セキュリティなど機能として見えづらい要件です。
個人的にはここはエンジニアに任せていいと思います。
ただし、エンジニアと会話できるようにはなるべきです。
具体的なスキルについてはおいおい紹介しますね。