ブログ移転のお知らせ
サイト名を変えて、そのまま継続するつもりだったけれど、せっかくなので、はてなブログで続けることにしました（というわけでサイトのタイトルも元に戻した）。
新サイトは「hidekatsu-izuno 日々の記録」です。
はてなダイアリーからはてなブログへサイトごと移動すればという話もあるのですが、以前、移動させたところ、コメントや一部の書式がうまく移動できなかったため取りやめたという経緯があったりします。
書く内容自体はたいして変わらないとは思うので、今後ともよろしくお願いいたします。
タイトルは変えたけれども
今更ではあるけれども、Twitter も Facebook も実名でやってるし、あえて匿名にする必要がなくなってしまったので、ブログタイトルも変えてみた。ARN（＝以前のブログタイトル）という名前も元々、私の画号みたいなもので匿名にする意図はなく、絵を描くこともブログ更新もほとんどなくなってしまっている現在においては、使う機会も減ってしまった。
一時期流行っていた匿名・実名論争も、トンデモない人は匿名だろうが実名だろうがトンデモないこと言うし、まともな人は職務の差し障りが無い分、よりまともなことを言うことが、誰の目にも明らかになった現代において、匿名であることのメリットは、職務上差し障りのあることでも書ける、とか、炎上した際に職場や自宅にクレームが来る可能性を下げることくらいしかないのではなかろうか。
ただ、この「職務上差し障りのあることが書けない」という問題は予想外に大きな障害である。仕事上の極秘事項とか客先の秘密を書けないというのは当たり前の話だし、私だってそんなこと書くつもりはない。それは契約以前に倫理やマナーの問題である。
むしろ困るのは客先の販売している商品やサービスの扱いである。私の仕事はいわゆるひとつのシステムエンジニアだ。そうすると様々な業種の客先から仕事を請け負うことになる。
もし、客先の商品に不満があったとしても、それを取り上げて批判することは当然慎まねばならない。まぁ、これは仕方ない。個人的にも許容できる。
一方、その会社の商品を大変気に入っている場合はどうだろうか。私自身の言説の信頼を損ねないためにも、ステマと見られる行為は慎まねばなるまい。というわけで、結果として客先の商品については書けなくなってしまう。
では、その客先のライバルの商品が自分のお気に入り（特に食い物とか）だった場合どうだろうか。
もし、うっかり客先担当者がライバル社の商品を絶賛する記事を見てしまったらどう思うだろうか。普通は気分を害すだろう。逆に不満を書くのも前述の通りステマと見られてしまいかねないので書くのがはばかられてしまう。結果、客先の商品分野と同じジャンルの商品については何も書けない。
さらに言うと、社内ではあちこちでいろんな人がいろんな企業から仕事を請け負っている。となると、うっかり特定の商品について何かを書いたことが原因で、同じ会社の会ったこともない誰かが不利益を被ることもありうる。ここまで考えると、ありとあらゆる商品について語るのが難しくなってしまう。
幸か不幸か、このブログは経済と開発系の話題しかないので、さほど問題になることはないとは思っていたのだが、ここ最近、困った事例に出くわしてしまった。
システムの問題に対する言及である。
例えば、高木浩光先生がシステムの脆弱性をいつものようにあげつらったとしよう。浩光先生の言うことであるから大抵正しい見解であるし、その大半は知識ある人なら「それはないわー」と思うものも多い。以前なら何も考えずリツィートしていただろう。しかしこれは罠である。
多くの Web システムではその開発会社は公開されていない。その問題を持つシステムはもしかしたら自社の別部署の仕事かもしれないではないか。非人情を自覚する私とて、同僚の批判をするのははばかられる。彼らは彼らなりに決められた予算の中で最大限の努力をしたのかもしれず、自分がそのシステムの担当者だった場合、同じ会社の人間からボロクソに言われていたのを知ったらどう思うだろうか。
というわけで、本日も某大手企業の通販サイトが国内でさえシェア 35% もある chrome からログインできないなどという今どきありえない仕様になっていても、その不満はそっと胸にしまう（ことはしなかったが社名をぼかしてツィートした）のであった。
Work Rules! から何が学べるか
- 作者: ラズロ・ボック,鬼澤 忍,矢羽野 薫
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2015/07/31
- メディア: 単行本
- この商品を含むブログ (10件) を見る
Googleが人事評価を統計的に処理して人事制度の刷新をはかっているという話は前々から出ていたのだが、その実態はなかなか表に出て来なかった。「Work Rules!」は、Googleがこれまでに行ってきた人事制度改革を余すことなく開陳した本だ。
人事制度や昇進の基準は、どうしても人が関係する以上、たいへんセンシティブだし、教育問題同様、誰にとっても身近な話なため、なかなか客観的な議論が難しい。
たとえば、私が良い上司とは何なのかについてツィートする時、人事部は私が上司や待遇に不満を持っているのかもしれない、と思うかもしれない。いや、もちろん何ら不満がまったくないわけではなかろうが、そこまで強くもっているわけでもない。
私が良い上司の条件に興味を持つのは、出世したいという願望よりむしろ、どのような上司が良い上司なのかわからないのに、上司の良し悪しに文句を付けられるのだろうか、という点にある。あるいは、さすがに私も年齢が年齢なので、上司ではないにしろ、後輩などに仕事を指示しなければならないことも増えてきた。その時、どのように接するのが良いのだろうか。
Work Rules! は比較的優れた本ではある。おそらく同種の本の中では一番良いのではないか。しかしながら、読んだ感想として消化不良を感じてしまうのも事実だ。著者自身も書いているように、Googleの人事制度は確実に以前より良くなっている。しかし、いまだ結論ははっきりしない。
この本で一番はっきりしないと言われているのは業績評価システムだが、良いマネジャーとは何かを研究した Project Oxygen の結論も個人的には微妙である。具体的には、以下のことが挙げられている（番号の小さいものほど重要とのこと）。
- 良いコーチであること。
- チームに権限を委譲し、マイクロマネジメントをしないこと。
- チームのメンバーの成功や満足度に感心や気遣いを示すこと。
- 生産性／成果志向であること。
- コミュニケーションは円滑に。話を聞き、情報は共有すること。
- チームのメンバーのキャリア開発を支援すること。
- チームに対して明確な構想／戦略を持つこと。
- チームに助言できるだけの重要な技術スキルを持っていること。
この項目を見て、えっ、そんな結果が！ と驚く人はいるだろうか。むしろ、凡庸な結論に見えないだろうか。Googleは、管理職などいなくてもいいかもしれないから、とりあえず廃止してみようなどと考えるギークな会社であるから驚いたのかもしれないが、たぶん、普通の会社は驚かない。
そういえば、この本に通底していることではあるが、「Googleでなければできないんじゃない？」と思われることが多々ある。
Googleならば最高な人材を集めることができる。報酬も好きな額支払うことができる。Googleならば、仕事はできるが人間的に問題があるかもしれない管理職を排除すれば良いのかもしれないが、普通の会社は、人間性からもたらされるチームへの負の影響と良好な仕事の結果を天秤にかける必要がある。
Googleならば、良い結果をもたらすために管理職に管理職として役割を専任させることができるが、普通の会社は、管理職は優秀な営業職や優秀なプロジェクトマネージャーの役割を兼務しており、管理職としての立場に専任できない。良いコーチであったとしても、本業がうまく行かなければ、すぐに役職から降ろされてしまう。
いや、むしろ逆なのか。「チームに権限を委譲し、マイクロマネジメントをしないこと」という２番目のルールの重要性を鑑みるに、むしろ管理職を専門職化すべきということを示唆しているのかもしれない。
Googleの知見を普通の企業に持ち込むにはもう一工夫が必要なようにも思う。
話変わって、Googleの労働環境のお話。Googleは「悪をなさない」という社是すら持っていた会社であるから、素晴らしい社員達が素晴らしい環境で素晴らしい仕事をすることが会社の利益に繋がるという理念で社員を扱っている。
しかしながら、世界の企業を見るとこれは必ずしも事実とは異なる。Amazon.com は AWS という社会を変えるサービスを生み出し今なお生み出し続けている革新的企業であるが、報道を信じるならば労働者は部品であるという理念を持っているように見受けられる。ブラック労働と言えばワタミやすき屋も話題にのぼったが、それらの企業も、労働者は部品のように扱ったが、消費者にとっては安くてそれなりに美味しいというメリットを提供してくれている。
SunやDECは、技術者にとっては住み良い企業だったかもしれないが、消費者にとってはそうでなかったかもしれないし、実際、潰れてしまった。
おそらく、正解はGoogleにはない。むしろ、労働者もしょせんは資源のひとつに過ぎない以上、（社会からの反発を受けない限り）労働者をこき使ってでも消費者に尽くし利益を上げるのが経営者の正しい姿なのであろう。その点でも Google の方法論がどこまで普遍性を持つのか、検討を要するように思う。
以下、余談。一方で企業が労働者を搾取するということは、国家全体にとっては大切な国民の効用を下げるだけでなく、ただでさえ少なくなっていく労働力を摩耗させて使い潰しているわけだから、決して喜ばしいことではない。個々の企業の最適解が全体の生産性を悪化させている。まったくもって合成の誤謬だ。
ようは、労働者を守るのは経営者の役割ではなく、競争ルールを定める政府の役割なのであるから、労働環境を改善すべく法整備を進めろという話である。
労働時間が減少すれば生産性は引き下がるのではと思うかもしれない。ところが、安い労働力が溢れている地域では、そもそも生産性を改善する機運が生まれないという話もある。実際、日本でもオイルショックがあったから、省エネが進んだ。労働時間を削減すれば、どの企業も生産性を上げる工夫をしなければ今までと同じことができなくなる。結果、生産性は改善する。
世の中、少しづつでも良くなってくれるとありがたいのだが……。
Javaの正規表現とJavaScriptの正規表現の空白クラスは異なる
本日は軽いネタ。Java だろうが JavaScript だろうが、正規表現は拡張構文の違いはあるものの基本的には同じに扱える。と思いきや、Unicodeが入ってくるとだいぶ状況が違うようだ。
言語によってサロゲートペアの扱いが違うのは知っていたが、空白クラス（\s）の定義まで違うとは思わなかった。
例えば、Javaはこれ。ASCII範囲のものしか空白には含まれていない。XMLの空白（[ \t\r\n]）に比べるとやや範囲は広い。
- 空白文字: [ \t\n\x0B\f\r] （参考：java.util.regex.Pattern）
また、いつの間にか以下のような見慣れない空白クラスも定義されている。
- 水平方向の空白文字: [ \t\xA0\u1680\u180e\u2000-\u200a\u202f\u205f\u3000]
- 垂直方向の空白文字: [\n\x0B\f\r\x85\u2028\u2029]
それに対し、JavaScript は UNICODE範囲の空白をすべて扱えるようだ（以前はASCII範囲だったはずような気がするのでES5で変わったのだろうか。定義書もざっと確認したが該当の記述を見つけられなかった）。
- 空白文字: [ \f\n\r\t\v\u00A0\u1680\u180e\u2000-\u200a\u2028\u2029\u202f\u205f\u3000] （参考：正規表現）
しかし、この情報は古いのか、英語版のサイトを見に行くと以下のように書いてあり、少々内容が事なる。
- 空白文字: [ \f\n\r\t\v\u00a0\u1680\u180e\u2000-\u200a\u2028\u2029\u202f\u205f\u3000\ufeff] （参考：RegExp）
使える正規表現が違うのは許容できるけれども、同じ名前で異なる範囲を表すというのは結構ワナだ。それはともかく実装により違うのだとすると予期せぬ動作にも繋がってしまうので、JavaScriptで空白クラスを使うのは避けたほうがいいのかもしれない。
なぜ、プログラマは滅びないのか
先日、「プログラマを志す君に伝える「仕事が無くなるリスク」」という、少々頭の悪い記事を読み、まぁ、こんなのまともに相手する人いないか、と思っていた。
ところが、「将来、人工知能がプログラマの代わりになることを想定するのはおかしいことではない」という意見をいくつか目にしたのだ。こういう見解は、人工知能がどういうものなのかについて誤解があるのではないかと思う。そのような未来は起こりそうにないし、仮にそのような未来が実現したとするならば、人々はまったく働く必要がなくなる天国かAIに支配されたディストピアのいずれかになるだろうから、プログラマの存在価値どころの話ではなくなってしまう。
まず、ある人が「○○できるシステムが欲しい」と望んだとしよう。きっと「○○できるようなシステムが欲しい」という言葉から考えられるシステムは無数にあるだろう。人工知能は、この無数の可能性の中からもっとも適切と思われるひとつを選び出しプログラムを生成する。
さて、この生成されたプログラムが望んだシステムと合致しているか、どうやれば確認できるのだろうか。正当性を確認するためには、「○○できるシステム」の仕様を詳細に書き起こし、検証する必要がある。
経済学には「政策目標がN個が存在するとき、N個の目標を同時に達成するためには、独立な政策手段もまた同数のN個なければならない」というティンバーゲンの定理というものがある。これは N 個の独立した要件を満たすためには、入力も N 個必要だということも意味している。N個の結果を個別にコントロールする必要があるわけだから、ある意味当たり前の話かもしれない。
ある人が望むシステムを人工知能が正しく生成するためには、N 個の要件を人工知能に正しく教える必要がある。これはまるでプログラムのような詳細設計書を作成する作業に等しい。プログラムに等しい詳細設計書からプログラムを生成するくらいならば、普通の人はそのような設計書の代わりにプログラミング言語でプログラムを書くだろう（日本語プログラミング言語「なでしこ」を使ってもいい）。その方が簡単だからだ。人工知能の出る幕など無い。
抽象的だろうか。では、このような例はどうだろう。「1ならば2、5ならば10、7ならば14を返す関数」をAIによって自動生成したとする（そのような仕様を指示する人はいない、と思うかもしれないが、例えば単体テストケースからそれを満たす関数を自動生成すると考えてみよう）。さて、2を入力した場合、何が返されるだろうか。言うまでもなく独立した３点を通る関数は無数に存在する。
いや、人工知能であれば、常識を見つけ出し、直線を仮定した上で 2倍して 4 を返す関数を生成するはずだ、と思うかもしれない。しかし仕様には明記されていない以上、その答えが正しいとする根拠はどこにもない。要件を出した人にとっての常識と人工知能にとっての常識が同じとは限らない。それ以上に、仕様が明らかではないプログラムなど危なくて使うことができない。８割は正しい値を返すが、２割は間違った結果を返す可能性があるSIN関数など使いたいとは思わないのではなかろうか。
現在においても人工知能が有用な分野は、だいたい合っていれば十分役に立つし、間違ったところで大問題は起きない場合に限られる。幸か不幸かプログラマが開発するプログラムの大半はその要件を満たさない。
少ない入力で適切な結果を得られるようにすることは、仮定を置くことで、ありえないパターンを捨てることを意味している。おそらくこれは、人工知能というより DSL（ドメイン固有言語）と呼ぶべきものだろう。では、DSLを見つけ出すことはできるだろうか。これはある程度できるかもしれない。いわゆるデータマイニングだ。しかし、その場合も、発見されたDSLを使用する／しないの「判断」は人間が行う必要がある。
例えば、人工知能は「必須のセレクトボックスには空欄の選択肢は不要」というDSLを発見するかもしれない。これはほとんどのシステムでは適切かもしれないが、人によっては気付かず実行ボタンを押してしまうので初期値は空欄にして必ず選ばせたい、と思うかもしれない。これは趣味の問題であって、人工知能には「判断」を下すことができない。
もちろん、もし、人工知能が人間の知能を完全に模倣できたとすれば、「判断」を下すことができるようになるかもしれない。しかし、そのような人工知能が実現したならば、プログラムに限らず、あらゆる知的作業はすべて人工知能に行ってもらえば良い。プログラマの将来どころの話ではない。
人間がやるべきことは、その時点では機械では難しい肉体労働だけであろうし、そのような世界ではおそらく生産能力も飛躍的に進歩しているだろうから、我々はほとんど働くことなく好きなものを飲み食いできるはずである。あるいは、人工知能はもはや人間を必要とせず、あらたな支配者になるかもれない。いずれにしても、あと数百年はただの夢物語であるから、今生きている人間が気にする必要があるとは思えない。
システム開発はもっと明朗会計にならなければいけない
数ヶ月前、都内某所に引っ越しを行ったのだけれど、その際、何箇所かに引っ越しに見積りをしてもらってわかったことがある。まったく明朗会計ではないのだ。いろいろ情報を集めた結果わかったのは、きちんと相見積を取った上で、あそこはこの値段だったので、こっちも下げてくれみたいな交渉をしないと、最安値の三倍程度の金額になることもあるようだ。数千円の違いだけならば、たいした話ではないが、数万から数十万違うとなれば真剣にならざるを得ない。正直なところ、引っ越しのために荷物をまとめたり、各種申請で忙しい時になぜわざわざ引っ越し程度のために余計な労力とお金をつぎ込まなければならないのか理解できない。
結局、日通の単身パックという金額設定がほぼ定額のプランを選んだ。値段も安かったので助かったが、それ以上に騙されることがないという安心感の方が大きかった。引越し作業も（これは引越し業者というより作業者によるところが大きいのだろうが）非常にてきぱきと行ってくれて、満足だった。もし、他の会社の最初の見積りを信じたら同じ引っ越し作業に三倍の金額がかかるところだった。
ひるがえってシステム開発の話。もちろん私もシステム開発に従事する人間であるから、見積りの難しさは知っている。特に初期の見積りは、曖昧な前提に基づくため、結果は曖昧にならざるを得ない。「販売管理システムを導入するんですがいくらくらいかかりますか？」と言われても、その条件だけでは、数万円の市販会計パッケージからERPをアドオンカスタマイズした数十億円のものまで想定し得る以上、見積りようがないのは事実である。
しかしながら、お客に立場からすれば不安になるのもわかる。作って欲しいシステムのイメージは漠然とはあって、それを実現してほしいだけなのだから、それが1000万なのか2000万なのか一億なのか業者から教えてもらえるのが当然なのにも関わらず、たいてい予想よりも大きい金額を出してきて（これはSIerがぼったくっているという意味ではない。システムの開発には想像以上にお金がかかるのだ）、前提が代わるたびに追加費用が請求される。お客が不信感を抱くのも致し方ない。
どうやったらこの問題を解決できるか。
まず、見積りは二つのステップから成る。ひとつは要件を決めること。もうひとつはその要件から費用を割り出すこと。
まず、後者について考える。要件が決まれば、KKDなりKLOCなりFPなどで工数を割り出し、工数に対し人月単価をかけ費用を割り出すのが一般的となる。しかしながら、KKDは論外としても、KLOCなりFPがどれくらい信頼できるのだろうかという問題は残る。
ところが、最近 JUAS のソフトウェアメトリックス調査を読んでいて面白いことに気付いた。以下の二つの図を見て欲しい。
まず、KLOCだけれども、まったく参考にならない。個人的経験からも、機能の開発にはそれに付随して考える時間が大半を占めており実際にソースコードを作成する量や時間は重要ではない。また、JavaだろうとPHPだろうと、フレームワークが違えば作成するコード量はまったくことなり、機能要件から想定KLOCを求めるという作業に無理がある（実際、別のページには Java のプロジェクトに限定して全体工数とKLOCを比較したグラフもあるが、まったく相関がみられない）。
それに対し、FPは明確な相関が見られる。しかもこの図は工数ではなく費用で出ている。このことからわかることは、FPを計算出来る程度まで要件が落とし込めていれば、費用は自ずと決まるということである。そして、これより安く発注しようとすれば、プロジェクトの品質、納期のいずれかが割を食うだろうということであり、著しく安く発注するならば、プロジェクトの破綻を自ら招いているということが明らかになる。
あとはFPを求めるだけである、と言ってもそれが難しいのは明らかである。なんせ、要件という曖昧なものからシステム機能にまで落としこむのであるから。そこで提案なのだが、むしろ、この作業を客側と共有してはどうだろうか。要件からシステム機能への落とし込みはお客では難しいだろうから、そこまでは SIer が受け持つ。しかしながら、FPの算出方法はお客に教え、後の費用の計算はお客自身に行ってもらえばいい。予算オーバーであれば、自分自身で機能を削るしかなくなる。
ここまで書いて今までの経験を照らし合わせると、一点うまくいきそうにない点に気付いてしまった。きっとお客はシステム系の管理機能を削り始めるのではないか。たしかにシステム系の管理機能は、データベースを直接修正すればなくても良い機能ではあるものの、矛盾したデータ登録が発生しやすくなってしまい、運用品質を落とすことになる。お客にして見れば、運用品質が低いのは運用者の問題であることにしてしまえるので、削らない理由にまで思い至らないかもしれない（人は概ね自分の理解の及ばない仕事を過小評価するものだ）。
システム開発を明朗会計にするには、もう一段工夫がいりそうだ。
XMLIC 1.0.3 リリース＆GitHubへの移行
XMLIC の 1.0.3 リリースに合わせて GitHub に移行しました。機能追加そのものはたいした内容ないですが……。wmf2svg も移行し次第 OSDN 側のプロジェクトサイトは閉じてしまおうと思うのだけれど、OSDNは申請しないとプロジェクト閉じれないという面倒くさい仕様で困ってしまう。
http://hidekatsu-izuno.github.io/xmlic/
[20:58 追記] wmf2svg も GitHubに移行した。
