コード型ログ(1) スレッドを止めるにはinterruptを使う

他の人が書いていたら読めるけれども、知らなければ書けない定型的なソースコードの型を集めているので気が向いたら書いていく。ダジャレが好きなので、コード型ログと呼ぶ。今回は１回目。

---

無限ループを持つスレッドはinterrupt()で止められるようにする。

package org.example.katalog;

public class InterruptSample {
  public static void main(String[] args) {
    Thread t = new Thread() {
      @Override
      public void run() {
        // interruptされるまで、"Hello world"を出力し続ける。
        // なお、isInterrupted()は呼ぶとフラグがクリアされてfalseになる。
        while (!isInterrupted()) {
          System.out.println("Hello world");
        }
      }
    };

    t.start();

    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }

    // interruptするとスレッドのisInterrupted()のフラグが立つ。
    t.interrupt();

    // interruptしてもまだスレッドが止まっているわけではない。
    // スレッドが止まるまで待つ。
    try {
      t.join();
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
}

悪い例は制御フラグを独自につくることである。Javaのスレッドには言語組み込みでその目的のフラグが用意されているのだからそれを使う。

package org.example.katalog;

class HelloPrinter extends Thread {
  // スレッドを止めるべきかのフラグ。
  // volatileはあるスレッドで代入した値が他のスレッドでも
  // 同じものが見えることを保証するおまじない。
  volatile boolean stop = false;

  @Override
  public void run() {
    while (!stop) {
      System.out.println("Hello world");
    }
  }
}

public class InterruptBadSample {
  public static void main(String[] args) {
    HelloPrinter t = new HelloPrinter();

    t.start();

    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }

    t.stop = true;

    try {
      t.join();
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
}

シンプル騎士団を結社する

シンプルであることが設計の最大の美徳ある。これを教義とした秘密結社、シンプル騎士団を結成したいと思う。活動の実体もないし、名簿とかもない。シンプルさって大切だよねと思っている人は、ただ心に思うだけで、特に手続きもなしに構成員になれる。

さて、シンプル騎士団の構成員の一人として、シンプルさについて思うところをについて書く。

シンプルな設計の重要性のついては、しばしば言及される。有名な設計指針として、KISS原則というものがある。"Keep it simple, stupid" とか "Keep it short and simple"とかの略とされる。*1

なぜ、シンプルな設計が重要かというと経済性のためである。シンプルにすればコストが削減される。そして、その効果というのは想像以上となる。複雑性というのは、設計したその時に考えているよりも、ずっと高価である。

最近よく製造業を引き合いに出している気がするが、製造業の経営側の人が言うには「技術者に好きに設計させるとすぐに部品点数を増やしたり、複雑な形にしてしまって製造原価が増える」そうだ。確かにそのとおりで、設計している人には製造するときのコストは分からないものだ。設計図面を引くときのコストと製造するときのコストというのは大きく乖離している。図面で何気なく、穴を一個開けたり、角を丸めたりするのはのは簡単だけれども、実際に金属を削ってその形にするのはコストがかかるものなのです。

機械設計ではシンプルにせよという圧力は非常に強い。一円のコストをかけて良いならもっとマシにできるのにと思いながら、単純にさせられてしまうというのはよくあることだそうだ。実際、自動車も外観とかの仕上げは綺麗だが、下から覗いたら驚くほどの安っぽい作りである。鋳造してちょっと削っただけとか、板をちょっと曲げて溶接しただけとか。

凝ったものを作れるのは軍需産業ぐらいだろう。彼らは好き勝手に高価なものを作っているわけではないが、民生品と比べると驚くようなギミックが付いていることがある。例えば、HEAT弾はたかが弾丸だけれどもびっくりするような複雑さだし、戦闘機のジェットエンジンのノズルはうにうに動く。

しかし、KISS原則はロッキード・マーチン社という軍需産業をしている会社で言われ始めたそうだ。コスト圧力が民需品ほどは高くなくて、放っといたらどんどん複雑化して凝ったものになっていきがちゆえに言われ始めたのかもしれない。

単純にすることで減るのは製造原価だけではない。だから、民需品を作っているところから比べたら原価意識が低いと思われる軍需産業でKISS原則なんて言われたのだろう。シンプルにすれば製造コスト以外のリソースの使用も削減できる。シンプルにすれば、使用性もメンテナンス性も信頼性も向上する。また、思考のコストも減る。凝ったものを作り始めたら、もともと解決したかった問題を忘れがちだ。

問題は、原価以外のコストは見えないコストであることだ。ロッキード・マーチンのスカンクワークスを仕切っていた人は有能だったから、見えないコストも勘定できたのだろうけれども、通常は見えないコストまで考慮されない。製造業の場合は、原価の圧縮がそのまま会社の利益になるので、シンプルにしようという強い動機が働くから、原価以外のコストが見えなくても困らない。

しかしながら、ソフトウェア産業は製造原価がほとんどない。ただデータをコピーするだけだから、複製のコストは限りなく小さい。いくら複雑であろうとも製造原価は変わらない。そのために、複雑性によって生じる見えないコストが見過ごされがちである。

むしろ、製造コストが変わらないのだから、多機能で複雑であるほどよいみたいな風潮さえある。私はこの風潮が非常に嫌いなのだ。この風潮に反旗を翻す人々の集まりがシンプル騎士団である。

ソフトウェアだってシンプルな方がいいに決まっている。

複雑さはすなわち技術的負債だ。デットコードやコピペは資産でもないし、それらをつくることは生産性に含むべきでもない。排除すべきものだ。それらを生み出すLOC生産性なんて殺せ。無意味な複雑さを作ることとか穴掘って埋め戻すだけの作業だ。世の中には一切貢献しないし、ただ他の人の足を引っ張るだけのものだ。

見えないコストも含めた真の経済性を求める人は、ぜひシンプル騎士団に入って欲しい。構成員がすべきことはただひとつだ。シンプルさの維持を、設計の際に大切にすることだけである。

*1:この原則に余計なものがついていたら自身を違反しているので、KISとする場合もある。しかし、その流儀でいうとシンプル騎士団も余計なものを含んでいるとなってしまうので、ここでは採用しない。遊びは必要だと思っている。遊びの余地を作るためにどうでもいいものを削り落とすべきなのだ。

技術者が得意げに解説することこそ解決すべき技術的課題

技術者というのは、製品の仕組みだとか作リ方だとか飼い慣らし方だとかを知っている。それが彼らの自尊心だから、知っていることを得意げに語りたがるし、知らない人を下に見たりする。気持ちはわかるし、誇りを持つことは良いことだ。

ずっとやっていたら詳しくなって当然だ。それが彼らの優位性なので、そこにプライドを持つのは当たり前のことだ。歳月を費やしてわかりにくいものを覚えていったのだ。それをドヤ顔で語るのも無理からぬことだ。

しかし、俺の知っていることはお前らも覚えろと他人に求めても、technologyって何も進歩しないのでないかと思う。

ソフトウェアの歴史は、抽象化の繰り返しだ。人間にやさしくないものに皮をかぶせて、ユーザーフレンドリーに見せかける。それを何十年も繰り返している。

技術者が得意げに語るようなところというのは、まさに皮をかぶせるべきところだと思う。何これ使いづらいなと思って文句を垂れると、なんべんもやって筋トレしてなれろみたいな風に怒られるわけですが、その努力をなくすことがすなわち技術革新だと思う。事実そういう風に技術は発展している。マシンの管理とかめんどくせえと言ったらVMになるし、OSのインストールすらめんどくせえとなったらDockerになるし。

皮を剥いだら現れるようなものも、これ分かりづらいなと思うようなところも、当然ある。分かりやすく書こうなんて風潮は最近のことだから、読めないコードがあっても不思議ではない。読んで分かれと言われたところで、分かりにくいものがそのままなら何の進歩もない。得意げにこれがこうでと説明するなら、そういう風に書き直せばいいのだ。そうしたら、皮の内側を分厚くするもできるし、皮の内側が怪しげなシロモノであることを恐れずに、外に新しく皮を増やしていくこともできる。

めんどくさいとか分かりにくいとかに慣れたら、どうしようもなく古い発想のものしか作れないと思うわけです。これらの感性が使う人の気持ちになれる唯一のヒントだ。低レベルのプログラミングができる人は高レベルもできるとかいう人がいるが、それは嘘だ。レベルを降りるのはできなくもないが、登るのは不可能だ。使う人の気持ちが分からないから。原始的なところとか複雑なところにを潜ってもいいが、傲慢だけ身につけて、怠惰と憤怒を忘れたら、もう帰って来れなくなる気がする。

大して潜ってもいないのに、すでに遭難気味だ。製品の中身は分かるが、使い方は分からないとか言いたくねえな。アプリケーションを、ちゃんと作ったほうがいいのだろうか。

○×ゲームの神の一手を導いてみた

小さい頃にノートの隅や地面で良く遊んだ○×ゲームを計算機で解いてみた。

○×ゲーム程度であれば、スクリプト言語を用いて、かつ枝刈りとかせずに終端までミニマックス法で全探索しても十分に解ける。ミニマックス法というのは、要するに負けない手を打てば勝てるという戦法で、○×ゲームのようなゲームではミニマックス法ですべての局面を調べることができれば、最善の一手が得られることが知られている。

○×ゲームは両者が最適な手を打てば引き分けとなる。先手に関しては一手目をどこに置いても、引き分けに持ち込むことができる。二手目以降からは、正しく受けないと負けてしまう。したがって、二手目を正しく受けれない可能性があるので、微妙に後手が不利かもしれない。

一手目が中の場合は、後手は隅で受ける必要がある。

初手が隅の場合は、中で受ける。

初手が、辺の場合は、隣の隅か中か対辺に打てばよい。

以下のPythonスクリプトを実行すると、先手後手双方が最善の一手を打ち合う

fjk@x240:~/works/ox-game$ ./oxgame.py 

   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   |   |   | 
   +---+---+---+


   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   | O |   | 
   +---+---+---+


   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   |   | O |   | 
   +---+---+---+


   +---+---+---+
   | O |   |   | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   |   | O |   | 
   +---+---+---+


   +---+---+---+
   | O |   |   | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O |   | 
   +---+---+---+


   +---+---+---+
   | O |   | O | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O |   | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O |   | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O | O | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   |   | X | X | 
   +---+---+---+
   | X | O | O | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   | O | X | X | 
   +---+---+---+
   | X | O | O | 
   +---+---+---+

特に結論とかはない。

---

ソースコード：

ソフト開発にも生産技術者が必要

製造業には必ず生産ラインの世話をする役職の人がいる。製造業においては、この役割の人は階級が高くて、会社内ではエリートがする仕事である。昔は社会的にも地位の高い仕事だったのだろう。現在だと聞かないが、かつては製鉄業の現場監督はエリートの仕事であったそうだ。今の日本国の首相である安倍晋三も昔は製鉄所の現場で働いていたらしい。どなたか忘れてしまったが、かつての製鉄業の偉い人は「俺は生まれ変わっても鉄を作る」と言ったそうだ。アツいし、誇りに満ち溢れるよね。

現在でも、製造現場の現場指揮官のような仕事は高給取りで組織内での地位が高いことには変わりないと認識しているが、印象として社会的に高い地位の仕事と認知されていないと私は思っている。決して低いわけではないが、同窓会で工場で現場監督しているといっても、おそらく「ふーん」となるだけで、「すごーい（黄色い声）」とはならないだろう。

私も、学生の時分はそういう仕事はしたいとは思わなかった。キーエンス・任天堂・シスコ・アップルのような工場とかいらんでしょみたいな風潮が流行っていたのだ。そういう流れに逆らう形で、「ものづくり」とかいって工場の誇りを取り戻すための言葉が使われていて、この言葉は嫌いだった。工作は好きだったが、生産ラインが嫌いだった。

しかし、現在では、工場の現場の頂点に社長が君臨するような、工場中心の企業の代表格であるトヨタ自動車が、非常に大きな利益を出している。本屋にはトヨタ自動車の秘密みたいな本が平積みにされている。ミーハーなだけかもしれないが、トヨタマン流の行動原理は見習わなければならないと最近強く思っている。

生産ラインは嫌いだったが、ソフトウェアの開発にも結局ラインはあった。産業としてやろうと思ったら、ラインつまりシステムの形に落とし込まなければ、安定した生産というのは無理だと気づいた。製造途中の製品が流れていくのとは違い、意思決定とそのための情報が流れていくことになるので、形態は工場のラインとは異なるものになる。システムといっても、コンピュータシステムのことではない。システムの構成要素にホワイトボードだとか口頭伝達が含まれていてもよい。

ソフトウェアの開発をシステムの形に落とし込んでいって、そのシステムの維持管理をする役回りの人は当然いて然るべきだと思うけれども、あまり聞かない。製造業では、企業によって呼び名が変わると思うが、しばしば生産技術者と呼ばれる人である。

プロジェクト・マネジャーの仕事ではない。人間は適応性が高いから、人間が構成要素として組み込まれてているシステムというのは、整っていていなくても、即興でゴニョゴニョすることで一見回っているかのように見えてしまう。そういうことをすると一時的には問題を隠して乗り越えることができる。プロジェクト・マネジャーという役回りは、ゴニョゴニョと調整をして、問題をやり過ごすことだと思っている。プロジェクト・マネジャーのゴニョゴニョ自体もシステムの中にブラックボックスとして含まれてしまっているのだ。

システムに組み込まれた人間が一時的にシステムを逸脱して即興で解決するということに頼らずに、システム自体を綺麗に整えていくのが、筋だと思うのだ。即興で問題をさばいて解決している人が褒められる傾向にあるが、その人らは問題の存在を隠してしまって、いわゆる根本原因の解決を妨げているのではないかと思ったりする。やり過ごせればもうどうでも良くなってしまうものだし、やり過ごしたこと自体に達成感があっちゃうから困る。

イメージ的には、即興の調整役みたいな人に属人化されていてブラックボックス化されている意思決定のフローを可視化してシステム化したりする仕事、あるいは、そういう調整が必要なくなるように、前工程からやってくるもののバラつきを防ぐようにする仕事がいるのではと思っている。

何と呼ぶべきかわからないが、広い意味でいうところのQAエンジニアになるのだろうか。製造業だと、品質を一定に保つための仕掛けを治具という。ソフトウェアだと、テストフレームワークだとかビルドツールだとかCIツールがそれに相当する。課題管理システムとかもそれに入るかもしれない。現場を観察して、必要に応じて治具を作ったり、その運用をしたりする、そういう役回りの人は必要だと思うのだけれど、認知されていないし、名前もついていない。

名前のついていない職種を募集している企業はないので、探せないが、需要はあるのだろうか。というよりも、私はそういう仕事をする人は必要だと思うので、その考えに同意してコストをかける価値を認める会社があるなら、私がやってあげてもいいよという感じだろうか。もちろん、ラインでもなくて、その上に流れている製品でもなくて、製品が解決する問題の方に本来は興味があるので、そこが同意できることが前提ですが。

企業と効率とインターネットの可能性

一般論として世の中の企業というのは非効率で不合理な多くてどうにかならんもんかなと思う。

ムダのために会社が損をしたら、株主なり債権者は金銭的に困る。従業員からしても、自分の金ではないからと、『サラリーマンは気楽な稼業と来たもんだ』とはならない。日本社会は会社が潰れないこと前提にできているから、潰れたらすごく困る。

ムダによる高コストを価格に転嫁するようなことがあれば、顧客にも悪いことをしている。現実には原価が高いから高く売るなんてことはできないので、顧客が本当に求めているときに商品を提供できなくて機会損失を与えたり、カタログスペックには現れないような微妙なところの品質が落ちたりして、買う側も気付かないようなところで損をするようになるのだろう。三菱自動車なども、コスト体質だとかの内情は知らないけれども、当然トヨタ自動車と同じような開発体制や生産体制を整えることはできないにも関わらず、トヨタ自動車と同じような値段で同じようなものを作ろうとしたら、無理がたたることになったのだろう。

また、ムダな仕事を黙々とするような従業員の人生は社会にとって無意味なのではないかとか思ったりするわけです。考えすぎるとすべては無意味でムダだといった虚無主義に陥ってしまうが、少なくとも経済的な意味においては間違いなくムダは社会的な損失だろう。

不合理・非効率――ムダの排除をして不幸になるステークホルダーはいない。

すごい昔は、カイゼンとか効率とか嫌いだった。効率最優先で人間性を阻害した利益至上主義で、それらが環境破壊だとか公害だとかを起こしていて、人を大切にせずに劣悪な環境で働かせて使い捨てにするような、汚い怪物ぐらいに（ちょっと盛っているが）思っていた。

しかし、その後企業ってもっと生産的なところだと思っていたのに――と逆にショックを受けて、考えが反転した。あくまで一般論で、どこでもそうで誰に聞いても誰もが一様にショックを受けている。それで今は非効率を憎んで、世の中のムダは抹殺すべきぐらいに思っている。

ムダをなくすだけでは、高いものが安くなるだけではないか単純には思ってしまう。人が要らなくなって、単に失業者が増えるだけではないかと。街の本屋が消滅してAmazon.comだけになったら、世の中つまらなくなるのではと。

でも、決してそうではないと、最近気づいた。単に不合理・非効率を排するだけでも、今までになかった喜びが現れる。

インターネットでしばしば本を買う。便利というのは麻薬で、インターネット通販サイトにはずいぶん貢いている。通販の便利さは実店舗に出向かなくても手元に本が欲しい時に手に入るだけではなかった。本棚を見ると、Amazonがもしなかったら絶対に読まなかったであろうし、認知すらしていなかった本が数多くある。冷静になって考えると、これはとんでもないことだ。私の人生は明らかにAmazonによって変えられている。

Amazonはインターネットを利用して物流と小売を効率的にしただけだ。インターネットそれ自体は、ただの通信網であって、そのものは何かを生み出したりはしない。それなのに、私は人生を変えられている。当たり前のようにそこにあったから、インターネットのすごさを忘れていた。非常に今さらながら、インターネットの可能性を再発見した。

ジェフ・ベゾスは、私に私が知らなかったような知識を与えて私の人生に影響しようとなんて、別に考えたわけではない。これが良いことだったかは知らないし、私が新しい本に出会ったことは社会に何の影響もないが、思わぬところで思わぬ効果があったわけだ。その事実が、無性に面白い。

アメリカの金持ちが、こんなに離れたところに住んでいる私の人生にかなり強く影響しているという事実に気づいたら、世界の見方が変わる。それを実現するインターネットのすごさよ。

企業はファイヤーウォールの内側にいて非効率なことをしているけれども、ファイヤーウォールをぶち破ってインターネットが企業内に進出し始めたら、革命的なことが起こるのではないかと思い始めた。実際そういう話が、最近私のアンテナによく引っかかる。社会の片隅にいる私の耳にまで聞こえるということは、もう爆発が起こる臨界点近くまで機運が高まっているのだろう。

ドリル／穴 問題について

マーケティングの格言に

ドリルを買いに来た人が欲しいのはドリルではなく穴である。

というのがある。至言だ。この言葉にはいろいろ思うところがある。

言葉だけ聞くと当然のことである。道具なんて所詮道具だ。用途があって道具がある。用途がない道具はない。その道具があったら何ができるの？この問は道具を作るときにするべき本質的な問いかけだろう。

しかしながら、俺達が作っているのはドリルでなくて穴だなんていう発想をする人は実に少ない。企業には往々にして商品種別ごとの事業部がある。例えば、工具を作っている会社ならドリル事業部なるものがある。ドリル事業部なんてあったらドリルなるものが絶対的に存在していると思って、ドリルを作って売るという発想しかできない。ドリルって何に使うものなのかなど、考えもしない。

自動車メーカーの人に車の機能を聞いたら、「走る・曲がる・止まる」という人がいる。それは違うだろう。車の機能は、人や荷物をある場所から別の場所まで運ぶことだと私は思う。走る喜びとか・所有すると喜びとかもわからんではないので、それを機能に含むこともありうるかもしれない。だが、走る・曲がる・止まるは機能をつくる要素かもしれないが、それ自体は自動車の機能ではないと思う。走って・曲がって・止まるだけならラジコンでいいではないか。

「自分の作っているものがどう使われるかは分からない」という言葉は非常によく聞く。それを聞くたびに、ネガティブな感情が蓄積していく。

それでいて、もっとよく聞く言葉は「競合他社と比べて何が違うの？」である。機能が何かを分からないものの、機能要素について議論して一体なにの意味があろうか。何に使うのか分からないから、カタログスペックばかり気にするのだ。

ユーザーは、カタログスペック見て比較検討するのかもしれない。でも、ユーザーがカタログスペックだけ見ていると思っているなら、ユーザーのことを馬鹿にしすぎやしないか。売る方も馬鹿なら買う方も馬鹿なのか市場というのは？私は違うと信じている。

ヘンリー・フォードは言った：

もし顧客に、彼らの望むものを聞いたていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。

しかし、消費者が買ったのは自動車なのだ。

顧客の望むものを聞いてそれをそのまま作って、イノベーションのジレンマに陥っているのなら、まだましかもしれない。T型フォードがすでに発売していて、顧客はT型フォードが欲しいと言っていても、馬を売っていた連中は多分それに気付かないかそれを認めなかったのだろうと想像する。馬は忠誠心があるから車より優れているとか、意味不明なことを言っていたのではなかろうか（根拠はない）。それは何に使うのと考えたら、ほとんどの用途では自動車の方がいいに決まっている。

私は何に使うのか分からずに、ドリルなんて作りたくない。ものづくりなんて興味がない。ましてドリルそのものになんて、かけらも興味がない。私は社会に穴を提供したいのだ。ドリルの回転数とかアタッチメントの数とかどうでもいい。別にドリルがすぐに壊れるものであっても、顧客が欲しいのがたった一個の穴ならそれでいいではないか。別にそれなら穴ぐらい出向いて開けてやるよ。