Slide 1
Slide 1 text
ITプロジェクトの「歩き方」
〜事業会社がITを手の内に入れるために〜
(株)クオリティスタート
2019/10/11 第1版
ITプロジェクトに従事する皆様へ
Slide 2
Slide 2 text
ࣗݾհ
n ゆもと みちたか(YUMOTO Michitaka)
ü (株) クオリティスタート 代表
ü 1979.11.12 東京都⽣まれ
ü 新卒でSIer→事業会社で情シス→独⽴
ü IT企画/プロジェクト⽴ち上げ・SaaSや業務シ
ステムの導⼊⽀援、要件定義などが現⾏業務。
ü Java/Python/Swift/C#あたりを少々。
ü プログラミング教育をやっていた時に、←の本
を書きました。3冊刷。圧倒的感謝。
ü 野球⼤好きスワローズファンです。
Slide 3
Slide 3 text
はじめに
3
n この資料は、事業会社がITシステムを使って業務改善・事業開発の
プロジェクトを成功させる確率を上げるために書かれたものです。
n コーポレート・エンジニアの⽅々や、諸般の事情で突然ITプロジェ
クトにアサインされた⽅々などに是⾮読んで欲しいと思います。
n 元々はITコンサルタント育成プログラムの⼀環として、新卒並びに
中途採⽤の研修メニューだったものを、ギュッと濃縮しました。
n 思いついた検討すべき改善アイデアが、相談する⼈がいなかったり、
上⼿いやり⽅がわからないので、企画として⽴ち上がらずに消えて
しまうケースが多くて「もったいない」と感じています。
n 皆様の事業を⽀えるITを作るための⼀助になる資料とならんことを。
Slide 4
Slide 4 text
4
IT企画とは？
Slide 5
Slide 5 text
IT企画の「企画内容」とは何か
5
8):
8)"5
)08
どんな業務上の課題があって、どういう解決をしたいのか
どういうITシステムがあれば、それが達成できるのか
どうやってそのITシステムを⼿に⼊れ、運⽤するのか
WHY→WHAT→HOWまで「⼀気通貫に落とし込む」必要があること
1
ポイント
必要なITを⼿に⼊れてからが、本当のスタート。運⽤体制も要検討。
2
Slide 6
Slide 6 text
IT企画のロードマップ
6
フェーズ 作業内容
コンセプトワーク
現状分析を⾏って、ITを通じて「どういった未知の良さ」を⼿に
⼊れることができるのかを定義する
構想⽴案
経営 or 業務課題を解決するための、ビジネスや業務のあり⽅を
デザインし、どんなITが必要なのかを明⽂化する
PoC(仮説検証)
企画したITが本当に課題解決に寄与するものか、検証を⾏う
特に不確実性の⾼く重要度の⾼いものを中⼼に⾏う
要件定義
システムに必要な要求が決まったら、UI・機能・データの３つの
側⾯を整理し、機能要件を確定させる。⾮機能要件もここで。
開発、テスト システム開発を⾏い、テストを実施し品質を担保する
稼働開始 機能要件、⾮機能要件を全て満たせれば、稼働開始
コンセプト〜要件定義までがIT企画の範囲
※ 開発やテストについては開発⽅法論のスコープなので、対象外となります。
Slide 7
Slide 7 text
IT企画の成功に⽴ちはだかる4つの壁
7
1 IT技術が発達して様々なソリューションが⽣まれ、
IT企画の適⽤範囲が広⼤になり、取捨選択が困難。
2 経営、業務、ITの三者を始め、ステークホルダーが多い。
それなのに、各々で⼤切にしたい価値が異なる。
成果物が⽬に⾒えない上に不定形である。⾔語化も難しい。
ゴールの設定が困難。
3
4 同じ事をやっている⼈が社内(社外)におらず、相談する
相⼿もなかなか⾒つからない。
⾃分たちで正解を⾒つけるか、作り出せ。
Slide 8
Slide 8 text
コンセプチュアル・スキルを磨こう
8
半径5メートルを変えるために、企画の⼒を
テクニカル・スキル
⾃分⼀⼈で成果を出す
ことができる能⼒及び
専⾨性のこと。
⼿を動かして得ていく
もの。
ヒューマン・スキル
このヒトの⾔うことは
よくわかるとか、⼀緒
に働きたい、キチンと
話を聞いてくれるとか。
ファシリテーション。
そういうスキル。
コンセプチュアル・
スキル
課題を⾒つけその対策
を⽴案するなど、⾃分
以外の周りの⼈と共創
して、成果を出す⼒。
物事をよく観て、意味
を⾒出す⼒。
n 何かを変える-> 前例がない -> 正解を⾒つけるしかない -> コンセプト重要！
n コンセプチュアル・スキルを磨くのに、僕はブログがすごく効果的だった。公開
して発信すると、⾊んなモノの⾒⽅というフィードバックがあったからです。
n ITという武器を持っているみなさんに、意味のある課題解決をしてほしい。
Slide 9
Slide 9 text
真ん中にあるスキルは・・・？
9
https://speakerdeck.com/wataruyoshida/qing-sisufalsekiyariawokao-eru
吉⽥航さんの公開資料「 情シスのキャリアを考える」より引⽤
Slide 10
Slide 10 text
10
ITを使って課題を解決するには、
する必要がある
Slide 11
Slide 11 text
11
コンセプトワーク
Slide 12
Slide 12 text
どこがゴールなの？を決めよう
12
コンセプトワークは、ゴール地点を決めること
現在地
⽬指す
ゴール
STEP 1
STEP 2
STEP 3
STEP 4
現状とゴールの距離
現状と⽬指すゴールへの距離
が遠いのはあたり前なので、
それは気にしない。
距離を測るには「現在、どの
地点にいるのか」を認識する
しかありません。
そのため、AsIs分析の密度を
特に重要視しています。
Slide 13
Slide 13 text
「業務インフラ」という視点を持とう
13
業務を運営する環境・組織体制・業務プロセス
などを包括した「働き⽅」のベースとなるもの
ۀΠϯϑϥ
組織
構成
業務
内容
IT
環境
ۀΠϯϑϥ
組織構成
各業務に対して、どんな組織・
チームで構成されているのか。
業務内容
業務の開始から終了まで、どんな
作業を⽇々⾏っているのか
IT環境
業務を実⾏する為の道具として、
どんなITが存在しているのか
この３つの観点で整理しないと、
現状分析の密度が薄くなります。
そうすると、間違った課題設定
をしてしまうリスクが⾼くなる。
Slide 14
Slide 14 text
「業務インフラ」現状分析で⾏うこと
14
名称 作業内容
ビジネスモデルの整理 貴社に新規顧客が出来てから請求・回収に⾄るまでの流れを整理します。
業務フロー作成
顧客・⾃社・パートナー(外注・発注先)の3つの登場⼈物を元に、貴社
の業務プロセスの全体像をA4ヨコ1枚で整理します。
作業⼀覧精査
業務は複数の作業で構成されているので、誰がどの順番でどんな作業を
⾏っているかを整理します。
現⾏ITシステム精査 業務を⾏うのに利⽤しているITを列挙して整理します。
利⽤帳票精査
帳票は業務を写す鏡です。業務を回すための通常業務で使⽤する帳票、
管理者が状況を把握するために管理⽤途で使⽤する帳票があります。
1つの業務は複数の作業で構成されている。その構造を可視化する。
1
ポイント
ビジネスモデルを理解しないと、業務の⽬的が正しく理解できない。
2
Slide 15
Slide 15 text
ビジネスモデルの整理と業務フロー
15
横軸に業務の流れ、縦軸に登場⼈物のスイムレーンで整理
受注 契約 作業依頼 施⼯
顧
客
⾃
社
取
引
先
業務内容
Slide 16
Slide 16 text
業務フローを書くポイント
16
n A4ヨコ1枚程度に収める粒度で書くこと。全体を⾒たいので。
n 登場⼈物は「顧客」「⾃社」「取引先(発注先)」の3つです。仕事の流れ
と⼈の流れを紐付けて、どんなビジネスをどうやって回しているのかを
知ることが⽬的です。
n 図解系は俯瞰するために書くものなので「粒度」が重要です。
n ⾃社業務を書く時には「ロールの違う他部署・他⼈に受け渡すまで」の
範囲を1つの業務内容としてまとめるとわかりやすいです。
n ⾃社の中で複数のロール(営業と総務等)があり、仕事の受渡が発⽣するの
であれば、⾃社というレーンを複数に分けて書きます。
n ワークフロー(承認経路)は書かないでください。理由は後述します。
n 更に細かいフローが書きたい場合は、⼤分類・中分類という格好で粒度
を揃えて整理してください。まずは、顧客を踏まえた⼤分類からです。
Slide 17
Slide 17 text
ワークフロー(承認経路)の整理
17
ਃ
ワークフローは業務フローではなく、表で整理する
ਃ
申請者 確認A 確認B
ਃ
決裁
ਃ
ࠩ ࠩ ࠩ
ü 申請と差戻の流れを図⽰しても
意味がない。
ü どの条件でどういう経路が存在
するかを⽰す必要がある。
ü ワークフローは条件分岐なので
条件を⽰すには表形式がベスト。
区分 申請者 申請者の部⾨⻑ 執⾏役員 社⻑
Aパターン ○ ○
Bパターン ○ ○ ○
Cパターン ○ ○ ○ ○
n 条件によってフローが異なるものは、表形式で整理するとスッキリします。
͜Ε͕
ਖ਼ղʂ
Slide 18
Slide 18 text
業務フローの限界(１)
18
n 業務フローは業務を俯瞰するために書くと前述しました。
n フローチャート系の成果物で「書き切る」ことをする必要はありません。
細かすぎて伝わらなくなるからです。
n 裏を返すと、俯瞰するためには「複数の作業をまとめて、１つの業務と
して表現する」というグルーピングが必要になります。
n グルーピングすることで⾒えなくなった複数の作業を表現できないので、
正確さにはどうしても⽋けます。
n これらの限界を埋めるため、業務フローだけではなく、先程のワークフ
ローの条件整理であるとか、業務を構成する作業の⼀覧を別表で整理を
⾏うなど、現状分析をより正確に⾏う⼯夫をする必要があります。
書ききれない業務/作業が出てきてしまう
Slide 19
Slide 19 text
業務フローの限界(２)
19
⽇常的な業務しか表現することが出来ない
n 業務フローで表現できるのは⽇常業務です。会社を運営するため、毎⽇
のように⾏う必要がある、ある⼀定のやり⽅に沿って⾏われるものです。
n ⽇常的に⾏わず、⼿を動かせば良いというものでもない業務があります。
それを管理業務と当⽅では呼んでいます。
n わかりやすいのが数字の分析です。得意先からどれぐらい受注があった
のか、どの商品が出ているか、予約状況はどうなっているか等です。
n 現状がどうなっていて、今度どういう⾏動を次に取るべきかの舵取りを
⾏う管理業務は、業務フローで表現することは出来ません。
n 管理業務の場合、⼤抵その管理を⾏うためのドキュメントや帳票が存在
します。経営層・管理層へのヒアリングを⾏う際には忘れずにチェック。
Slide 20
Slide 20 text
業務フローの限界(３)
20
どの業務でどんな問題があるか表現できない
n 業務フローを眺めても、どんな業務でどんな問題があるかは精査できま
せん。経路が複雑であるとか、ここだけボリュームが⼤きいなどです。
n 業務上で発⽣する問題を可視化するには、作業レベルにブレイクダウン
して整理する他に⽅法がありません。
n また、業務運営上の問題は、個⼈の能⼒の優劣が問題ではなく、業務を
⾏う仕組みの上に発⽣する構造的な問題です。誰がやってもこのやり⽅
では同じ事を繰り返すよね、という所を⾒つけることが重要です。
n 課題の可視化については王道は有りません。ひたすらリストアップして、
同じものはまとめて、どこを直せば変わるのかを仮説検証するのみ。
n 業務フローで表現できる業務には限界があるので、注意しましょう。
Slide 21
Slide 21 text
作業⼀覧と現⾏ITシステム調査
21
業務 作業名 作業内容 IT
⾒積
1. ⾒積依頼
お客様より⾒積り依頼をもらう場合と、
年間契約等で定期的に再⾒積を出す場
合がある。
SalesForce
2. 商談実施
⾒積提⽰後、顧客担当者と⾃社の営業
担当者と商談する。
3. ⾒積作成
商談内容や依頼内容を精査し、⾒積を
作成する
4. ⾒積承認
この内容で提⽰してよいか営業担当者
に確認を取る。⾦額によっては決裁者
に確認を取る。
5. ⾒積提⽰ 先⽅に⾒積書を送付し、提⽰を⾏う。
6. 受注判定
ご発注頂けたら受注、そうでなければ
失注となる。新規顧客の受注の場合は、
顧客管理システムと販売管理システム
に受注を登録する。
顧客管理(Access)
販売管理(OBIC)
業務を作業に分解、使っているITを列挙する
Slide 22
Slide 22 text
作業⼀覧と現⾏ITシステム調査( 2 )
22
n 業務を⼤分類にして、作業内容を時系列にまとめて精査します。
n ワークフローについては、承認プロセスの有無があることだけ記載します。
詳細は前述したワークフロー条件分岐をまとめた表で確認します。
n 「現⾏ITシステム」の範疇に、Excelも含まれます。何かしらプログラム
が実装され、そこにデータを⼊⼒して業務を⾏っているソフトウェアのこ
とを「現⾏ITシステム」と呼んでいます。
n 現⾏ITシステムの操作を順を追って現場の⽅に操作して頂き、利⽤⽤途を
ヒアリングしましょう。マニュアルやスクリーンショットだけでは、限界
があります。
n 操作感(Webアプリとデスクトップアプリでは操作性が違う)も合わせて、
確認しておきましょう。⼿順が1つ増えるだけで、ユーザーはものすごく
抵抗を感じます。
Slide 23
Slide 23 text
利⽤帳票、ドキュメントの精査
23
n ⾒積書、契約書、発注書、請求書、在庫表・・そういった業務運営上必要
なドキュメントのことを「帳票」と⾔っています。
n 帳票には顧客や取引先に提出するための帳票と、⾃分達が業務を管理する
ために使う帳票があります。
n 帳票で⾒る観点は、出⼒項⽬と出⼒内容に加⼯・集計があるかどうかです。
個々にある項⽬は最低限出せるように(登録・編集できる)しなくてはなり
ません。
n 加⼯があるというのは、⼊⼒内容をそのまま出⼒したものではないデータ
がある場合です。最も多いのは集計されたデータが帳票にでているケース。
n 要件定義をやるとなった時に問題になりますが、帳票は出⼒される内容、
レイアウト、形式によって、実装難易度や⼯数がかなり違います。
n 何気ない会議資料、実は以外とすごく⼿間がかかって作られていることも。
Slide 24
Slide 24 text
業務運営上の問題＝「業務ストレス」
24
n 現状が⾒えてくると、次は何をどうしたいかの検討へ移ります。
n 多かれ少なかれ、下記のような問題を抱えています。
ü 「やり⽅が⾮効率」
ü 「特定の個⼈、もしくは部署の業務負荷が⾼い」
ü 「欲しい情報が取れない」
ü 「兼務や割り込みが多くて落ち着いて仕事ができない」
ü 「⽣産性が上がらない」
ü 「属⼈性の⾼さがボトルネックになっている」
ü 「何をどういじればよいのかわからんシステムやExcelがある」
これらは「業務ストレス」と⾔うべきもの
Slide 25
Slide 25 text
業務ストレスとは何か
25
n 組織での働き⽅に起因して発⽣する「不満・不便・不安・⾮効率」などの
不健康な負担が発⽣している状態を、業務ストレスと呼んでいます。
n 業務ストレスの発⽣原因は、業務インフラにあります。
n 基盤となっている業務運営のやり⽅があって、そのやり⽅を踏襲する以上
は、誰がやっても同じストレスが発⽣するはずです。
n IT企画の⽬的は、業務ストレスを解消する業務インフラの改善です。この
ストレスがあることを認識するのが、現状分析の⼤きな⽬的です。
n 「御社の課題はなんですか」という問いに正確に答えるのは本当に難しい
ので、「どうなればハッピーなのか」「何から解放されたいのか」という
視点で考えると良いです。
業務ストレスを可能な限りなくしていこう
Slide 26
Slide 26 text
業務ストレス４⼤分類
26
名称 内容
ߴ͍ෛՙ ある業務において、特定の個⼈・部署の作業量がとても多い。
յΕͨڮ 業務の受け渡しがうまく出来ずに、様々な⼿間が発⽣している。
ଐਓԽ どうやって作業を⾏っているのか、他⼈が⾒ても判断ができない。
࣫ࠇͷҋ 欲しい情報が取れない or 精度が低いので、経営判断を正しく⾏えない。
最も解放されたいストレスは、何ですか？
n 中⼩企業で多いのは属⼈化の解消です。ただ、問題が根深いのも属⼈化です。
n メンテナンスできないITがあったり、能⼒が⾼いゆえに他の⼈を育ててフォロー
に回るまで時間がかかるなどで、やりたくても踏ん切りがつかない事が多い。
n 属⼈化と⾼負荷は、だいたい⽐例します。属⼈化が⾼い＝負荷が⾼いです。
n 「壊れた橋」によくあるのが、⼆重⼊⼒やExcelによる帳票作成などです。
Slide 27
Slide 27 text
「未知の良さ」を⾔葉にしよう
27
未知の良さを、20⽂字程度の⾔葉にしよう
わからない
わかっている
⼿に⼊れたい
⼿放したい
既知の問題
未知の良さ
漠然とした
不安／不満
Slide 28
Slide 28 text
コンセプトワークで未来に旗を⽴てる
28
n 現状分析を⾏い、⾃社を取り巻く業務インフラがどうなっていか
を整理します。
n 業務インフラの整理が終わると、「解放されたい業務ストレス」
が⾔葉にできるようになります。
n 解放されるためには、どうなっていたらいいのかをイメージして
「このITで⽬指すのはこういう未来だ」という旗を⽴てましょう。
それがコンセプトワークのゴールです。
n コンセプトワークは「これを無くしたら意味がない」という企画
の⽴脚点を作るものでもあります。
n このフェーズが⼀番みなさんが⼤変で、重要なフェーズです！
Slide 29
Slide 29 text
29
構想⽴案
Slide 30
Slide 30 text
構想⽴案はWHATを決めるフェーズ
30
8):
8)"5
)08
どんな業務上の課題があって、どういう解決をしたいのか
どういうITシステムがあれば、それが達成できるのか
どうやってそのITシステムを⼿に⼊れ、運⽤するのか
n 構想⽴案は「どういうITがあればいいのか」を⾒定めるフェーズになります。
n 簡単に⾔えば「業務のやり⽅をこう変えて良くしたい」→「こういうやり⽅を構築
する必要がある」→「それを担保するためのITに必要なのはこれ」です。
n システムに求める要求を整理して、RFPと元になる情報をまとめ上げるのがゴール。
Slide 31
Slide 31 text
オペレーションの変⾰を実現しよう
31
企業経営
事業の成⻑
ビジネスモデル
の変⾰
オペレーション
の変⾰
企業を経営する⽬的は、会社を存続させること。
会社の存続させるために、事業を変⾰して成⻑
させていく継続的な取り組みが必要。
事業が成⻑するためには、継続的にビジネスモ
デルを⾒直して、改善・変⾰することが不可⽋。
ビジネスモデルの変⾰をするには、現場のオペ
レーションを変えなければならない。
Slide 32
Slide 32 text
あるべき業務をデザインしよう
32
業務改善の鉄板「ECRSの原則」を活⽤しよう
Eliminate
(なくしてみる)
Combine
(まとめてみる)
Rearrange
(交換してみる)
Simplify
(簡単にする)
不要な作業をやめる １つにまとめてみる ワークフローの改善 作業を簡略化する
n 最も単純で効果が出るのはなくすことなので、まず無くせるかどうか(縦割りで同じ事を
違う部署がやっていないか)を検討するのが良いでしょう。Eから始めます。
n 次に、CRSの内容に移ります。ITが最も効果を発揮するのは「Combine」です。⼿作業
でやっている内容をプログラムにやらせることで、作業内容が⼀気に集約化されます。
また、複雑な⼿順を簡素化する(Simplify)ことにもなります。
Slide 33
Slide 33 text
ユーザーストーリーマッピング
33
受注 出荷 納品
業務の流れ
作業内容
必要機能
ü 在庫確認
ü ⽋品連絡
ü 注残確認
ü 取置残管理
ü 送料計算
ü 出荷依頼
ü 出荷データの
取込
ü 在庫引当
ü 売上登録
ü 伝票起票
ü 返品対応
ü 不良品対応
ü 売上集計表の
作成
ü 注残管理
ü 取置管理
ü 委託倉庫から
の送料計算
ü 委託倉庫へ出
荷依頼を⾏う
ü 出荷後、出荷
データを取り
込めて、出荷
処理と同時に
売上登録する
ü ⾚伝⼊⼒時は
⾃動的にマイ
ナス計算
ü 年指定により
12ヶ⽉単位の
商品別売上集
計ができる
ユーザーが取る⾏動に、最適な機能を導き出す
n 横軸に業務の流れを描き、作業内容を⽰す付箋と、機能を⽰す付箋を⽤意します。
n この作業内容をこういう機能を使って、簡略化・集約できると価値が出るのでは、
というアイデアを出すためのものです。ポストイットの数だけ強くなれるよ。
Slide 34
Slide 34 text
アイデア整理マトリックス
34
インパクトの⼤きさと、所要時間で分けて整理
効果が⼤きい
効果が⼩さい
時間がかかる
すぐできそう
やらなくてもよい
ものがあればここ
ちょっとした改善
だけど、改善後の
効果が⽬に⾒える
もの
やりきったら最⾼
だけども、⼀筋縄
ではいかないもの
やりきっても何の
メリットもない
Slide 35
Slide 35 text
要求事項を抽出し、優先順位をつける
35
n 業務改善アイデアは業務単位でグルーピングすると整理が楽です。
n アイデアに優先順位をつけて、何をどの順番で実現するのかを考えます。
そのために、どういった機能を持ったITがあれば良いのかを整理します。
n 必要な機能の抽出を⾏うフェーズに⼊る前に、IT企画の経験があるヒト
にサポートしてもらうのがベストです。
n サポートに⼊る意味は、「ITでできること」の引き出しの数が違うのと、
コスト(難易度や⼯数)の算出がより正確にできるからです。
n 全ての機能を実装するのは困難ですし、優先順位をつけないとシステム
で達成したい成果もブレます。
n システム要求を出して優先順位を設定したら、RFPの⼟台となる企画書
をまとめる作業に⼊りましょう。まず、まとめましょう。
Slide 36
Slide 36 text
ITで業務改善するためのポイント(１)
36
業務を簡略化する＝ルール化できる場所を探す
n ⼈間がやっている内容をプログラムにやらせるのが、IT活⽤ならではの
業務改善のポイントです。
n 顧客への報告書作成業務などで、⼊⼒した内容をコピペで報告書に転記
するのではなく、初めから報告書をテンプレート化して、ボタンを押す
と出⼒できるようにする等です。
n 同じく管理業務等で使う数字の作成なども、ITが得意な分野です。
n 業務内容を簡素化するには「ヒトが⼊⼒しないとダメな作業」と「⼊⼒
された後は、ルール化すればプログラムにより代⾏できる作業」の２つ
に分けるとわかりやすいです。
n ITは空気を読まないので「この場合は、こうする」と決めて、ルールを
設定しないと効果が出ません。業務の「標準化」が必要です。
Slide 37
Slide 37 text
ITで業務改善するためのポイント(２)
37
どこでも、どの端末でも、操作ができるように
n もう１つあるのは、モバイル端末の活⽤を考えること。
n メールやファイル閲覧等は可能だが、スマホで⼊⼒作業ができないので
パソコンを持ち歩くケースはまだまだ多い。
n やることは変わらないが、「スマホで可能になるだけで良い」という
業務は結構あります。その代わりセキュリティの担保が必須です。
n 特に清掃や施⼯など、現場に⾏って作業をしなければならず、作業それ
⾃体が売上にダイレクトに跳ね返る業種では、モバイル活⽤が有効。
n 「その場でお客様が⽬の前にいる状況で何をしたいのか」という観点で
整理すると、良いアイデアが湧いてくるはずです。
Slide 38
Slide 38 text
ITで業務改善するためのポイント(３)
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 運⽤⼿順が複雑になってしまうなら、その案はやばいと思うべき。
Slide 39
Slide 39 text
追体験をしてみよう
39
n 「業務(ドメイン)知識」と呼ばれるものがあり、お客さんがどうやって
業務を回しているか、そこでどんなやり取りがされているかを複合的に
表現する⾔葉です。
n 現場で起こっている課題を抽出して抽象化するには、発⽣する諸問題を
理解して構造化する訓練が必要になります。
n 「業務がわかるSEがいない」みたいな話の9割は、その抽象化ができて
いないから発⽣すると思います。はじめからわかる⼈はいないのにね。
n 業務知識のキャッチアップは、追体験するしかないと考えています。
n 追いかけてユーザーの⽴場に⽴って同じことを体験することをイメージ
し、ロールプレイングをします。
n 映像を作る時に「絵コンテ」と呼ばれる映像の設計書に該当するドキュ
メントがあります。今でいうと、ストーリーボードってやつ。あれを、
作ってみると頭に⼊りますよ。
Slide 40
Slide 40 text
RFP(提案依頼書)を煮詰めていく
40
項⽬ 内容
システム化の⽬的 なぜ、このシステムが欲しいのかを、コンセプトワークから導く
現状の課題
業務フロー・作業⼀覧・業務ストレス精査などから、現状「変えたいが
出来ていない」ことをまとめる。
変⾰後のイメージ
システムによって、誰がどんな動きができて、どういう情報が⼿に⼊り、
どんなメリットを得たいのかをまとめます。箇条書きではなく、図解が
望ましい。
機能要件
業務単位で「この機能は絶対にないと困る」というものを書き出す。
理想は、画⾯遷移と業務内容がまとまったもの。
⾮機能要件 システム構成、運⽤体制、セキュリティ、稼働時間(SLA)など。
データ移⾏ 必要であれば、どのデータを移⾏したいのかを記載する。
スケジュール システム稼働をいつから⾏いたいかを明記する。
今まで検討してきたことを企画書に落とし込もう
n RFPを受けて、開発会社は「どうやって作るのか」を決める要件定義という作業
を⾏います。RFPが雑だと、要件定義の⼯数が膨れ上がり、リスクが拡⼤します。
n 企画書を作ったら、変⾰後のイメージを確かめる(仮説検証)するために、簡易的
な試作品で検証するのがベストです。
Slide 41
Slide 41 text
RFP(提案要求)と要件定義の乖離
41
RFP 要件定義
IT企画がない場合
「要望に合わせたシステムを描く」のは難しく、
コミニケーションコスト・リスクが伴う。
この
ギャップ
がリスク
RFP 要件定義
IT企画をキッチリ⾏う
低リスク
提案依頼と要件定義に乖離
があればあるほど、導⼊を
する側のリスクが⾼まる。
要望に合わせた、不定形の
成果物を作るコミュニケー
ション・コストがそのまま
価格に転嫁されます。
IT企画をキッチリ⾏えば、
リスクが下がり、コストも
下がります。IT活⽤のノウ
ハウも御社に残ります。
Slide 42
Slide 42 text
42
仮説検証(PoC)
Slide 43
Slide 43 text
仮説検証(PoC)
43
必要な機能を実装したら、
こんなイメージになる。
これが本当に必要なのか、
ユーザーに確認しよう。
仕様を聞いても使い⽅が
イメージできないと良し
悪しは判断できない。
試作品があると助かる。
Ϣʔβʔ
IT企画者
試作品を作る フィードバック
試作品(プロトタイピング)を元に検証を⾏う
Slide 44
Slide 44 text
仮説検証をやらないとこうなりやすい
44
システム開発が始まったら、後戻りできない
先に仕様を決めないと、
何も出来ません
作るための資料作りが先になり、
出来上がるシステムが後になる
։ൃձࣾ
ITシステムのイメージが
⾒えにくいけど、⼤丈夫
かな...？
͓٬༷
お待たせしました。
システムをご覧下さい。
։ൃձࣾ
このシステムでは業務が
すごくやりにくい…
お⾦を払って不便なもの
を買うなんて…
͓٬༷
何ヶ⽉後に
システムが
出来る
Slide 45
Slide 45 text
システム導⼊＝注⽂住宅を建てる
45
n 注⽂住宅の難しい点は、作る前にイメージを固める必要がある点。
契約時にどんな家が⽴つかは平⾯図やパース等で判断します。
n システム導⼊も同じ事です。どんなITが⼿に⼊るかは、図⾯に該当
する仕様書、パースに該当する試作品で判断するしかありません。
n 家ができてから「こんな家に住みたいとは⾔っていない。」は無理
です。本番運⽤が始まったら、元には戻れません。
n 注⽂住宅の場合で特に気をつけるのは、⽇々の⽣活をイメージして
ライフスタイルに最適な動線を描けているか、にあるそうです。
n システム導⼊においても、⽇々の作業を、このシステムの操作性、
実装された機能、出⼒できるデータや帳票を活⽤して、⽇常業務を
運営することができるか、を検証します。
n 同じ業種・業態でも、業務インフラが違えば課題が違います。
Slide 46
Slide 46 text
試作品とはどういうものか
46
画⾯イメージを作り、画⾯と画⾯をつなげよう
Slide 47
Slide 47 text
試作品はHTMLプロトタイプがベスト
47
n SaaSでもパッケージでもなんでも、ソフトウェアは操作してみないと
どういうものだか評価できません。
n プロトタイプは紙ベースではダメです。画⾯イメージを並べられても、
ユーザーはまず「⾃分ごと」として捉えてくれません。
n 要件定義にかける想い(丁寧にしっかりやって成功させよう)に対して
温度差があります。ITサイドが「10」に対してユーザーは「1」です。
n HTMLの試作品には、画⾯イメージ・遷移はもちろんのこと、データ
もなるべくそれっぽいものをダミーで埋めておきます。⽇々の作業を
イメージしてもらうためです。
n KintoneやPleasanterのようなPaaSを使うのもアリかもしれませんが、
PaaSの制約を超える要件が出てくると・・・悩みどころ。
n HTMLプロトタイプをいい感じに作れるツール、常に募集中。
Slide 48
Slide 48 text
試作品で作るのは⼊⼒画⾯数個でよい
48
n HTMLプロトタイプで作るのは「⼊⼒画⾯」です。マスタメンテでは
なく、⾒積や出荷といった、業務プロセスをになう業務が対象です。
n 修正依頼が最も多いのは、⼊⼒画⾯の操作性、表⽰項⽬、補助機能の
追加等です。最も多く操作し、最も時間がかかるのが、⼊⼒画⾯への
操作だからです。
n 補助機能とは、サジェスト・キーイベント・⼦画⾯連携・ajaxなどに
よる画⾯の要素の更新・・・そういったものを指します。
n 「こいつは重たいな」という画⾯の特徴としては、項⽬が多い、1つの
画⾯に⾊んな情報が盛り込まれている、レイアウトが複雑などです。
n 要件定義フェーズでやることじゃないかって話かもしれないですが、
このステップをユーザー側でやるのと、業者が主導になってやるのは
⼤きな違いがあります。得られる経験値が、絶対に違います。
Slide 49
Slide 49 text
49
要件定義
Slide 50
Slide 50 text
要件定義はHOWを決めるフェーズ
50
8):
8)"5
)08
どんな業務上の課題があって、どういう解決をしたいのか
どういうITシステムがあれば、それが達成できるのか
n 要件定義は「どうやってITシステムを⼿に⼊れるか」を決めるフェーズになります。
n システムをどんな画⾯で操作して、操作によってどんなアクションが実⾏されて、
どういうデータが作成・出⼒できたら良いのかを決めるのが、要件定義の⽬的です。
n また、システムの稼働環境・保守運⽤体制などもここで決めます。
どうやってそのITシステムを⼿に⼊れ、運⽤するのか
Slide 51
Slide 51 text
システムを⼿に⼊れる4つの⼿段
51
⼿段は４つあり、⼀⻑⼀短があります。
⼿段 概要 メリット・デメリット
オーダーメイド
開発会社に発注して、ゼロから作って
もらう。
最も⾃由度が⾼く独⾃性のあるシス
テムが作れるが、期間も⾦額もリス
クも最も⾼く、継続的改善は困難。
DIY(内製) ⾃社の⼈員で作り上げる。
⾃由度・継続的な改修が可能になる
が、属⼈化は避けられない。内製を
担当した⼈材の退職リスクが⾼い。
既製品を使う
パッケージやSaaSなどを使って、⽤意
されている範囲で⼯夫して使う。
⾦額・速度・リスクが最も⼩さいが、
既製品なので「業務に合わない」と
運⽤が根付かない。
既存ITの改修
既に動いているシステム等を改修して、
機能追加する
ドキュメント等が残っており、運⽤
体制が構築できているなら問題ない
が、何を変えたらわからないような
場合は、改修では済まなくなる。
n 既製品を使う場合は、要件定義を⾏わないこともあります。
n それ以外の選択肢を取る場合、次ページ以降の要件定義⼯程が必要です。
Slide 52
Slide 52 text
要件定義フェーズの主な成果物
52
成果物名称 作成⽬的
画⾯遷移図 利⽤するシステムの画⾯遷移を定義したもの
画⾯仕様書
各々の画⾯でどんな情報を⼊⼒・出⼒するかを決めたもの
画⾯イベント(クリック・キー操作)などもあるなら定義する
ER図、DDL
データベースの設計図(ER図)及び、実際にDBを構築するために必要なプ
ログラム記述 (DDL)
機能定義書
ユーザーのアクションに沿って、どんな処理を実装しなければならない
のかを記述したもの。
データ移⾏
マスタデータCSV取り込みでよいのか、トランザクション系のデータも
含めるのかで、⼀切不要なのか。それにより、⼯数がえらい違います。
バッチ仕様書
⽇次・週次・⽉次・年次等、スケジュール管理によって定期的に実⾏す
る必要があるプログラムがある場合、その内容を整理します。
インフラ構築
OS・サーバ・ミドルウェア等のソフトウェア構成、オンプレ・クラウド
等の稼働環境、監視体制、セキュリティ要件、SLAなど。
どんなシステムを作るのか / どう運⽤するのか
Slide 53
Slide 53 text
要件定義が終わっても道半ば
53
要望→要求→要件が前半戦、開発以降が後半戦
要望 要求 要件
UI データ 機能
開発 テスト 稼働
システム稼働までの流れ
8): 8)"5 )08
n 要望→要求→要件に落とし込むまで、⾮常に多くの中間成果物が必要です。
n それでも、まだ道半ばです。最も時間がかかる「開発」が待っています。
n スポーツに例えるとラグビーのようなものです。
Slide 54
Slide 54 text
要件定義はUI、データ、機能の３つ
54
どんなデータを、どんな画⾯で、どう操作する？
ü システムへの要求事項
ü 機能⼀覧
ü 帳票⼀覧 etc..
要件定義の流れ
処理A
?
処理C
処理D
処理B
顧客 ユーザ
注⽂ 予約
売上 請求
UI(画⾯) 機能 データ
n 検討する⼿順は 「どんなデータを、どの画⾯で、どう操作する」です。
n UIデザインをする前に、システムがどんなデータを扱おうとしているのか、そこを
最初に整理します。「データモデリング」と⾔われる作業です。
n データモデリングができるようになると、要件定義が楽しくなります。
Slide 55
Slide 55 text
ITができるのは「データ操作」だけ
55
データの構造・流れ・作り⽅を変え、業務を変える
n ほぼ全ての業務は、「データのやり取り」を⾏います。
n ⾒積データ、受注データ、契約データ、売上データ、出荷データ、請求
データ、⼊⾦データ、顧客データ、商品データ・・・キリがない(笑)
n そういうデータを作成・参照・更新・取消などをしながら、データを必要
とする⽅々がコミュニケーションを取って、業務を回しています。
n ITができるのは「データの操作」だけですが、「業務でやり取りされる
データの流れや構造を変えて、⼈の動きを変える」ことができます。
n 誰がどんな仕事をしようと、データの構造は変わらない。誰がやっても、
同じ性質のデータが出来ます。操作するデータを変えれば、仕事のやり⽅
も連動して変わります。
Slide 56
Slide 56 text
データモデリング (１）
56
システム化対象となる業務の作業内容を整理する
顧
客
⾃
社
問い
合わせ
詳細
確認
プラン
⼀覧
予約
⼊⼒
ホテル予約(例)
予約
完了
予約
確認
n データモデリングをする場合は、業務単位ではなく作業単位で精査します。
n 作業の流れを順番に整理して、誰がどんなデータをどういう操作を⾏うのかを整理
するのが基本です。
Slide 57
Slide 57 text
データモデリング (２）
57
エンティティとフィールドにデータを整理しよう
n データの持ち主が「エンティティ」で、付属
情報が「フィールド(属性)」です。
n 例えば、「年齢」はフィールドです。35とい
う数字だけでは、その持ち主がわかりません。
n フィールドの持ち主を探していくと、共通の
持ち主が⾒つかります。それがエンティティ
です。
n この例では、予約・プランがエンティティと
なります。
n 申込者は悩ましいところです。後述します。
ü 予約番号
ü 申込者⽒名
ü ⼈数(⼤⼈・⼦供)
ü 住所
ü 年齢
ü 電話番号
ü 宿泊⽇程
ü 利⽤プラン
ü 決済⽅法
ü チェックイン予定時刻
ü 交通⼿段
ü ⾦額
ホテル予約に必要な情報
Slide 58
Slide 58 text
データモデリング (３）
58
エンティティの関連性(依存関係)を整理しよう
予約
プラン
申込者
n エンティティは、それ⾃体が単独で登録・更新等ができる必要があります。
n 例えば、「プラン」は予約と⼀緒にデータが⽣成されるようではダメです。新しい
プランを作るのに、新しい予約が必要になってしまいます。
n このように、「それ⾃体が独⽴して作られるべきデータ」はエンティティです。
n 申込者は予約なしでは成⽴しないので、予約エンティティの属性で良いでしょう。
プラン プランは独⽴したエンティティですが、
予約時には必ず必要になる情報です。
こういった場合、「プランを特定できる
情報」を(例えばプランID等)予約エン
ティティに、保存できるようにします。
そうすれば、予約にあるプランIDから、
プランの詳細を参照でき、プラン⾃体は
独⽴してデータの操作が可能になります。
Slide 59
Slide 59 text
データモデリング (４）
59
業務単位で「ヒト」「モノ」「コト」に分けよう
n 業務を「ヒト」「モノ」「コト」の３つに分けて整理します。
名称 内容 例(ホテルの予約システム)
ώτ そのシステムを利⽤する⼈達
社員(役職・部⾨等）、取引先、得意先、
アルバイト。
Ϟϊ システムで取り扱う資産・サービス プラン・予約・お部屋・設備・カレンダー
ίτ システムを通じて⾏われる⾏動・イベント
予約受付・問い合わせ・オンライン決済・
キャンセル・空き状況を確認する
「モノ」は名詞で「コト」は動詞です。機械的に整理してOK。
1
ポイント
業務内容を「どんな情報を」「どうするか」という話だけです。
2
Slide 60
Slide 60 text
データモデリング (ER図）
60
１〜４を繰り返し、対象となるデータを設計する
Slide 61
Slide 61 text
ER図を⾒れば業務がわかります
61
ER図は業務で作られるデータの全てがあります
n ER図(Entity Relation Diagram)は、業務を正確に写す鏡です。
n エンティティ間の依存関係を⾒れば、どの業務にどんな情報が必要になる
のかがわかります。
n 簡単に⾔えば、外部キーがあれば、外部キーの参照先のデータがなければ
データは作れません。作業の前後関係がそこでわかります。
n また、ER図には、業務の管理⼿法が描かれています。状態を表現したり、
フラグによってデータを識別したり、集計のキーとなる情報があったり、
⾒慣れないエンティティがあったり、等。
n RDBの世界では、テーブル( or ビュー)を増やして対応するか、カラムを
増やして対応するか、その2つしか取れる⼿段がありません。
Slide 62
Slide 62 text
画⾯設計のコツ(１)
62
どのデータを、どの順番で、どう操作するかを描く
プラン⼀覧
プラン名
⾦額
イメージ画像
検索
詳細
プラン詳細 予約⼊⼒ 予約完了
プラン名
⾦額
プラン説明…
カレンダー
お部屋
空き状況検索
予約申込
申込者情報
選択したプラン
⽇程
⼈数
⾦額
予約確定
予約番号
申込者情報
選択したプラン
⾦額
デ
タ
操
作
オペレーションの流れ
n 操作するデータに対して、やりたい操作を設計して、選べるようにしよう。
n どんなデータをどう操作できると、仕事がスムースに実現できるのか。それが重要。
Slide 63
Slide 63 text
画⾯設計のコツ(２)
63
UI⇔ロジック⇔データの受け渡しを意識しよう
UI ロジック(アクション) データ
商品検索
商品画像クリック
再購⼊
商品
注⽂履歴
UIで表⽰される要素は、必ずデータの属性になるはず。
そこをつなげると、ロジック (どんな⼊⼒を、どう処理
して、何を出⼒するか)の設計がシンプルになります。
オブジェクト指向的な設計が素直にできると思います。
ポイント
Slide 64
Slide 64 text
CRUDマトリックス
64
画⾯とデータを2軸で切って、操作内容を書く
n C: Create, R: Read, U: Update, D: Deleteの頭⽂字で「CRUD」です。
n 注⽂を登録するには、得意先と納品先を参照(Read)して、注⽂と明細を登録
(Create)して、商品を参照して選べるようにしつつ、更新(Update)する必要
があることを⽰しています。
n 規模が⼤きいシステムになると、詳細画⾯で⼆桁のRがある場合も。
Slide 65
Slide 65 text
画⾯仕様書の例
65
画⾯レイアウト、項⽬、操作、⼊⼒チェック等
画⾯レイアウト
アクション
画⾯項⽬
・・・
項⽬ ⽂字種 桁数 必須
⽒名(性) 全⾓⽂字 10 ●
⽒名(性) 全⾓⽂字 10 ●
郵便番号(ハイフンなし) 半⾓数字 7 ●
都道府県 ー ー
項⽬ 内容
登録ボタン 押下後、会員情報を登録し、XX画⾯に遷移
n ⼊⼒チェックは次ページに記載があります。
Slide 66
Slide 66 text
⼊⼒値の検査パターン
66
検査パターン 内容
必須チェック データの登録時、未⼊⼒ならエラーとするチェック。最も単純なもの。
⽂字種チェック 全⾓や半⾓、英数字制限、⽂字数や桁数などのチェック。
フォーマットチェック
郵便番号やメールアドレスのように、⼀定の形式に沿った内容以外は
エラーとなるチェック。
⼤⼩チェック
数値の⼤⼩や⽇付の⼤⼩の相関関係をチェックするもの。
開始⽇と終了⽇で、開始⽇は終了⽇より未来の⽇付なら、エラー。
原価よりも安い売価を⼊⼒するとエラー、など。
重複チェック
得意先コードのように、得意先全体で重複があってはならないデータ
において、⼊⼒値に既に同じ値があればエラーとするチェック。
相関チェック
キャンセルというチェックボックスにチェックを⼊れた場合、キャン
セル申請があった⽇付を必ず⼊⼒しなければならない、という種の
チェックです。
業務ルールチェック その会社のルール上、チェックする必要があるものです。
⼊⼒値の検査は、実はかなり奥が深く、⾯倒です
Slide 67
Slide 67 text
機能仕様書を書くべき局⾯
67
67
⼊⼒値が「そのまま格納されない」ケースは必須
n ⾮常に⼤きくわけると、「画⾯からの⼊⼒値がそのままデータとして格納
される場合」と「⼊⼒値を加⼯したり、別のデータを操作する場合」の
２つに分けられます。
n 前者のケースは、機能仕様書は不要です。ユーザーマニュアルがあれば、
それで良いです。
n 後者のケースの代表例が、在庫の引き落としです。注⽂受けたら、在庫を
減らす必要があります。在庫を減らすという作業はユーザーが⾃分で画⾯
操作して⾏うものではないので、そのロジックを実装する必要があります。
n ソースコードはドキュメントではありません。引き継ぎをスムースに⾏う
ためにも、ロジックが⼊っている箇所はその内容を記述しましょう。
Slide 68
Slide 68 text
機能仕様書の例
68
68
ը໘ ॲཧ༰ DB
1. 受注テーブルに1件追加する。
JSONファイルのキー名はテーブルのカラム名
と⼀致している。フォーマットは別紙参照。
受注情報
2. 受注明細にレコードを追加する。
JSONファイルの”detail” キーに、配列で受注
明細情報が格納されている。以降5番まで明細
の１件ずつ同じ処理をすること。
3. 単価履歴にレコードを追加する。
キー 値
Item_id 商品ID
customer_id 顧客ID
gedai 売り単価
price 定価
受注
受注明細
単価履歴
Slide 69
Slide 69 text
ビジネスに貢献する「IT企画」を
69
69
n 事業は時代の流れでなくなることがありますが、業務は会社がある限り、
なくなることはありません。
n 業務インフラをひとつ上のステージに導くのは、業務内容を理解し、それ
をITに落とし込む⽅法論を持っている必要があります。そういったロール
を担う⼈材が、とんでもなく不⾜しています。
n 多くの会社にとって、ITは間接部⾨です。ソフトウェアを作り公開して、
それで売上を上げているわけではないからです。
n IT企画の⾻⼦は、業務で流通するデータの構造を掴み、リノベすることで
「こういう働き⽅ができたら」を実現することです。
n その答えは、その会社の業務の現場で⾒つけるしかありません。開発会社
には⾒つけることは出来ない。それだけは無くさないでください。
n 相談にはいつでも乗ります(腕まくり
Slide 70
Slide 70 text
経営
業務
部⾨
IT
部⾨
IT企画のプロフェッショナルに光を
70
経営、現場、ITの三者の間に⽴ち、つないでいく
そんなロールを担える⼈材がもっと必要です！！
IT企画はこの円を
描くことです
YOU!
Slide 71
Slide 71 text
コーポレート・エンジニアに光を
71
71
n 業務インフラをひとつ上のステージに導くのは、業務内容を理解し、それ
をITに落とし込む⽅法論を持っている必要があります。そういったロール
を担う⼈材が、とんでもなく不⾜しています。
n 「情報システム部⾨のエンジニア兼企画職」とも呼ぶべきロール、コーポ
レート・エンジニアが⽻ばたけるようになってほしい。
n コーポレート・エンジニアがもし専⾨職となるとのであれば、「会社の働
き⽅をデザインしてITで仕組みを作るプロ」になるのではないかと。
n 皆さんの仕事の幅が広がることが、事業会社の働き⽅を変え、⼈の動きや
業績を変え、令和の時代に⽻ばたける会社へと！なるはずです。
n 相談にはいつでも乗ります(腕まくり)
事業はなくなることがあるが、業務はなくならない
Slide 72
Slide 72 text
72
いかがでしたでしょうか？
不確実でふわっとしたコンセプトから地道に
議論を重ね仮説を構築し、その仮説が正しい
ものであるかを、検証する。
検証の結果、ITシステムの全体像が⾒えたら
実装するための⼯程を、地道に設計する。
成功するIT企画が泥臭い作業の集合体である
ことを掴んで頂けたら、幸いです。
Slide 73
Slide 73 text
IT企画のワークショップを企画中です
73
座学では⾝につかないので、体験型がベスト！
n ガイダンス
n IT企画概論(座学)
n 本資料のポイントを中⼼に学んで頂きます。
n 業務分析ワークショップ
n 業務フロー・作業⼀覧の書き起こし
n 業務ストレスの整理、改⾰後の業務フロー等
n システム要求整理ワークショップ
n 機能⼀覧、データモデリング、UI設計まで。
n クロージング
ü ⼈数は5〜6名。
ü 2チームに分かれて⾏います。
ü 半⽇程度で終わります。
ü 2回ほどクローズドで試したい
ので、(実験台)参加者募集。
ü もちろん無料。
ü ⼟⽇のどちらか(多分⼟曜)。
ü 11⽉下旬予定。
Slide 74
Slide 74 text
おわり
74
お読み頂き、ありがとうございました！
Ø 湯本 堅隆(YUMOTO Michitaka)
Ø 株式会社 クオリティスタート
Ø https://quality-start.in
Ø Twitter: @gothedistance
Ø [email protected]
ご相談やご質問等、お気軽にお問い合わせ下さい。