***

 
 

　2024年問題は、日本の物流業界に迫る大きな転換点である。この問題は、労働基準法に基づくドライバーの労働時間規制の厳格化に端を発し、2024年4月から新たな規制が施行される。これにより、物流業界はドライバーの労働時間の短縮とそれに伴う配送能力の低下に直面することになる。この変化は、物流事業者、荷主企業、消費者に広範な影響を及ぼすと予測されている。

　本稿は、2024年問題をはじめとする物流業界の課題について解像度を高めることで、今後の物流業界で必要になる改革を考えるための土台としたい。

 
 


# 物流の2024年問題とは

 

### 2024年4月以降、働き方改革関連法により、様々な問題が懸念される
1. ドライバーの拘束時間の減少
 - ドライバーの労働時間が1日最大16時間で合ったものが15時間に、継続休憩時間は最低8時間から11時間を基本とした下限9時間と制限される
 - 事業運営に必要な工数確保が困難になり、今までどおりの運送ができなくなる、もしくは法を順守した経営を行うことが困難になることが予想される
 - 2030年には、全国の約34%の貨物が運べなくなり、東北や四国などの地方部に関しては40%近くもの貨物が運べなくなるとされる
2. 売上・利益の減少
 - 1日に運ぶことのできる荷物の絶対量が少なくなり、事業者だけでなく、荷主を含むステークホルダー全体の利益の減少につながる - 
3. ドライバーの収入減少
 - 残業時間が規制されることで、その分ドライバーの収入が減少する
 - 収入減収による他業界への人材流出により、物流業界の人材不足が加速する

 
 

### ステークホルダーへの影響について
　ECの拡大や物流の多頻度/小ロット化、脱炭素ニーズの高まりなどにより、物流事業者だけでなく、多くのステークホルダーが大きな影響を受けることが予想される。

#### 荷主
1. 配送コストの増加
 - 2024年問題によって売上・利益が減少すると想定される物流事業者が、まずは運賃を上昇し、損失を押さえようとする意思が働くことは想像がたやすい
 - 運賃の上昇により、荷主が提供する商品価格の上昇や利益率の低下に繋がる可能性が考えられる
2. 供給チェーンの遅延
 - 労働時間の制限により、配送のタイムラインが遅れる可能性が考えられる
 - 配送の遅延により、製造工程を持つ事業者はオペレーションの変更を余儀なくされる可能性や、賞味期限等、時間に敏感な商品を扱う荷主にとって大きな問題となり得る
3. サプライチェーンの再構築
 - コスト増加や配送の遅延等に対応するために、より効率的な物流パートナーの選定が必要になる場合がある 

#### 消費者
1. 商品価格の高騰
 - 配送コストの増加により、エンドユーザーである消費者が、商品価格の上昇などのコスト負担のしわ寄せを受ける可能性が考えられる
2. サービス品質の変化
 - 配送遅延や時間指定による配達の受領タイミングへの影響

 
 

# 物流の2024年問題をたらしめる現状と課題
　労働時間規制によって、物流業界が2024年問題と言われるまで大きな影響を受けると考えられる背景には、大きく3つの課題があると考える。

### 1. 物流の危機的状況に対する荷主企業や消費者の理解の醸成が不十分
- 荷主企業や消費者が配送に対し迅速性や利便性を求める一方で、物流コストの透明性が低いことや、配送プロセスの複雑さなどを背景に、労働力不足やコスト上昇に対する認識が不十分であると考えられる
- 荷主企業の理解が不十分な場合、課題に対する適応が間に合わず、物流事業者への低価格要求による適正運賃の確保が困難になることや、消費者へのサービス品質の低下を招く可能性が高まることが考えられる
- 消費者の理解が不十分な場合、荷受け時間の柔軟性が向上せず、配送効率の向上が非常に困難である

 
 

### 2. 物流プロセスにおける課題
- 荷主からの短納期や小口頻繁な配送要求によって、物流事業者にとって非効率的なルート計画や過剰なリソース配分を強いられる
- 異なる荷主ごとに異なる梱包基準や荷扱い方法が要求され、標準化された効率的な処理が困難になる
- 予測不能な注文や緊急配送要求などによる外部要因が、物流事業者のリソース計画を複雑化させる
- 複数の中継地点を経由するようなサプライチェーンをはじめ、情報の非対称性から配送遅延や需給の不均衡が起こりやすい

 
 


### 3. 物流標準化・効率化（省力化・省エネ化・脱炭素化）における課題
 - 貨物追跡システムや輸送管理システム、在庫管理システムなど、様々なシステムが利用される中、システム間での互換性がない場合、情報のリアルタイム性が欠落や需要予測が困難になり、効率性の低下や顧客満足度の低下につながる
 - RPAやAIを活用した物流プロセスの自動化の余地がまだ大きく、積み込み・荷卸し作業の非効率性による配送遅延や人件費の高騰、労働力不足が常態化している
 - 二酸化炭素排出の削減ニーズが高まる中、電気自動車などの代替燃料の採用やインフラ整備が進んでいない

 
 


　以上のように、「物流の2024年問題」は、物流業界における労働環境の改善や効率化、技術革新など、様々な側面からのアプローチが求められている複雑な課題である。
また、多くのステークホルダーの協力なしでは課題解決は困難であり、それぞれが共通認識を持った上で、いくつもの対応策を講じる必要がある。

 

　次の記事では、上記の課題解決に対して求められる社会全体での物流改革について触れていく。

 
 


参考文献：

- [「物流の2024年問題」の影響について（2）](https://www.meti.go.jp/shingikai/mono_info_service/sustainable_logistics/pdf/003_01_00.pdf),経済産業省ウェブサイト第3回 持続可能な物流の実現に向けた検討会
- [2024年問題について]([https://www.meti.go.jp/shingikai/mono_info_service/sustainable_logistics/pdf/003_01_00.pdf](https://wwwtb.mlit.go.jp/tohoku/at/docs/trans/truck2023_03/date4.pdf)https://wwwtb.mlit.go.jp/tohoku/at/docs/trans/truck2023_03/date4.pdf),経済産業省ウェブサイト第3回 持続可能な物流の実現に向けた検討会
- [トラックドライバー不足時代における輸配送のあり方 ～地域別ドライバー不足数の将来推計と共同輸配送の効用～](https://www.meti.go.jp/shingikai/mono_info_service/sustainable_logistics/pdf/003_01_00.pdf),第351回NRIメディアフォーラム





　2024年問題は、日本の物流業界に迫る大きな転換点である。この問題は、労働基準法に基づくドライバーの労働時間規制の厳格化に端を発し、2024年4月から新たな規制が施行される。これにより、物流業界はドライバーの労働時間の短縮とそれに伴う配送能力の低下に直面することになる。この変化は、物流事業者、荷主企業、消費者に広範な影響を及ぼすと予測されている。

　本稿は、2024年問題をはじめとする

2024年問題～物流業界の課題とは～

***

 
 

# "効率化"の取り組みとそのリスク

労働人口の減少やIT技術の向上などにより、昨今の日本企業ではDXやらAI活用やらのバズワードを引っ提げて、”効率化”を目的とした取り組みが散見されるようになった。

 

環境における課題の大きさ・共通性と、トレンドに則った解決策がうまくフィットしているため、どこもかしこも”効率化”と向き合わざるを得ない状況のように感じる。競合優位性としての生産性の高さを掲げる企業も少なくないのではないだろうか。

 

もちろん、”効率化”を一概に悪いと言うつもりは全くない。目的達成に対する手段として、”効率化”という選択が最適な場合も当然考えられる。

 

実際に、SaaSやシステム等を活用することで人件費を半分以下に抑えることや、一人当たりの売上を2倍、3倍にすることなんてことも十分現実的な話である。

 

しかし、”効率化”がはらむリスクは考慮から漏れることが多く、**”効率化”を目指す取り組みが、一転して重大な経営課題となり得るケースは多いのではないかと考える。**

 

**そのリスクの一つが”適応力”の低下である。**

 
 

# 時間的価値の向上による、状況適応の価値の損失

 

例えば、SAPなどをはじめとする、ERP（Enterprise Resources Planning）と呼ばれる基幹システムがある。これは、迅速かつ的確な経営判断を行う、いわゆる「経営の効率化」のために導入される、会計や販売、人事情報などを統合して管理するシステムである。

 

しかし、「経営の効率化」を目的とし、その結果、業績の向上などを目指すわけだが、実はこの基幹システムが大きな経営課題となっているケースは非常に多く見受けられる。
（執筆時、筆者はコンサルタントとしてシステム刷新のPMOを担当している）

 

**これは、日々移り変わる業務プロセスや事業の重要指標にシステムが適応できず、適切な経営判断を行うためには現場の属人性に頼った情報集約に頼らざるを得ない場合や、そもそも重要な経営判断を行うための要素が精緻に確認できない場合などが該当する。**

 

社内で何気なく利用しているシステムは、”効率化”を求めて導入されたものがほとんどであるはずだが、システムでの対応が困難な業務で合ったり、そのわずらわしさから、ExcelやGoogleスプレッドシートなどで業務を独自にカスタマイズ（効率化）した、いわゆる職人とも呼べるような方がどの職場にもいるように思うが、心当たりはないだろうか。

 

つまり、**”効率化”を目指した取り組みは、時間を重ねるごとに”適応力”が求められるようになり、適応できなくなった仕組みは陳腐化し、重大な課題となり得ると言える。**

 

また、製造卸のような業態を例に挙げると、自然災害による工場停止などを考慮したバックアップの製造施設や過剰在庫の確保、ライン中断を考慮した予備人員の確保は、”効率化”とは逆行した”適応力”（冗長性）の確保であり、**”効率化”と”適応力”はトレードオフであることがよくわかる。**

 

**”効率化”によって我々は時間的価値を手にしていると言えるが、その裏側では、状況適応の価値が損なわれている可能性を考慮することが重要になると考える。**

 
 

>「効率は、競争優位性の主要な源泉であり続けている。だが、効率の向上をひたすら追求していると、個々の市場関係者が下す決定が全体として生み出すレジリエンスという公共の利益の供給量は、最適ではなくなる」
> — William Galston. "Efficiency Isn't the Only Economic Virtue." The Wall Street Journal, March 10,2020.

 
 

SDGsではないが、筆者は持続可能な活動にこそ、大きな価値があると考えている。上述の論考を企業活動だけに当てはめるのではなく、政治活動や教育システムなどにも適用し、目的に応じて最適な意思決定ができるよう努めていきたい。

 
 
 

**参考書籍**：
ジェレミー・リフキン (著), 柴田 裕之 (翻訳)
["レジリエンスの時代 再野生化する地球で、人類が生き抜くための大転換"](https://www.amazon.co.jp/%E3%83%AC%E3%82%B8%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9%E3%81%AE%E6%99%82%E4%BB%A3-%E5%86%8D%E9%87%8E%E7%94%9F%E5%8C%96%E3%81%99%E3%82%8B%E5%9C%B0%E7%90%83%E3%81%A7%E3%80%81%E4%BA%BA%E9%A1%9E%E3%81%8C%E7%94%9F%E3%81%8D%E6%8A%9C%E3%81%8F%E3%81%9F%E3%82%81%E3%81%AE%E5%A4%A7%E8%BB%A2%E6%8F%9B-%E9%9B%86%E8%8B%B1%E7%A4%BE%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%E3%83%BB%E3%82%B3%E3%83%A2%E3%83%B3-%E3%82%B8%E3%82%A7%E3%83%AC%E3%83%9F%E3%83%BC%E3%83%BB%E3%83%AA%E3%83%95%E3%82%AD%E3%83%B3/dp/408737002X)


"効率化"の取り組みとそのリスク

労働人口の減少やIT技術の向上などにより、昨今の日本企業ではDXやらAI活用やらのバズワードを引っ提げて、”効率化”を目的とした取り組みが散見されるようになった。



環境における課題の大きさ・共通性と、トレンドに則った解決策がうまくフィットしているため、どこもかしこも”効率化”と向き合わざるを得ない状況のように感じる。競合優位性としての生産性の高さを掲げる

効率化と適応力はトレードオフである

***

 
 

　ERP（Enterprise Resource Planning）システムは、企業の業務プロセスを一元管理し、効率的な経営を実現するための重要なツールである。近年、多くの企業が様々なERPシステムの導入を進めているが、その方法論について「Fit to Standard」と「Fit & Gap」という二つの異なるアプローチが存在し、特に「Fit to Standard」でのアプローチがこのDX時代に注目を集めている。なぜ「Fit to Standard」が注目を浴びるようになっているのか、解説していく。

 
 

# Fit to Standardとは
　「Fit to Standard」アプローチは、システムの標準機能のみを利用し、企業のビジネスプロセスや要件をこれに合わせる戦略である。このアプローチにより、企業はシステムのアップデートやメンテナンスが容易になるというメリットを享受できる。

 
 

# Fit & Gapとは
　一方で、「Fit & Gap」アプローチは、企業の既存の業務プロセスや特定の要件に合わせて、ERPシステムをカスタマイズまたは追加開発する方法である。特に、日本企業では独特な商習慣や自社独自の業務プロセスに対応するため、このアプローチが採用されることが多く見受けられる。

 
 

# それぞれのメリット/デメリット
　「Fit to Standard」のメリットとして、システムの導入期間やコストを抑えることができる。また、システムのアップデートや保守が容易であり、最新の機能を迅速に利用することが可能となる。デメリットとしては、企業の独自の要件や業務プロセスに柔軟に対応するのが難しいことなどが挙げられる。

 

　対照的に、「Fit & Gap」のメリットは、企業の独自性にきめ細かく対応できる点が大きい。デメリットとしては、導入コストや期間が増大し、システムのアップデートや保守が困難になることが挙げられる。また、過度なカスタマイズにより、レガシーシステムの問題が発生する可能性も重要なポイントである。

 
 

参考までに、上記メリットとデメリットを踏まえ、5つの評価基準を設定したそれぞれの比較表を作成した。

 

| 評価基準※ | Fit to Standard | Fit & Gap |
|------------|-----------------------------------|------------------------------------------|
| コスト | ○（標準機能の利用でコスト削減） | ×（カスタマイズによるコスト増加） |
| 導入期間 | ○（カスタマイズが少ないため導入速度が速い）| △（カスタマイズによる導入期間の延長可能性高） |
| 柔軟性 | △（企業固有の要求に対応しにくい） | ○（ビジネスニーズの変化に柔軟に対応） |
| リスク | ○（標準機能のためリスク低） | △（カスタマイズによるリスク高） |
| ユーザー満足度 | △（制約が多くユーザー満足度低下の可能性）| ○（ユーザーの要求に応じたシステム構築で満足度向上）|

 

 - ※評価基準について
 1. コスト: 導入コスト、運用コスト、保守コストを考慮
 2. 導入時間: システム導入にかかる期間
 3. 柔軟性: ビジネスニーズの変化にどれだけ対応できるか
 4. リスク: 予期せぬバグやトラブル、運用面などによるリスクの大きさ
 5. ユーザー満足度: エンドユーザーの満足度

 
 

# ERP導入における課題
　多くの企業がERP導入において抱える課題としては、コストや導入期間のオーバーラン、業務の効率化や統合の困難さ、システムの保守やアップデートなど多岐にわたる課題が山ほど挙げられる。
　また、独自の業務プロセスや商習慣に対応するためのカスタマイズが、将来的なシステムの拡張性や柔軟性を損なうことも一因となり、その複雑性の高さによって導入プロジェクトの推進難易度が非常に高いものとなってしまっている。ここ数年でDX人材の不足や育成が各社の課題として取り沙汰されるようになった大きな要因の一つとも言えるだろう。

 
 

# Fit to Standardでの課題の解消
　「Fit to Standard」は、これらの課題に一定の解決策を提示する。
　コストと時間の観点からは、標準機能の利用により、リソースの削減が可能である。また、システムのアップデートやメンテナンスもスムーズに行えるため、長期的な運用においても利便性が増す。
　ただし、ビジネス要件との完全なマッチングを求める企業にとっては、柔軟性の制約がハードルとなる可能性がある。

 
 

# 結論
　最終的に、企業がどのアプローチを選択するかは、ビジネスの要件、リソース、期間等の様々な要因を考慮する必要がある。Fit to Standardアプローチが提供する利便性と効率性は魅力的であるが、企業独自のニーズに対する柔軟性も重要な要素となる。適切なバランスでこれらの要因を考慮し、ビジネスを次の段階へと導く戦略を選択することが求められる。

　以上、ERP導入における「Fit to Standard」アプローチの重要性とその実践についての概要を記述した。最終的に、企業がどのアプローチを選択するかは、ビジネスの要件、リソース、期間等の様々な要因を考慮する必要がある。その中で、企業が成長し、変化するビジネス環境に適応するためには、効果的なERPに限らず、様々なシステムへの対応・導入が不可欠となる。適切なバランスでこれらの要因を考慮し、ビジネスを次の段階へと導く戦略を選択することが求められるだろう。





　ERP（Enterprise Resource Planning）システムは、企業の業務プロセスを一元管理し、効率的な経営を実現するための重要なツールである。近年、多くの企業が様々なERPシステムの導入を進めているが、その方法論について「Fit to Standard」と「Fit & Gap」という二つの異なるアプローチが存在し、特に「Fit to Standard」でのアプローチがこの

Fit to StandardによるERP導入

***

 
 

プロジェクトの成功率を高める検証手法として、心理学者であるゲイリー・クラインが提唱した事前検死(プレモータム)についてまとめる。

 
 

# 事前検死(pre-mortem)とは
事前検死(pre-mortem)とは、**プロジェクトの開始前に「プロジェクトは失敗した」という想定で、チーム内でその原因を検証すること**をいう。

「pre-mortem」は、医療の改善などのために遺体の検死や解剖を行うことを意味する「post-mortem」に由来しており、絶対に失敗が許されない場面において絶大な威力を発揮するとされている。

 
 

# 事前検死を行う4ステップ
当然だが、前提として事前検死の目的はプロジェクトを中断ではなく、強化することにある。
ここでいう強化とは、主に目的/目標達成の達成確率を高めることを指す。

 
 

## 0. 失敗を許容する文化形成
これは事前検死を行うためのステップというよりは、検証を適切に行うために必要不可欠な準備に近い。

人間のバイアスを可能な限り取り除いた状態、失敗に対してオープンかつ正直な組織でない限り、核心的な失敗に事前にたどり着くことは難しいだろう。

そもそも失敗することは当然であり、失敗から学ぶことは最も「費用対効果」が高いことであるという共通認識を持つことが重要である。

 
 

## 1. 具体的な失敗イメージを描き、言語化する
事前検死の実践例
- チームのリーダーは（プロジェクトの責任者とは別の人物）は、メンバー全員に「プロジェクトが大失敗しました」と告げる
- メンバーは次の数分間で、失敗の理由をできるだけ書き出さなければならない
- その後、プロジェクトの責任者から順に、理由をひとつずつ発表していく。それを理由がなくまるまで行う

本ステップにおいて重要な点が2つ。
1. プロジェクトの目的を整理し、それを達成できないことによる損失(失敗)の優先順位を設定し、優先順位の高いものから上記に取り組む
2. 目標・計画を達成するまでのプロセスを**時系列に従って鮮明にイメージ(言語化)する**こと。その中でマイルストーンを設定していくと、途中経過の振り返りも行いやすくなる

 
 


## 2. 失敗の原因を抽出する
1.にて上げた失敗に対してあらゆる角度から原因分析を行う。

ここでも重要になるのが、時系列を通じて考えること。失敗する場合、マイルストーン前までに失敗の要因が少しずつ蓄積しているはず。

設定したマイルストーンにおいて、どのように準備に失敗しているかを考えていく。そうすることで、さらにリアルに失敗までの道のりが見え、失敗し得る原因が把握しやすくなる。


 
 

## 3. 原因に対する解決策を立てる
失敗の原因が整理できてきたら、次はその対策を講じる。

1. 2.で設定した各マイルストーンにおける達成率を定量/定性の両面から言語化する

2. 予期せぬ問題を考慮した上で、各マイルストーンでの目標を達成できるよう打ち手を複数立案する


 
 

## 4. 検証を通した計画を実行する
失敗を防ぎ成功を導くための新しい計画を遂行していく。

モチベーション理論の一つによると、人間はうれしい感情よりも苦痛に対してより強く反応するため、ただ単に成功を思い浮かべるよりも事前検死によって失敗を想像したほうが成功率はぐっと高くなるらしい。

これはたぶん無意識的に事前検死を行うようになるからではないだろうかと思う、、、

大抵の計画は計画通りに実行できないから、定期的にプロセスを振り返る機会を設け、計画を練り直すことが必要である。

 
 

# まとめ
当然だが、事前検死をどれだけ丁寧に取り組んだとしても失敗はあらゆるところで起こりうる。

あくまでも重要なのは、**失敗を許容する文化形成**と**定期的に振り返り改善し続ける習慣**をもつチーム作りだと思う。

大々的に時間や人数を集めて事前検死を行う必要はなく、上記のような組織の中で定常的にそれに近い思考や議論がなされている状態を目指していきたい。

 
 

# 参考書籍
https://www.amazon.co.jp/dp/B01MU364ID?tag=note0e2a-22&linkCode=ogi&th=1&psc=1
https://www.amazon.co.jp/dp/B07D728XKW?tag=note0e2a-22&linkCode=ogi&th=1&psc=1





プロジェクトの成功率を高める検証手法として、心理学者であるゲイリー・クラインが提唱した事前検死(プレモータム)についてまとめる。

事前検死(pre-mortem)とは
事前検死(pre-mortem)とは、プロジェクトの開始前に「プロジェクトは失敗した」という想定で、チーム内でその原因を検証することをいう。

「pre-mortem」は、医療の改善などのために遺体の検死や解剖を行うことを

プロジェクトの成功率を高める事前検死(pre-mortem)とは

***

 
 

Facebook創始者であるザッカーバーグの名言として広く知られている言葉に、"Done is better than perfect(完璧よりも実行することが重要である)"がある。

今回、"Done is better than perfect"の意図することを勝手に解釈し、それを実践することによるメリットはなにか、また、自身の置く環境と照らし合わせ、既に実践しているもののアップデートや変化のきっかけとしたい。

 
 

# "Done is Better than Perfect" の解釈
調べてみると、どうやら、Facebook上場時のIPO申請資料に記載されている”The Hacker Way”という行動原理が思想の源泉のようだ。

>The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it ? often in the face of people who say it’s impossible or are content with the status quo.
>
>Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.
>
> [Mark Zuckerberg’s letter to investors before Facebook’s initial public offering (IPO) in 2012.](https://www.sec.gov/Archives/edgar/data/1326801/000119312512034517/d287954ds1.htm)

上記より私は、**Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once.**(技術者は、すべてを一度に正しく実行しようとするのではなく、小さな反復からすばやくリリースして学習することにより、長期的に最高のサービスを構築しようとする。)こそが、本質的な行動原理としての価値であり、その実践として**Done is better than perfect**がスローガンとして置かれているのだなと理解した。

つまり、完璧じゃなくていいからとりあえずやってみて、それを改善し続けることで最高のものにしよう、ということであると。

 
 

## "Done is Better than Perfect" の恩恵

この言葉から受ける恩恵について、以下の2つのポイントを考察する。

### 1. 創造物の発信と自信の向上

完璧ではないものを世に出すことに対する抵抗を乗り越え、行動することで以下の恩恵がある。

- 創造物やアイデアの発信が容易になる
- 失敗から学ぶことで、次第に高いクオリティを達成する方法を見つける

 
 

### 2. 潜在的価値との出会い

先鋭的行動を起こすことで社会のフィードバックを受け入れ、経験学習機会を創出し続けることができる。
不確実性の高い潜在的な価値と向き合い、先駆的結果を蓋然性高く生み出すためには非常に重要と感じる。

- 変化や顧客の反応を取り入れて進化する能力
- 実践によってのみ得られる洞察や成長の機会

 
 

## "Done is Better than Perfect" の実践

### 1. "Be the first penguin"

[ファーストペンギン](https://jinjibu.jp/keyword/detl/773/#:~:text=%E3%80%8C%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88%E3%83%9A%E3%83%B3%E3%82%AE%E3%83%B3%E3%80%8D%E3%81%A8%E3%81%AF%E3%80%81,%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88%E3%83%9A%E3%83%B3%E3%82%AE%E3%83%B3%E3%80%8D%E3%81%A8%E5%91%BC%E3%81%B3%E3%81%BE%E3%81%99%E3%80%82)になることを恐れない。

- 未知の領域に対しても、失敗を恐れずに行動する
- 行動から得られる結果を客観的に評価し、改善の方向性を探索し続ける

 
 

### 2. 失敗を許容するカルチャーの醸成

実践を評価し、失敗を許容するカルチャーを醸成すること。
これには組織としての努力と個人的な意識が必要である。

- [心理的安全性](https://www.recruit-ms.co.jp/glossary/dtl/0000000230/#:~:text=%E3%80%8C%E5%BF%83%E7%90%86%E7%9A%84%E5%AE%89%E5%85%A8%E6%80%A7%EF%BC%88psychological,%E3%81%A8%E5%AE%9A%E7%BE%A9%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82)を尊重し、失敗を恐れずにチャレンジする環境を整備する
- [成人発達理論](https://www.corner-inc.co.jp/media/c0156/#:~:text=%E3%80%8C%E6%88%90%E4%BA%BA%E7%99%BA%E9%81%94%E7%90%86%E8%AB%96%E3%80%8D%E3%81%A8%E3%81%AF%E3%80%81%E6%88%90%E4%BA%BA%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%A6,%E3%81%AE%E3%81%93%E3%81%A8%E3%82%92%E6%8C%87%E3%81%97%E3%81%BE%E3%81%99%E3%80%82)や臨床心理学の概念を取り入れ、個人の心理的ハードルを理解する
- 失敗から学び、次の行動へのフィードバックを受け入れる文化を育てる


最終的には、実践する環境や他者のサポートがどれだけ整っているかによって、可能性を広げることができるだろう。

 
 

### 3. 組織としての学習

各個人が蓄積した知識や洞察を一般化することで、組織全体の学習を進めること。

- 学習の蓄積や一般化を評価し、誰もが常に情報にアクセスできる状態を持つ
- 高頻度で情報をアップデートし、共有が可能な機会を持つ

 
 

# まとめ

"Done is better than perfect" の考え方は、完璧を求めるよりも行動することの重要性を強調している。実践を通じて経験を積み、改善を続けることで、最終的には理想の状態に近づくことができるといえるだろう。価値観の言語化や組織文化の整備も大切だが、自身の意志と行動が変化をもたらす最大の要因といえる。"Done is better than perfect" の精神を持って、積極的な行動を心がけたい。





Facebook創始者であるザッカーバーグの名言として広く知られている言葉に、"Done is better than perfect(完璧よりも実行することが重要である)"がある。

今回、"Done is better than perfect"の意図することを勝手に解釈し、それを実践することによるメリットはなにか、また、自身の置く環境と照らし合わせ、既に実践しているもののアップデート

ザッカーバーグの「Done is better than perfect」の理解と実践

***

 
 


# 想定読者
 - データアナリストや〇〇Ops、企画職などプロジェクトのマネジメントに関わる方
 - プロジェクトマネージャーの元でプロジェクト推進を行う方
 - (エンジニアの方)

 

# Design Doc とは

 [2007年の Google Developer Day Tokyo での鵜飼氏のプレゼン](https://www.youtube.com/watch?v=pc-IQkVmOdI)によると、Design Docは「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものらしい。

Design Docとは一般的に設計書のことを指し、開発組織で多く活用されるものだが、プロジェクトの成功確度を高める観点で、**ビジネス職でも十分に活用できるものである**と考える。

私自身、アナリティクスやOpsを始めとするプロジェクトマネジメントに携わる中で**ドキュメント**の重要性は日々痛感している。
 - 自分の理解の整理につながる
 - プロジェクトに関連する事象について網羅的に考察する機会を得る
 - 文章化することで、複雑、曖昧な部分が明確になる
 - 早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得る
 - プロジェクトの目的から解決策、実行に至るまでの合意形成
 - 新しいメンバーがプロジェクトを理解する手助けになる
 - etc...

ドキュメントのお作法？としてよく知られるDesign Docだが、まずはイメージしやすいようにいくつかの実例を上げた上で、作成において気をつけることなどを記述していく。

 

# Design Docの実例

 1. [WebKit WebSocketDesign Doc（グーグル）](https://docs.google.com/document/d/1s1ryja1V8dDotMK2WBGT2wnwchZ_x7Tag2L3OZfn5Po/preview#)
 2. [Dagger 2.0](https://docs.google.com/document/d/1fwg-NsMKYtYxeEWe82rISIHjNrtdqonfiHgp8-PQ7m8/edit#)
 3. [デザインドックで学ぶデザインドック(FLYWHEEL)](https://www.flywheel.jp/topics/design-doc-of-design-doc/)

 

### 典型的な記述項目
![](https://storage.googleapis.com/zenn-user-upload/9bb084bdac30-20220605.png)
> これらの項目のどれを含むかどうかは作者の任意です。自分のプロジェクトの目的に応じて書くべき項目を選びましょう。ただし、この表中の項目名に（＊：アスタリスク）が付いているものは、ほぼ必須と考えてよい項目です。
> ***参照：[残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）](https://atmarkit.itmedia.co.jp/ait/articles/1606/21/news016.html)***

 
 

記述項目のテンプレートとしては上記がわかりやすく、参考になりそうだった。
だが、**プロジェクトによって考慮事項や解決策の複雑性に変化が大きいため、項目を一般化して運用するものとは言えないだろう**。

プロジェクトにMECEで柔軟な選択を持たせることで成功確度を高めることがDesign Docの価値の一つでもあるため、形式張らないドキュメントでプロジェクトにとって最も意味のある形で記述することが求められるようだ。(むずい)

 
 


# ①Design Doc作成の事前準備

Design Docでは、**目的(Goal)と要素や環境(Facts)がセットになった状態での目的達成への手段の明確化と、それらすべてに対し、それらが適切である根拠が常に明示されている状態**が最低限求められる。
それにより、プロジェクトに関連する事象について網羅的に考察することや解決策に対しクリティカルな視点が入るなど、プロジェクトの成功確度の向上につながる。

そのため、事前にプロジェクトの関係者や有識者を交えながら、GoalとFactsを適切に定義していく必要がある。

したがって、Design Docというものはいきなり書き始めず、まずは **「目的(Goalとnon Goals)の理解」** とそれに **「必要な要素や環境(Facts)の理解」** を言語化していく。


 
 

### 目的(Goalとnon Goals)の理解

当然だが、**関係者間で目的を明確かつ簡潔に言語化することで、プロジェクトの共通理解を常に持ち続けること**が重要。

また、目的(Goal)と混合されやすいようなものを、**意図的に目的(Goal)から除外するもの(non Goals)** としてリストにしておくことも非常に重要。

これにより、ときにはGoalに立ち戻って意思決定を行ったり、プロジェクトの迷走を防ぐことがで
きる。


 
 

### 必要な要素や環境(Facts)の理解

目的達成のための手段が適切であるかを確認する。
とくに、開発の場合には使用する技術や手法、アルゴリズムが要求仕様(目的)を実現し得るか確認する必要が出てくる。

ビジネス面では、たとえば普段取り扱わないようなダッシュボードや分析結果をアウトプットするために使用するツールやデータなどが、目的の要件を満たしているか確認する必要があるだろう。


詳細は後述するが、作成するDesign Docの価値を高めていくには、
使用するツールやデータが明確な場合には、なぜそれが目的達成のために適切であるのか、
また、適切なツールやデータが社内には整備されておらず、そのための準備が必要な場合には、さらにブレイクダウンしていき、理由や背景を明確化しながら整理していく必要がある。

とくに、データアナリストやOps職の方は、データアーキテクトやデータマネジメントもプロジェクトでカバーしなければいけない領域の一つになることが多いのではと思う。

そこで、下記のシステムコンテキスト図のように、アウトプットに必要なデータやツールの関係性などを可視化しておくのが吉だろう。
![](https://storage.googleapis.com/zenn-user-upload/1053676816d6-20220605.png)

> ***参照：[IBM Cloud 資料>VMware Solutions>システム・コンテキスト](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-htdc-hpcs-system-context&locale=ja#:~:text=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%BB%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%81%AF%E3%80%81%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE,%E5%AF%BE%E8%A9%B1%E3%82%92%E8%A1%A8%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82)***

 
 

# ②Design Docの作成

①での整理をベースに、以下を中止ながら項目を立て明確に言語化し作成していく。
①での整理をベースに、以下を中止ながら項目を立て明確に言語化し作成していく。

 
 


### 結論だけでなく、理由や背景(Bacground)を記載

**まずは、プロジェクトが発足するにあたった背景(Bacground)を簡潔に記述する**こと。必要に応じて、理解をサポートするための資料も添付する。
これらはあくまでも主観に基づく内容ではなく、客観的事実をベースに共有しながら、以降の内容を素早く適切に理解するためのサポートを行う。

そして、先述した「Goalを達成するため---手段が適切である根拠が常に明示されている状態」を目指すために、**各論にて5W1Hを意識したBacgroundを記載していく**。
①での整理をベースに、以下を中止ながら項目を立て明確に言語化し作成していく。
それにより、一つひとつの意思決定の背景が汲み取れるため、レビューや振り返りが非常に有用でかつ効率的なものになる。

メンバーから「なぜ？」「どうやって？」などのメンバーから「なぜ？」「どうやって？」などの質問が出るたびに、テキストとして記述していくと、ドキュメントの価値は上がっていくだろう。
質問が出るたびに、テキストとして記述していくと、ドキュメントの価値は上がっていくだろう。

 
 


### プロジェクトメンバーやFactsに関して知見の深いメンバーと常に共有する

現場感や整理事項に知見の深いメンバーからの質問や提案などを通じ、ドキュメントがもつプロジェクトの解像度を上げていくことで、その価値は高まっていく。

とくにプロジェクトメンバーへの共有では、ただ閲覧権限を付与して共有することではなく、意図的に見てもらう機会を与え、**議論は常にドキュメントを通じて行う**ということに注意したい。
Design Docのもつ大きな価値の一つには、このコミュニケーションの活性化、円滑化も含まれていることは忘れてはいけない。

質問が出るたびに、テキストとして記述していくと、ドキュメントの価値は上がっていくだろう。

また、専門の知見をもつメンバーに対しては、きちんと**レビューを貰う機会を作る**ことが重要。

有識者からのレビューほど偉大なものはなく、
 - 組織全体の共通資産となる
 - セキュリティ、プライバシーなどの横断的な懸念事項の考慮によるリスクマネジメント
 - プロジェクトの手戻りや変更点の減少(レビューのタイミングが早ければ早いほど良い)
と、プロジェクトの成否を分けるような事象にクリティカルにアプローチすることが期待できる。


 
 

### Design Docに適したツール

Design Docを作成するのに最も代表的なツールがGoogleドキュメントだろう。
Googleドキュメントの良い点は、レビューによるコメントや共有範囲が簡単に設定でき、リアルタイムでの同時編集が可能な点だろう。

開発組織では、GitHub + Markdownによる管理もあるようだが、エンジニア以外の活用ハードルの高さはありそう。


 
 

# Design Docを書くべきではないとき

ここまでを読むと、Design Doc(ドキュメント)は大事かもしれないけど作成するのめっちゃ大変じゃんと思う方が大半ではないだろうか。

もちろん、Design Docもプロジェクト完遂のための一つの手段であり、労力とトレードオフの関係である。そのため、これにかかる労力が、設計、文書化、上級職によるレビューなどに関する組織的な合意形成のメリットを上回る場合はDesign Docを書くべきではないだろう。

一見複雑で難儀な意思決定に思えるかもしれないが、考慮事項は非常にシンプルで、**いずれかの解決策が曖昧であるかどうか、つまり問題の複雑さが原因なのか、解決策の複雑さが原因なのか、あるいはその両方なのか**ということ。

プロジェクトが複数回にわたり実行されており、再度の実行における懸念が上がらない場合は言わずもがな、社内の事例をアナロジーとして転用できそうなものなどは、わざわざDesign Docに労力を割くのは適切な意思決定とは言えないだろう。

反対に、考えられる解決策が複数上がったり、意思決定に係る要素が多岐にわたる、複雑である場合などにはDesign Docを起こすのが賢明と感じる。


しかし、そもそもプロジェクトというものは都度ドキュメントに残すことで、ナレッジの蓄積や課題の顕在化、コミュニケーションを円滑にするなど多くのメリットをもたらしてくれる。あくまで、Design Docの粒度でドキュメントを作成するかの選択の問題であると思う。

そのため、素早く人を巻き込み、要件を抑えたドキュメントを適切な粒度で作成しながら、プロジェクトやコミュニケーションを円滑に進められるということは、プロジェクトをマネジメントする上で最も重要なスキルの一つであると認識している。

 
 

# 参考記事
 - [残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門](https://atmarkit.itmedia.co.jp/ait/articles/1606/21/news016.html)
 - [Design Docs at Google](https://www.industrialempathy.com/posts/design-docs-at-google/)
 - [デザインドックで学ぶデザインドック](https://www.flywheel.jp/topics/design-doc-of-design-doc/)


想定読者
 データアナリストや〇〇Ops、企画職などプロジェクトのマネジメントに関わる方
 プロジェクトマネージャーの元でプロジェクト推進を行う方
 (エンジニアの方)

Design Doc とは

 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると、Design Docは「Google で必ず書くことになっているドキュメント」であり、「プロジェ

Design Docをビジネス職で応用する

***

 
 

企業経営を行う上で避けて通れないのが「販売管理システム」の導入だ。近年は特に「クラウド」や「オンプレミス」といった言葉が聞かれるが、実際にはどのような違いがあり、どちらが企業に適しているのだろうか。今回は、それぞれの特徴とメリット・デメリットを解説する。
 

# 販売管理システムの基本
まず初めに、販売管理システムの基本を理解する。これは企業が販売活動をスムーズに行えるよう支援するシステムである。
販売管理システムは「クラウドベース」または「オンプレミス」として展開されるが、これらの違いを知ることは非常に重要だ。

 
 

# クラウドベースの販売管理システム
クラウドベースのシステムはインターネットを通じてサービスを利用する形態を取る。ここではそのメリットとデメリットを探る。

## メリット
1. 初期コストの削減：高額なハードウェア投資が不要である。
2. 柔軟なスケーリング：企業の成長に合わせて簡単にシステムを拡張できる。
3. リモートアクセス：インターネット環境があればどこからでもアクセス可能だ。

 

## デメリット
1. 通信環境に依存：通信環境が悪いとシステムの利用が困難になる。
2. セキュリティ懸念：クラウドサービス提供者のセキュリティポリシーに依存する形となる。

 
 

# オンプレミスの販売管理システム
次に、企業の内部ネットワーク上にシステムを設置するオンプレミスについて見ていく。
 

## メリット
1. カスタマイズの自由度：企業のニーズに合わせてシステムを細かくカスタマイズできる。
2. セキュリティの強化：データ管理とセキュリティポリシーを企業自身でコントロールできる。
 

## デメリット
1. 初期コストが高い：ハードウェアやライセンス購入など、初期投資が重くなりがちである。
2. メンテナンス負荷：システムのメンテナンスやアップデートを自社で行う必要がある。

 
 

# クラウド vs. オンプレミス: どちらを選ぶべきか
企業にとって最適な販売管理システムを選ぶには、クラウドとオンプレミスのそれぞれの利点と欠点、そして自社の状況を深く理解することが基本となる。

| | クラウド | オンプレミス |
|--------------|--------------|--------------|
| **初期コスト** | 安価（サブスクリプション料金） | 高価（ライセンス購入、ハードウェアなどの設備投資が必要） |
| **カスタマイズ性** | 限定的（プロバイダーの範囲内） | 広範囲（企業独自の要件に合わせたカスタマイズが可能） |
| **セキュリティ** | 中程度（プロバイダーが基本的なセキュリティを担保） | 高度（企業がセキュリティを完全にコントロール可能） |
| **アクセスの便利さ** | 容易（いつでもどこでもアクセス可能） | 限定的（特定のネットワークからのアクセスが主） |
| **保守・メンテナンス** | 簡易（プロバイダーが管理・運営） | 複雑（自社での定期的なメンテナンスが必要） |

 

1. 初期コスト: クラウドベースは初期コストが低く抑えられるのに対し、オンプレミスはハードウェアやライセンスの購入が必要で初期投資が高くなる。
2. カスタマイズ性: オンプレミスは企業の特定の要件に合わせて細かくカスタマイズが可能だが、クラウドは提供者の設定範囲内でしかカスタマイズができない。
3. セキュリティ: オンプレミスは企業がセキュリティを完全にコントロールできるが、クラウドはサービス提供者のセキュリティポリシーに依存する。
4. アクセスの便利さ: クラウドはインターネット環境さえあればどこからでもアクセスが可能だが、オンプレミスは主に企業内のネットワークからのアクセスとなる。
5. 保守・メンテナンス: クラウドはサービス提供者がメンテナンスを行うため企業の負担が少ないが、オンプレミスは自社でのメンテナンスが必要となる。


# まとめ
販売管理の現場で「クラウド」や「オンプレミス」の導入を検討する際には、それぞれの特徴を理解した上で、企業の状況とニーズに最も適したシステムを選ぶことが重要だ。

販売管理システムは企業の成長を支える重要な要素であり、クラウドベースとオンプレミスという二つの異なるアプローチから最適な解決策を見つけることができる。





企業経営を行う上で避けて通れないのが「販売管理システム」の導入だ。近年は特に「クラウド」や「オンプレミス」といった言葉が聞かれるが、実際にはどのような違いがあり、どちらが企業に適しているのだろうか。今回は、それぞれの特徴とメリット・デメリットを解説する。

販売管理システムの基本
まず初めに、販売管理システムの基本を理解する。これは企業が販売活動をスムーズに行えるよう支援するシステムである

どっちがおすすめ？クラウドとオンプレの販売管理

***

 
 

販売管理システムとはどのようなものであるのか、そしてなぜ現在、多くの企業がクラウドベースのシステムを選んでいるのかについて解説する。

 

# 販売管理システムとは
販売管理システムは企業が商品の販売プロセスを効率化し、管理するためのシステムである。在庫管理、顧客管理、売上分析など多くの機能が含まれており、これらを一元的に管理できる。

 
 

## クラウドベースの販売管理システムのメリット
今やクラウドは販売管理の新常識である。これにはいくつかの理由がある。

- アクセスの簡便さ：どのデバイスからでもアクセスできる
- 安全性：データバックアップとセキュリティ対策が整っている
- コスト削減：初期投資が少なく、メンテナンスも簡易

 
 

## 販売管理システムの基本機能
それでは、販売管理システムの基本的な機能について詳しく見ていく。

 

### 1. 在庫管理
在庫の数量をリアルタイムで把握できる。品切れを防ぐだけでなく、余剰在庫も避けられる。
 
### 2, 顧客管理
顧客の購買履歴や好みを記録し、パーソナライズされたサービスを提供できる。
 
### 3. 売上分析
売上データを分析して効果的な販売戦略を立てられる。
 
 

# クラウドを活用した販売管理システムの導入ステップ
初めて販売管理システムを導入する企業にとって、以下のステップが基本となる。

1. 目的の明確化:何を目的にシステムを導入するかを明確にする。
2. 要件定義:必要な機能をリストアップする。
3. ベンダー選定:信頼できるベンダーを選ぶ。
4. デモやトライアルの利用:システムを試用し、企業に適したものか確認する。
5. 導入と教育:システムを導入し、スタッフの教育を行う。

 
 

# クラウド販売管理システムの未来
現在のクラウド販売管理システムは、業務効率化の基盤として多くの企業に採用されているが、その未来はさらに輝かしいものとなりそうだ。
ここでは未来の販売管理システムがどのようなものになるのか、いくつかのポイントを挙げて検討してみよう。
 

1. AIとの連携
 - 未来の販売管理システムは、AI技術をさらに深く統合することで、自動的に顧客の傾向を分析したり、在庫管理を最適化したりすることが可能になるだろう。

2. IoT（モノのインターネット）の活用
 - IoTデバイスのデータを利用して、在庫管理や供給チェーンの管理をさらに効率的に行えるようになる。例えば、商品が自動で注文される「スマートオーダリングシステム」の導入などが進むだろう。

3. 高度なセキュリティ
 - クラウドサービスの普及に伴い、セキュリティも日進月歩で進化していく。未来の販売管理システムは、高度なセキュリティ技術を取り入れて、データ漏洩などのリスクをさらに低減する。

4. 持続可能なビジネスモデルへの貢献
 - クラウドシステムを活用することで、企業はリモートワークを推進し、オフィスの必要な面積を減らすなど、環境負荷の低減に貢献する方向で進化することが期待される。
 
 

# まとめ
クラウド販売管理システムの未来は非常に広がりを持っており、今後の技術革新と連携してさまざまな可能性を開く。
様々な最先端技術の統合によって、販売管理システムは企業にとってさらに重要かつ強力なツールへと進化するだろう。
この変化を見据え、現在からクラウド販売管理システムの導入を検討することは、未来への賢明なステップと言えるのだ。

ここでは未来のクラウド販売管理システムに期待される進展について触れた。技術が進化することで可能になる新しい販売方法や効率的な運営方法を探求することで、企業は競争力を高めることができる。
だからこそ、企業はこの技術の進歩に目を向け、その準備を進めるべきなのである。

販売管理とクラウドの組み合わせにより、ビジネスは新たな局面を迎える。この記事が初学者の方々の第一歩となるよう願っている。





販売管理システムとはどのようなものであるのか、そしてなぜ現在、多くの企業がクラウドベースのシステムを選んでいるのかについて解説する。

販売管理システムとは
販売管理システムは企業が商品の販売プロセスを効率化し、管理するためのシステムである。在庫管理、顧客管理、売上分析など多くの機能が含まれており、これらを一元的に管理できる。

クラウドベースの販売管理システムのメリット
今やクラウドは販

Leisurely Strategy
with
Effectuation and Causation

BLOG

2024年問題～物流業界の課題とは～

効率化と適応力はトレードオフである

Fit to StandardによるERP導入

Leisurely StrategywithEffectuation and Causation

BLOG

2024年問題～物流業界の課題とは～

効率化と適応力はトレードオフである

Fit to StandardによるERP導入

Leisurely Strategy
with
Effectuation and Causation