社員は大事にされなきゃ貢献もしない

4月――どこからともなく新入社員が会社に入ってきます。私も会社員をしている時間がずいぶん長くなってしまい、彼らを指導する立場になってしまいました。会社員をやっているものの、私は会社組織というものがあまり好きではないのだが、彼らには会社組織に愛着を持ってもらって、貢献してもらいたいと思います。それが仕事ですし(仕事自体はそんなに嫌いではない)。

自分をないがしろにする組織に、貢献しろとは無理な話でして、働いて欲しかったらこちらが良くしてあげなければならない: まともな給料を出す; 事務所はきれいにする; 研修には予算を出す; 自分がやりたくない仕事をおしつけない; ちゃんとした人と働かせる; 目を疑うような雑な仕事のメンテをさせない; そもそも仕事として成立していることをさせる。軽んじられていると感じたら、ちょっとでもやる気のある人はすぐに去りますし、そうでない人も組織を軽んじて邪魔をするでしょう。

こういうところは淘汰されたらいいのにと思うけれども、組織というのは意外にしぶといもので、なぜか存続しています。それは悪い組織であっても、支えている人がいるからで、こういう人らは世の中を悪くしているのではないかとさえ思います。仕事だからといって世の中を悪くしてよい法はないし、仕事はもっと尊いものであってもいいように思います。

私としましては、組織への忠誠心をもってもらって、組織に貢献しもらうためには、社員にはたくさん与えるべきだと思っています。給料・予算は経営者が決めることだから、私にはどうすることもできませんが、それ以外の私が操作できることに関しては、気持よく働ける環境を整えてあげるべきでしょう。それが仕事だというのもあるのですが、それが社会を良くすることだと信じているからです。それもかなり直接的に世の中を良くすることだと。仕事でやっているだけなので、当人からのお礼も感謝も求めてないのですが、仕事ですから会社からの対価は欲しいですね。

社員に与えるべきものといったら、学びです。会社というものはおっさんにこそ教育が必要だと思いますが、そうは言っても若者は学ぶことが多いし、学ぶ意欲が多少はありますので、何も学べないのはつらいものです。

逆に覚えることを覚えたら、返さなくても別の会社に行ってくれていいとも思います。人の入れ替わりが多いことが悪いこととも思ってないし、どこでも働けるしいつでも辞められるという状態になって、それでも働き続けたいと思えるところがよい職場だと思っていますので。会社の教育で得られたものであっても、能力に見合った給与なり機会なり環境を与えるのは、会社の責務であって、それをしたくないからと社員を囲いこむための人事制度を作ったり、学びを与えないというのは良くない会社だと思います。

私は良き師に出会えず(と自分では思っていて)、延々と無駄な時間を過ごしてきたので、自分がして欲しかったことは若者にはしてあげたいと、余計なお世話かもしれませんが、思うわけです。

実装に依存するな、仕様に依存しろ

仕様とはわかりくい概念です。辞書には次のようにあります:

製品や注文にあたって、あらかじめ定める仕上がり品の構造やデザイン。

仕様は発注者が定めて、受注者がそれに従うもののようです。仕様書を固めて、そのとおりに製造し、仕様書と照らし合せて完成品を検品する。一度つくっておしまいという工程であれば、これが全てでしょう。作って動いてで全てであれば仕様書なんて納品されたら燃やしてしまっても問題ないはずです。実際そういうスタンスのいい加減なところだと、仕様書は適当に共有フォルダに放り込まれて、管理もされていないでしょう。

しかし、仕様は実装を行う人や検査を行う人だけが参照するものではありません。仕様は、作る人だけでなく、使う人も従わなければならないものです。仕様として定められていることが満足されることを期待してよい――という約束事が仕様です。つまり、仕様とは利用者と提供者の「契約」です。契約とは双方が守るものであって、一方を縛るものではありません。

利用者は仕様にないことを期待してはなりません。同じ仕様を満たすやり方は幾通りもあります。ここではこれを実装とよびましょう。利用者は仕様に依存するべきであり、実装に依存するべきではありません。利用者は中身の実装なんて知るべきはないし、仮に知っていたとしても知らないふりをして、機能を利用せねばならないのです。このことを「デルメルの法則」と呼びます。

例えば、ある関数 getItem()AbstractItem というインターフェイスをもつオブジェクトを返すという仕様だとして、 ConcreteItem クラスを返す実装になっていたとしましょう。呼び出し側は次のようなことをしてはなりません。

ConcreteItem item = (ConcreteItem) getItem();

これの何が悪いのかというと、getItem()ConcreteItem 以外のものを未来には返すかもしれないからです。今は確かに ConcreteItem だけしか返さないかもしれませんが、そんなことを約束していなければ、他のものを返せれても文句は言えません。非互換だとか言われても、知らんがなとなります。

仕様に違反した使い方をして壊れたら、悪いのは利用者です。実装に依存するのは、ねこを電子レンジに入れるがごとき愚行です。

さすがに上記のような言語仕様で決められているようなものを、わざわざ無視して汚くしてしまう人は少ないですが、見た目に汚くないと人はしばしばこういうことをします。どこからか裏ワザを見つけきて、それを利用して問題を解決しようとするのです。どうも裏ワザを利用して問題を解決するのが、エレガントな解法だと思っているようです。

しかし、このような下手のハッカー気取りは間違っていまして、中身なんてどうでもよいことです。仕様書がないからブラックボックス化しているとしばしば言われますが、仕様書とはブラックボックス化するためにあるものです。利用者が中身に興味を示さないように用意するのが仕様書であるということを我々は理解するべきでしょう。

社会は素人ばっかりだ

社会に関する驚くべき事実の一つが、ほとんど全ての人が労働をして給与所得を得ていることです。大体の人は働かないと文化的な生活が維持できないので、何かしらの職業についています。当たり前のことではあるが、よくよく考えてみるとすごいことです。こんな社会が成立しているのは有史以来現代だけだし、未来には成立していないのではないでしょうか。

会社に入ったら次のようなことを言われると思います。

学生の時分は、親がコストを払い、君たちは教育というサービスを受けていた。しかし、社会人になったら、君たちは給与をもらい、対価として価値を提供しなければならない。

これは新入社員をビビらせるための方便で、プロ意識を持って仕事をしましょうというぐらいの意味です。間違ってはないし、私も新入社員研修をしたらきっと同じことを言うでしょう。

しかし、この言葉には嘘が含まれています。会社員はプロ意識を持って給料に見合った価値を提供してほしいというのは使用者の理想であって、実際にはサラリーに見合うだけの働きをしているサラリーマンなんていないということです。サラリーとはそれだけ払わないとそいつが生活できないという額を払っているだけで、そいつの働きに対するフィーではありません。働きに対して対価を貰っていたら誰も生活なんてできやしない。あなたが平均して1日1万円得ているとして、あなたが今日1日かけて資料を作ったなら、その資料に1万円の価値がありますか。本屋にあなたの資料が置いてあって、1万で買う人がいますか。いるわけがありません。

働きに商品価値がついて、それだけ稼げる人はサラリーマンなんてしなくてもよいです。少ないながらそのようなプロフェッショナルはいます: 士業、コンサルタント、作家、etc. そうでない人は諦めてサラリーマンをやっているしかありません。

逆に言うと、会社というシステムはすごくないでしょうか。プロ意識をもって仕事をしましょうと言ったところで、社会は素人ばっかりです。ほとんど全ての人が働いているのだから、達人ばっかりだったらおかしいですよね。ほとんどの人は高等教育を受けずに働きはじめ、そして、会社員は働き始めてからも、驚くほど勉強をしない。個々の仕事は素人のそれであっても、会社全体としては維持でき、従業員は生活できているのだからすごくないですか。サラリーマン地味た態度は好きではないですが、『サラリーマンは気楽な稼業と来たものだ』とはよく言ったものです。

ただ、このようなシステムがずっと存続できるとは思えません。たまたま一時期に成立していただけだと思います。企業が従業員の生活を維持する義務なんてありますか。企業がそれに気づけば、まともに給料なんて払わなくなる。実際そのようなことが起こっているように見えます。サラリーマンにはやさしくない時代が来るのでしょう。その先にあるのは、ベーシックインカムなのでしょうか。

設計は名前のことだけ考えろ

ドゥルーズという学者は

哲学とは概念を創造することだ

と述べていますが、現代で「概念の創造」という仕事を最も行っている職種は哲学者ではなくてプログラマでしょう。辞書を引くとコンピュータ用語が多く出てきます。それだけ新しい概念が作られたということです。辞書に載っている単語はもはや専門用語ではなくて、説明なしに一般に使うことが許される言葉ですが、辞書に載っていない専門家の間で常用される用語はもっと多いです。計算機が発明されて以来、膨大な概念が発見・発明されてきました。新しい用語を作るのが仕事だと思われている業界なので、現在も日々新語が生まれています。

言語というのは強力な思考ツールで、概念を抽出し、名前をつけると、さも実体があるかのように認識できるようになります。計算機自体は物理的な実体がありますが、その上で動いているプログラムは物理的な実体がありません。人間がこれを認識するには、概念を整理して適当な名前をつけて言語化しなければなりません。システムを導入する業務に対しても同じことが言えるでしょう。業務も物理的な実体がないので、概念を創造しなければ認識できません。

概念の創造は「モデリング」と呼ばれる仕事です。これができないと、おかしなシステムやプログラムになってしまいます。分かってない人がわけわからずに作るのだから当然です。

モデリングを別の言い方で呼ぶと「名付け」です。正しいモデルには適当な名前を与えることができます。適当な名前は、概念を明らかに表し、表すものが広すぎも狭すぎもせず、冗長すぎずシンプルです。おかしな名前がついているときは、モデルがおかしいとみなすべきです。ネーミングセンスがないために気の利いた名前が付いていないことはありえますが、モデルを上手く表せない名前しか付けれない場合はモデルの方が間違っています。名前のないものは認識できないので、名前から概念を作っていかないと上手くいきません。

モデリング/名付けは、抽象的な思考でストレスがかかる作業であり、凝ろうと思えばとことん凝れるが手を抜くことも簡単にできてしまうので、易き流れて先に進めてしまいがちです。しかし、そこを踏ん張って十分に煮詰めた方が良いと思います。名前重要という格言がありますね。

ただ、モデリング/名付けは語彙力が必要であり、ものを知らない人がやっても、ないものは出てこない。できないものはどうしようもないので、現実的にできる範囲でやればよいでしょう。 type や class を kbn (区分) としてしまうのも仕方のないことだと思います。さすがに kbn は嫌だと思う良心のある人は、語彙力を鍛えていくべきでしょう。

まずは日本語の語彙。そもそも業務(ドメイン)の言葉が変だったりします。さきほどの区分を表す日本語はそれ以外にも、タイプ、クラス、分類、類別、類、型、種、級、いくつもでてきます。日頃から言葉に注意しなければ、語彙は増えない。あと辞書を引くこと。サラリーマンに学を求めるべきではないのかもしれませんが、サラリーマンに理解できないことの一つが誰も辞書を持ってないことです。

次に英単語。私が気に入っているのは Lingvist という楽天が提供している英単語学習サービスと、thesaurus つまり類語辞典です。thesaurus に関しても、どうして誰も持っていないのか理解できないです。type の類語として、class, kind, group, category, division があることを知っていて、それらがポンポン出てくる人なんていないはずです。

最後にプログラム特有の語彙。これは辞書に載っていないが、慣例化しているものがかなりあります。例えば、 push/pop。データが並んでいて、末尾にデータを追加する/末尾からデータを取り出すという意味だが、知らなければ読めないし書けない。他には、Builder という名前のクラスがあったとしても、デザインパターンを知らなければ、何をするためのクラスか分からないだろう。これらは辞書には載っていないので、知らなくても仕方はないと思うが、知らないからと怒り出さないようにはしたい。プログラマは世界に 1000 万人もいるので、プログラミングの用語の辞書には需要があるでしょう。

全ての言葉を覚えるなんて不可能ですが、名前が重要と気づいて、自分の語彙の幅が狭いと知ったならば、ちょっとは勉強した方が便利だと思います。

パッケージングと付加価値

安く買って高く売るは、商売の基本です。世の中には仲介業者というのが大勢いて、(ちゃんと調べたことはないですが)労働者のかなりの割合が仲介業をしていると思われます。

しかし、今や21世紀であって、これだけ IT 化が進んできますと、ただ右から左にものを流すだけの商売というのは難しくなってきているでしょう。インターネットが全世界をほぼリアルタイムで、ほとんど無料で接続してます。仲介業者によって従来行われていた業務は、ネットワークの上だけで、以前よりも上手く達成されるようになりました。インターネット黎明期に創業して今や大企業になっている会社は、そういう事業をしている会社が多いです。

彼らは世の中をますます効率化してどんどん事業を伸ばしていくべきだと思いますが、仲介業者が彼らに駆逐されないためには、ただ橋渡しをするだけでなくて、もっと付加価値を生めるようになるべきでしょう。単に効率的になるだけでは、社会は発展しないし、つまらないですから。

付加価値を生むとは、つまり、ひと手間を加えるということです。今も言われているのかは知らないですが、日本国は加工貿易といって、原材料を輸入し、加工して別の形に変えたものを輸出していました。工業は大規模すぎて今さら参入できないですが、ちょっとひと手間加えて見栄えを変えるだけで、付加価値というのは生まれます。付加価値のない商売は、とことん値切られた上で、誰も買わなくなると思いますが、ひと手間が入っている商売は生き残るし、今後求められるのはそのひと手間だと思います。

ひと手間の加えようは無数にあるわけですが、現在最も有望だと私が考えているのは、パッケージングです。これはどういうことかといいますと、商品を組み合わせたり、組み替えたりして、使いやすい形態にすることです。

例えば、

  • 漫画全巻ドットコム。マンガの単行本は、なぜかバラ売りされていますが、全て揃って一つの作品なので、まとめて売るというだけで消費者が使いやすい形態になります。

  • リサイクルショップ。どこで買ったか忘れてしまいましたが、引っ越したときに洗濯機と冷蔵庫と電子レンジのセットを買いました。急いでいたので、悩まずに買うことができて、大変便利でした。

  • FOLIO。これは新興の証券会社でして、テーマに対して投資ができるという新しい形態の金融商品を提供しています。株は 100 株か 1000 株の単位でしか基本は売買できないので、多くの会社には投資できないものです。しかも、会社というものはやたらと数があるけれども、普通の人は個々の会社なんて興味がないので、選べません。FOLIO は、株を1株ずつにバラした上で、テーマという形で複数の会社をまとめることで、消費者にとって魅力的な形態に株を組み替えてしまいました。私はここの商品には惚れ込んでいまして、この会社がどう化けるのか興味津津です。

これらはただ既存のものを組み合わせるだけなので、誰でも思いつきそうなのですが、思いつかないものです。そして、簡単に真似できそうだけれども意外と真似ができないものです。真似しようとしたらビジネスモデルを作り替えなければならないので、新規にはじめるよりコストがかかってしまいます。また、パッケージングの過程は外から見えないので、そこは真似できないからです。

ものなんて溢れかえっていて、供給過剰な昨今です。ネットで調べれば、大抵のものが安く手に入ります。しかし、消費者には多すぎて、探せないし選べない。単品の商品で差別化するのは今や無理です。違いなんてほとんどなくて、実用上はどれでも同じなんだから。また、消費者は、手に入るものを全てを管理し消費しきることが、もうできなくなってしまっています。なので、売り手としては、パッケージングを上手くして、消費者が買いやすくすることが、今後の仲介業のあるべき姿ではないでしょうか。

この世に要件定義ができる人間は何人いるのだろう?

ITエンジニアの求人倍率が5倍以上と、非常に高い。世間ではエンジニアにやらせたい仕事の数に比べて、エンジニアの数が極端に不足しているということです。しかし、このことは私の感覚に合っていない。エンジニアの層は薄くて総数は少ないように思いますが、それでも余っているような気がしてます。

何もしていないわけではないが、別にやらなくてもいいことをやっている人が多いように思うのです。仕事をする人の数に対して、やるべき仕事が少なすぎるように感じています。やらなくていい開発をしなければ、エンジニア不足なんて問題は存在しないのではないでしょうか。

以前にいた会社では、企画を作れる人なんていなかったので、企画なしになんとなく開発が行われていた。多分あれは、開発をする人の仕事を維持するためだけの仕事だったのでしょう、あるいは管理職の仕事を維持するためのものだったのでしょう。人は余っていて、アイドリングのような仕事をさせるにしても、仕事を回すには人が足りない。エンジニア不足といっても実際のところは、このような事情なのではないかと推測します。

無意味な仕事をするなんて不幸なことだと思うのですが、それが平気な人の方が多いようです。もし意味を見出しているなら、単に見解の相違なので、無意味とか言ってごめんなさいと謝ります。そうでなくて、これは本当にやるべきことなのかとか考えないか、考えてないようにしている人が大多数だと思います。目の前のタスクをこなしていたら意義なんて分からないものですし、そんなこと考えない方で作業した方が、効率がよいからです。こういう人々を仮に作業者と呼びましょう。作業者はおそらく不足していない。やらなくていい仕事が多すぎるだけです。

しかし、やるべき仕事をつくることができる人は一体どれほどいるのだろう。事業を起こす人は、ほどんどいないし、そこまで大勢は要らないでしょう。しかし、要求・要件を定義したりすることができる人というのは、作業者の数に対して少なすぎると思います。要求者が言うことをそのまま転記する仕事のことを言っているのでない。いわゆる真の要求を見つけ出したり、論点を明らかにできる人のことを言っている。ぼんやりとしか言及できないのは私がそれをできないからです。

仕事の価値なんて何をするかでほとんど決まります。やろうとしていることが正しかったら、実装の品質なんて少々劣っていてもよいとさえ思います。前述の以前いた会社の人は、うちの製品は商品性はないが品質は高いと言っていましたが、それを品質が低いというのではないでしょうか。実装の品質も本当にこれ売っているのかと疑問に思うようなものでしたが。要件定義が正しければ、品質なんて後からついてくると思います。

私は、何かを間違ってエンジニアとかやっているが、基本的に開発が嫌いなので、作って動いたなんて仕事だと思っていない。これをする意味あるのかとしばしばぶーたれている。このスタンスが果たして好ましいのかは別として、この視点から見たら、世の中には問題は山積みだけれども、それを要件にできる人が少なすぎるがために、やるべきでない仕事が多すぎるように思うわけです。

ぼんやりとしたイメージしかまだ持てないのではあるが、大して難しいことのようにも思わない。私はできないのだが、どうしてみんなもできないしやらないのだろうと不思議に思う。そもそもこれは誰がするべき仕事なのだろうか。コンサルタントの仕事なのだろうか。供給の少なさに比して高い需要があると見ているので、みんなやったらいいのにと思うし、そうしたらみんなが幸せになるのではないだろうか。

難しいことは仕事ではない

仕事が難しくなければならないなんて一体誰が決めたのでしょう。このことを誤解している人が多いように思いますし、そのために私もずいぶん長らく勘違いをしていました。しかしながら、考えを改めまして最近では、難しいことは仕事ではないと思っております。

難しいことに価値があると考えることが、そもそも間違いなのだと思います。仕事の難しさ仕事の価値は必ずしも相関しません。簡単だけれども有意義な仕事は少なくないですし、難しそうであっても無意味な仕事はもっと多いです。

しかし、難しいから偉いとなぜか人は思ってしまいます。この考えは危険です。なぜならば、難しいことに価値を見出してしまうと、どうでもいい仕事でさえいたずらに難しくしてしまうからです。チャレンジングなどの言葉も下手に使うと罠に陥りやすい危険な単語でしょう。

生産性という単語を最近よく耳にしますが、仕事に難しさだとかチャレンジングさを求めると、著しく生産性が下がるように思います。生産性とは安定して生産することです。困難なことに挑むならば安定した結果は期待してはいけないでしょう。加えて簡単なことも難しく難しくしようものなら、生産性なんて諦めるべきです。意味なしに難しい仕事なんて非生産的な仕事なのだから、そこに生産性を求める方が間違っています。簡単な仕事を安定してこなしているのが最も生産性が高い状態でしょう。

難しいことはやらないというのが、安全な態度だと思うのです。難易度をフラットな視点で見据えて、易しいなら易しいなりに、難しいなら難しいなりにこなせるならいいと思います。しかし、それは無理で、チャレンジングなことをやろうなどとすると、難しいことは余計に難しくなり、引っ張られて簡単なことも難しくなってしまうものです。

特に指導する側の人は、仕事を難しくしたがる病から脱しなければならないと思います。上の人が仕事は難しくなければならないと思っていたら、仕事を難しくしなければならないと勘違いしてしまうでしょう。そうしたら余計な重しに足を取られて、全員が不幸になると思うのです。

もし偉い人が呪縛から抜けられず自分だけ抜けたなら、簡単な仕事をあたかも難しいようにこなすことは処世術として有効でしょう。仕事自体の価値が評価できない人は、どれだけ大変そうに仕事をしたかでしか評価できないのですから、仕方ありません。

あるいは、みんなが難しいと思っていることが、自分には簡単そうに見えたらそれは是非ともやったらいいと思います。偉業を行った人はしばしば、それが難しいことだとは知らなかった、と言います。

難しいことなんて取り組んだところで疲弊するだけで、何もいいことはないから、そこから積極的に逃げるのが、プロフェッショナルとして正しい態度なように思います。