123.技術力より課題解決力が重要

初回：2021/1/13

1.本題に入る前に

　この間『118.EXCEL方眼紙の正しい使い方』というコラムに対して、Horusさんが『Excel方眼紙？そんなのは好きにすればいい。』というコラムを書かれました。その内容にではなく、コメントで『Excel方眼紙が効率的というのは全面否定しておきます。』とのこと。全面否定されていることについてはその人の自由なので別段何とも思わないのですが、効率的かどうかについて、少し考察しておきたいと思います。

　まず、効率的という場合『何に対して』効率的なのかが重要です。まあ、Horusさん特有の言い回しなので、効率的を全面否定したからと言って、非効率とも言われていません。効率的を否定するというのは、普通か非効率という事なので、私としては効率的な場合もある事を示す必要があります。

　そして、効率的とか効率的でないという議論を行う場合、効率的という前提を示す必要があります。例えば、リッター当たりで何キロ走れるのか＝燃費の効率と、1000CCのエンジンで何馬力（今ではPSではなくkW表記ですが）出せるので燃焼効率が良いとか、まずは何に対しての効率性なのかを明確にする必要があります。

　そこを論じることなくExcel方眼紙が効率的だと言っても、議論がかみ合いません。このあたりを考慮しながら、私の考えを述べておきたいと思います。

　私がシステムで考える効率性とは、生まれてから死ぬまでの全期間に渡る効率性です。システム開発で良く効率性が話題になるのは、作る部分だけの場合が多いように感じます。あるシステムを効率よく作ったとして、それの維持が非効率だと、そのシステムが生まれてから破棄するまでの全期間のトータルにおいては非効率になる事があります。6か月で作ったシステムを10年使い続ける事を考えれば、保守の効率性はもっと重要視されるべきでしょう。さらに、システムが死ぬ瞬間、普通は別のシステムにリプレースします。このリプレースまで含めて効率的かどうかを検討すべきだと思います。

　Excel方眼紙で再利用しない議事録や簡単な帳票系の資料なら、作成するだけで保守しないので非効率にならないと思います。逆にこれで統計情報を表示したり月次推移や予実判断などの基礎資料にする場合、使いまわすことになったり複雑な数式で処理したりすると、保守やその後のシステム化で必要以上に工数がかかったりします。その場合は非効率だと思います。なので私がExcel方眼紙を使う場合は、複雑な数式が必要になったり月次推移など、継続して使用するような所には使いません。

　つまり、私個人としては、効率的と思われる所でしか、Excel方眼紙を使わないので、Excel方眼紙は効率的に使える（つまり、全面否定に対して部分否定）と考えています。

2.技術力と課題解決力

P子「やっと私の出番が来た」（※1）

　よく、技術力が重要とか、技術力を付けよう、技術力のない技術者は死ねとか言われていますが、私はそうは思っていません。

P子「誰も、死ねとか言ってないわよ」

　先ほどのシステムの効率性を考える場合、私は保守の重要性を重んじています。例えば、最新技術で構築したシステムが、10年後も使い続けた場合、本当に保守できるのか？を十分に考える必要があると思っています。

　Javaをやり始めたころ、Appletでシステム構築というのが流行った時期がありました。私もそのプロジェクトに参加したことがありますが『こりゃあかん』と感じていました。実際、導入したシステムは、規模を縮小しつつ、部分リプレースを繰り返して廃止されました。実際、Java9以降はアプレット(Applet)は非推奨になっています。

　それ以外に一時的に流行っては廃れた技術は多いと思います。技術力＝最新技術を知っているというなら、そんな技術力は要りません。

　また、複雑な技術...例えばEXCELの各種機能を使いまくって高度な計算や複雑な統計処理を行った資料なんて、普通の人達にはメンテナンスできません。それは自己満足以外の何者でもありません。

　業務において、最重要なのは課題解決力だと思っています。技術力はその課題を解決する手段であり、技術者なら数ある手段の内、効率的（費用対効果が高い）手段を選択すべきです。

3.課題解決力

　私はシステムで課題を解決する場合、最低10年先まで考えます。もちろん、不確実な世の中なので外れることもありますが、顧客が望んでも最新技術は使いません。複雑な技術も使いません。

　Javaにしても、ORACLEのSQLにしても、複雑なことはしません。出来るだけ単純で判りやすい方法を採用します。

　ただし、最新技術を知らなくてよいとか、複雑な技術を知らなくてよいとは言っていません。使わないだけです。そうでないと顧客が聞きかじりの最新技術を使いたいとご要望された場合でも、反対（使わない手段）を提示できないからです。

　課題解決の手段は、システム構築だけではありません。人手で対応すべきところはそのままにすることもありますし、業務手順を見直す、場合によっては組織の見直しまで提言する場合もあり得ます。

　複雑な手法でしか問題が解決できない場合は、課題自体を分割するとか入れ替えを目指します。課題の入れ替えとは、その課題を直接解決するのではなく、原因となっている個所をずらして別の課題に置き換える事です。もう少し具体的に説明しないと伝わらないと思いますので、このあたりの課題解決手法については、別途（気が向いたら）書きたいと思います。

　一応、反論も予想されますので、お断りを入れておきます。

　最新の技術を使用することが目的のシステム（プロトタイプや実験的取り組み）や保守期間が短いシステムなどは、最新技術や複雑な手法で課題を解決するケースもあります。私の携わっている生産管理や工場設備系のシステムでは、長期間にわたって使用されることがほとんどなので、保守の比率が高くなります。

4.課題解決力の一例

　技術力は手段で、課題解決力を身に付けましょうという事ですが、具体的にどういう力が課題解決力なんでしょうか？

P子「要するに、課題を解決する力でしょ」

　言ってしまえばそうです。手段は何でも構いません。

　例えば、ある課題があった場合『その課題を解決できそうな人を知っている』そして『課題解決のアドバイスをもらったり手伝ってもらえる』人は、課題解決力があるという事です。それも、自分の部署の人だけでなく、他部署の人や他社の人なども知っている事は課題解決力になります。また、『課題解決出来るツールを知っている』、『その使い方を知っている人を知っている』もまた課題解決力があると言えます。

P子「他人任せね」

　少し違います。もちろん、自分で解決できる力を付ける事は大切です。でも、それも手段です。「要するに、課題を解決する力」であれば、何でもありです。

　そうは言っても簡単ではありません。特に、技術者にとっては。

　ここでは課題解決力をアップする方法を述べたいと思います。（私には出来ませんが皆さんなら出来るかも？）

　１．嫌いな人、苦手な人を作らない。
　　　　課題解決をお願いする場合に、幅広い人材活用するため。
　２．常にアンテナを張り巡らせる
　　　　誰が何の知識を有しているか。世間話は重要です。
　３．最新技術にもある程度精通しておく
　　　　課題解決をお願いする場合、丸投げはよくありません。
　４．お礼は忘れずに
　　　　ギブ＆テイクは基本ですね。

　技術者が技術力を付けるのは当たり前ですが、一人の技術者の技術力だけでは課題は解決できません。それに、技術者だからこそ、課題解決力を身に付けることが出来ると思っています。

　あなたが技術者だとして、口だけの管理者に従いますか？私は従いません。

P子「だから出世できないのよ」

　ほっといてください。

　でも、自分よりも能力のある技術者を敬（うやま）って力を貸してほしいと頼みに来る技術者になら、力を貸すでしょう。

　技術力だけにこだわるのではなく、課題解決力を身に付けるようにしましょう。

　ほな、さいなら。

======= <<注釈>>=======

※1　P子「やっと私の出番が来た」
　P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。

スピンオフ:CIA京都支店『妖精の杜』

　ここはCIA京都支店のデバイス開発室。安らぎを求めて傷ついた戦士が立ち寄る憩いの場所、通称『妖精の杜』と呼ばれていた。

　P子：CIA京都支店の優秀なスパイ。早坂さんにはなぜか毒を吐く。
　早坂：デバイス開発室室長代理。みんなから『妖精さん』と呼ばれている。

　P子：「早坂さんって、嫌いな人や苦手な人っているの」
　早坂：「目の前に...」
　P子：「シバくよ」

　P子：「早坂さんって、意外とアンテナ張り巡らしてるわね」
　早坂：「私のはパラボラアンテナなので張り巡らせていません」
　P子：「シバくよ」

　P子：「早坂さんって、意外と最新技術に詳しいわね」
　早坂：「P子さんこそ、昔の技術には詳しいですよね」
　P子：「シバくよ」