プロジェクトオーガナイザの吉田聖書です。
前回は、コンピュータ・プログラムの
構成要素について書きました。
どんな複雑なプログラムであっても、
必ず「入力」「論理」「出力」という
3つの要素から構成されるということでした。
今回は、それをプログラム以外のことに
応用してみたいと思います。
さて、プログラムの構成要素は
- 入力
- 論理
- 出力
とお伝えしました。
普段「論理」のところは
「ロジック」と言ったりしているので、
同じように全て英語で言いかえると、
- 入力 ⇒ input
- 論理 ⇒ logic
- 出力 ⇒ output
のようになります。
会話ではこちらの方がなじみやすいでしょうか。
この構造の意味するところは、
出力は入力によって決まるという点にあります。
プログラミング言語によっては
関数という仕組みがあります。
関数は英語でfunctionと言い、
functionはまさに「機能」を意味しています。
数学の関数（函数）を連想するかもしれませんが、
数学の関数も、まさに、入力xを与えると
何か分からない関数fがyという値を出力するもので、
y=f(x)
と書きますよね。
この時、xが入力、yが出力、fが論理です。
yの値はxの値に依存するのです。
この考え方はプログラム以外でも応用が利きます。
例えば人に質問する場面で
なかなか知りたい情報を聞き出せない
というケースがあるでしょう。
そういう場合、大抵は質問が悪いのです。
質問の粒度が回答の粒度を決めます。
質問が具体的であれば
具体的な回答が得られやすいですが、
質問が抽象的であれば
回答も抽象的で
あいまいなものしか得られないでしょう。
それは自分が回答する立場になってみればわかります。
一般論で質問されたとしたら、
一般論でしか回答のしようが無いですよね。
だから、具体的な回答が欲しければ、
前提条件をいくつか想定するなど
具体的に質問するようにしなければなりません。
アウトプットを変えたければ
インプットを変える必要があるのです。
これは仕事などの活動に対しても言えます。
メンバーに作業指示を出しても
成果が得られない時があります。
そんな時、漫然と指示を繰り返していても
成果が上がることはありません。
仕事の場合は、
インプットに環境や相手の状態等も含まれます。
同じことをしても環境によって結果は異なりますが、
環境を変えることができるのであればそうすればよいでしょう。
ただ、一般的には環境を変えることの方が困難であるため、
より良い成果を手に入れたいのであれば
指示というインプットを変えていく必要があります。
最後になりますが、
これらは考え方のモデルであって
あらゆるケースにあてはまるかというと
そんなことはありません。
ただ、ISO（国際標準）でいう
プロセスアプローチというのは
まさにこの発想であり、
1つのプロセスに対して活動以外に
インプットとアウトプットが定義されます。
以前「プロセス・マッピング」というアイデアを紹介しましたが、
このアイデアはこのモデルに基づいています。
「作業は何かしらの資源を成果物に変換する活動である」
と定義し、作業と成果物の連鎖によって
活動の全体を表現しようとしています。
こういうことからも、
インプットの質がアウトプットの質を決める
というのは自然な発想なのです。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。