読者です 読者をやめる 読者になる 読者になる

EverLearning!

野本 竜哉 による、ICT機器を活用した学習の動向をレポートするブログ。ここでの投稿内容は、所属組織を代表するものではなく、あくまで個人としての情報発信となります。

開発者の論理、運用(利用)者の論理

このブログは教育関連の話題を扱うブログですが、今日はちょっと教育に限定しない話題を書いてみたいと思います。組織内で、システムを開発(または導入)する側と、それを利用する側の話です。
たぶん、すごくあたり前のことが書いてあるだけなので、そんなに気負わず読んでみてください。あー、あるある、くらいの気持ちになっていただければそれで充分です。

基本的に多くの組織内では仕組みやシステムを「作る」もしくは「導入する」担当と、それを「使う」もしくは「運用する」担当に分かれていると思います。当方は社会人まだ7年目ではありますが、これまでに両方の立場を経験させていただきました。その中で、立場が変わるとモノの見え方が変わるということを「社内システム」を例に挙げて話をしたいと思います。

 

社会人1年目、私は社内システムを「使う」、いわゆるユーザーとしての仕事を経験します。

そこで日々感じていたのは
・なぜ使う側の立場をここまで考えていないシステムなのか
・何でもかんでも備考欄で吸収するのはいかがなものか
・この手作業でやる所をシステム化すればもっと人件費が浮くのに
・1分1秒が惜しいのに、なぜこんなトロいシステムを使うのか
・業務手順の変更や改善をなぜきちんと作り手は説明してくれないのか
といった不満でした。

大学〜大学院で一つの研究室内システムを作り上げた経験もあったので、「ちょっと手を加えれば直せそう」と見える部分は沢山目に付きました。そこでいくつかは「具体的にこうしてはどうか」と提案をしたこともありますが、ちょっとした仕様変更(文字を入力する枠を追加したり、条件フラグをひとつ増やすなど)だけでウン十万円かかる、などと言われて玉砕し続けました。
とはいえ、ただで引き下がるのは嫌だったので、ExcelVBAなど使えるものを活用して効率化ツールを作るなど、工夫や提案を続けてみました。そうしていたらある時、社内システムの開発プロジェクトに関わる機会に恵まれました。

そこで、今までとは正反対の立場を経験します。

システムの開発や改修は、ヒト・モノ・カネ・時間との戦いでした。限られたリソースの中で結果を出さなければなりません。しかも、ユーザーに要望を聞くと、とても消化しきれないほど大量の意見が出るし、最初に聞いた時に出てこなかった要望が、締め切りをだいぶ過ぎた後に出てくる(しかも重要で絶対に実装しないといけなかったりする)ということもよくありました。
こうした事情から全ての希望を満たすことはまずできないという現実に直面します。よって「割り切り」をするわけですが、その時に真っ先に削られる候補に挙がるのが「システム内であったら便利だけど、別の方法でカバーできるよね」という機能です。

例えば、画面内にひとつ入力枠を追加してほしいというケース。Excelや紙であれば枠を書くだけでOKなので「簡単でしょ?」と思われがちです。しかし、システムとなると、枠を増やすためにはデータベースやそのテーブル構造をまず理解し、どこに変更を加えれば良いかを把握し、その変更による影響がありそうな部分(特に他のシステムと連携する部分)を特定し、試験環境で動かしてみて大丈夫か、では本番の環境に導入したらどうか…などかなりの部分の精査が必要になります。こうした検証や試験に加え、仕様書の書き換えや、新機能の説明会とその資料の作成するなど、相当な手間がかかります。このあたりは実際に経験してみて、なるほどこれは「ウン十万円」というコストは適正だったんだな、と納得したのを覚えています。(ちなみに、この話は”内製開発”、つまり業者に発注せず自分で作る、という経験を元に書いています。もし外注していたらたぶん桁が違う数字になっていたでしょう…) 

結局、ここにかける時間と手間をかけるのであれば、現場には数秒間の負担や手間になってしまうものの、「申し訳ないですけどExcelで…」とか「備考欄に手入力で追記してください…」というのが費用対効果という意味で現実的な答えになるわけです。

細かい例を挙げるとキリがないのですが、開発をやってみた結果、過去の自分の持っていた不満について自分自身で回答すると、以下のようになってしまいます。

・なぜ使う側の立場をここまで考えていないシステムなのか
 -> ヒアリングを重ねても、システムを毎日使っている人と同等に詳しくなるのは難しいです…。

・何でもかんでも備考欄で吸収するのはいかがなものか
・この手作業でやる所をシステム化すればもっと人件費が浮くのに
 -> 上記の例の通り。システムを使う人の人件費が浮いても、作る側や展開する側の人件費がそれを上回ってしまうと「やらないほうがベター」なんです…。勿論コスト以外に人命や安全などもっと重視するものがある場合は、この限りではありません。

・1分1秒が惜しいのに、なぜこんなトロいシステムを使うのか
 -> システムの動作速度はいろんな要因で決まるため、全体的なパフォーマンスの向上はかなり難易度が高くコストに見合わないケースが多いです…。これについてもコスト以外の重要要因がある場合はこの限りではありません。

・業務手順の変更や改善をなぜきちんと作り手は説明してくれないのか
 -> すみません本当はもっとちゃんと説明したいんです。でも人や時間が足りないというのが本音です。説明文書や資料はきちんと作っているので、最低限そちらをみていただければ…。

 

とはいえ、双方言い争っても何の解決にもならないので、それぞれ持てる手段で歩み寄るためにも対話は絶対に必要です。どうしても利用者にカバーしてもらわないといけない場合は、そのほうが全体を見た場合に効率的であることを理解してもらえるよう、きちんと説明することは最低限必要でしょう。

一方で両方の立場を経験してみて重要だと感じたのは、システムを「使う側」の人間も、こうした「作る側」や「導入する側」の事情を理解するように努めることです。開発や提供をする側に文句や愚痴ばかり言ったり、費用対効果が低い機能改善を強く求めてばかりいると、開発/導入を行う側はどうしてもその人を避けたくなってしまうものです。

実はこの話は、システムに限ったことではなく、仕事をする上でのあらゆる面で重要なことだと私は考えています。異なる立場同士で話をする時には、相手の事情をまず理解しようと考える。不満に思っていることが実現できないのには、なんらかの理由や制約条件があると考えて、事情を聞いてみる。実はこれができる人は意外と少ないので、大抵の場合は「この人は自分を理解してくれそうだ」と見てくれて、腹を割って話してくれます。すごくあたり前の話ではありますが、改めて、自戒も込めて書き残しておきます。


最後に、一応教育についての話題を扱うブログとして、自分が大事にしている言葉を示して終わりにします。
 

学びの多くは相互理解から。争いの多くは相互不理解から。

 

今後も様々な立場の方とお話しをし、知らないことを補うため自らも学ぶ、ということを続けていきたいと思います。

 

※ちなみに、今回のエントリーはあくまで組織内に閉じた話をしています。これがモノの売買など「組織外」が絡む話になるとだいぶ事情が変わってくる部分がありますが、その辺は要望があればまた書きます。