1979.11.12 東京都⽣まれ ü 新卒でSIer→事業会社で情シス→独⽴ ü IT企画/プロジェクト⽴ち上げ・SaaSや業務シ ステムの導⼊⽀援、要件定義などが現⾏業務。 ü Java/Python/Swift/C#あたりを少々。 ü プログラミング教育をやっていた時に、←の本 を書きました。3冊刷。圧倒的感謝。 ü 野球⼤好きスワローズファンです。
中途採⽤の研修メニューだったものを、ギュッと濃縮しました。 n 思いついた検討すべき改善アイデアが、相談する⼈がいなかったり、 上⼿いやり⽅がわからないので、企画として⽴ち上がらずに消えて しまうケースが多くて「もったいない」と感じています。 n 皆様の事業を⽀えるITを作るための⼀助になる資料とならんことを。
n ⾃社業務を書く時には「ロールの違う他部署・他⼈に受け渡すまで」の 範囲を1つの業務内容としてまとめるとわかりやすいです。 n ⾃社の中で複数のロール(営業と総務等)があり、仕事の受渡が発⽣するの であれば、⾃社というレーンを複数に分けて書きます。 n ワークフロー(承認経路)は書かないでください。理由は後述します。 n 更に細かいフローが書きたい場合は、⼤分類・中分類という格好で粒度 を揃えて整理してください。まずは、顧客を踏まえた⼤分類からです。
n グルーピングすることで⾒えなくなった複数の作業を表現できないので、 正確さにはどうしても⽋けます。 n これらの限界を埋めるため、業務フローだけではなく、先程のワークフ ローの条件整理であるとか、業務を構成する作業の⼀覧を別表で整理を ⾏うなど、現状分析をより正確に⾏う⼯夫をする必要があります。 書ききれない業務/作業が出てきてしまう
わかりやすいのが数字の分析です。得意先からどれぐらい受注があった のか、どの商品が出ているか、予約状況はどうなっているか等です。 n 現状がどうなっていて、今度どういう⾏動を次に取るべきかの舵取りを ⾏う管理業務は、業務フローで表現することは出来ません。 n 管理業務の場合、⼤抵その管理を⾏うためのドキュメントや帳票が存在 します。経営層・管理層へのヒアリングを⾏う際には忘れずにチェック。
また、業務運営上の問題は、個⼈の能⼒の優劣が問題ではなく、業務を ⾏う仕組みの上に発⽣する構造的な問題です。誰がやってもこのやり⽅ では同じ事を繰り返すよね、という所を⾒つけることが重要です。 n 課題の可視化については王道は有りません。ひたすらリストアップして、 同じものはまとめて、どこを直せば変わるのかを仮説検証するのみ。 n 業務フローで表現できる業務には限界があるので、注意しましょう。
個々にある項⽬は最低限出せるように(登録・編集できる)しなくてはなり ません。 n 加⼯があるというのは、⼊⼒内容をそのまま出⼒したものではないデータ がある場合です。最も多いのは集計されたデータが帳票にでているケース。 n 要件定義をやるとなった時に問題になりますが、帳票は出⼒される内容、 レイアウト、形式によって、実装難易度や⼯数がかなり違います。 n 何気ない会議資料、実は以外とすごく⼿間がかかって作られていることも。
n IT企画の⽬的は、業務ストレスを解消する業務インフラの改善です。この ストレスがあることを認識するのが、現状分析の⼤きな⽬的です。 n 「御社の課題はなんですか」という問いに正確に答えるのは本当に難しい ので、「どうなればハッピーなのか」「何から解放されたいのか」という 視点で考えると良いです。 業務ストレスを可能な限りなくしていこう
࣫ࠇͷҋ 欲しい情報が取れない or 精度が低いので、経営判断を正しく⾏えない。 最も解放されたいストレスは、何ですか？ n 中⼩企業で多いのは属⼈化の解消です。ただ、問題が根深いのも属⼈化です。 n メンテナンスできないITがあったり、能⼒が⾼いゆえに他の⼈を育ててフォロー に回るまで時間がかかるなどで、やりたくても踏ん切りがつかない事が多い。 n 属⼈化と⾼負荷は、だいたい⽐例します。属⼈化が⾼い＝負荷が⾼いです。 n 「壊れた橋」によくあるのが、⼆重⼊⼒やExcelによる帳票作成などです。
ü ⽋品連絡 ü 注残確認 ü 取置残管理 ü 送料計算 ü 出荷依頼 ü 出荷データの 取込 ü 在庫引当 ü 売上登録 ü 伝票起票 ü 返品対応 ü 不良品対応 ü 売上集計表の 作成 ü 注残管理 ü 取置管理 ü 委託倉庫から の送料計算 ü 委託倉庫へ出 荷依頼を⾏う ü 出荷後、出荷 データを取り 込めて、出荷 処理と同時に 売上登録する ü ⾚伝⼊⼒時は ⾃動的にマイ ナス計算 ü 年指定により 12ヶ⽉単位の 商品別売上集 計ができる ユーザーが取る⾏動に、最適な機能を導き出す n 横軸に業務の流れを描き、作業内容を⽰す付箋と、機能を⽰す付箋を⽤意します。 n この作業内容をこういう機能を使って、簡略化・集約できると価値が出るのでは、 というアイデアを出すためのものです。ポストイットの数だけ強くなれるよ。
n サポートに⼊る意味は、「ITでできること」の引き出しの数が違うのと、 コスト(難易度や⼯数)の算出がより正確にできるからです。 n 全ての機能を実装するのは困難ですし、優先順位をつけないとシステム で達成したい成果もブレます。 n システム要求を出して優先順位を設定したら、RFPの⼟台となる企画書 をまとめる作業に⼊りましょう。まず、まとめましょう。
n 同じく管理業務等で使う数字の作成なども、ITが得意な分野です。 n 業務内容を簡素化するには「ヒトが⼊⼒しないとダメな作業」と「⼊⼒ された後は、ルール化すればプログラムにより代⾏できる作業」の２つ に分けるとわかりやすいです。 n ITは空気を読まないので「この場合は、こうする」と決めて、ルールを 設定しないと効果が出ません。業務の「標準化」が必要です。
業務は結構あります。その代わりセキュリティの担保が必須です。 n 特に清掃や施⼯など、現場に⾏って作業をしなければならず、作業それ ⾃体が売上にダイレクトに跳ね返る業種では、モバイル活⽤が有効。 n 「その場でお客様が⽬の前にいる状況で何をしたいのか」という観点で 整理すると、良いアイデアが湧いてくるはずです。
n やることは減っているのに、できることが増えている n こういった状態を⽬指すには、ヒトが頑張って作業を増やすのではなく ITを使って任せる所は任せるように業務を設計します。 n より少ない労⼒で、より多くのことを⽰す⾔葉が、「Less Is More」 n More and Moreでも、More is Lessでも、Less is Less でも、ダメです。 n 運⽤⼿順が複雑になってしまうなら、その案はやばいと思うべき。
「業務がわかるSEがいない」みたいな話の9割は、その抽象化ができて いないから発⽣すると思います。はじめからわかる⼈はいないのにね。 n 業務知識のキャッチアップは、追体験するしかないと考えています。 n 追いかけてユーザーの⽴場に⽴って同じことを体験することをイメージ し、ロールプレイングをします。 n 映像を作る時に「絵コンテ」と呼ばれる映像の設計書に該当するドキュ メントがあります。今でいうと、ストーリーボードってやつ。あれを、 作ってみると頭に⼊りますよ。
です。本番運⽤が始まったら、元には戻れません。 n 注⽂住宅の場合で特に気をつけるのは、⽇々の⽣活をイメージして ライフスタイルに最適な動線を描けているか、にあるそうです。 n システム導⼊においても、⽇々の作業を、このシステムの操作性、 実装された機能、出⼒できるデータや帳票を活⽤して、⽇常業務を 運営することができるか、を検証します。 n 同じ業種・業態でも、業務インフラが違えば課題が違います。
温度差があります。ITサイドが「10」に対してユーザーは「1」です。 n HTMLの試作品には、画⾯イメージ・遷移はもちろんのこと、データ もなるべくそれっぽいものをダミーで埋めておきます。⽇々の作業を イメージしてもらうためです。 n KintoneやPleasanterのようなPaaSを使うのもアリかもしれませんが、 PaaSの制約を超える要件が出てくると・・・悩みどころ。 n HTMLプロトタイプをいい感じに作れるツール、常に募集中。
補助機能とは、サジェスト・キーイベント・⼦画⾯連携・ajaxなどに よる画⾯の要素の更新・・・そういったものを指します。 n 「こいつは重たいな」という画⾯の特徴としては、項⽬が多い、1つの 画⾯に⾊んな情報が盛り込まれている、レイアウトが複雑などです。 n 要件定義フェーズでやることじゃないかって話かもしれないですが、 このステップをユーザー側でやるのと、業者が主導になってやるのは ⼤きな違いがあります。得られる経験値が、絶対に違います。
とする⽅々がコミュニケーションを取って、業務を回しています。 n ITができるのは「データの操作」だけですが、「業務でやり取りされる データの流れや構造を変えて、⼈の動きを変える」ことができます。 n 誰がどんな仕事をしようと、データの構造は変わらない。誰がやっても、 同じ性質のデータが出来ます。操作するデータを変えれば、仕事のやり⽅ も連動して変わります。
n フィールドの持ち主を探していくと、共通の 持ち主が⾒つかります。それがエンティティ です。 n この例では、予約・プランがエンティティと なります。 n 申込者は悩ましいところです。後述します。 ü 予約番号 ü 申込者⽒名 ü ⼈数(⼤⼈・⼦供) ü 住所 ü 年齢 ü 電話番号 ü 宿泊⽇程 ü 利⽤プラン ü 決済⽅法 ü チェックイン予定時刻 ü 交通⼿段 ü ⾦額 ホテル予約に必要な情報
n 簡単に⾔えば、外部キーがあれば、外部キーの参照先のデータがなければ データは作れません。作業の前後関係がそこでわかります。 n また、ER図には、業務の管理⼿法が描かれています。状態を表現したり、 フラグによってデータを識別したり、集計のキーとなる情報があったり、 ⾒慣れないエンティティがあったり、等。 n RDBの世界では、テーブル( or ビュー)を増やして対応するか、カラムを 増やして対応するか、その2つしか取れる⼿段がありません。
D: Deleteの頭⽂字で「CRUD」です。 n 注⽂を登録するには、得意先と納品先を参照(Read)して、注⽂と明細を登録 (Create)して、商品を参照して選べるようにしつつ、更新(Update)する必要 があることを⽰しています。 n 規模が⼤きいシステムになると、詳細画⾯で⼆桁のRがある場合も。
それで良いです。 n 後者のケースの代表例が、在庫の引き落としです。注⽂受けたら、在庫を 減らす必要があります。在庫を減らすという作業はユーザーが⾃分で画⾯ 操作して⾏うものではないので、そのロジックを実装する必要があります。 n ソースコードはドキュメントではありません。引き継ぎをスムースに⾏う ためにも、ロジックが⼊っている箇所はその内容を記述しましょう。
n 多くの会社にとって、ITは間接部⾨です。ソフトウェアを作り公開して、 それで売上を上げているわけではないからです。 n IT企画の⾻⼦は、業務で流通するデータの構造を掴み、リノベすることで 「こういう働き⽅ができたら」を実現することです。 n その答えは、その会社の業務の現場で⾒つけるしかありません。開発会社 には⾒つけることは出来ない。それだけは無くさないでください。 n 相談にはいつでも乗ります(腕まくり
n コーポレート・エンジニアがもし専⾨職となるとのであれば、「会社の働 き⽅をデザインしてITで仕組みを作るプロ」になるのではないかと。 n 皆さんの仕事の幅が広がることが、事業会社の働き⽅を変え、⼈の動きや 業績を変え、令和の時代に⽻ばたける会社へと！なるはずです。 n 相談にはいつでも乗ります(腕まくり) 事業はなくなることがあるが、業務はなくならない
業務分析ワークショップ n 業務フロー・作業⼀覧の書き起こし n 業務ストレスの整理、改⾰後の業務フロー等 n システム要求整理ワークショップ n 機能⼀覧、データモデリング、UI設計まで。 n クロージング ü ⼈数は5〜6名。 ü 2チームに分かれて⾏います。 ü 半⽇程度で終わります。 ü 2回ほどクローズドで試したい ので、(実験台)参加者募集。 ü もちろん無料。 ü ⼟⽇のどちらか(多分⼟曜)。 ü 11⽉下旬予定。
gothedistance
beerandtech_recruiter
godot
c0rp_mdm
vstandard
beglobal_document
fabrica_com
livesense
jtes
hachi_hiring
botexpress
tokyo_metropolitan_gov_digital_hr
kkosukeee
keathley
jakevdp
jmmastey
kneath
sachag
aleyda
shlominoach
danielanewman
colly
destraynor
jacobian
