Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ITプロジェクトのはじめ方 / How to work around software pro...

ITプロジェクトのはじめ方 / How to work around software project

事業会社が今よりも事業を成長させるために、ITシステムの構築や導入を成功させるために、どうやってプロジェクトを立ち上げて、どんな中間生成物や検討が必要で、どうやって要件を決めるべきかを解説した資料です。

私の経歴やブログは以下の通りです。

https://quality-start.in/about
https://gothedistance.hatenadiary.jp
https://note.mu/it_planning/

YUMOTO Michitaka

October 30, 2019
Tweet

More Decks by YUMOTO Michitaka

Other Decks in Business

Transcript

  1. ࣗݾ঺հ n ゆもと みちたか(YUMOTO Michitaka) ü (株) クオリティスタート 代表 ü

    1979.11.12 東京都⽣まれ ü 新卒でSIer→事業会社で情シス→独⽴ ü IT企画/プロジェクト⽴ち上げ・SaaSや業務シ ステムの導⼊⽀援、要件定義などが現⾏業務。 ü Java/Python/Swift/C#あたりを少々。 ü プログラミング教育をやっていた時に、←の本 を書きました。3冊刷。圧倒的感謝。 ü 野球⼤好きスワローズファンです。
  2. はじめに 3 n この資料は、事業会社がITシステムを使って業務改善・事業開発の プロジェクトを成功させる確率を上げるために書かれたものです。 n コーポレート・エンジニアの⽅々や、諸般の事情で突然ITプロジェ クトにアサインされた⽅々などに是⾮読んで欲しいと思います。 n 元々はITコンサルタント育成プログラムの⼀環として、新卒並びに

    中途採⽤の研修メニューだったものを、ギュッと濃縮しました。 n 思いついた検討すべき改善アイデアが、相談する⼈がいなかったり、 上⼿いやり⽅がわからないので、企画として⽴ち上がらずに消えて しまうケースが多くて「もったいない」と感じています。 n 皆様の事業を⽀えるITを作るための⼀助になる資料とならんことを。
  3. IT企画のロードマップ 6 フェーズ 作業内容 コンセプトワーク 現状分析を⾏って、ITを通じて「どういった未知の良さ」を⼿に ⼊れることができるのかを定義する 構想⽴案 経営 or

    業務課題を解決するための、ビジネスや業務のあり⽅を デザインし、どんなITが必要なのかを明⽂化する PoC(仮説検証) 企画したITが本当に課題解決に寄与するものか、検証を⾏う 特に不確実性の⾼く重要度の⾼いものを中⼼に⾏う 要件定義 システムに必要な要求が決まったら、UI・機能・データの3つの 側⾯を整理し、機能要件を確定させる。⾮機能要件もここで。 開発、テスト システム開発を⾏い、テストを実施し品質を担保する 稼働開始 機能要件、⾮機能要件を全て満たせれば、稼働開始 コンセプト〜要件定義までがIT企画の範囲 ※ 開発やテストについては開発⽅法論のスコープなので、対象外となります。
  4. コンセプチュアル・スキルを磨こう 8 半径5メートルを変えるために、企画の⼒を テクニカル・スキル ⾃分⼀⼈で成果を出す ことができる能⼒及び 専⾨性のこと。 ⼿を動かして得ていく もの。 ヒューマン・スキル

    このヒトの⾔うことは よくわかるとか、⼀緒 に働きたい、キチンと 話を聞いてくれるとか。 ファシリテーション。 そういうスキル。 コンセプチュアル・ スキル 課題を⾒つけその対策 を⽴案するなど、⾃分 以外の周りの⼈と共創 して、成果を出す⼒。 物事をよく観て、意味 を⾒出す⼒。 n 何かを変える-> 前例がない -> 正解を⾒つけるしかない -> コンセプト重要! n コンセプチュアル・スキルを磨くのに、僕はブログがすごく効果的だった。公開 して発信すると、⾊んなモノの⾒⽅というフィードバックがあったからです。 n ITという武器を持っているみなさんに、意味のある課題解決をしてほしい。
  5. どこがゴールなの?を決めよう 12 コンセプトワークは、ゴール地点を決めること 現在地 ⽬指す ゴール STEP 1 STEP 2

    STEP 3 STEP 4 現状とゴールの距離 現状と⽬指すゴールへの距離 が遠いのはあたり前なので、 それは気にしない。 距離を測るには「現在、どの 地点にいるのか」を認識する しかありません。 そのため、AsIs分析の密度を 特に重要視しています。
  6. 「業務インフラ」という視点を持とう 13 業務を運営する環境・組織体制・業務プロセス などを包括した「働き⽅」のベースとなるもの ۀ຿Πϯϑϥ 組織 構成 業務 内容 IT

    環境 ۀ຿Πϯϑϥ 組織構成 各業務に対して、どんな組織・ チームで構成されているのか。 業務内容 業務の開始から終了まで、どんな 作業を⽇々⾏っているのか IT環境 業務を実⾏する為の道具として、 どんなITが存在しているのか この3つの観点で整理しないと、 現状分析の密度が薄くなります。 そうすると、間違った課題設定 をしてしまうリスクが⾼くなる。
  7. 「業務インフラ」現状分析で⾏うこと 14 名称 作業内容 ビジネスモデルの整理 貴社に新規顧客が出来てから請求・回収に⾄るまでの流れを整理します。 業務フロー作成 顧客・⾃社・パートナー(外注・発注先)の3つの登場⼈物を元に、貴社 の業務プロセスの全体像をA4ヨコ1枚で整理します。 作業⼀覧精査

    業務は複数の作業で構成されているので、誰がどの順番でどんな作業を ⾏っているかを整理します。 現⾏ITシステム精査 業務を⾏うのに利⽤しているITを列挙して整理します。 利⽤帳票精査 帳票は業務を写す鏡です。業務を回すための通常業務で使⽤する帳票、 管理者が状況を把握するために管理⽤途で使⽤する帳票があります。 1つの業務は複数の作業で構成されている。その構造を可視化する。 1 ポイント ビジネスモデルを理解しないと、業務の⽬的が正しく理解できない。 2
  8. 業務フローを書くポイント 16 n A4ヨコ1枚程度に収める粒度で書くこと。全体を⾒たいので。 n 登場⼈物は「顧客」「⾃社」「取引先(発注先)」の3つです。仕事の流れ と⼈の流れを紐付けて、どんなビジネスをどうやって回しているのかを 知ることが⽬的です。 n 図解系は俯瞰するために書くものなので「粒度」が重要です。

    n ⾃社業務を書く時には「ロールの違う他部署・他⼈に受け渡すまで」の 範囲を1つの業務内容としてまとめるとわかりやすいです。 n ⾃社の中で複数のロール(営業と総務等)があり、仕事の受渡が発⽣するの であれば、⾃社というレーンを複数に分けて書きます。 n ワークフロー(承認経路)は書かないでください。理由は後述します。 n 更に細かいフローが書きたい場合は、⼤分類・中分類という格好で粒度 を揃えて整理してください。まずは、顧客を踏まえた⼤分類からです。
  9. ワークフロー(承認経路)の整理 17 ਃ੥ ワークフローは業務フローではなく、表で整理する ਃ੥ 申請者 確認A 確認B ਃ੥ 決裁

    ਃ੥ ࠩ໭ ࠩ໭ ࠩ໭ ü 申請と差戻の流れを図⽰しても 意味がない。 ü どの条件でどういう経路が存在 するかを⽰す必要がある。 ü ワークフローは条件分岐なので 条件を⽰すには表形式がベスト。 区分 申請者 申請者の部⾨⻑ 執⾏役員 社⻑ Aパターン ◦ ◦ Bパターン ◦ ◦ ◦ Cパターン ◦ ◦ ◦ ◦ n 条件によってフローが異なるものは、表形式で整理するとスッキリします。 ͜Ε͕ ਖ਼ղʂ
  10. 業務フローの限界(1) 18 n 業務フローは業務を俯瞰するために書くと前述しました。 n フローチャート系の成果物で「書き切る」ことをする必要はありません。 細かすぎて伝わらなくなるからです。 n 裏を返すと、俯瞰するためには「複数の作業をまとめて、1つの業務と して表現する」というグルーピングが必要になります。

    n グルーピングすることで⾒えなくなった複数の作業を表現できないので、 正確さにはどうしても⽋けます。 n これらの限界を埋めるため、業務フローだけではなく、先程のワークフ ローの条件整理であるとか、業務を構成する作業の⼀覧を別表で整理を ⾏うなど、現状分析をより正確に⾏う⼯夫をする必要があります。 書ききれない業務/作業が出てきてしまう
  11. 業務フローの限界(2) 19 ⽇常的な業務しか表現することが出来ない n 業務フローで表現できるのは⽇常業務です。会社を運営するため、毎⽇ のように⾏う必要がある、ある⼀定のやり⽅に沿って⾏われるものです。 n ⽇常的に⾏わず、⼿を動かせば良いというものでもない業務があります。 それを管理業務と当⽅では呼んでいます。 n

    わかりやすいのが数字の分析です。得意先からどれぐらい受注があった のか、どの商品が出ているか、予約状況はどうなっているか等です。 n 現状がどうなっていて、今度どういう⾏動を次に取るべきかの舵取りを ⾏う管理業務は、業務フローで表現することは出来ません。 n 管理業務の場合、⼤抵その管理を⾏うためのドキュメントや帳票が存在 します。経営層・管理層へのヒアリングを⾏う際には忘れずにチェック。
  12. 業務フローの限界(3) 20 どの業務でどんな問題があるか表現できない n 業務フローを眺めても、どんな業務でどんな問題があるかは精査できま せん。経路が複雑であるとか、ここだけボリュームが⼤きいなどです。 n 業務上で発⽣する問題を可視化するには、作業レベルにブレイクダウン して整理する他に⽅法がありません。 n

    また、業務運営上の問題は、個⼈の能⼒の優劣が問題ではなく、業務を ⾏う仕組みの上に発⽣する構造的な問題です。誰がやってもこのやり⽅ では同じ事を繰り返すよね、という所を⾒つけることが重要です。 n 課題の可視化については王道は有りません。ひたすらリストアップして、 同じものはまとめて、どこを直せば変わるのかを仮説検証するのみ。 n 業務フローで表現できる業務には限界があるので、注意しましょう。
  13. 作業⼀覧と現⾏ITシステム調査 21 業務 作業名 作業内容 IT ⾒積 1. ⾒積依頼 お客様より⾒積り依頼をもらう場合と、

    年間契約等で定期的に再⾒積を出す場 合がある。 SalesForce 2. 商談実施 ⾒積提⽰後、顧客担当者と⾃社の営業 担当者と商談する。 3. ⾒積作成 商談内容や依頼内容を精査し、⾒積を 作成する 4. ⾒積承認 この内容で提⽰してよいか営業担当者 に確認を取る。⾦額によっては決裁者 に確認を取る。 5. ⾒積提⽰ 先⽅に⾒積書を送付し、提⽰を⾏う。 6. 受注判定 ご発注頂けたら受注、そうでなければ 失注となる。新規顧客の受注の場合は、 顧客管理システムと販売管理システム に受注を登録する。 顧客管理(Access) 販売管理(OBIC) 業務を作業に分解、使っているITを列挙する
  14. 作業⼀覧と現⾏ITシステム調査( 2 ) 22 n 業務を⼤分類にして、作業内容を時系列にまとめて精査します。 n ワークフローについては、承認プロセスの有無があることだけ記載します。 詳細は前述したワークフロー条件分岐をまとめた表で確認します。 n

    「現⾏ITシステム」の範疇に、Excelも含まれます。何かしらプログラム が実装され、そこにデータを⼊⼒して業務を⾏っているソフトウェアのこ とを「現⾏ITシステム」と呼んでいます。 n 現⾏ITシステムの操作を順を追って現場の⽅に操作して頂き、利⽤⽤途を ヒアリングしましょう。マニュアルやスクリーンショットだけでは、限界 があります。 n 操作感(Webアプリとデスクトップアプリでは操作性が違う)も合わせて、 確認しておきましょう。⼿順が1つ増えるだけで、ユーザーはものすごく 抵抗を感じます。
  15. 利⽤帳票、ドキュメントの精査 23 n ⾒積書、契約書、発注書、請求書、在庫表・・そういった業務運営上必要 なドキュメントのことを「帳票」と⾔っています。 n 帳票には顧客や取引先に提出するための帳票と、⾃分達が業務を管理する ために使う帳票があります。 n 帳票で⾒る観点は、出⼒項⽬と出⼒内容に加⼯・集計があるかどうかです。

    個々にある項⽬は最低限出せるように(登録・編集できる)しなくてはなり ません。 n 加⼯があるというのは、⼊⼒内容をそのまま出⼒したものではないデータ がある場合です。最も多いのは集計されたデータが帳票にでているケース。 n 要件定義をやるとなった時に問題になりますが、帳票は出⼒される内容、 レイアウト、形式によって、実装難易度や⼯数がかなり違います。 n 何気ない会議資料、実は以外とすごく⼿間がかかって作られていることも。
  16. 業務運営上の問題=「業務ストレス」 24 n 現状が⾒えてくると、次は何をどうしたいかの検討へ移ります。 n 多かれ少なかれ、下記のような問題を抱えています。 ü 「やり⽅が⾮効率」 ü 「特定の個⼈、もしくは部署の業務負荷が⾼い」

    ü 「欲しい情報が取れない」 ü 「兼務や割り込みが多くて落ち着いて仕事ができない」 ü 「⽣産性が上がらない」 ü 「属⼈性の⾼さがボトルネックになっている」 ü 「何をどういじればよいのかわからんシステムやExcelがある」 これらは「業務ストレス」と⾔うべきもの
  17. 業務ストレスとは何か 25 n 組織での働き⽅に起因して発⽣する「不満・不便・不安・⾮効率」などの 不健康な負担が発⽣している状態を、業務ストレスと呼んでいます。 n 業務ストレスの発⽣原因は、業務インフラにあります。 n 基盤となっている業務運営のやり⽅があって、そのやり⽅を踏襲する以上 は、誰がやっても同じストレスが発⽣するはずです。

    n IT企画の⽬的は、業務ストレスを解消する業務インフラの改善です。この ストレスがあることを認識するのが、現状分析の⼤きな⽬的です。 n 「御社の課題はなんですか」という問いに正確に答えるのは本当に難しい ので、「どうなればハッピーなのか」「何から解放されたいのか」という 視点で考えると良いです。 業務ストレスを可能な限りなくしていこう
  18. 業務ストレス4⼤分類 26 名称 内容 ߴ͍ෛՙ ある業務において、特定の個⼈・部署の作業量がとても多い。 յΕͨڮ 業務の受け渡しがうまく出来ずに、様々な⼿間が発⽣している。 ଐਓԽ どうやって作業を⾏っているのか、他⼈が⾒ても判断ができない。

    ࣫ࠇͷҋ 欲しい情報が取れない or 精度が低いので、経営判断を正しく⾏えない。 最も解放されたいストレスは、何ですか? n 中⼩企業で多いのは属⼈化の解消です。ただ、問題が根深いのも属⼈化です。 n メンテナンスできないITがあったり、能⼒が⾼いゆえに他の⼈を育ててフォロー に回るまで時間がかかるなどで、やりたくても踏ん切りがつかない事が多い。 n 属⼈化と⾼負荷は、だいたい⽐例します。属⼈化が⾼い=負荷が⾼いです。 n 「壊れた橋」によくあるのが、⼆重⼊⼒やExcelによる帳票作成などです。
  19. コンセプトワークで未来に旗を⽴てる 28 n 現状分析を⾏い、⾃社を取り巻く業務インフラがどうなっていか を整理します。 n 業務インフラの整理が終わると、「解放されたい業務ストレス」 が⾔葉にできるようになります。 n 解放されるためには、どうなっていたらいいのかをイメージして

    「このITで⽬指すのはこういう未来だ」という旗を⽴てましょう。 それがコンセプトワークのゴールです。 n コンセプトワークは「これを無くしたら意味がない」という企画 の⽴脚点を作るものでもあります。 n このフェーズが⼀番みなさんが⼤変で、重要なフェーズです!
  20. 構想⽴案はWHATを決めるフェーズ 30 8): 8)"5 )08 どんな業務上の課題があって、どういう解決をしたいのか どういうITシステムがあれば、それが達成できるのか どうやってそのITシステムを⼿に⼊れ、運⽤するのか n 構想⽴案は「どういうITがあればいいのか」を⾒定めるフェーズになります。

    n 簡単に⾔えば「業務のやり⽅をこう変えて良くしたい」→「こういうやり⽅を構築 する必要がある」→「それを担保するためのITに必要なのはこれ」です。 n システムに求める要求を整理して、RFPと元になる情報をまとめ上げるのがゴール。
  21. オペレーションの変⾰を実現しよう 31 企業経営 事業の成⻑ ビジネスモデル の変⾰ オペレーション の変⾰ 企業を経営する⽬的は、会社を存続させること。 会社の存続させるために、事業を変⾰して成⻑

    させていく継続的な取り組みが必要。 事業が成⻑するためには、継続的にビジネスモ デルを⾒直して、改善・変⾰することが不可⽋。 ビジネスモデルの変⾰をするには、現場のオペ レーションを変えなければならない。
  22. あるべき業務をデザインしよう 32 業務改善の鉄板「ECRSの原則」を活⽤しよう Eliminate (なくしてみる) Combine (まとめてみる) Rearrange (交換してみる) Simplify

    (簡単にする) 不要な作業をやめる 1つにまとめてみる ワークフローの改善 作業を簡略化する n 最も単純で効果が出るのはなくすことなので、まず無くせるかどうか(縦割りで同じ事を 違う部署がやっていないか)を検討するのが良いでしょう。Eから始めます。 n 次に、CRSの内容に移ります。ITが最も効果を発揮するのは「Combine」です。⼿作業 でやっている内容をプログラムにやらせることで、作業内容が⼀気に集約化されます。 また、複雑な⼿順を簡素化する(Simplify)ことにもなります。
  23. ユーザーストーリーマッピング 33 受注 出荷 納品 業務の流れ 作業内容 必要機能 ü 在庫確認

    ü ⽋品連絡 ü 注残確認 ü 取置残管理 ü 送料計算 ü 出荷依頼 ü 出荷データの 取込 ü 在庫引当 ü 売上登録 ü 伝票起票 ü 返品対応 ü 不良品対応 ü 売上集計表の 作成 ü 注残管理 ü 取置管理 ü 委託倉庫から の送料計算 ü 委託倉庫へ出 荷依頼を⾏う ü 出荷後、出荷 データを取り 込めて、出荷 処理と同時に 売上登録する ü ⾚伝⼊⼒時は ⾃動的にマイ ナス計算 ü 年指定により 12ヶ⽉単位の 商品別売上集 計ができる ユーザーが取る⾏動に、最適な機能を導き出す n 横軸に業務の流れを描き、作業内容を⽰す付箋と、機能を⽰す付箋を⽤意します。 n この作業内容をこういう機能を使って、簡略化・集約できると価値が出るのでは、 というアイデアを出すためのものです。ポストイットの数だけ強くなれるよ。
  24. アイデア整理マトリックス 34 インパクトの⼤きさと、所要時間で分けて整理 効果が⼤きい 効果が⼩さい 時間がかかる すぐできそう やらなくてもよい ものがあればここ ちょっとした改善

    だけど、改善後の 効果が⽬に⾒える もの やりきったら最⾼ だけども、⼀筋縄 ではいかないもの やりきっても何の メリットもない
  25. 要求事項を抽出し、優先順位をつける 35 n 業務改善アイデアは業務単位でグルーピングすると整理が楽です。 n アイデアに優先順位をつけて、何をどの順番で実現するのかを考えます。 そのために、どういった機能を持ったITがあれば良いのかを整理します。 n 必要な機能の抽出を⾏うフェーズに⼊る前に、IT企画の経験があるヒト にサポートしてもらうのがベストです。

    n サポートに⼊る意味は、「ITでできること」の引き出しの数が違うのと、 コスト(難易度や⼯数)の算出がより正確にできるからです。 n 全ての機能を実装するのは困難ですし、優先順位をつけないとシステム で達成したい成果もブレます。 n システム要求を出して優先順位を設定したら、RFPの⼟台となる企画書 をまとめる作業に⼊りましょう。まず、まとめましょう。
  26. ITで業務改善するためのポイント(1) 36 業務を簡略化する=ルール化できる場所を探す n ⼈間がやっている内容をプログラムにやらせるのが、IT活⽤ならではの 業務改善のポイントです。 n 顧客への報告書作成業務などで、⼊⼒した内容をコピペで報告書に転記 するのではなく、初めから報告書をテンプレート化して、ボタンを押す と出⼒できるようにする等です。

    n 同じく管理業務等で使う数字の作成なども、ITが得意な分野です。 n 業務内容を簡素化するには「ヒトが⼊⼒しないとダメな作業」と「⼊⼒ された後は、ルール化すればプログラムにより代⾏できる作業」の2つ に分けるとわかりやすいです。 n ITは空気を読まないので「この場合は、こうする」と決めて、ルールを 設定しないと効果が出ません。業務の「標準化」が必要です。
  27. ITで業務改善するためのポイント(2) 37 どこでも、どの端末でも、操作ができるように n もう1つあるのは、モバイル端末の活⽤を考えること。 n メールやファイル閲覧等は可能だが、スマホで⼊⼒作業ができないので パソコンを持ち歩くケースはまだまだ多い。 n やることは変わらないが、「スマホで可能になるだけで良い」という

    業務は結構あります。その代わりセキュリティの担保が必須です。 n 特に清掃や施⼯など、現場に⾏って作業をしなければならず、作業それ ⾃体が売上にダイレクトに跳ね返る業種では、モバイル活⽤が有効。 n 「その場でお客様が⽬の前にいる状況で何をしたいのか」という観点で 整理すると、良いアイデアが湧いてくるはずです。
  28. ITで業務改善するためのポイント(3) 38 Less Is More(より少ない労⼒で、より多くを) n ITの良い所は、ルール化された作業であれば⼈間よりも確実に、素早く、 正確に⾏うことができる点です。特に集計作業には強い。 n やることは変わらないけど、作業内容が減って楽になる状態

    n やることは減っているのに、できることが増えている n こういった状態を⽬指すには、ヒトが頑張って作業を増やすのではなく ITを使って任せる所は任せるように業務を設計します。 n より少ない労⼒で、より多くのことを⽰す⾔葉が、「Less Is More」 n More and Moreでも、More is Lessでも、Less is Less でも、ダメです。 n 運⽤⼿順が複雑になってしまうなら、その案はやばいと思うべき。
  29. 追体験をしてみよう 39 n 「業務(ドメイン)知識」と呼ばれるものがあり、お客さんがどうやって 業務を回しているか、そこでどんなやり取りがされているかを複合的に 表現する⾔葉です。 n 現場で起こっている課題を抽出して抽象化するには、発⽣する諸問題を 理解して構造化する訓練が必要になります。 n

    「業務がわかるSEがいない」みたいな話の9割は、その抽象化ができて いないから発⽣すると思います。はじめからわかる⼈はいないのにね。 n 業務知識のキャッチアップは、追体験するしかないと考えています。 n 追いかけてユーザーの⽴場に⽴って同じことを体験することをイメージ し、ロールプレイングをします。 n 映像を作る時に「絵コンテ」と呼ばれる映像の設計書に該当するドキュ メントがあります。今でいうと、ストーリーボードってやつ。あれを、 作ってみると頭に⼊りますよ。
  30. RFP(提案依頼書)を煮詰めていく 40 項⽬ 内容 システム化の⽬的 なぜ、このシステムが欲しいのかを、コンセプトワークから導く 現状の課題 業務フロー・作業⼀覧・業務ストレス精査などから、現状「変えたいが 出来ていない」ことをまとめる。 変⾰後のイメージ

    システムによって、誰がどんな動きができて、どういう情報が⼿に⼊り、 どんなメリットを得たいのかをまとめます。箇条書きではなく、図解が 望ましい。 機能要件 業務単位で「この機能は絶対にないと困る」というものを書き出す。 理想は、画⾯遷移と業務内容がまとまったもの。 ⾮機能要件 システム構成、運⽤体制、セキュリティ、稼働時間(SLA)など。 データ移⾏ 必要であれば、どのデータを移⾏したいのかを記載する。 スケジュール システム稼働をいつから⾏いたいかを明記する。 今まで検討してきたことを企画書に落とし込もう n RFPを受けて、開発会社は「どうやって作るのか」を決める要件定義という作業 を⾏います。RFPが雑だと、要件定義の⼯数が膨れ上がり、リスクが拡⼤します。 n 企画書を作ったら、変⾰後のイメージを確かめる(仮説検証)するために、簡易的 な試作品で検証するのがベストです。
  31. RFP(提案要求)と要件定義の乖離 41 RFP 要件定義 IT企画がない場合 「要望に合わせたシステムを描く」のは難しく、 コミニケーションコスト・リスクが伴う。 この ギャップ がリスク

    RFP 要件定義 IT企画をキッチリ⾏う 低リスク 提案依頼と要件定義に乖離 があればあるほど、導⼊を する側のリスクが⾼まる。 要望に合わせた、不定形の 成果物を作るコミュニケー ション・コストがそのまま 価格に転嫁されます。 IT企画をキッチリ⾏えば、 リスクが下がり、コストも 下がります。IT活⽤のノウ ハウも御社に残ります。
  32. 仮説検証をやらないとこうなりやすい 44 システム開発が始まったら、後戻りできない 先に仕様を決めないと、 何も出来ません 作るための資料作りが先になり、 出来上がるシステムが後になる ։ൃձࣾ ITシステムのイメージが ⾒えにくいけど、⼤丈夫

    かな...? ͓٬༷ お待たせしました。 システムをご覧下さい。 ։ൃձࣾ このシステムでは業務が すごくやりにくい… お⾦を払って不便なもの を買うなんて… ͓٬༷ 何ヶ⽉後に システムが 出来る
  33. システム導⼊=注⽂住宅を建てる 45 n 注⽂住宅の難しい点は、作る前にイメージを固める必要がある点。 契約時にどんな家が⽴つかは平⾯図やパース等で判断します。 n システム導⼊も同じ事です。どんなITが⼿に⼊るかは、図⾯に該当 する仕様書、パースに該当する試作品で判断するしかありません。 n 家ができてから「こんな家に住みたいとは⾔っていない。」は無理

    です。本番運⽤が始まったら、元には戻れません。 n 注⽂住宅の場合で特に気をつけるのは、⽇々の⽣活をイメージして ライフスタイルに最適な動線を描けているか、にあるそうです。 n システム導⼊においても、⽇々の作業を、このシステムの操作性、 実装された機能、出⼒できるデータや帳票を活⽤して、⽇常業務を 運営することができるか、を検証します。 n 同じ業種・業態でも、業務インフラが違えば課題が違います。
  34. 試作品はHTMLプロトタイプがベスト 47 n SaaSでもパッケージでもなんでも、ソフトウェアは操作してみないと どういうものだか評価できません。 n プロトタイプは紙ベースではダメです。画⾯イメージを並べられても、 ユーザーはまず「⾃分ごと」として捉えてくれません。 n 要件定義にかける想い(丁寧にしっかりやって成功させよう)に対して

    温度差があります。ITサイドが「10」に対してユーザーは「1」です。 n HTMLの試作品には、画⾯イメージ・遷移はもちろんのこと、データ もなるべくそれっぽいものをダミーで埋めておきます。⽇々の作業を イメージしてもらうためです。 n KintoneやPleasanterのようなPaaSを使うのもアリかもしれませんが、 PaaSの制約を超える要件が出てくると・・・悩みどころ。 n HTMLプロトタイプをいい感じに作れるツール、常に募集中。
  35. 試作品で作るのは⼊⼒画⾯数個でよい 48 n HTMLプロトタイプで作るのは「⼊⼒画⾯」です。マスタメンテでは なく、⾒積や出荷といった、業務プロセスをになう業務が対象です。 n 修正依頼が最も多いのは、⼊⼒画⾯の操作性、表⽰項⽬、補助機能の 追加等です。最も多く操作し、最も時間がかかるのが、⼊⼒画⾯への 操作だからです。 n

    補助機能とは、サジェスト・キーイベント・⼦画⾯連携・ajaxなどに よる画⾯の要素の更新・・・そういったものを指します。 n 「こいつは重たいな」という画⾯の特徴としては、項⽬が多い、1つの 画⾯に⾊んな情報が盛り込まれている、レイアウトが複雑などです。 n 要件定義フェーズでやることじゃないかって話かもしれないですが、 このステップをユーザー側でやるのと、業者が主導になってやるのは ⼤きな違いがあります。得られる経験値が、絶対に違います。
  36. 要件定義はHOWを決めるフェーズ 50 8): 8)"5 )08 どんな業務上の課題があって、どういう解決をしたいのか どういうITシステムがあれば、それが達成できるのか n 要件定義は「どうやってITシステムを⼿に⼊れるか」を決めるフェーズになります。 n

    システムをどんな画⾯で操作して、操作によってどんなアクションが実⾏されて、 どういうデータが作成・出⼒できたら良いのかを決めるのが、要件定義の⽬的です。 n また、システムの稼働環境・保守運⽤体制などもここで決めます。 どうやってそのITシステムを⼿に⼊れ、運⽤するのか
  37. システムを⼿に⼊れる4つの⼿段 51 ⼿段は4つあり、⼀⻑⼀短があります。 ⼿段 概要 メリット・デメリット オーダーメイド 開発会社に発注して、ゼロから作って もらう。 最も⾃由度が⾼く独⾃性のあるシス

    テムが作れるが、期間も⾦額もリス クも最も⾼く、継続的改善は困難。 DIY(内製) ⾃社の⼈員で作り上げる。 ⾃由度・継続的な改修が可能になる が、属⼈化は避けられない。内製を 担当した⼈材の退職リスクが⾼い。 既製品を使う パッケージやSaaSなどを使って、⽤意 されている範囲で⼯夫して使う。 ⾦額・速度・リスクが最も⼩さいが、 既製品なので「業務に合わない」と 運⽤が根付かない。 既存ITの改修 既に動いているシステム等を改修して、 機能追加する ドキュメント等が残っており、運⽤ 体制が構築できているなら問題ない が、何を変えたらわからないような 場合は、改修では済まなくなる。 n 既製品を使う場合は、要件定義を⾏わないこともあります。 n それ以外の選択肢を取る場合、次ページ以降の要件定義⼯程が必要です。
  38. 要件定義フェーズの主な成果物 52 成果物名称 作成⽬的 画⾯遷移図 利⽤するシステムの画⾯遷移を定義したもの 画⾯仕様書 各々の画⾯でどんな情報を⼊⼒・出⼒するかを決めたもの 画⾯イベント(クリック・キー操作)などもあるなら定義する ER図、DDL

    データベースの設計図(ER図)及び、実際にDBを構築するために必要なプ ログラム記述 (DDL) 機能定義書 ユーザーのアクションに沿って、どんな処理を実装しなければならない のかを記述したもの。 データ移⾏ マスタデータCSV取り込みでよいのか、トランザクション系のデータも 含めるのかで、⼀切不要なのか。それにより、⼯数がえらい違います。 バッチ仕様書 ⽇次・週次・⽉次・年次等、スケジュール管理によって定期的に実⾏す る必要があるプログラムがある場合、その内容を整理します。 インフラ構築 OS・サーバ・ミドルウェア等のソフトウェア構成、オンプレ・クラウド 等の稼働環境、監視体制、セキュリティ要件、SLAなど。 どんなシステムを作るのか / どう運⽤するのか
  39. 要件定義が終わっても道半ば 53 要望→要求→要件が前半戦、開発以降が後半戦 要望 要求 要件 UI データ 機能 開発

    テスト 稼働 システム稼働までの流れ 8): 8)"5 )08 n 要望→要求→要件に落とし込むまで、⾮常に多くの中間成果物が必要です。 n それでも、まだ道半ばです。最も時間がかかる「開発」が待っています。 n スポーツに例えるとラグビーのようなものです。
  40. 要件定義はUI、データ、機能の3つ 54 どんなデータを、どんな画⾯で、どう操作する? ü システムへの要求事項 ü 機能⼀覧 ü 帳票⼀覧 etc..

    要件定義の流れ 処理A ? 処理C 処理D 処理B 顧客 ユーザ 注⽂ 予約 売上 請求 UI(画⾯) 機能 データ n 検討する⼿順は 「どんなデータを、どの画⾯で、どう操作する」です。 n UIデザインをする前に、システムがどんなデータを扱おうとしているのか、そこを 最初に整理します。「データモデリング」と⾔われる作業です。 n データモデリングができるようになると、要件定義が楽しくなります。
  41. ITができるのは「データ操作」だけ 55 データの構造・流れ・作り⽅を変え、業務を変える n ほぼ全ての業務は、「データのやり取り」を⾏います。 n ⾒積データ、受注データ、契約データ、売上データ、出荷データ、請求 データ、⼊⾦データ、顧客データ、商品データ・・・キリがない(笑) n そういうデータを作成・参照・更新・取消などをしながら、データを必要

    とする⽅々がコミュニケーションを取って、業務を回しています。 n ITができるのは「データの操作」だけですが、「業務でやり取りされる データの流れや構造を変えて、⼈の動きを変える」ことができます。 n 誰がどんな仕事をしようと、データの構造は変わらない。誰がやっても、 同じ性質のデータが出来ます。操作するデータを変えれば、仕事のやり⽅ も連動して変わります。
  42. データモデリング (1) 56 システム化対象となる業務の作業内容を整理する 顧 客 ⾃ 社 問い 合わせ

    詳細 確認 プラン ⼀覧 予約 ⼊⼒ ホテル予約(例) 予約 完了 予約 確認 n データモデリングをする場合は、業務単位ではなく作業単位で精査します。 n 作業の流れを順番に整理して、誰がどんなデータをどういう操作を⾏うのかを整理 するのが基本です。
  43. データモデリング (2) 57 エンティティとフィールドにデータを整理しよう n データの持ち主が「エンティティ」で、付属 情報が「フィールド(属性)」です。 n 例えば、「年齢」はフィールドです。35とい う数字だけでは、その持ち主がわかりません。

    n フィールドの持ち主を探していくと、共通の 持ち主が⾒つかります。それがエンティティ です。 n この例では、予約・プランがエンティティと なります。 n 申込者は悩ましいところです。後述します。 ü 予約番号 ü 申込者⽒名 ü ⼈数(⼤⼈・⼦供) ü 住所 ü 年齢 ü 電話番号 ü 宿泊⽇程 ü 利⽤プラン ü 決済⽅法 ü チェックイン予定時刻 ü 交通⼿段 ü ⾦額 ホテル予約に必要な情報
  44. データモデリング (3) 58 エンティティの関連性(依存関係)を整理しよう 予約 プラン 申込者 n エンティティは、それ⾃体が単独で登録・更新等ができる必要があります。 n

    例えば、「プラン」は予約と⼀緒にデータが⽣成されるようではダメです。新しい プランを作るのに、新しい予約が必要になってしまいます。 n このように、「それ⾃体が独⽴して作られるべきデータ」はエンティティです。 n 申込者は予約なしでは成⽴しないので、予約エンティティの属性で良いでしょう。 プラン プランは独⽴したエンティティですが、 予約時には必ず必要になる情報です。 こういった場合、「プランを特定できる 情報」を(例えばプランID等)予約エン ティティに、保存できるようにします。 そうすれば、予約にあるプランIDから、 プランの詳細を参照でき、プラン⾃体は 独⽴してデータの操作が可能になります。
  45. データモデリング (4) 59 業務単位で「ヒト」「モノ」「コト」に分けよう n 業務を「ヒト」「モノ」「コト」の3つに分けて整理します。 名称 内容 例(ホテルの予約システム) ώτ

    そのシステムを利⽤する⼈達 社員(役職・部⾨等)、取引先、得意先、 アルバイト。 Ϟϊ システムで取り扱う資産・サービス プラン・予約・お部屋・設備・カレンダー ίτ システムを通じて⾏われる⾏動・イベント 予約受付・問い合わせ・オンライン決済・ キャンセル・空き状況を確認する 「モノ」は名詞で「コト」は動詞です。機械的に整理してOK。 1 ポイント 業務内容を「どんな情報を」「どうするか」という話だけです。 2
  46. ER図を⾒れば業務がわかります 61 ER図は業務で作られるデータの全てがあります n ER図(Entity Relation Diagram)は、業務を正確に写す鏡です。 n エンティティ間の依存関係を⾒れば、どの業務にどんな情報が必要になる のかがわかります。

    n 簡単に⾔えば、外部キーがあれば、外部キーの参照先のデータがなければ データは作れません。作業の前後関係がそこでわかります。 n また、ER図には、業務の管理⼿法が描かれています。状態を表現したり、 フラグによってデータを識別したり、集計のキーとなる情報があったり、 ⾒慣れないエンティティがあったり、等。 n RDBの世界では、テーブル( or ビュー)を増やして対応するか、カラムを 増やして対応するか、その2つしか取れる⼿段がありません。
  47. 画⾯設計のコツ(1) 62 どのデータを、どの順番で、どう操作するかを描く プラン⼀覧 プラン名 ⾦額 イメージ画像 検索 詳細 プラン詳細

    予約⼊⼒ 予約完了 プラン名 ⾦額 プラン説明… カレンダー お部屋 空き状況検索 予約申込 申込者情報 選択したプラン ⽇程 ⼈数 ⾦額 予約確定 予約番号 申込者情報 選択したプラン ⾦額 デ タ 操 作 オペレーションの流れ n 操作するデータに対して、やりたい操作を設計して、選べるようにしよう。 n どんなデータをどう操作できると、仕事がスムースに実現できるのか。それが重要。
  48. 画⾯設計のコツ(2) 63 UI⇔ロジック⇔データの受け渡しを意識しよう UI ロジック(アクション) データ 商品検索 商品画像クリック 再購⼊ 商品

    注⽂履歴 UIで表⽰される要素は、必ずデータの属性になるはず。 そこをつなげると、ロジック (どんな⼊⼒を、どう処理 して、何を出⼒するか)の設計がシンプルになります。 オブジェクト指向的な設計が素直にできると思います。 ポイント
  49. CRUDマトリックス 64 画⾯とデータを2軸で切って、操作内容を書く n C: Create, R: Read, U: Update,

    D: Deleteの頭⽂字で「CRUD」です。 n 注⽂を登録するには、得意先と納品先を参照(Read)して、注⽂と明細を登録 (Create)して、商品を参照して選べるようにしつつ、更新(Update)する必要 があることを⽰しています。 n 規模が⼤きいシステムになると、詳細画⾯で⼆桁のRがある場合も。
  50. 画⾯仕様書の例 65 画⾯レイアウト、項⽬、操作、⼊⼒チェック等 画⾯レイアウト アクション 画⾯項⽬ ・・・ 項⽬ ⽂字種 桁数

    必須 ⽒名(性) 全⾓⽂字 10 • ⽒名(性) 全⾓⽂字 10 • 郵便番号(ハイフンなし) 半⾓数字 7 • 都道府県 ー ー 項⽬ 内容 登録ボタン 押下後、会員情報を登録し、XX画⾯に遷移 n ⼊⼒チェックは次ページに記載があります。
  51. ⼊⼒値の検査パターン 66 検査パターン 内容 必須チェック データの登録時、未⼊⼒ならエラーとするチェック。最も単純なもの。 ⽂字種チェック 全⾓や半⾓、英数字制限、⽂字数や桁数などのチェック。 フォーマットチェック 郵便番号やメールアドレスのように、⼀定の形式に沿った内容以外は

    エラーとなるチェック。 ⼤⼩チェック 数値の⼤⼩や⽇付の⼤⼩の相関関係をチェックするもの。 開始⽇と終了⽇で、開始⽇は終了⽇より未来の⽇付なら、エラー。 原価よりも安い売価を⼊⼒するとエラー、など。 重複チェック 得意先コードのように、得意先全体で重複があってはならないデータ において、⼊⼒値に既に同じ値があればエラーとするチェック。 相関チェック キャンセルというチェックボックスにチェックを⼊れた場合、キャン セル申請があった⽇付を必ず⼊⼒しなければならない、という種の チェックです。 業務ルールチェック その会社のルール上、チェックする必要があるものです。 ⼊⼒値の検査は、実はかなり奥が深く、⾯倒です
  52. 機能仕様書を書くべき局⾯ 67 67 ⼊⼒値が「そのまま格納されない」ケースは必須 n ⾮常に⼤きくわけると、「画⾯からの⼊⼒値がそのままデータとして格納 される場合」と「⼊⼒値を加⼯したり、別のデータを操作する場合」の 2つに分けられます。 n 前者のケースは、機能仕様書は不要です。ユーザーマニュアルがあれば、

    それで良いです。 n 後者のケースの代表例が、在庫の引き落としです。注⽂受けたら、在庫を 減らす必要があります。在庫を減らすという作業はユーザーが⾃分で画⾯ 操作して⾏うものではないので、そのロジックを実装する必要があります。 n ソースコードはドキュメントではありません。引き継ぎをスムースに⾏う ためにも、ロジックが⼊っている箇所はその内容を記述しましょう。
  53. 機能仕様書の例 68 68 ը໘ ॲཧ಺༰ DB 1. 受注テーブルに1件追加する。 JSONファイルのキー名はテーブルのカラム名 と⼀致している。フォーマットは別紙参照。

    受注情報 2. 受注明細にレコードを追加する。 JSONファイルの”detail” キーに、配列で受注 明細情報が格納されている。以降5番まで明細 の1件ずつ同じ処理をすること。 3. 単価履歴にレコードを追加する。 キー 値 Item_id 商品ID customer_id 顧客ID gedai 売り単価 price 定価 受注 受注明細 単価履歴
  54. ビジネスに貢献する「IT企画」を 69 69 n 事業は時代の流れでなくなることがありますが、業務は会社がある限り、 なくなることはありません。 n 業務インフラをひとつ上のステージに導くのは、業務内容を理解し、それ をITに落とし込む⽅法論を持っている必要があります。そういったロール を担う⼈材が、とんでもなく不⾜しています。

    n 多くの会社にとって、ITは間接部⾨です。ソフトウェアを作り公開して、 それで売上を上げているわけではないからです。 n IT企画の⾻⼦は、業務で流通するデータの構造を掴み、リノベすることで 「こういう働き⽅ができたら」を実現することです。 n その答えは、その会社の業務の現場で⾒つけるしかありません。開発会社 には⾒つけることは出来ない。それだけは無くさないでください。 n 相談にはいつでも乗ります(腕まくり
  55. コーポレート・エンジニアに光を 71 71 n 業務インフラをひとつ上のステージに導くのは、業務内容を理解し、それ をITに落とし込む⽅法論を持っている必要があります。そういったロール を担う⼈材が、とんでもなく不⾜しています。 n 「情報システム部⾨のエンジニア兼企画職」とも呼ぶべきロール、コーポ レート・エンジニアが⽻ばたけるようになってほしい。

    n コーポレート・エンジニアがもし専⾨職となるとのであれば、「会社の働 き⽅をデザインしてITで仕組みを作るプロ」になるのではないかと。 n 皆さんの仕事の幅が広がることが、事業会社の働き⽅を変え、⼈の動きや 業績を変え、令和の時代に⽻ばたける会社へと!なるはずです。 n 相談にはいつでも乗ります(腕まくり) 事業はなくなることがあるが、業務はなくならない
  56. IT企画のワークショップを企画中です 73 座学では⾝につかないので、体験型がベスト! n ガイダンス n IT企画概論(座学) n 本資料のポイントを中⼼に学んで頂きます。 n

    業務分析ワークショップ n 業務フロー・作業⼀覧の書き起こし n 業務ストレスの整理、改⾰後の業務フロー等 n システム要求整理ワークショップ n 機能⼀覧、データモデリング、UI設計まで。 n クロージング ü ⼈数は5〜6名。 ü 2チームに分かれて⾏います。 ü 半⽇程度で終わります。 ü 2回ほどクローズドで試したい ので、(実験台)参加者募集。 ü もちろん無料。 ü ⼟⽇のどちらか(多分⼟曜)。 ü 11⽉下旬予定。
  57. おわり 74 お読み頂き、ありがとうございました! Ø 湯本 堅隆(YUMOTO Michitaka) Ø 株式会社 クオリティスタート

    Ø https://quality-start.in Ø Twitter: @gothedistance Ø [email protected] ご相談やご質問等、お気軽にお問い合わせ下さい。