他にない、上質なITを

IT企画のワークフロー

IT企画(ITプロジェクト)の進め方〜 IT企画・IT戦略を正しく実行するために〜

Pocket

「経営もしくは業務課題を解決するために必要な、業務や事業をより良くするためのITシステム」を企画して、それが手に入るためにどうすればよいかの施策を立案し実行できるようにする」ことを、IT企画と呼んでいます。また、そのIT企画を実行するための一連の業務を、ITプロジェクトと呼んでいます。

業務をデザインし、それを支える業務システムの設計を行うというサービスに代表される「IT企画」「IT戦略立案」というジャンルに特化し、その実現までの流れを公開している会社はあまりなく、ITプロジェクトを立ち上げて進めていく方法論を公開している企業も、あまりないと感じています。

「業務分析や業務設計」「システム開発の方法論」「プログラムの作り方」という単位では標準的なワークフローが確立されていますが、各々の工程に断絶があるように感じています。

発注企業様、開発会社様、支援しているコンサルティング会社様も「ITプロジェクトを立ち上げて成果を出すためのワークフロー」の確立という共通の悩みがあります。

この「IT企画(ITプロジェクト)の進め方」というページでは、業務システムを構築するということを見据えた私達のやり方が強く反映されているとはいえ、何かしらお役に立つ情報だと考えております。是非ご高覧ください。お役に立てば何よりです。

  1. プロジェクト設計
  2. 構想立案
  3. 仮説検証(PoC)
  4. 要件定義

1.プロジェクト設計

最初に行うのは、プロジェクトを運営する土台作りです。

主には、今回のプロジェクトのゴールを決めること、体制を作ること、WBSを引いてどんな成果物をどの順番で作るかを決めること、などです。

1.1 プロジェクトのゴール設定

一番最初に行うのは、ゴール設定です。

私達のプロジェクトの場合は「業務をデザインし、それを支える業務システムの設計が出来て、開発や導入に至る準備ができること」が主なゴールになりますが、どんな業務課題・経営課題を解決したいのか、何を手放して何を手に入れたいのかについて、解像度を高めていきます。御社が立てた問いに対する「腹落ち」ができれば、ゴール設定の8割は出来たも同然です。

ゴールの設定で最も大切なのは「理想像を描く」ではなく「現状認識の密度を上げること」です。「今の会社には、こういう問題があるのでは?」という問いが正確でなければ、描くべき理想像も不適切なものになります。特に、IT戦略や業務システム企画に関しては、業務(実作業)レベルの現状認識が不足していると、それを元に作り出すシステムが使えないものになってしまいます。

1.2 体制づくり

プロジェクトチームの編成を行います。プロジェクトを進めるのは弊社主導で行い、成果物の作成も弊社が行いますが、ご希望であれば御社メンバーに成果物を作って頂き弊社がレビュー・コーチングする体制も組むことが出来ます。

1.3 WBS作成

お見積りの段階で既に大まかに作成してはおりますが、バイネームで主担当者を決定すること、及びタスクの取捨選択を行います。最も細かいレベルまで規定したテンプレートがありますので、適宜改変します。

1.4 プロジェクト計画書作成

ゴール設定、スコープ(対象範囲)、成果物、体制、WBSが整理できたら、改めてそれらを集約したプロジェクト計画書を作ります。エビデンスとして残すことが目的です。

1.5 キックオフ・ミーティング

プロジェクト計画書を元に、「プロジェクトに関わるメンバー全員が共有すべき情報や事項を確認し、プロジェクトを開始するための最終確認のミーティング」です。ゴールはプロジェクト計画書に合意を頂き、双方の社印を捺印します。

2.構想立案

プロジェクトが開始されたら、「業務をデザインし、価値のある、使いやすい、実現可能な業務システムとして作られるべきもの」を作り上げるための構想を練ります。システム開発をどうするか、みたいな話は一切不要です。

2.1 コンセプトデザイン

IT企画のコンセプトワーク
最初に行うべきは、なぜこのITを求めているのか、手に入れる必要があるのかを的確に示す「コンセプト」の策定です。コンセプトは、「今はまだわからない未知の良さを表現している、20文字程度の言葉」です。

すでにわかっていて、手に入れたいものが見えているなら、コンセプトがどうこうじゃないですよね。手段を決めるだけの話になります。場合によっては、買ってくれば良いだけになることもあるでしょう。皆さんが目指す所は「既に知っているものではなく、未知の良いこと」であるはずです。未知ですから言語化されていないので、それを認識する言葉を作る=コンセプトを決める必要があります。

2.2 現状分析

現在地と目的地の距離を図り、どういうステップで目的地までたどり着くかの方針を決めるのが構想立案ですべきこと。次に行うのは、現状分析です。主に4つのタスクを想定しています。

2.2.1 業務フロー

改善したい業務の今の流れと、関わっている人たちを整理するために作成します。ただ、この業務フローは全体図を俯瞰することが目的なので、A4用紙1枚でまとめる程度で良いです。チャート系は作り込むとより正確に表現しよう、より細かく作ろうとしてしまいます。俯瞰できる粒度であることが目的なので、その精密さは必要ありません。

業務フローの中にどこまで作業内容を書くのかは悩ましいですが、「自分もしくは自部署で完結できる範囲のことは1つの作業」にまとめます。極端に言えば部門の違う方に対して作業依頼を行うような場合は、別の作業として書き起こします。このようなルールを決めて作らないと、質がぶれます。

2.2.2 作業一覧

業務を構成する作業内容を一覧化してまとめたものです。業務フローよりも、こちらの作業一覧のほうが重要です。
1つの業務は複数の業務で構成されます。以下のようなイメージです。

ステップ 作業内容
1. 見積依頼 先方より「見積を提示してほしい」との打診を頂く。
2. 商談実施 依頼を受けて内容を確認するために、商談を実施する。
3. 見積作成 商談内容や依頼内容を精査し、見積を作成する。
上長もしくは営業担当者への承認が必要なケースがほとんど。
4. 見積提示 先方に見積書を送付し、提示を行う。
5. 受注判定 ご発注頂けたら受注、そうでなければ失注となり、見積業務が完了。

これらのステップにヌケモレが無いことを確認します。営業マンは1と5しか見ていないとか、事務方は3と4しか見ていないなんてことが結構あります。全員で業務に対する現状認識の解像度を上げるために、業務を構成する作業一覧は必ず精査します。登場人物と作業内容を精査します。

2.2.3 現行システム調査

業務上利用しているシステムの画面や項目、それらをどう使っているかについて精査します。主に画面項目、操作の流れ、出力帳票などについて確認を行っています。

2.2.4 現行帳票整理

帳票には「外部の人のやり取りで必要な帳票」と「業務運営上、管理用途で必要な帳票」に大別できます。前者は発注書、納品書、請求書等です。これらについて見落とすことはあまりありませんが、管理用途の帳票は見落としがちです。見積の予算一覧とか、作業計画など、得意先に提示することはないが社内の人間を動かすために必要な帳票を作っているのであれば、それらも精査します。

2.3 ToBe業務デザイン

現状分析できたら、2.1で決定したコンセプトに基づいて、どういう業務のやり方が望ましいかについての議論をともに行い、業務デザインを行います。

業務デザインのコンセプトを一言で言えば「Less is More」です。今までより少ない労力で、より多くのことを実現することを目指します。

「やることが増えて出来ることを増やす」のは現場の負担が増え続けてしいます。「やることが減ってできることが減る」のも本末転倒です。「やることは減っているが、出来ることが変わらない」や「やることは減っているのに、システム化によって出来ることが増えている」という状況を作るにはどうしたらいいのか、楽しんで創意工夫を凝らして頂きたいと思います。

今までのやり方を必ず見直さないと、やることを減らすことは難しいです。面倒なことはプログラムにやらせましょう。良い意味で怠慢になってください。すべき事の時間を捻出するために、ルール化すれば代行できる作業は、どんどんプログラムに外注させるというイメージを持ってください。

ECRSの法則

以下は、業務改善の鉄板であるECRSの法則と呼ばれるものです。これに沿って、Less is Moreとなるポイント、テコ入れをすべきポイントを考えます。

  • 【無くせないか? (Eliminate)】その業務は無くせないかを考える
  • 【一緒にできないか? (Combine)】業務をまとめて一緒に処理する
  • 【変更できないか? (Rearrange)】仕事や作業の順序を入れ替える
  • 【単純化できないか? (Simplify)】やり方を簡単にできないかを考える

最も効率化が図れるのは「その業務をなくすこと」ですが、今まで行っていたことは消せない理由がありますので、単純に排除することは困難です。そこで「一緒にまとめて集約することで、消すことは出来ないか。あるいは、単純化出来ないか。」を中心に考えるアプローチをまず検討するのが、現実的です。

作業の集約や変更を行うために考慮しなくてはならないのが、属人性です。

属人化には良い面もあります。例えば、同じお客様の営業を行っても個人差があるのは当然のことです。どんな仕事もどこかで感覚的な嗅覚を求められますし、その嗅覚の鋭さや持っている能力によってその人でなければ出せない付加価値があります。それが顧客へのサービス品質の向上につながっているのであれば、経営として喜ばしいことです。

問題は問い合わせの対応や在庫の確認、商品出荷作業といった「顧客へサービスを提供する以上、当然やらなければならない作業」が属人化している場合が困ります。当たり前の作業が属人化したら、そこがボトルネックになります。

属人性を排除に関連して、高度なスキルを持っている人材があうんの呼吸で回している業務などをシステムの機能に落とすような場合は、なかなか難しいです。システムに落とすということは、あうんの呼吸を明文化してルールを作ることを意味します。その中には「いつもはXXを実行するだけだが、YYというイレギュラーが発生した場合は、XXの他にZZを行う」みたいな例外が、たくさん存在します。レアケースを読み解いて通常はどこまでルールで縛ればよいかを決めていくアプローチが良いでしょう。

2.4 ユーザーストーリーマッピング

業務の流れと、現状の業務から作業内容を洗い出すことが出来たら、次は必要な機能を抽出するためのセッションを行います。アジャイル開発の世界で「ユーザーストーリーマッピング」と呼ばれるものを作ります。

業務の流れというのが、一番大きな軸です。時間軸と考えて良いでしょう。で、作業内容は前述の現状分析で洗い出した、その業務を行うのに必要な作業群です。新しく作業内容が追加されてもOKです。

必要機能には、その作業を行うのにITシステムがどんな機能を持っている必要があるのかを列挙します。実際には全員でホワイトボードに向き合ってポストイットを貼りまくります。熱量を持って一気にブレストしていきましょう。こういうのはダラダラやってもアイデアは出ません。ECRSの法則に則って、この作業まとめられるんじゃない?みたいなものはまとめてくくって、1つの機能として集約してもOKです。

ここで初めて、業務システムとして持つべき機能の洗い出しを行います。

機能は「こういうことがしたいという要望」に依存し、要望は「こういう問題を解決したい」という問題認識に依存します。そのため、私どもは「問題認識の共有」→「要望の整理」→「要望を実現する機能の整理」という流れで落とし込みをしていきます。

3.仮説検証(PoC)

作るべき機能が見えてきたら、さぁシステム開発・・・ではありません。機能は言葉でしか表現できないので、実際に出来上がるシステムの間にずれがあるかもしれませんので、より確実な形で検証を行います。

注文住宅を作る時には、設計士に対して間取り、インテリア、外観などの要望を伝えることで、平面図や立体図、パースと呼ばれる建物の外観や室内を立体的な絵にした物を使い、図面などではわかりにくい全体のイメージを表現します。ITの世界でも全く同じです。「○○ができること」という機能を列挙しただけでは、実際に日々の仕事で使う業務システムが本当に要望に叶うものであるか、仮にこのシステム開発を発注しても問題ないか、という点を検証します。

3.1 試作品作り(プロトタイピング)

パースに当たる試作品のことを、プロトタイプと呼びます。プロトタイプで作るものは、そのシステムで必要だと思われる画面を作ることです。ツールを使って画面をデザインし、画面をつなげて業務の流れをイメージして再現します。

これは、あるお客様のモバイルアプリの画面デザインの例です。

システムを作ってしまうと時間がすごくかかってしまうので、画面とその操作だけを行うだけの試作品を作ります。

プロトタイプはペーパープロトタイピングではなく、ユーザー操作(クリック、入力等)ができるようなプロトタイプを作ります。試作品の操作性を体感して頂くことで、そのシステムがどんなことができるかのイメージが固まるようになり、皆さん自身の考えやアイデアがより深まって、色んな議論が進むようになります。

以下、試作品作りの流れです。

3.1.1 画面設計

画面作りのインプットになるのは、作業一覧とユーザーストーリーマッピングです。この2つが主なインプットです。

画面を作る目的は、以下の流れを踏むことでより業務を正確に理解し、正しい業務システムかどうかの検証を進めるためです。

  1. 画面を作れば、業務運営上で必要な情報がわかります
  2. 必要な情報がわかれば、業務上の判断基準や完了条件がわかります
  3. 判断基準や完了条件が理解できれば、この画面のゴールがわかります
  4. ゴールを元に、本当に必要な機能を導いていきます

どういった画面があり、どんな情報が表示され、ユーザーの操作(クリックやキー押下等)があったら、どういう処理を実行しなければならないのかを、細部に詰めて行きます。

プロトタイプを成功させるコツは、業務の流れを再現する画面遷移を実現することと、操作性について細かく詰めていくことです。項目の多い少ないは比較的後からでも調整できますが、操作性の良し悪しは現場の使い勝手に直結するためです。

3.1.2 行動設計

画面設計が終わった所で、改めてこの業務システムを使うユーザーの行動が適切なものかを確認します。

私どもは、当該業務の専門家ではありませんが、様々な業種のIT企画や業務システムのデザインを行いました。体験したことがない仕事や業界を対象にしたことも多くありますが、それらをキャッチアップする術を知っています。正確には、画面設計を行っていることでキャッチアップできます。

業務知識を得るためにやっていることは、「追体験」です。追いかけてユーザーの立場に立って同じ体験をイメージし、ロールプレイングをします。

追体験は元々「他人の体験を、作品などを通してたどることによって、自分の体験としてとらえること。」の意味です。作品ではなく業務内容を通じて自分が今この仕事をやれと言われたらどんなタスクをこなす必要があり、何を確認しなければならないのか。そこでどんなコミュニケーションを誰と取って仕事を回す必要があるか・・・をイメージして、自分なりに作業の流れを組み立てて、業務内容の理解を深めています。画面設計を行うと、必然的にそういった力がつきます。

この理解と皆さんの要望をぶつけ合って、より良い行動が取れるように、この業務システムを使うことで「こういう行動が取れるようになるのがベスト」を作り上げるのが、行動設計の意味です。

3.1.3 画面と機能の整理

画面設計と行動設計が終われば、改めてこの業務システムで必要な機能が画面単位で網羅できるかを確認し、ヌケモレがないかを精査します。

3.1.4 操作マニュアル作成

社内説明が必要な場合や、画面数が多くなった場合などは、ユーザーズマニュアルをプロトタイプを元に作ることをおすすめしています。操作マニュアルとして精査することで、新たに作るべきこと・修正すべきことが見つかることも多いです。

以上が、仮説検証で行うべきことです。

4.要件定義

仮説検証が終わり、プログラムの開発を行うことが決定した場合、次に行うのは「要件定義」になります。

要件定義という言葉の「要件」が広い意味で捉えられてしまう(主語がないため)ので、当方のワークフローにおいては、要件定義の要件は「プログラムが開発できるために必要な3つの情報の集合体」と定義しています。

その3つの情報は「UI(画面)」「データ」「機能」の3つです。

4.1 画面仕様

システムとして動かすためには、仮説検証で作ったプロトタイプだけでは不十分です。画面に関してはいえば、以下の物事を決める必要があります。

  1. 画面項目及びデータマッピング
  2. 画面遷移
  3. 画面上で可能な操作・連動
  4. 入力チェック・業務ルールチェック

当然ですが、システム上で表示されるデータは、データベースなどに保存されている必要があります。そのデータベース上で保存されている内容と画面項目がどう紐づくかが、データマッピングと呼んでいます。

画面遷移については文字通り、この画面からどういう遷移が可能なのかを指します。画面上で可能な操作は、ボタンのクリックやキーイベント(Enter押したらマスタを参照する的な)の有無をまとめ、プログラムを動かす必要があるものを列挙してまとめます。連動と呼んでいるのは、数値の自動計算やコンボボックスで関東を選ぶと表示される県がフィルターされる、みたいなものです。

入力チェックについては、「必須項目チェック」「型チェック」「相関チェック」「業務ルールチェック」の大きく4つがあります。型チェックは、数字しか入れてはいけないのに文字を入れては駄目とか、電話番号や郵便番号のようにフォーマットが規定されているものはそのフォーマットに従う必要があるとか、そういうものです。

相関チェックにも色々ありますが、代表的なのは一意性制約、大小関係、関連チェックです。一意性というのは、例えば得意先コードのように得意先データ全体で重複が許されない値のことです。また、注文明細などで同一品番を入力不可にするみたいな一意性制約もあります。

大小関係は、契約の開始日と終了日のように、開始日は必ず終了日より前で無くてはならないものを指します。逆もしかりです。関連チェックは、例えばキャンセルというチェックボックスにチェックを入れたら、キャンセル申請があった日付を必ず入力しなければならない、という種のチェックです。

業務ルールチェックは、その会社のビジネスルールを実装するものです。一意性、大小、関連では表現できないようなチェックを行う場合に行います。過去あった例ですと、新しく注文を入力するとき、もし当該得意先で既に同商品を予約していたら、予約分を重複している旨をアラートで上げるというチェックです。そのお客様からしたら二重発注になるので、キャンセルになる可能性が高いので前もって警告を出すようにしていました。

このような形で、画面1つを決めるにも色々な事を考える必要があります。

4.2 データモデリング

業務システムの提供形態は色んなものがあります。スマホアプリ、Webサイト、デスクトップアプリ等。どういう形態でも、画面を通じてデータの読み取り・書き込みを行う部分は変わりません。

データを保存する為のソフトウェアのことをデータベースと言います。データベースの世界においては、1970年頃にコッド博士という偉人によって提唱された「リレーショナル・モデル」というデータ保存フォーマットがずっと使われています。2019年の今でも、です。

カタカナにすると非常に固くなりますが、世の中のシステムのデータのほとんどは、皆さんにも馴染みのある形式で保存されています。2次元表(列と行)形式です。

データベースに該当するのが、Excelのブックです。

Excelのブックは複数のシートを持つことが出来ます。これをテーブルと言います。一覧表と言ったほうが速いですね。テーブルには好きなだけ列を持つことが出来ます。

画面からデータを登録すると、該当するテーブルの行が1行末尾に追加されます。更新する場合は、更新する行をフィルターして、どの列を更新するかを決めます。削除の場合も同様に、削除する列をフィルターして消す、というだけです。仕組みはいたってシンプルです。

1つ1つの画面単位で、画面と上記のテーブルの紐づけをします。例えば注文を登録する画面には、注文表に1行追加して、場合によっては商品表の現在庫を減らすという処理が必要になります。ユーザーが実際操作する画面を元に、どういったテーブルを作りそのテーブルにどんな列を作ればよいかを決める作業のことを、データモデリングと言います。画面で表示された項目のほとんどは、データベースに保存されていなければなりません。

この工程によってER図というデータベースの設計図が出来上がりますが、一般のユーザーの方がそれらを見ることはありません。開発会社やエンジニアが、プログラム作成のインプットにするためのものです。

4.3 機能定義

データモデリングを行い画面との整合性を確認していると、「画面の入力値がそのまま反映されるもの」と「画面の入力値を元に、ユーザーから見えない所でデータを加工・登録・更新しなくてはいけないもの」に大別できます。前者は画面仕様がそのまま機能仕様になりますが、後者は別途プログラムを書かないといけないケースがほとんどです。

例えば、先程の注文を登録したら在庫を落とすとか、注文を登録したら発注データを作るとか、、データを年月で集計して月別合計を表示するとか、そういったものです。こういった目に見えないプログラムが業務のツボを抑えることで、業務システムの価値は上がります。しかし、目に見えないプログラムがどうやって動いているかの理屈を抑えておかないと、管理不能になってしまいます。昔作ってもらって仕様がわからず手の入れようがない業務システムは、枚挙に暇がありません…お気をつけてください。

そのため、目に見えないプログラムが動作している(画面の入力と出力内容が一致しない)場合は、機能定義書を別途作るようにしています。

これが機能定義書の例です。画面からの入力、最終的に出力するデータのテーブル名、どういう順番で登録がされているかを記載します。

フォーマットは何でも良いですが、重要なのはどういうデータがどの順番でどのテーブルに格納されるかを記録されていることが重要です。

画面から入力したデータがそのまま出てくる画面が多ければ多いけど、システムとしてはシンプルになりますが、出来ることが減っていきます。プログラムを書けば書くほど出来ることは増えますが、融通がきかずブラックボックス化するリスクは高まります。このバランスをどう取るかが、プログラム開発時には重要になります。

4.3 その他

もっと細かく分類できるのですが、システム開発のワークフローを説明するページではないので、その他という項目でサラッとまとめてしまいます。代表的な決めないといけない項目は以下の通りです。

  1. 帳票出力
  2. 認証認可
  3. 運用環境
  4. セキュリティ
  5. バッチプログラム設計

機能面で言いますと、帳票(ExcelやPDF)の出力が必要な場合は別途帳票設計が必要になります。

認証認可についてです。認証はこのシステムに対しするログインをどのようにして行うのか、です。社内のPCにログインして、そのログイン情報をそのまま引き連れて認証を行う(シングルサインオン)みたいな場合は、ひと手間必要になります。認可は権限設定です。管理者はこの画面を触れるが、事務担当者はアクセスできないというようなものです。

運用環境やセキュリティについては、ツールやSaaSを使う分には、各々の動作環境に依存します。パッケージソフトの場合、社内にサーバーを構築しないと行けないタイプが結構多いので、その手間(要は壊れた時にどう復旧してデータを守るか)が増えるなど、です。今ですと、Amazon Web Servicesのようなサービスを使うことが増えています。運用環境の制約によって、システムを運用するフローも規定されます。

運用環境で大切なことは「SPOFを作るな」です。SPOFとは、Single Point Of Failureの頭文字をつなげたもので、 システムを構成する要素のうち、そこが停止するとシステム全体が停止してしまう部分を指します。例えば、データベースサーバが壊れたら、それにアクセスする全てのプログラムが利用できないような場合、SPOFが存在することになります。コスト重視で甘受するというやり方もありですが、データのバックアップだけは確実に取得してください。アプリケーションは再構築できますが、データの中身は1からやり直すことはできませんので。

バッチプログラムは毎日・毎月・毎年と言った、時間をトリガーにして動作するプログラムの総称だとお考えください。画面操作を元に動作しないプログラムで、何かのデータ処理を一括で行うプログラムです。例えば、注文残の商品の入荷日を登録して、「現在日付が入荷日の7日前になったら、アラートメールを出す」とか「2ヶ月以上売上伝票のないお客様をリストアップして、メールを入れる」とか、そういうプログラムのことを指します。

このような画面操作とは全く別のタイミングで起動するプログラムは、多くの場合スケジューリングを行います。毎日深夜3時になったら起動する、みたいなものです。

このように、システムの機能ではなく運用に着目して決めなくてならない決めごとを、非機能要件と表現します。機能要件と非機能要件は合わせてセットで考えます。

ワークフローを作って公開する理由

ITプロジェクトのような不定形な成果物を作らねばならない種の仕事を進めるには「枠組みを決め、その枠組の中で議論を行い成果物を作る」ことを決めるのが先決です。それをやらないと肥大化したり、空中分解を引き起こすリスクが高くなります。

適切な制約を作り、成果物のフォーマットを規定することでクリエティビティを発揮できる環境を作り、本当に決めないといけないことにじっくりと時間を割くために、ワークフローを作り始めました。どうしてもゴールが動きやすくなるITプロジェクトを管理できる手法を確立する必要があります。

システム開発を長く経験したユーザー企業のIT企画・IT担当・IT戦略のご担当者は圧倒的に少ないので、システム開発で決めなくてはいけないことの多さ、綿密に物事を詰めていかねばならない面倒さなどを知って頂き、大変失礼な言い方ですが見切り発車でIT導入を行うリスクについて、思いを馳せて頂けたらと思っています。

ここで共有したノウハウが、業務システム、プロダクト開発、IT企画、IT戦略、ITプロジェクト立ち上げや支援などに関わる方々の働き方や現場の課題解決の一助となれば幸いです。


IT企画の進め方

ITプロジェクトの進め方、公開中

事業を運営するために必要なITや業務システムの企画の作り方、プロジェクト担ってからの進め方をワークフローという形で完全無料公開しています。10000文字超えの力作です。是非御覧ください。

ITプロジェクトの進め方

IT戦略・IT企画の無料相談承ります。

ITプランナーが御社にお伺いして、御社のシステム企画のディスカッション・パートナーをさせて頂くサービスです。60分時間限定ですが、IT企画のモヤっとスッキリさせるお手伝いをさせて頂けたら。

ITプランナーへの無料相談

お問い合わせはこちらから