できていないことを約束するのか約束しないのか

おはようございます。

眩しいくらいの青空です。嵐の前の静けさでしょうか。

＝＝＝ほぼ毎朝エッセー＝＝＝

□□機能をしっかりと実装していく

ペーパーウェアという言葉は、その昔ビルゲーツが「さもできていると約束して後から開発する」ことを指した有名なものです。

ソフトウェアはそのモノ自体が見えないこともあり、本当に「できていない」のか「できている」のかの判断が難しい特質があります。

モラルの低い、ちょっと腕に覚えがある技術者であればそこらへんの人をだますのは簡単なことなのです。

そこでその手の「できていないことを約束して…」の後に、どのようなパターンがあるのかをざっと考えてみました。

１）できていないことを約束して出せないのか
２）できていないことを約束して拙速に品質低く出すのか
３）できていないことを約束して正確に実行するのか

もちろん、３）が理想ですが、なかなかそこは見抜けません。

そして、多くの「賢い」人たちは、約束をするなどというリスクは取らずに次の姿勢で望みます。

ａ）できていないことは約束せずに何もやらないのか
ｂ）できていないことは約束せずに自信なさげに出すのか
ｃ）できていないことは約束せずにしっかりと出すのか

もちろん、ｃ）が理想ですが、なかなかそこには至れません。やはり、約束があるから突破力もスピードも出るもの。

物事にはスピードと突破力といった、机上の空論だけでは成り立たないものが多く存在します。いわゆる〆切り効果。マンガ家などのクリエイティブな仕事こそ〆切りが重要だったりするものです。

コツは１）２）３）ａ）ｂ）ｃ）の存在を意識しながら、自分が何をやっているのかという大きな地図を頭に描いて置いておくことなのでしょう。