TumblrPocket中小企業(弊社もですが)において、「この作業、大変なんでシステム化できないかな?」という状況がたまにあります。このような場合、システム開発会社に見積を依頼して検討する、ということになるということが多いと思います。見積の結果、コスト的に見合わないと判断する場合もあります。導入を決断したが効果がいまいち、というのも聞く話ですので、判断は慎重になるでしょう。ここまで比較的よくある流れかと思います。ここで個人的には、あくまで一例ではありますが、「その大変な作業を分割・再配置することで分業はできないか?」と検討するプロセスを、加えてはいかがかと考える次第です。「そんな検討はもうやったし無理だったよ!」という声も出ると思います。経験上、この検討は十分ではない場合が多々あります。現状の作業は既に最適化されているわけで、最適化した本人がこれを打開することは、想像をはるかに超えるレベルで困難です。その最適化は必要があるからなされているわけで、それ以前の状態に戻した姿で考えるということは、その最適化のアイデアや、かけた時間と労力を否定されるように感じてしまうためです。これは、視野が広い狭いという問題ではなく、いわゆる「成功体験の罠」としての面があるということです。実際の組織内での人間関係では、非常に困難なポイントとなります。我々は直感的に「経路途中の現在地からどうルート変更すればゴールに速く着くか?」というような思考を優先させる傾向にあります。実際にはスタートからゴールに至る手段が変わるわけですから、経路自体を見直す必要があるわけです。経路を変えることが目的ではありませんので、結果として途中まで同じ経路を選択することも十分ありえます。検討してみたら実は既存のスタートとゴールの定義があいまいだったり正しくなかったり、ということが発覚することも多くあります。単独でうまくいっていると考えられていたプロセスが、実は以降のプロセスでカバーされることによって成立していた、という事実が判明することも多くあります。既存の成功自体が盤石なものではなく「たまたまうまくいっていた」という可能性も十分ありうるのです。した再構築は、システム化を検討する際にどのみち必要になります。分割・分業の検討がうまくいかなかったとしても、そこで出した選択肢は非常に有用であるわけです。そもそも分割・分業ができるようになれば、その時点で現状の「大変な作業」は解消され、システム化すること自体が必要ではなくなるかもしれません。それはそれで目的は達成するわけですのでOKですよね。繰り返しにはなってしまいますが、必ずしも頭が固いとか視野が狭いという問題ではないのだと思います。成功体験によって選択肢が増やせなくなるということは誰にも起こりえます。認識しづらいし打開が難しい場合があるということを、スタートラインに置いて考えてみるというのも一案ではないかな?と考える次第です。技術担当取締役を中心に技術者が書いております。プログラミング・サーバー/クラウド技術などについての小ネタから、システム化にまつわるあれこれや、プログラマー教育、そこから発生する様々な考え方などまでご紹介。