言葉定義の無理解は思考を曖昧にする（１）目的、目標

言葉の定義を理解せず曖昧なまま考えを進めると、思考過程が曖昧になりどこかで論理が破綻します。
「元コンサルタントのつぶやき(1)正しい考え方、伝え方の心得<その１>」
の冒頭でも若干触れましたが、この点について私の考えを記します。
（何回かに分けます）

●　定義を理解せずに安易に使われている単語群　●

数多くあります。
日本語で似たような意味（単語）に見えても、その内容は全く違う、という場合が多いので定義や使用方法に悩んだら、該当する英単語等で本来の意味を探るべきだと思います。

例として、
(1)　目的（objective）と目標（goal）
(2)　問題（trouble / problem）と課題（issue）
(3)　アクシデント（accident）とインシデント（incident）
(4)　改善（improvement）と改革（innovation）、変革（transformation）
(5)　初歩（introduction / orientation）と基礎（basis / foundation）
(6)　学習（learning）と習得（acquisition）
(7)　戦術（tactics）と戦略（strategy）
などがあると思います。
（なおカッコ内の英単語は必ずしも辞書等で出ているものではありません）
基本的には、各項番の後ろに上げたものほど、意味を間違って使うとまずいものという認識です。

●（１）プロジェクトでよく誤解される、目的、目標　●

　例えば業務系ERP導入プロジェクトなどにおいて、稼動前のユーザー受け入れテスト（UAT：User Acceptance Test）やシステムテスト（ST：System test）段階まで来るとこんなことを言いだす人が必ずでます。

「プロジェクトが『システムを導入すること』を『目的』にしてしまって、本来やりたかったこと（目的）に向かってない！」

　ごもっとも、という場合もありますが、
「システムサービスインという『目標』に向かっているプロジェクト現状の『目的』と『目標』への無理解」
がある一定割合であったりします。

　昔ながらのウォーターフォール型開発では、局面開発技法（フェージングアプローチ）をとるので、最終フェーズ（UATとかSTフェーズ）で、
　「システムの予定通りのサービスイン（導入）」
を目標にするのは当たり前。ここまで来て「やりたかったことと違う」というならば、もっと前の時点で「変更管理」として途中で要件変更などすべきなのです。または、開発技法を変えるとか（スパイラル型とかアジャイル型とか）。そのための「進捗管理」「文書管理」「変更管理」です。

--------------
　「目的＝ 目指すべき方向性と共有された価値観に基づき実現すべきこと」
　「目標＝ 目的実現のための手段・ステップ」
です。

２年とか掛かるような「目的実現策」に「２年後の目標」だけ設定するのは無理があって、１年・半年毎とかマイルストン単位（基本構想、要件定義、概要設計、詳細設計、統合テスト、ユーザーテスト、システムテスト等）で中・小目標を設定するのが普通です。

上記ではシステム開発を例に取りましたが、一般の企画、プロジェクト、業務プログラムの実行過程（いわゆるPDCAサイクル）でも常に意識する必要があります。

なお、プロジェクトものなどでは、
・目的
・目標
・（背景にある）価値観の共有
の３点が極めて重要で、スタート段階でこの明確な理解と合意が無いとはじめから失敗が見えているようなものです。

続く（（２）～（７））