小ネタ:小難しい話と保守

小難しい話は誰だって嫌い

私のヨメは、一時期PC製造業のコールセンター業務、しかも社内の障害受付業務に従事していたこともあり、多少コンピュータ関連には詳しいのですが、さすがに私のように普段の仕事がIT関連ではないので、私がIT系の話をしても何が何だか、という顔をするのは当然です。

これが対クライアント、という話になると、ただチンプンカンプンというだけではなく、「技術的にはいろんなことを知っている人なのだけれど、言っている意味が分からなくて困る」という不信感につながります*1

開発と「小難しさ」と保守

開発そのもののプロセスについても同様で、クライアントに納品するものについては基本的にクライアント自身がある程度手を入れられるようにするのが「親切」なんだろうな、と考えるようになりました。もちろん、手を入れてはいけない個所について(根本的なロジックなど)はブラックボックス化していていいわけですが、外部ツールとの連携などについては誰でもいじれるような状態にしておいた方が、外部ツール自体のバージョンアップなどでクライアント自身が手を加えることがやりやすくなるという点で有益なのではないでしょうか。

DevOps的な概念ではありますが、私はそのあたりを意識することが多いです。実際にクライアント側がいじれることで私の仕事が減るのか、と言えば実際にはそうではなく、DevOps的に言えば、運用レベルでこちらに依頼を受けるというケースであったり、技術支援のレベルでのフォローを行う依頼があったり、と、スポットでの修正依頼よりも長くクライアントとお付き合いができるようになり、当然その方が売上としてはうれしい状態になってくれるわけです。

例:自動連携ツールの利用

例えば、という話ですが、このブログは、記事がブログ(はてなブログ)に公開されると、

  1. はてなブログ標準機能でTwitterに投稿があったことをお知らせする
  2. Twitterはてなブログの投稿があるとIFTTTによりFacebookページに投稿する

というやり方でSNSへの投稿をしています。技術者的には「ありがちなやり方」ですし、『簡単』ですのでクライアントに対してもこの方法を提案してしまいがちなのですが、クライアントにとって、IFTTTに関してだけは「よくわからないツール」となりがちです。

IFTTTに限らず、この手の自動連携ツール(ZapierやIntegromatなど)は確かに楽ですし、もっと一般に広まってほしいな、とは私も思うのですが、技術的な面で1つ大きな問題を抱えています。自動連係ツールは要するにAPI同士をつなげるための仕組みなわけですが、それぞれの出入り口となるAPIの仕様は固定ではないため、仕様の大幅変更や旧仕様の利用制限等が発生した場合*2に想定している機能が使えなくなり、更にこの設定変更、ただ自動連携ツールにログインして再認証であったり認証コードの取得や再登録などの『簡単』な作業を行う必要があります。

『簡単』の尺度の違い

『簡単』と技術者が思っているので、クライアントに対しても「カンタンな作業なんでやっといてください」と言ってしまうのですが、非技術者であるクライアントが再認証のボタン一つで済むならともかく、なんかどこか見たこともないようなサイトにアクセスして、謎の文字列をコピーして、それをまた、見た覚えがないとは言わないけれど数年に1度くらいしかアクセスしない画面の小さい枠の中に貼り付けてボタンをいくつか押す、とか、怖くてできないわけです。壊してしまうじゃないか、コレで壊れたら自分のせいになっちゃうじゃないか、と。

保守の引継ぎをするケースはフリーランスなので多いのですが、意外と保守をしてほしいという理由がこういうところにあったりします。元の保守をやっていた会社が小難しい事ばかり言い、お金ばかりむしり取っていく、という印象を持っているクライアントさんのなんと多い事か。

反省

技術屋として、最先端の技術を使ってすごいことをするのは「当然のこと」であって、そのすごいことをすべてではないけれどある程度の部分がクライアントでもできるんだよ、という状態にすることができるのが本当の姿なんじゃないのかな、と思います。

*1:技術的に大変難しいということを専門用語を並べて述べ、その費用として大変高額である、ということを伝えたとして、言った側は根拠をきちんと示したつもりでいるわけですが、聞いている側は根拠そのものを信頼していいのかどうかがその内容からは判断できないわけで、よくわからないことばかり言って煙に巻いているのではないのか、と感じてしまうわけです。

*2:これが顕著なのがFacebookTwitterだったりします。