課題解決のプロセスと手段の目的化

かつで学校の授業にて課題解決のワークショップの講義があったのですが，そのプロセスが結構汎用的だなと思ったので紹介しようと思います．また，クライアントワーク（受託）でモノづくりの仕事に従事しているのですが，その中で「手段の目的化」という陥りがちなミスがあったので，課題解決のプロセスと絡めて紹介できればと思います．

学校で学んだ「課題解決のプロセス」

学校で学んだ課題解決のプロセスは以下の図の通りになります．

課題解決のプロセス

まず，現状とあるべき姿（理想）を把握することが重要です．例えば以下のケースが挙げられます．そして，現状とあるべき姿とのギャップ（＝問題点）を明確にする（Step 1〜3）ことで，取り組むべき課題を明らかにします．例えば，

a) エンジニアの残業時間「100時間/月」（＝現状）を「10時間/月」（＝あるべき姿）にしたい
　→残業時間が多すぎる

b) ある事業について，年間110％成長（＝現状）から年間150%成長（＝あるべき姿）に上げたい
　→事業が伸び悩んでいる
など

などの例があります．ポイントとして，対象となっている人・モノ・領域（チームなど）は何か，それらが今どのような状態なのかを明確化することです．特にモノづくりの領域になると，これから作るモノのユーザってどんな人なのか，どんなことをしているのか，どのような状態なのか明確化しないと，モノをつくったところであまり解決できない可能性が高くなります．

次に，取り組むべき課題を明確にするために，そもそもその問題点を生み出している「現状の原因」を洗い出します（Step 4）．例(a)エンジニアの残業時間「100時間/月」であれば

• プロジェクトで割り当てられているリソース（人や時間）が少ない

• エンジニアが取り組むべきタスクが多すぎる

• 不要な会議に参加している   など

といった原因が挙げられるかと思います．

現状（とその原因）・あるべき姿・問題点を洗い出し分析することで取り組むべき課題を設定します（Step 5）．同じく例(a)の場合，

• 課題1. プロジェクトで割り当てられているリソースを増やす

• 課題2. エンジニアが取り組むべきタスクを調整

といった課題が設定できるかと思います．
設定した課題に対してどのような解決策を考え列挙します（Step 6）．

• 課題1. プロジェクトで割り当てられているリソースを増やす

  • 解決策1-1. 人を採用する

  • 解決策1-2. 納期を伸ばす

• 課題2. エンジニアが取り組むべきタスクを調整

  • 解決策2-1. やる内容とやらない内容を予め決めておく

  • 解決策2-2. 一部のタスクをシステムで自動化させる

列挙した解決策を選定し，必要に応じて構築/実装し，運用していきます（Step 7）．

手段の目的化とは

この課題解決のプロセスで大事なこととして「手段の目的化」を防ぐということが挙げられるかと思います．「手段の目的化」とは，あるべき姿を実現するために解決策を列挙・選定したはずが，その解決策を実行すること自体が目的化してしまうことを指します．例えば，顧客の作業効率を上げることを目的として自動化システムを導入するはずが，いつしかそのシステム・機能を導入することが目的化してしまっているということです．

学校の授業では，先述の図で言う「7. 解決策の構築/実装」はありませんでした．ただ，手段の目的化が起きないように，「手段」と「目的」の差を明確化する為に設置しました（つまり，目的が「2. あるべき姿」，手段が「6. 解決策」〜「7. 解決策の構築/実装」に相当します） ．

そもそもこのシステム・機能は何の為にあるのか，その目的を明確化してチームで認識を合わせておかないと，解決策を実施したところであまり効果が見られずリソースの無駄遣いに終わってしまう可能性があります．そのために，あるべき姿を制定し，認識合わせをする必要があります．

私自身まだまだこの過ちを冒してしまいそうな時が偶にあるのですが，その時は今から構築・実施する解決策って何の為にあるんだっけということを念頭に置いて取り組むようにしています．