ࣗݾհ n ゆもと みちたか(YUMOTO Michitaka) ü (株) クオリティスタート 代表 ü 1979.11.12 東京都⽣まれ ü 新卒でSIer→事業会社で情シス→独⽴ ü IT企画/プロジェクト⽴ち上げ・SaaSや業務シ ステムの導⼊⽀援、要件定義などが現⾏業務。 ü Java/Python/Swift/C#あたりを少々。 ü プログラミング教育をやっていた時に、←の本 を書きました。3冊刷。圧倒的感謝。 ü 野球⼤好きスワローズファンです。
はじめに 3 n この資料は、事業会社がITシステムを使って業務改善・事業開発の プロジェクトを成功させる確率を上げるために書かれたものです。 n コーポレート・エンジニアの⽅々や、諸般の事情で突然ITプロジェ クトにアサインされた⽅々などに是⾮読んで欲しいと思います。 n 元々はITコンサルタント育成プログラムの⼀環として、新卒並びに 中途採⽤の研修メニューだったものを、ギュッと濃縮しました。 n 思いついた検討すべき改善アイデアが、相談する⼈がいなかったり、 上⼿いやり⽅がわからないので、企画として⽴ち上がらずに消えて しまうケースが多くて「もったいない」と感じています。 n 皆様の事業を⽀えるITを作るための⼀助になる資料とならんことを。
業務フローを書くポイント 16 n A4ヨコ1枚程度に収める粒度で書くこと。全体を⾒たいので。 n 登場⼈物は「顧客」「⾃社」「取引先(発注先)」の3つです。仕事の流れ と⼈の流れを紐付けて、どんなビジネスをどうやって回しているのかを 知ることが⽬的です。 n 図解系は俯瞰するために書くものなので「粒度」が重要です。 n ⾃社業務を書く時には「ロールの違う他部署・他⼈に受け渡すまで」の 範囲を1つの業務内容としてまとめるとわかりやすいです。 n ⾃社の中で複数のロール(営業と総務等)があり、仕事の受渡が発⽣するの であれば、⾃社というレーンを複数に分けて書きます。 n ワークフロー(承認経路)は書かないでください。理由は後述します。 n 更に細かいフローが書きたい場合は、⼤分類・中分類という格好で粒度 を揃えて整理してください。まずは、顧客を踏まえた⼤分類からです。
業務フローの限界(１) 18 n 業務フローは業務を俯瞰するために書くと前述しました。 n フローチャート系の成果物で「書き切る」ことをする必要はありません。 細かすぎて伝わらなくなるからです。 n 裏を返すと、俯瞰するためには「複数の作業をまとめて、１つの業務と して表現する」というグルーピングが必要になります。 n グルーピングすることで⾒えなくなった複数の作業を表現できないので、 正確さにはどうしても⽋けます。 n これらの限界を埋めるため、業務フローだけではなく、先程のワークフ ローの条件整理であるとか、業務を構成する作業の⼀覧を別表で整理を ⾏うなど、現状分析をより正確に⾏う⼯夫をする必要があります。 書ききれない業務/作業が出てきてしまう
業務フローの限界(２) 19 ⽇常的な業務しか表現することが出来ない n 業務フローで表現できるのは⽇常業務です。会社を運営するため、毎⽇ のように⾏う必要がある、ある⼀定のやり⽅に沿って⾏われるものです。 n ⽇常的に⾏わず、⼿を動かせば良いというものでもない業務があります。 それを管理業務と当⽅では呼んでいます。 n わかりやすいのが数字の分析です。得意先からどれぐらい受注があった のか、どの商品が出ているか、予約状況はどうなっているか等です。 n 現状がどうなっていて、今度どういう⾏動を次に取るべきかの舵取りを ⾏う管理業務は、業務フローで表現することは出来ません。 n 管理業務の場合、⼤抵その管理を⾏うためのドキュメントや帳票が存在 します。経営層・管理層へのヒアリングを⾏う際には忘れずにチェック。
業務フローの限界(３) 20 どの業務でどんな問題があるか表現できない n 業務フローを眺めても、どんな業務でどんな問題があるかは精査できま せん。経路が複雑であるとか、ここだけボリュームが⼤きいなどです。 n 業務上で発⽣する問題を可視化するには、作業レベルにブレイクダウン して整理する他に⽅法がありません。 n また、業務運営上の問題は、個⼈の能⼒の優劣が問題ではなく、業務を ⾏う仕組みの上に発⽣する構造的な問題です。誰がやってもこのやり⽅ では同じ事を繰り返すよね、という所を⾒つけることが重要です。 n 課題の可視化については王道は有りません。ひたすらリストアップして、 同じものはまとめて、どこを直せば変わるのかを仮説検証するのみ。 n 業務フローで表現できる業務には限界があるので、注意しましょう。
作業⼀覧と現⾏ITシステム調査( 2 ) 22 n 業務を⼤分類にして、作業内容を時系列にまとめて精査します。 n ワークフローについては、承認プロセスの有無があることだけ記載します。 詳細は前述したワークフロー条件分岐をまとめた表で確認します。 n 「現⾏ITシステム」の範疇に、Excelも含まれます。何かしらプログラム が実装され、そこにデータを⼊⼒して業務を⾏っているソフトウェアのこ とを「現⾏ITシステム」と呼んでいます。 n 現⾏ITシステムの操作を順を追って現場の⽅に操作して頂き、利⽤⽤途を ヒアリングしましょう。マニュアルやスクリーンショットだけでは、限界 があります。 n 操作感(Webアプリとデスクトップアプリでは操作性が違う)も合わせて、 確認しておきましょう。⼿順が1つ増えるだけで、ユーザーはものすごく 抵抗を感じます。
利⽤帳票、ドキュメントの精査 23 n ⾒積書、契約書、発注書、請求書、在庫表・・そういった業務運営上必要 なドキュメントのことを「帳票」と⾔っています。 n 帳票には顧客や取引先に提出するための帳票と、⾃分達が業務を管理する ために使う帳票があります。 n 帳票で⾒る観点は、出⼒項⽬と出⼒内容に加⼯・集計があるかどうかです。 個々にある項⽬は最低限出せるように(登録・編集できる)しなくてはなり ません。 n 加⼯があるというのは、⼊⼒内容をそのまま出⼒したものではないデータ がある場合です。最も多いのは集計されたデータが帳票にでているケース。 n 要件定義をやるとなった時に問題になりますが、帳票は出⼒される内容、 レイアウト、形式によって、実装難易度や⼯数がかなり違います。 n 何気ない会議資料、実は以外とすごく⼿間がかかって作られていることも。
業務運営上の問題＝「業務ストレス」 24 n 現状が⾒えてくると、次は何をどうしたいかの検討へ移ります。 n 多かれ少なかれ、下記のような問題を抱えています。 ü 「やり⽅が⾮効率」 ü 「特定の個⼈、もしくは部署の業務負荷が⾼い」 ü 「欲しい情報が取れない」 ü 「兼務や割り込みが多くて落ち着いて仕事ができない」 ü 「⽣産性が上がらない」 ü 「属⼈性の⾼さがボトルネックになっている」 ü 「何をどういじればよいのかわからんシステムやExcelがある」 これらは「業務ストレス」と⾔うべきもの
業務ストレスとは何か 25 n 組織での働き⽅に起因して発⽣する「不満・不便・不安・⾮効率」などの 不健康な負担が発⽣している状態を、業務ストレスと呼んでいます。 n 業務ストレスの発⽣原因は、業務インフラにあります。 n 基盤となっている業務運営のやり⽅があって、そのやり⽅を踏襲する以上 は、誰がやっても同じストレスが発⽣するはずです。 n IT企画の⽬的は、業務ストレスを解消する業務インフラの改善です。この ストレスがあることを認識するのが、現状分析の⼤きな⽬的です。 n 「御社の課題はなんですか」という問いに正確に答えるのは本当に難しい ので、「どうなればハッピーなのか」「何から解放されたいのか」という 視点で考えると良いです。 業務ストレスを可能な限りなくしていこう
業務ストレス４⼤分類 26 名称 内容 ߴ͍ෛՙ ある業務において、特定の個⼈・部署の作業量がとても多い。 յΕͨڮ 業務の受け渡しがうまく出来ずに、様々な⼿間が発⽣している。 ଐਓԽ どうやって作業を⾏っているのか、他⼈が⾒ても判断ができない。 ࣫ࠇͷҋ 欲しい情報が取れない or 精度が低いので、経営判断を正しく⾏えない。 最も解放されたいストレスは、何ですか？ n 中⼩企業で多いのは属⼈化の解消です。ただ、問題が根深いのも属⼈化です。 n メンテナンスできないITがあったり、能⼒が⾼いゆえに他の⼈を育ててフォロー に回るまで時間がかかるなどで、やりたくても踏ん切りがつかない事が多い。 n 属⼈化と⾼負荷は、だいたい⽐例します。属⼈化が⾼い＝負荷が⾼いです。 n 「壊れた橋」によくあるのが、⼆重⼊⼒やExcelによる帳票作成などです。
コンセプトワークで未来に旗を⽴てる 28 n 現状分析を⾏い、⾃社を取り巻く業務インフラがどうなっていか を整理します。 n 業務インフラの整理が終わると、「解放されたい業務ストレス」 が⾔葉にできるようになります。 n 解放されるためには、どうなっていたらいいのかをイメージして 「このITで⽬指すのはこういう未来だ」という旗を⽴てましょう。 それがコンセプトワークのゴールです。 n コンセプトワークは「これを無くしたら意味がない」という企画 の⽴脚点を作るものでもあります。 n このフェーズが⼀番みなさんが⼤変で、重要なフェーズです！
構想⽴案はWHATを決めるフェーズ 30 8): 8)"5 )08 どんな業務上の課題があって、どういう解決をしたいのか どういうITシステムがあれば、それが達成できるのか どうやってそのITシステムを⼿に⼊れ、運⽤するのか n 構想⽴案は「どういうITがあればいいのか」を⾒定めるフェーズになります。 n 簡単に⾔えば「業務のやり⽅をこう変えて良くしたい」→「こういうやり⽅を構築 する必要がある」→「それを担保するためのITに必要なのはこれ」です。 n システムに求める要求を整理して、RFPと元になる情報をまとめ上げるのがゴール。
ユーザーストーリーマッピング 33 受注 出荷 納品 業務の流れ 作業内容 必要機能 ü 在庫確認 ü ⽋品連絡 ü 注残確認 ü 取置残管理 ü 送料計算 ü 出荷依頼 ü 出荷データの 取込 ü 在庫引当 ü 売上登録 ü 伝票起票 ü 返品対応 ü 不良品対応 ü 売上集計表の 作成 ü 注残管理 ü 取置管理 ü 委託倉庫から の送料計算 ü 委託倉庫へ出 荷依頼を⾏う ü 出荷後、出荷 データを取り 込めて、出荷 処理と同時に 売上登録する ü ⾚伝⼊⼒時は ⾃動的にマイ ナス計算 ü 年指定により 12ヶ⽉単位の 商品別売上集 計ができる ユーザーが取る⾏動に、最適な機能を導き出す n 横軸に業務の流れを描き、作業内容を⽰す付箋と、機能を⽰す付箋を⽤意します。 n この作業内容をこういう機能を使って、簡略化・集約できると価値が出るのでは、 というアイデアを出すためのものです。ポストイットの数だけ強くなれるよ。
要求事項を抽出し、優先順位をつける 35 n 業務改善アイデアは業務単位でグルーピングすると整理が楽です。 n アイデアに優先順位をつけて、何をどの順番で実現するのかを考えます。 そのために、どういった機能を持ったITがあれば良いのかを整理します。 n 必要な機能の抽出を⾏うフェーズに⼊る前に、IT企画の経験があるヒト にサポートしてもらうのがベストです。 n サポートに⼊る意味は、「ITでできること」の引き出しの数が違うのと、 コスト(難易度や⼯数)の算出がより正確にできるからです。 n 全ての機能を実装するのは困難ですし、優先順位をつけないとシステム で達成したい成果もブレます。 n システム要求を出して優先順位を設定したら、RFPの⼟台となる企画書 をまとめる作業に⼊りましょう。まず、まとめましょう。
ITで業務改善するためのポイント(１) 36 業務を簡略化する＝ルール化できる場所を探す n ⼈間がやっている内容をプログラムにやらせるのが、IT活⽤ならではの 業務改善のポイントです。 n 顧客への報告書作成業務などで、⼊⼒した内容をコピペで報告書に転記 するのではなく、初めから報告書をテンプレート化して、ボタンを押す と出⼒できるようにする等です。 n 同じく管理業務等で使う数字の作成なども、ITが得意な分野です。 n 業務内容を簡素化するには「ヒトが⼊⼒しないとダメな作業」と「⼊⼒ された後は、ルール化すればプログラムにより代⾏できる作業」の２つ に分けるとわかりやすいです。 n ITは空気を読まないので「この場合は、こうする」と決めて、ルールを 設定しないと効果が出ません。業務の「標準化」が必要です。
ITで業務改善するためのポイント(２) 37 どこでも、どの端末でも、操作ができるように n もう１つあるのは、モバイル端末の活⽤を考えること。 n メールやファイル閲覧等は可能だが、スマホで⼊⼒作業ができないので パソコンを持ち歩くケースはまだまだ多い。 n やることは変わらないが、「スマホで可能になるだけで良い」という 業務は結構あります。その代わりセキュリティの担保が必須です。 n 特に清掃や施⼯など、現場に⾏って作業をしなければならず、作業それ ⾃体が売上にダイレクトに跳ね返る業種では、モバイル活⽤が有効。 n 「その場でお客様が⽬の前にいる状況で何をしたいのか」という観点で 整理すると、良いアイデアが湧いてくるはずです。
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 運⽤⼿順が複雑になってしまうなら、その案はやばいと思うべき。
追体験をしてみよう 39 n 「業務(ドメイン)知識」と呼ばれるものがあり、お客さんがどうやって 業務を回しているか、そこでどんなやり取りがされているかを複合的に 表現する⾔葉です。 n 現場で起こっている課題を抽出して抽象化するには、発⽣する諸問題を 理解して構造化する訓練が必要になります。 n 「業務がわかるSEがいない」みたいな話の9割は、その抽象化ができて いないから発⽣すると思います。はじめからわかる⼈はいないのにね。 n 業務知識のキャッチアップは、追体験するしかないと考えています。 n 追いかけてユーザーの⽴場に⽴って同じことを体験することをイメージ し、ロールプレイングをします。 n 映像を作る時に「絵コンテ」と呼ばれる映像の設計書に該当するドキュ メントがあります。今でいうと、ストーリーボードってやつ。あれを、 作ってみると頭に⼊りますよ。
システム導⼊＝注⽂住宅を建てる 45 n 注⽂住宅の難しい点は、作る前にイメージを固める必要がある点。 契約時にどんな家が⽴つかは平⾯図やパース等で判断します。 n システム導⼊も同じ事です。どんなITが⼿に⼊るかは、図⾯に該当 する仕様書、パースに該当する試作品で判断するしかありません。 n 家ができてから「こんな家に住みたいとは⾔っていない。」は無理 です。本番運⽤が始まったら、元には戻れません。 n 注⽂住宅の場合で特に気をつけるのは、⽇々の⽣活をイメージして ライフスタイルに最適な動線を描けているか、にあるそうです。 n システム導⼊においても、⽇々の作業を、このシステムの操作性、 実装された機能、出⼒できるデータや帳票を活⽤して、⽇常業務を 運営することができるか、を検証します。 n 同じ業種・業態でも、業務インフラが違えば課題が違います。
試作品はHTMLプロトタイプがベスト 47 n SaaSでもパッケージでもなんでも、ソフトウェアは操作してみないと どういうものだか評価できません。 n プロトタイプは紙ベースではダメです。画⾯イメージを並べられても、 ユーザーはまず「⾃分ごと」として捉えてくれません。 n 要件定義にかける想い(丁寧にしっかりやって成功させよう)に対して 温度差があります。ITサイドが「10」に対してユーザーは「1」です。 n HTMLの試作品には、画⾯イメージ・遷移はもちろんのこと、データ もなるべくそれっぽいものをダミーで埋めておきます。⽇々の作業を イメージしてもらうためです。 n KintoneやPleasanterのようなPaaSを使うのもアリかもしれませんが、 PaaSの制約を超える要件が出てくると・・・悩みどころ。 n HTMLプロトタイプをいい感じに作れるツール、常に募集中。
試作品で作るのは⼊⼒画⾯数個でよい 48 n HTMLプロトタイプで作るのは「⼊⼒画⾯」です。マスタメンテでは なく、⾒積や出荷といった、業務プロセスをになう業務が対象です。 n 修正依頼が最も多いのは、⼊⼒画⾯の操作性、表⽰項⽬、補助機能の 追加等です。最も多く操作し、最も時間がかかるのが、⼊⼒画⾯への 操作だからです。 n 補助機能とは、サジェスト・キーイベント・⼦画⾯連携・ajaxなどに よる画⾯の要素の更新・・・そういったものを指します。 n 「こいつは重たいな」という画⾯の特徴としては、項⽬が多い、1つの 画⾯に⾊んな情報が盛り込まれている、レイアウトが複雑などです。 n 要件定義フェーズでやることじゃないかって話かもしれないですが、 このステップをユーザー側でやるのと、業者が主導になってやるのは ⼤きな違いがあります。得られる経験値が、絶対に違います。
要件定義はHOWを決めるフェーズ 50 8): 8)"5 )08 どんな業務上の課題があって、どういう解決をしたいのか どういうITシステムがあれば、それが達成できるのか n 要件定義は「どうやってITシステムを⼿に⼊れるか」を決めるフェーズになります。 n システムをどんな画⾯で操作して、操作によってどんなアクションが実⾏されて、 どういうデータが作成・出⼒できたら良いのかを決めるのが、要件定義の⽬的です。 n また、システムの稼働環境・保守運⽤体制などもここで決めます。 どうやってそのITシステムを⼿に⼊れ、運⽤するのか
ITができるのは「データ操作」だけ 55 データの構造・流れ・作り⽅を変え、業務を変える n ほぼ全ての業務は、「データのやり取り」を⾏います。 n ⾒積データ、受注データ、契約データ、売上データ、出荷データ、請求 データ、⼊⾦データ、顧客データ、商品データ・・・キリがない(笑) n そういうデータを作成・参照・更新・取消などをしながら、データを必要 とする⽅々がコミュニケーションを取って、業務を回しています。 n ITができるのは「データの操作」だけですが、「業務でやり取りされる データの流れや構造を変えて、⼈の動きを変える」ことができます。 n 誰がどんな仕事をしようと、データの構造は変わらない。誰がやっても、 同じ性質のデータが出来ます。操作するデータを変えれば、仕事のやり⽅ も連動して変わります。
データモデリング (２） 57 エンティティとフィールドにデータを整理しよう n データの持ち主が「エンティティ」で、付属 情報が「フィールド(属性)」です。 n 例えば、「年齢」はフィールドです。35とい う数字だけでは、その持ち主がわかりません。 n フィールドの持ち主を探していくと、共通の 持ち主が⾒つかります。それがエンティティ です。 n この例では、予約・プランがエンティティと なります。 n 申込者は悩ましいところです。後述します。 ü 予約番号 ü 申込者⽒名 ü ⼈数(⼤⼈・⼦供) ü 住所 ü 年齢 ü 電話番号 ü 宿泊⽇程 ü 利⽤プラン ü 決済⽅法 ü チェックイン予定時刻 ü 交通⼿段 ü ⾦額 ホテル予約に必要な情報
ER図を⾒れば業務がわかります 61 ER図は業務で作られるデータの全てがあります n ER図(Entity Relation Diagram)は、業務を正確に写す鏡です。 n エンティティ間の依存関係を⾒れば、どの業務にどんな情報が必要になる のかがわかります。 n 簡単に⾔えば、外部キーがあれば、外部キーの参照先のデータがなければ データは作れません。作業の前後関係がそこでわかります。 n また、ER図には、業務の管理⼿法が描かれています。状態を表現したり、 フラグによってデータを識別したり、集計のキーとなる情報があったり、 ⾒慣れないエンティティがあったり、等。 n RDBの世界では、テーブル( or ビュー)を増やして対応するか、カラムを 増やして対応するか、その2つしか取れる⼿段がありません。
機能仕様書を書くべき局⾯ 67 67 ⼊⼒値が「そのまま格納されない」ケースは必須 n ⾮常に⼤きくわけると、「画⾯からの⼊⼒値がそのままデータとして格納 される場合」と「⼊⼒値を加⼯したり、別のデータを操作する場合」の ２つに分けられます。 n 前者のケースは、機能仕様書は不要です。ユーザーマニュアルがあれば、 それで良いです。 n 後者のケースの代表例が、在庫の引き落としです。注⽂受けたら、在庫を 減らす必要があります。在庫を減らすという作業はユーザーが⾃分で画⾯ 操作して⾏うものではないので、そのロジックを実装する必要があります。 n ソースコードはドキュメントではありません。引き継ぎをスムースに⾏う ためにも、ロジックが⼊っている箇所はその内容を記述しましょう。
ビジネスに貢献する「IT企画」を 69 69 n 事業は時代の流れでなくなることがありますが、業務は会社がある限り、 なくなることはありません。 n 業務インフラをひとつ上のステージに導くのは、業務内容を理解し、それ をITに落とし込む⽅法論を持っている必要があります。そういったロール を担う⼈材が、とんでもなく不⾜しています。 n 多くの会社にとって、ITは間接部⾨です。ソフトウェアを作り公開して、 それで売上を上げているわけではないからです。 n IT企画の⾻⼦は、業務で流通するデータの構造を掴み、リノベすることで 「こういう働き⽅ができたら」を実現することです。 n その答えは、その会社の業務の現場で⾒つけるしかありません。開発会社 には⾒つけることは出来ない。それだけは無くさないでください。 n 相談にはいつでも乗ります(腕まくり
コーポレート・エンジニアに光を 71 71 n 業務インフラをひとつ上のステージに導くのは、業務内容を理解し、それ をITに落とし込む⽅法論を持っている必要があります。そういったロール を担う⼈材が、とんでもなく不⾜しています。 n 「情報システム部⾨のエンジニア兼企画職」とも呼ぶべきロール、コーポ レート・エンジニアが⽻ばたけるようになってほしい。 n コーポレート・エンジニアがもし専⾨職となるとのであれば、「会社の働 き⽅をデザインしてITで仕組みを作るプロ」になるのではないかと。 n 皆さんの仕事の幅が広がることが、事業会社の働き⽅を変え、⼈の動きや 業績を変え、令和の時代に⽻ばたける会社へと！なるはずです。 n 相談にはいつでも乗ります(腕まくり) 事業はなくなることがあるが、業務はなくならない
IT企画のワークショップを企画中です 73 座学では⾝につかないので、体験型がベスト！ n ガイダンス n IT企画概論(座学) n 本資料のポイントを中⼼に学んで頂きます。 n 業務分析ワークショップ n 業務フロー・作業⼀覧の書き起こし n 業務ストレスの整理、改⾰後の業務フロー等 n システム要求整理ワークショップ n 機能⼀覧、データモデリング、UI設計まで。 n クロージング ü ⼈数は5〜6名。 ü 2チームに分かれて⾏います。 ü 半⽇程度で終わります。 ü 2回ほどクローズドで試したい ので、(実験台)参加者募集。 ü もちろん無料。 ü ⼟⽇のどちらか(多分⼟曜)。 ü 11⽉下旬予定。
gothedistance
brainpad_mk
cyberagent_recruit
nozomi
miibio
kuroppe1819
doradora09
.png){kind=avatar}
cuebicventures
arm0020
joaoasrosa
10xinc
scottboms
jnunemaker
thoeni
malarkey
nonsquared
jmmastey
mthomps
robhawkes
deanohume
mongodb
zakiwarfel
reverentgeek