Nov - 14th
完全なテストは不可能だ
Posted at 11:32 am | Filed Under Software, Work
思うに、それは論理学でいうところの帰納法で解決できるのではなかろうか。
完全なテストは不可能だ:
さて、プログラムの話に戻ります。intの引数を2個とる場合、その組み合わせは1600京ほどに なるということを先の稿で述べました。 そして、バグが「ある」ことを証明する場合、バグの例をひとつ探し出せばよいのに対し、 バグが「ない」ことを証明するにはこの1600京のパターンすべてを網羅して検査し、 全て正常に動いたということを提示しなければなりません。
数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある。というかそうでないものの方が少ないはず。
悪魔の証明、という目の付けどころは悪くないのに。まあ、ちょと前に自分でも取り上げたわけだが。
Nov - 9th
キャッチ２２
Posted at 12:03 am | Filed Under Work
大前提：ソフトウェア開発は遅延する。
開発が遅延していることを報告する→ひとしきり罵倒され、原因と対策を明記した報告書を提出する（二度目はないと宣告される）
開発が遅延しているのを報告しない（１）→発覚したら顛末書を提出する
開発が遅延しているのを報告しない（２）→徹夜で帳尻を合わせれば無罪
徹夜でなんとかするか、ペナルティを受けるしかない。徹夜仕事も一種のペナルティだから、どうやってもペナルティしかない。
Oct - 29th
恫喝的マネジメント
Posted at 12:20 pm | Filed Under Work, life
昼休みに、トム・デマルコの本（”デッドライン“）に出てくる人物のことを考えた。今いる会社のマネジメントをジョエル・スポルスキの分類に無理矢理にでも当てはめるなら、この指揮統制マネジメントが一番近いだろう。そして、ご多分に漏れず、自分自身がここに書かれているソフトウェア開発者の典型だ：
うぬぼれの強いソフトウェア開発者は特にそうで、彼らは非常に頭が良く、他の人より知識があると思っていて、そう思うのには十分な理由があり、実際その通りなのだが、そのことによって何かをやるように命令されるのをすごく嫌うのだ。
マイクロマネジメント、とはよくいったもので、これはようするにしごきのことだ。開発部門だけでなく営業や企画運用を含めると、うちの会社では定期的に誰かがこれをやられている。つまり、目をつけられたが最後、自分の人事評価について決定権を持つ人物に大勢の目の前で詰め寄られ、激しく詰問され、難癖をつけられ、自尊心の欠片もないやり方でしごかれている。
それも世渡りのひとつ、と割り切れる人は残っている。そうでない人は、次の仕事が見つかればそちらに移動する。理由は簡単、外的要因が仕事の動機の中心なら、取り替え可能なのでいざ取り替える段となったら躊躇する必要さえないからだ。
幸いにも、開発部門でこれをやられる人はそんなに多くはない。多くはない、というのだから皆無というわけではなく、実はかくいう自分も、入社三年目だがその間に一年くらい口をきくことがなくなった上役がいる。最近、ようやく普通に用件があれば会話くらいはするようになったが、今日の午前中でそれも終わった。急に呼ばれた会議室で、いま開発中の案件についてああだこうだと質問されるので、ああだこうだと答えていると、てめえこの野郎、でけえ口叩きやがって、といった具合に罵られてしまった。まだ不具合も出していない（これからのお楽しみ）案件でこうなのだから、何かあったらどんなにひどいことになるのだろう。
それでいろいろ考えてみたのだが、この人物と一年くらい口をきかなくなったのには原因があって、そういえばそのとき、いざこざの原因になったこの案件が片付いたら、もうこの会社は辞めよう、現状の責任はあるわけだから最後まで見届けて、そしたらここにいるのはやめだ、と思いながら、結局片付いたら片付いたで毎日本当に休む間もなく過ごしているうちに、いつの間にか今に至ってしまったのだった。その最中に母親が亡くなったけれど、そういえば取締役で葬儀に来てくれなかったのはその人だけだったな。今の今まで考えたこともなかったけど。
そのときの教訓は、いくら売り上げを積めば幸せになれるといわれても、無理な開発案件はいくらやっても結局誰も幸せにはなれないよ、ということだ。もし何か奇跡が起きてうまくいったとしても、自分の人事について決定権を握っている人物が、自分の家族のことまで持ち出してさんざん馬鹿にしてくる職場で、次もうまくいく可能性はあまり期待できない。ついでにいえば、人事や給料にだって期待できない。なんで我慢したのかというと、もちろんその案件をなんとかしたいというのもあったし、たまには大嫌いで全員まとめてブロック塀で頭をかち割ってやりたいときもあるが、それでも社内には好きな人間たちもいるのと、それからそこまでこちらを馬鹿にするなら、じゃあそこにいて給料をもらう方がかえって嫌がらせになるかな、と思ったからでもある。
今日の会議についてもう一度考えると、まあそこまでカッカしてもらえているのだから、ある一定のレベルの嫌がらせにはなったのかな、といえなくもない。
去年はずっと、そんな中でも自分の価値を高めないといけない、己の価値のコアになるのはやっぱり技術だ、というわけでいろんなことをこっそり押し進めてきた。結構勉強できたし、実装してみたら使っている人に喜ばれる技術もあって、自分はひょっとしたら人事評価ほど無価値な人間ではないのかもしれないと思えるようになった。今となってみれば、まあこれも塞翁が馬というやつだったのかもしれない。とはいえ、それが評価に繋がっているわけではないので、居心地が悪いことには変わりなかった。いくら塞翁でも、心頭滅却したら燃えちゃった、では困る。
恫喝的マネジメントで最悪なのは、それが軍隊でしかうまくいかないことで、軍隊の生活は基本的にキャッチ２２なのだ。本来はコードを読んだり書いたりするはずの時間に、こうして糞の役にも立たない日記を書いているのもその副作用だ。
それにしても、三年も同じ職場にいると、他のところがどうだったのかちっとも思い出せない。ひょっとしてどこも状況は似たようなものなのだろうか。だとしたら、ソフトウェア開発なんてさっさとやめてもっとやりがいのある目標を見つけた方がましなのだろうか。
Oct - 23rd
不在の証明、ミニクジラ
Posted at 7:40 pm | Filed Under Work, life
メンテ中のウェブアプリケーションにセキュリティホールがあるとずっといわれているのだが。
今までに、具体的にどこがセキュリティ的に問題なのか指摘されたことはない。セキュアな運用を実現するための機能が欠けている、とはいわれたことがある。でも、それはアプリケーションの仕様にユーザレベルの細かい設定機能がないということで、セキュリティホールがあるといえるかどうかといえば、ちょっと違う話だ。
最近では、その話をされるたびに、不在の証明について考え込んでしまう。
ちょうどイラク戦争の時に大量破壊兵器について同じことがいわれていたので広く知られているとは思うが、悪魔の証明とか不在の証明とかいわれているものは、ようするに特殊なケースを除いて「ある事実が存在しないこと」を証明するのは一般的に困難なことが多いという意味だ。大量破壊兵器がある、と言い張ることは簡単だが、ないと証明するのは難しい。イラク国内を文字通り隅から隅まで探しても、実は驚異的な速さで移動しているため発見出来ないケースがある、といわれたらどうしようもない。で、実際には見つかっていないのだが、どんなにその事実を主張しても、相手が不在の証明を求めるか存在の可能性だけを主張し続ければ、いつまでたっても決着がつかない。
今、仕事で困っているのが、セキュリティホールが存在しないとこちらが証明しない限り、相手方には常に同じことを繰り返して主張される立場に自分が置かれてしまっていることで、それはまさしく「消極的事実の立証責任を当事者に負わせる」ものなので、証明は困難あるいは不可能としかいいようがない状況に陥ってしまっている。
もちろん、セキュリティに対する意識が高いのはよいことだ。しかし、それが不在の証明になってしまう状況は生産的ではない。不在の証明が出来ないのを理由に、やれ顧客が逃げるだの、リリースは出来ないだのいわれると、ではせめて積極的事実の証明として修正すべきセキュリティホースの存在を指摘してくれと思う。
IT業外には、セキュリティ意識が高い人のことをパラノイドという呼び方をする会社がある。これは蔑称ではなく、それだけ意識が高いことを賞賛する意味合いがあっての呼び方なのだが、もしそのパラノイアがある線を越えてしまうと、本物のパラノイドのように同じところをぐるぐる回って少しも前に進まないことになり、それはそれで新しいセキュリティホールも世に出ないので大変結構なことではあるが、新しい機能も製品も出ないので誰も幸せにはなれないのだ。
不在の証明について面白いことがしたいなら、高校生の頃にちょっとはやった遊びをやってみるのをお勧めする。昼休みに同僚に向かって、ホームセンターのペットショップに淡水では生息できないのでちょっと手間がかかるが、家庭でも十分飼育が可能なミニクジラというクジラが売っている、という話をしてみるのだ。大きさはだいたい手のひらに乗るくらいで、成長してもこれ以上にはならないらしい。エサは乾燥エビなどペットショプで売っているものでいい。小さいながらも立派に潮も噴くので、ガラスの天井があった方がいいが密閉すると空気が悪くなるのでそこら辺がちょっと気を使うところだ。ミンククジラの一種らしく、東南アジアの喫水域に生息し、マングローブの根元でエビなどを補食している。
もし、そんなのいないよという人がいたら、ミニクジラが存在しないことを証明してもらうといい。
Sep - 16th
軍隊的マネジメントの会社
Posted at 11:53 pm | Filed Under Work
たいそう忙しそうな女性がいる、と聞いたので、そのページに載っていた彼女のスケジュールをみたら驚いた。だって、朝７時２５分から会社にいて、退社時間が２４時丁度なのに、実質彼女が働いているのは４時間しかないんだもの。
いや、もちろん会議だって来客対応だって仕事なんだけどさ。
長期的なマネージメント、という点から仕事を組み立てようとしたとき、１日の内に自分の裁量で作業出来る時間が合計で４時間しかないのでは、何か改善したいポイントを見つけたとしても、ほとんど自分では動けない状態だ。
朝５時半に起きているということは、睡眠時間は２時間半。つまり、マネージメントがほとんど寝不足状態で、作業の進捗は報告と会議で把握してはいるものの、現場の状態から改善すべきポイントが見つかってもほとんど分析する時間がない。
つまり、彼女の会社は軍隊みたいな組織なんだろうな。だから、そんな分析や改善は不要なのかもしれない。部下のマネジメントの中心は、何かやった人を「怒る」だけ。猪突猛進型の現場で活躍する軍曹。それが彼女の仕事なのであれば、確かに余裕をもって考えることは無駄だ。
Sep - 15th
逆Switchによる作業効率の低下
Posted at 12:26 pm | Filed Under Work
業務の効率化についてはだいたいこんなことがいわれている：
業務の効率化は短期的には効率が落ちることが多い
業務の効率化は長期的な対策なしには実現できない
例えば、プログラマの作業環境を変更する場合。今まで慣れ親しんだ環境を大幅に変更されると、代替のシステムがどんなに便利であっても、ちょっとしたことですぐに作業の効率は落ちる。メモリの増設やディスプレイの追加や交換であれば、これといって問題はなく、むしろ助かったと感謝されるだろうが、バージョン管理システムの導入や夜間ビルド、自動テストなど、開発環境には欠かせないようなものであっても、慣れ親しんだ環境を捨ててそれまでの手順と異なる作業を強いることはプログラマの負担になる。
実体験を語るのはちょっと憚られるので、例えば、平均以上の技量を持つプログラマが、普段viでコードを書いているとしよう。仮名は丸山さんでいいや。２８歳、独身。痩せ形で、これといって目立つところはないが、強いて特徴をあげるとすれば、どんな暑い日でもシルクハットとお揃いの黒いビロードのスーツ姿でしか人前に出てこないWilcomユーザ。そんな丸山さんに、チームでの作業には欠かせないからという理由でコードチェックやレポジトリへの自動コミットなどなどの機能がてんこもりになったEclipseに移行してもらうとする。発案したのは丸山さんの直属の上司にあたるSEで、丸山さんとはちょっと趣味やコミュニケーションの面では難しい関係にあると感じているが、時折砂漠でラクダと話しているような気分になることを除けば、丸山さんのことは好きだし、出来ることなら夜道を歩いても通報されないくらいの時間には家に帰してあげたいと思っている。
もちろん、そのための準備としてSEは業務の合間に徹夜で資料を作成し、効率化グラフなんかをでっち上げて作業を進める承認を貰ったり、上司に予算を確保してもらったり、プログラマへの説明資料を用意していた。これが調査を含めて実働でだいたい一週間くらいの作業だから、コストはその分のSEの単価と彼の寿命、上司のミーティングの時間分の単価、それから説明会に出席する丸山さんたちプログラマの一時間分の時給の合計だ。１００万には届かないが、数十万円にはなっている。哀れなSEの命はプライスレス。
説明会は順調で、丸山さんも見事な口髭に手をやりながら、遠くを見るような目でしっかり話を聞いてくれていた。SEも少しは自分が何か出来たような気がして満足した。これで明日ちょっとくらいは遅刻してもいいなら、もっと幸せなのに。ソフトウェアの導入は各プログラマが各々の環境に一時間ばかりかけてインストールする。ここでもちょっとコストがかかった。今日の作業に支障が出ないように、インストール作業は定時ちょっと前に始められ、完了したらみんな帰っていいことになっている。丸山さんはちょっと戸惑っているようだ。エディタが白い背景にカラフルな文字という組み合わせには耐えられないと、あれこれ設定をいじっている。明日からは人心一新、ジョエル・テストで３ポイントくらいアップした環境で作業を続けよう。SEは明日から業務の効率化の計測が始まるため、結局また準備で終電まで働いた。
プログラマとその作り出すプログラムのユーザに共通している点は、いくら説明を聴いてもマニュアルを読んでも、片っ端から忘れてしまうことなので、翌朝から現場にはちょっとした混乱が生じていた。説明会で話を聞いているときにはなんだかわかったような気がしたのに、いざ目の前のシステムを触る段になって、あれはどうするんだっけ、これはどうなってんだっけ、と迷ってしまう。他のプログラマたちがあくせくとマニュアルを読み返したりしている中、丸山さんはというと、独自のマクロやキーバインドが使えないので、どうにかならないかとやはりウェブや書籍とにらめっこしている。午後になっても今日のタスクに取りかかれていないらしい。やがて、諦めてようやく作業を始めるが、ため息をついたり、ティッシュを敷いてその上にコーヒーかすをもんじゃ焼きみたいに丸く集めたり、どうも集中出来ていないらしい。周囲のプログラマが徐々に作業のペースを取り戻す中、明らかに孤立してしまっている。
と、ここまで延々と書いてきて、そろそろ疲れたのでどこかの本からパクッてきたようなお話し口調を中断して、結末がどうなったかというと、だいたいこんな感じだ：丸山さんは、自分が不当な扱いを受けているような気がしてくる。他のメンバと比べても遜色ない実績をあげてきたのに、急に妙なルールを押し付けられて足を引っ張られたような気分だからだ。SEはなんとか彼を励まして、このシステムがいかに他のメンバに貢献するのか説得するが、そんなことはわかっているとしか返事をもらえないのでほとほと困り果てている。お気付きの方もいるだろうが、作業環境の変更の際、SEは自分のプランについて上司には承認をもらっているがプログラマである丸山さんには何の相談もしていないので、これはある意味当然の帰結だ。やがて、丸山さんも慣れてきて長期的な効率の向上には貢献出来るようになるのだが、なんとなく心の中に生じた嫌な感じは拭い切れない。そう、彼は上司であるSEに「恨み」の感情を持ってしまったのだ。
この「恨み」というやつは、人間のモチベーション管理の面で非常に大きな障害となるやっかいな代物だ。初めてこの「恨み」フィルタを通してで周囲を見てしまうと、周囲の人間がいかにロクでもない奴らで、自分はいったいどんなに哀れでちっぽけで無価値な存在なのだろうと思い込むようになる。不当な扱いを受けるのは、人間の合理性をなんとなく信じて生きているわれわれ人間にとって、それはそんな扱いを受けて当然のろくでなしだからだ、という結論に自然に到達するようになっている。たとえそうでないにしても、少なくとも自分以外の人間はそう思っているに違いない。だから、自分はこの職場にはフィットしない。よし、転職しよう。
こうして、丸山さんはたっぷりの有給休暇を使って、ちょっとした念願だったワードローブに立て篭って座禅を組む精神修行を始めてしまい、残されたプログラマやSEは掃除用モップをしゃぶって悲しんでいる。人が増えても業務は減らないが、人が減ると業務は確実に増えるからだ。
というわけで、悲哀の中間管理職としては、業務効率改善はいい加減には出来ないな、と思うと同時に、どうして俺はMacで仕事出来なくされてしまったんだろう、そして支給されたDELLのマシンのレジストリとやらが壊れて作成したドキュメントは消え去りディスクは認識されなくなり、再インストールとアップデートのやり直しで丸一日を無駄にして、結局最後は元のMacBookを引っ張りだしてEmobileで常時接続しながら、LANには入れない不便な環境でもなんとか仕事をやり終えて、家族にはどうせ夜中にエロサイトでも眺めて遊んでいるんだろうとそしられ、徹夜明けの朝に銀行で結んだローンの契約では最悪の選択をして、家族からは馬鹿にされ、再作成したドキュメントは間違いだらけで、心臓が涎を垂らして貧乏揺すりが止まらなくなるのでもうなんとかしてくれ。
Sep - 11th
仕様書
Posted at 2:39 pm | Filed Under Work
この２週間、ずっと仕様書を作成している。来週で１回目のレビューだ。
気づいたらこの作業をやる他ない状況にいたのだが、はからずもちょっとした面白さのはじっこに自分が齧りついているかもしれない気がしてきたので、メモしておく。
まず、仕様書の作成を依頼された（本来自分から言い出すべきだったのだが）時に念を押されたのは以下の３つ：
（１）実装の詳細は書かない
つまり、これは機能仕様書であって、技術仕様書ではない。
（２）全ての機能と機能のフローを記載する
要するに、仕様書で大事なのはINとOUTがはっきりと書かれていること。
想定される読者は、プロジェクトマネージャ、営業マネージャ、この製品を使って実際のサービスを構築する開発チームのマネージャ、リリース後に保守を担当するテクニカルサポートチームのマネージャ。この人たちを、ただの読者にしておくことはやらない。それぞれの視点から、自分の担当する業務や今後の戦略に照らし合わせ、この仕様書に記載された内容で過不足ないかどうかをチェックする義務を負う。
（３）レビューの目的と期日、目的を明確にして通知する
最初の打ち合わせの時に、期日までにレビューを完了してリクエストを返さない限り、希望する機能が他にあったとしても、そしてそれが自分の業務に欠かすことの出来ないものであっても、絶対に組み込まれない旨を想定読者全員に通知する。もちろん、本当にそうするつもりだ。何か機能を組み込み忘れたせいで製品が売れなかったら、それはリクエストしなかった人の責任になる。
実は、この仕様書を作成する前に、もうプログラムを作成する日程を決めて実際に作業を始めようとしていた。そこへ、リリース後のサポートを担当するチームのマネージャからストップがかかった。現状のままで開発を進めた場合、製品の品質に重大な懸念があり、サポートは責任を持てないというのだ。まったくもってノリの悪い奴だ、と思ってやろうとしたが、その前にじっくりと考えて、確かにその通りだと思うことにした。まったくその通りだから。うん、実にその通りだ。当初は、複雑な製品なのだから、作ってからバージョンアップして改良していけばいい、と考えていた。でも、その割には改良のためのコストは誰もどこにも計上していない。自社製品なのだから、日々改良するのは当たり前、みたいな雰囲気もあったせいかもしれない。
最初は、どんな機能を実装するかは企画担当者に任せて、こちらはそれをプログラムにするにあたって必要な作業に集中していればなんとかなる、と思っていたのだが、それだといろんな人たちとの間で本当にコンセスサスが取れたものが作れないし、みんな忙しいから、いつも都合がいいときに内容をチェックして、要望をくれるわけでもない。だから、大規模な商談がまとまりそうになってはじめて「そういえばこんな機能あるよね？」といわれたりする。こういったことは作るコストに含まれていないから、結果的にずるずると金ばかりかかってしまう。
追記：
ギャーッッッッ！！！仕様書が5MBを越えたらWordが落ちて二度と開けなくなっちゃったよ！どうしよう！もう間に合わない！
Aug - 9th
新婚の法則
Posted at 11:50 am | Filed Under Work
結婚直前の部下は早めに帰宅させること。じゃないと辞めちゃう。
Aug - 2nd
気に入らねえ
Posted at 10:52 am | Filed Under Work
何の縁があったか知れないが、同じ会社に入ってきた若い連中がいる。最初は無邪気に元気で、まあ能力は少し足りなくても、それでもまあ頑張ってくれと思っていた。しかし、ある頃から彼らがどんどん生気をなくした顔になっていく。やがて、元気だった彼らも、用事を頼んでも怯えたような顔で目をそらしたり、しどろもどろに説明する手先がぶるぶる震えるようになり、数ヶ月後には鬱病だの心身症だのなんだのになって退職していくことになる。
そんなの珍しくもないという業界もあるだろう。俺の仕事も、まあそんなもんだ。だから、実際に直属の部下にも、こういう人はいた。いま思い返すと、つくづく悪いことをしてしまった。もちろん、なんとかしようとは思っていたし、出来ることはやった。でも、成果は最悪のものだった。俺だけの責任ではないのだが、少なくとも、俺とその周囲はその人が能力を発揮する可能性を潰した。これが現実であり、結果だ。
小飼弾の書くことで気に入らない理由は二つあって、一つは彼の書いていることは無闇な青春讃歌で、しかも「歳とってみりゃわかるよ青春の価値は」みたいな妄言であることなのだが、そういうのはプロ野球からだけではなくこの世から消えてしまって欲しい。で、もう一つは、可能性が発揮されるのは堪え難い負荷を克服した後だ、という無邪気なお題目で、甘やかされた中流みたいに命や死を軽んじた論法が繰り広げられていることだ。「俺は死にかけたけど、頑張ってよかったよ」「人間って案外簡単には死なないね」と、ここまではまだいい。でも、「死ぬより可能性がつぶれる危険の方が大きいのに、死ぬことを懸念しているのは喜劇だ」となると、冗談は顔だけにしろということになる。
彼と一緒に働いている（いた）人の中には、ものすごい負荷をかけてもなんとかやり通してしまうタイプの人間と、精神や身体（この２つは別々のものじゃない）に変調をきたして脱落した人間の２種類がいる（いた）はずだ。この業界では、別に珍しい話ではない。そして、何の偶然か知らないが、小飼弾の自己認識では彼は前者のタイプだったようだ。それはそれで御目出度い限りなので別に文句はないが、今やそんな彼も歳をとったし、ちょっと視点を変えてみることは出来ないだろうか。
例えば、もし彼が上司として職場で指揮を執っていたら、彼は前者のタイプの部下たちの可能性をどこまでも引き出すことが出来るかもしれない。商売繁盛、株価上昇、大変御目出度い。でも、その一方で後者のタイプの人たちの可能性は、間違いなく潰してしまうだろう。それどころか、相談に来た彼らに、
そこで考えを止められる、あるいはそこまで考えたところで息の根を止められるというのはかなり幸せなことではないか。
問題は、その後に生き残ってしまうことも多々あること。いや、確率から行けば、その方がずっと高いのだ。するとどうなるのか、「これ以上何もしないで死ぬ」ということが、「何かのために最適」という状態になるのだ。そのような状態を、私は「余生」と呼んでいる。
などと説教するかもしれない。自分の信じる変態でマゾな幸福論をぶちかますことで、己の正しさに光り輝くのも、ある局面では結構なことだろう。でも、ちょっと待ってもらいたい。可能性だなんだという前に、ずっと低いとはいえそれなりの確率で人が死ぬなら、それはシステムとして間違っていることなんじゃないだろうか。それに、コキ使っているうちにくたばった人がいたとして、その人の親御さんに「何かの為に死ねる(死んでもいいと思える)ということは基本的に幸せなことだと思う」などどふざけたことがどうして言えるだろうか。まあ、言うのは自由だし我々は世論と体制が許す限り自由である素晴らしい社会の一員なので、勝手にすればいいのだが、もし俺がそんなことを言われたら、「じゃあお前が死ね」と答えるだろう。
そういう意味で、この日記の人もとんでもない思い違いをしている。いや、この人は本当に自分が死ぬなんてことは想定していないのかもしれない。でも、
労働を強制されるのは最悪のことだが、死んでしまうぐらいに働けるなんて幸せじゃないか。というか、何かの為に死ねる(死んでもいいと思える)ということは基本的に幸せなことだと思う。
なんてことは、奴隷が奴隷に向かって話す、あるいは領主が奴隷に向かって言い放つ以外には口にしてはいけない言葉なのだ。何かの為に死んでもいい、と思うのは基本的には自己陶酔でしかない。己の想像世界の中で精一杯粋がるのも中産階級市民の大いなる自由の一つだが、死なれる側にとっては、なんとか死なないで済む方法はなかったのか、どうして死ななければいけなかったのかという終わらない問いだけが残されるものだ。奴隷だもんね、と言われたらそれなりの説明もつくだろう。でも、普通は人の自己認識はそうじゃない。
そう、小飼弾の書いたことで本当に気に入らなかったのは、彼が自己陶酔の中でどんな寝言を言い放とうが全くもって彼の勝手なのだが、世の中の人間にその寝言を当てはめていくと、誰かの子供であったり夫であったり親であったりする人間を、
実際そのころ、私は何度か自殺未遂もしている。そのころの私にとっては、それすら「壁を越える」方法の一つに思えたのだ。はっきり言って、莫迦である
なんて状態に追い込むことをいかにして防ぐのか考え、実践するのが正しいことであって、追い込まれた人を「死なない確率の方が高い」と誤摩化して丸め込んだり、そんな状態を生み出すシステムを是正したいと考える人の文章を引用して
この設問は、”depends on whom?”だけではなく、”depends on how old?”でもある。同じ人でも、それが人生のどのステージにいるかによって、どうすべきかの答えは変わってくるからだ。
とルー大柴みたいなご見解を述べることで「（才能、能力は）人によるよね」「歳食ってみりゃわかるよね」などと曲解してしまうのは間違っていると思うのだ。
最後に、小飼弾の署名も間違っている。正確には、Aging man with misguided fantasyだ。わかる人にはわかるように、これはレジデンツの歌詞だ。
結局つまらん冗談と駄洒落が言いたいだけなんじゃないか、と憶測される文章を書くことで小飼弾へのオマージュとする。
Jul - 12th
ホーア式、人事、仕事
Posted at 3:39 pm | Filed Under Work
最近ずっと勉強しているホーア式について考えてみた。
（俺が知ってる）ホーア式：
precondition { execute } post-condition
前提条件（precondition）があって、何か実行（execute）すると結果（post-condition）になる。
ロジックとして考えると、面白いことがいくつかある。例えばexecuteで例外や無限ループが発生すると、ロジックとしてはこの式はTRUEになる。なので、実際の業務とかプログラムのテストで使う場合はタイムアウトや例外発生時についても記述しておかないといけない。あと、preconditionがそもそも成立しない場合も、この式自体がスルーされるのでやっぱり結果はTRUEだ。ちょっとややこしいが、これをプログラムのif文だと思えば、そもそもif(precondition)が成立していなければこのif文の中身が実行されることはないので、式が存在しないに等しくなるからだ。
こういったことを踏まえて、ユニットテストが可能なプログラムの作成とホーア式にあてはめたテストによるプログラムのテストを実行できるようにする、というのが目下の俺自身のテーマでもある。いや、真面目な話。
で。
高校のとき、初めて教室に入ったら、壁に「ホーレンソー」とか書いてあった。報告と連絡と相談の頭を取って繋げてホーレンソー。これが大事なことだ、という。まるで密告でも奨励するかのような標語に非常に違和感を覚えたのだが、プログラミングの仕事をするようになって開発会社で働いているとやたらとこの言葉を耳にする。それから、PlanとDoとCheckの頭文字を並べたPDCという一昔前の携帯電話みたいな用語もあって、これもミーティングなんかでしょっちゅう聞かされる。PDCというのは、計画を立案して、実行して、その結果を計測するという意味のようだが、仕事の進め方はとにかくPDCでやるべきであり、その結果をもってその人の業務の評価が上がったり下がったりするというもの。この手のシステムで人事評価を下している会社はたくさんあるだろう。
でも、プログラミングの世界では、ホーア式のチェックやPDCが人事評価に繋がるというのは明らかにおかしい。
PDCは、ホーア式と基本的によく似ている。preconditionがあって、計画を立案して、そいつを実行して、post-conditionをチェックする。
plan { do } check
全部動詞が入っているのでちょっと違うが、まあ要するに業務の計画と実績はplanがあってdoしてみてcheckによって評価して、それがTRUEであればあんたは頑張ったと給料を払って、FALSEであれば何をやっとんじゃこのボケどこでそんなボンクラ頭を拾ってきた、とどやしつける。これが人事評価と呼ばれる拷問だ。
でも、プログラミングの世界でこれをやるのは明らかにおかしい。だって、プログラムを作ったら、普通はまずテストをするはずだ。そこで結果が間違っていたらどうする？直すでしょ。部下が組んだプログラムがホーア式でFALSEの状態のまま納品されていたらみんな怒るかもしれないけど、ブラックボックステストあるいは単体テストでこの状態であれば、とっとと直してくれというだけだ。
なぜなら、プログラミングの世界では、この時点での目標はprecondition { execute } post-conditionがTRUEになることであって、これを実行して真偽を確認するのは、単純にコードを書いたりテストをしたりするのと同じで、開発の中のひとつのプロセスに過ぎないからだ。その意味では、プログラムはこの時点ではまだ完成していない。テストは完成に至るためのプロセスの一つであり、それ以上でも以下でもない。そして、最終的な目標は、仕様の通りにプログラムが動くようにすることなのであって、これまたそれ以上でも以下でもない。それに、往々にして最初の設計や仕様がプログラムを作っていくにつれて現実にそぐわないものであることが判明するなんて日常茶飯事で、それをどうにかこうにか改良するプロセスは開発につきものだ。だから、最適化したりここを直したりそこを直したりといった作業が発生し、それがプログラミングの日常になっている。
ところが、いわゆる会社の業務というやつは、結局ここで例外だのエラーだのが発生することはすなわち担当者の誤りであって、部門あるいは全社的な最終目標を達成することよりも毎週ミーティングで提出させられるPDCの結果報告で点数を稼いでおくことの方が人事評価的には重視されるケースが多い。いうなれば、単体テストで×がついた項目があればそれだけで上司やら同僚やらに非難されてしまうのだ。プログラマにとっては理解しかねることだが、普通の会社ではこれが当たり前のようになっている。決算前に業績を積み上げるために価格を下げるような売り方がまかり通ってしまうのは、この短期的なPDCサイクルの中で評価を上げるためであり、それが長期的に見れば決算期以外の時期の買い控えを招くことになっても、個々の営業担当にとってみれば知ったこっちゃないというのと同じだ。
これは明らかにおかしい。作ったプログラムの中に単体テストで動かない箇所が見つかった場合にはプログラマにペナルティを課すなんてナンセンスだろう。動かない箇所を見つけるためのプロセスがテストなのだから、ペナルティを課すのでは目的が違う。もしそんなことになったら、プログラマは誰もテストに自分のプログラムを提出しない。工期が切迫していようがなんだろうがとにかくどこまでも自分でテストして、問題がありそうな箇所があればなんとか隠蔽するかもしれない。
ところが、プログラミングの世界を離れると、実際にこの手の隠蔽工作は会社の中では頻繁に行われていて、チェックの不備を突いたマジックであろうがなんだろうがとにかく数字合わせが出来れば問題なし、ということになるケースが非常に多い。なぜなら、それは営業にとってペナルティを逃れる手腕の一つであり、管理職にとって上司に怒鳴りつけられるのを回避するための処世術だからだ。チェックは仕事のプロセスの一部ではなくて、どちらかといえば検閲や取締り、ガサ入れに近い。
0.49999999999 { 四捨五入 } 0
« go back — keep looking »