前提 l 本セミナーが対象とするのは… l 事業部門でDX推進のミッションを与えられ、これからシステム開発含 めたDX施策を遂行しようとしている方 l システム開発プロジェクトに初めて参画しようとしているNon-ITの方 l DXの文脈におけるシステム開発の目的には以下の2種類があります が、本セミナーでは主に1の文脈に則って説明を進めます 1. 新規サービスの創出 2. 業務プロセス改革 8
DX時代の到来によるシステム開発のあり方の変化 11 l 今までのパターン l 事業部門が企画書を取りまとめ、システムの開発・改修が関わる部分は情報シス テム部門に依頼 l 情報システム部門が事業部門からヒアリングしながら要件を取りまとめ、内製も しくは外部ベンダーへの発注によって開発 l DXの文脈では l IT人材であるか否かに関わらず、情報システム部門を経由せずにシ ステム開発に関与する機会が多くなってきている l 色々な製品の登場によって、Non-ITでもシステム開発にリーチしやすく なっている
最近よく聞く失敗談 l お金をかけた割には思った通りのものができない！ l ちなみに・・・ l IT投資は100万オーダーだと少額な部類に入ります l 1000万, 1億, それ以上の単位のものも一般的にあります l 高額になりがちなITへの投資を有意義な投資にするためには l 何に気をつければ良いのか？何を考えれば良いのか？ l ベンダーに何を伝えれば良いのか？ 12 本セミナーでお伝えしたいこと
どこまで作る？(機能要件) l 最低限どのような機能を用意すれば、実証の目的を達成できる か？ l 検証のために必要な機能については、ベンダーは助言はできても 判断はできません l もしかすると、検証のためだけに必要な機能もあるかもしれない l 必要となる開発コストや開発期間をベンダーに聞きつつ、実証を 完遂できる必要最低限の機能を見定めましょう 18
どこまで作る？(非機能要件) l 非機能要件とは・・・ l 拡張性 l 追加開発・機能拡張のしやすさ l 性能 l 画面表示やデータベース更新等各種処理の速度 l 可用性 l システムの稼働時間 l セキュリティ l 非機能をどこまで充実させるかによって、開発のコストと期間は 大きく変動します l 検証の目的を達成するための最低限の要件を見定め、そのレベル で問題ないか否かを確認しましょう 20
PoCフェーズのスケジュール l 計画・開発・PoCそれぞれで必要な期間を算出します l よくある失敗事例 l 計画の最初の段階で全体の期間を最初に設定し、検証期間を割り当て た結果、開発に使える期間が短くなり過ぎてしまう 21 PoC計画 1か月 PoC用 システム開発 2か月 PoC 3か月 計画の最初に、PoCフェーズ全体の期間を6か月と決める 開発期間が 短すぎる！ ① ② ③
どこで作る？ • Microsoft Office365 • Google workspace • Salesforce SaaS(Software as a Service) • AWS/GCP/Azureのマネージドサービス • Kintone • ノーコード・ローコードツール PaaS(Platform as a Service) • クラウド上のレンタルサーバー(EC2(AWS)やGCE(GCP)) • データセンター • 自前のサーバー IaaS(Infrastructure as a Service) 23 すぐに使い始められる 準備にかかる コストや手間が大きい
どこで作る？ l SaaS→PaaS→IaaSの順に活用を検討することでスピーディーに実装 し、検証に移れます l 社内の既存業務を対象としたDXの文脈だと、 l 「業務にシステムを合わせる」よりも「製品に業務を合わせる」の考 え方が主流になってきています l 「SaaSありき」の考え方も有効です 24
パターン2で気をつけたいこと l サイクルの始まりでフィードバックの最新状況を確認し、優先度 をしっかり検討して必要なものから着手するようにしましょう l アジャイルチームで対応していくため、アジャイルな進め方をす るためのスキルセット・マインドセットがチームメンバーに必要 です l サイクルの期間が短くなるため、CI/CDを導入し、DevOpsを実現し ましょう 33
[参考]開発成果物の評価 l 開発成果物とは l プログラム・開発環境・各種ドキュメント l パターン1の場合 l きれいなアーキテクチャ・設計・コードになっているか l 専門家・システム部門にレビューを依頼しましょう l パターン2の場合 l 成果物評価は、本来は実施しない l アジャイルプロセスによって産み出された価値を評価しましょう l いずれにせよ、DXの文脈ではドキュメントに対する評価に偏重し ないように気をつけましょう 37
本日のまとめ l プロジェクトとしての最終ゴールを定義しましょう l 各フェーズで目指すべきゴールを、フェーズ開始時点でなるべく具体化して おきましょう l 企画は実現可能かつ具体的なレベルまで練れたか？ l PoCの目的は定まっているか？ l 方針に合った展開プランを策定できているか？ l これらを、社内はもちろん、パートナーとなるベンダーとも共有しましょう l ベンダーは「打てば響く」 l 具体的なインプットが与えられれば、その分明確な回答を得ることができます l 間違っても、「お任せします」を丸投げしないように l 今日の内容はプロジェクトの進め方の話がメインで、ITの専門家しか分から ないような話ではありません l もちろん、分からないところは情報部門やベンダーといった専門家に質問しましょ う 39
ncdc
gmofh_hr_team
copilot
nishimuraryuma
proni
thirdofficial
toyotasystems_career_pitch
eviryr_recruit
cinchr
mihofujita
progmat
upsider_official
memory1994
62gerente
carmenintech
pedronauck
jponch
sachag
sugarenia
productmarketing
jensimmons
jennybc
iamctodd
malarkey
cherdarchuk