業務用にしろ、社外サービス用にしろ、およそシステムというものはソフトウェアと人間の協働関係を構築することにあります。当然高度なシステムになればなるほどソフトウェアに期待する機能は多く複雑となり、そのロジックや運用も複雑なものになりがちです。それを作っていくために社内外の多くのメンバーが参加し、完成という一つの目標に向かって進むわけですが、終盤になればなるほど難しい局面に陥ることがあります。それにはいくつかの原因や対応策があるのですが、たいていの場合、納期や期限・投資費用との折り合いをつけることが難しい局面に陥ります。

例えば、１～１０までの機能を作る、という目的となっていても、それぞれの機能には複雑な要素が絡まっていて、簡単な機能もあれば最後まで相談しながら細かいところを決める作業が伴うものまであります。前述したとおり、システムとはソフトウェアと人の協働関係を構築することですから、人がどこまでやるのか、ソフトがどこまでやるのか、最後まで細かく決まらないことがあります。たとえ技術者さんに要求仕様をあらかじめ示していたとしても、ソフトウェアがだんだん完成してくると、それまで想定していなかった操作性の問題も発生してきてしまい、どうしても「そもそも、この機能の目的は・・・」という議論に立ち返りがちです。その議論が「度を過ぎる」と当初の要求仕様から逸脱し、その結果費用も日程も計画を割れて行ってしまう、というリスクが顕在化します。こうなってしまうと、「作り切る」ということがだんだんと難しくなってくることになり、システム化失敗のにおいも感じられるようになってきます。逆にそれを感じることができずに最終的に炎上すると完全な失敗に至ります。

このような「失敗のにおい」は、毎日システムのことを考えている当事者にとっては感じにくいものです。嗅覚が鈍っていると言ってもよいでしょう。「当初の目的や目標に対してメンバーの議論が漂流している」という状況は、責任者である社長自身が気が付かなければいけないことになります。その際、あくまでも「当初の目的と目標やアプローチに立ち戻る」ことに専念するべきです。社長まで「そもそも論」に参加し、ベースを保とうとする人が誰もいなくなってしまうとそれこそ空中分解しますし、「第一歩」を記すこともできないままプロジェクトそのものが瓦解する危険性が高くなってしまいます。

システム化というものは、「最初から全部完成するものではなく、不完全なものであったとしても少しずつ良くしていくもの」なので、「そもそも論」に代表される「あるべき姿」を追求しすぎるのは好ましく無いのです。あくまで程度問題なので、あるべき姿を追求することまでを否定するものではありません。あくまでも程度問題です…。このあたりの割り切りや、段階的なアプローチに立ち返ることが当事者の方々には難しい場合があるため、「システムを作りきる」ことが難しいことも発生するものなのです。全てがケースバイケースですので、鉄則を述べる様なことができませんが、「いったんはじめた以上、まずは不完全でも完成させるのが第一で、どんどん改善してゆく力を維持し続けるのが次にやること」とご納得頂くことしかありません。

どんなことがあっても、空中分解させない、という根性がシステムを作りきる為に最優先されるべきなのです。