かざいむ日誌

IT関係で知ったことなどを記事としてあげていきます。内容に不備や質問などあればぜひコメントをよせてください。

問題解決型と、比較優位型という課題へのアプローチ

今日同僚と話しててなかなか話が伝わらなかったので他の人の意見が知りたい。システム開発するときは、問題解決型で開発の提案をしますか?それともシステム導入後のメリットで開発を提案しますか?これまで、業務システムでは問題解決を主としつつ、メリットを混ぜた案件に入ることが多かったように思う。

この問題解決型とメリット型について最初に知ったのは大学で所属していた英会話サークル(ESS)の活動だった。このサークルはいくつか活動があり、私は政策などを英語で議論するDiscussionユニットに入っていた。そこでは課題に2つのアプローチをする。

  • Problem-Solving (問題解決型)
  • Comparative Advantage(比較優位型)

1つ目の問題解決型では、現状こんな問題があり、それによってこういう害が出ている。それを解決すべきだという点でまずコンセンサスを取り、次に具体的に何をすべきかを提案する。一方の比較優位型は現状はこう、次にこういう政策を考えています、これを実施したらこんなメリットがあります。どうでしょう?という具合に話を進める。

最近私が入っているプロジェクトでは1つ目のアプローチを徹底するように上司からもアドバイスされている。これをやりたいから援助してほしいという話が出たときに、上司がbeaurocratic redundancyは避けようと言っていた。beaurocratic redundancyとは官僚は仕事を増やしがちというような意味合いで使われると理解している。やった方がいいことをやっていくと、どんどん無駄な仕事が増える。

問題解決型についてもう少し詳しく言うと、もし何か援助してほしいと言われたら具体的に今何に困っているか、現在それに対して具体的にどんな行動をとっているか、というのを聞き取りそれらからその課題について相手が問題意識を持っていて、取り組んでいる場合にのみ、何をするのかを考えるのだ。

援助の話でいうと、やった方がいいことはいくらでもあるし、やりたいと思うが、足していくときりがない。そうすると本当に解決すべきことに取り組む余裕がなくなってしまうかもしれない。学校のカリキュラムも同じで、金融教育もやったほうが良いし、英語も勉強できた方がいい、問題解決やリサーチとかもできたらいい。でも、授業時間は限られているので、全部を細切れにしてカリキュラムを組むと、その分野に詳しくない先生が、知らないなりに教えることになり、なんだか本末転倒な結果となる気がする。

こういうことは民間企業では起きにくい。企業であれば利潤という評価指標があるからだ。だから公共部門はという話ではなく、評価軸が一つではない公共セクターはできたらいいことを足していくと大事なことができなくなるから、慎重にしないといけないという教訓なんだと思う。