hkoba blog

プログラマーです。プログラミング言語ミーハーです。ツッコミ歓迎です。よろしくどうぞ(能代口調)

自戒与太話: 上下意識はハッカー文化に合わない

自戒

あくまで自戒として。少しだけ 8p 方面へのエールも。

前提：フィフティー・フィフティーな関係って、言うじゃんよ？

我が国は、少なくとも法律の建前の上では欧米と同じく、 身分の上下のない、平等な社会 を目指すことになっています、よね？ だとして、以下に挙げる関係が、日本で「 50%/50% の、対等な関係 」(お互い様、貸し借りなし、恨みっこなし…)になっていると言い切れる人が、どのくらいいるでしょう？

  • 客と店員
  • 雇い主と従業員
  • 人事部と就職活動中の人
  • 上司と部下
  • 元請けと下請け
  • 大企業と中小企業
  • 老人と若者
  • 年長と年少
  • 先輩と後輩
  • 先生と生徒
  • お役人と一般大衆
  • 政治家と一般大衆
  • 先生と呼ばれる地位と、そこから漏れる人

もちろん、以下の点は踏まえるとして：

  • 上記の関係の中には、本質的な力量の差が存在するケースもあるので、そこを勘定に入れた関係のアンバランス(貸し借り)が生じるのはやむを得ません。
  • あるいは会社や軍隊のように、意思決定と命令の秩序体系を作るため、便法として地位を規定することもあるでしょう。
  • 心の中でどう思っているかは自由です。それを社会的に、言葉、態度、行動として外に出した時だけを考えます。

思考実験1. 文脈を外してみる

では、以下のように元の文脈を離れた時に、両者がきちんと「対等な関係」にリセット出来ているでしょうか？

  • お店の外での「客と店員」
  • 業務時間外の「雇い主と従業員」
  • 業務時間外の「上司と部下」
  • 部活の外での「先輩と後輩」
  • 学校の外での「先生と生徒」

文脈の外まで引きずって「偉ぶる / 下手に出る」部分が有れば、そこには根拠なき「上下意識」があるように思えます。「下手に出ない、といって怒る」などは、相手を(マイルドな)奴隷と見ている証拠でしょう。

フェアか否かは発言内容だけでなく、態度でも決まる

文脈を外れた時に「対等な関係」に戻れるなら、文脈の中ではどう振る舞っても良いのでしょうか？ そんなはずはなくて、例えば「 客から店員への暴言 」は不当でしょう。「強い立場を不当に利用して、抵抗できない相手を攻撃している」と言えます。

ただ、一歩踏み込んで、 どこからが暴言か？ となると、「何を言ったか・行ったか」単体で判断するのは簡単ではない、ように思います。例えば：

  • 食堂で客から店員へ「◯◯がマズイ、と苦情をいうこと」
  • 仕事で上司が部下へ「どちらのデザイン・プログラムソースコード・…が美しいか、に関して指導すること」

この「マズイ」「美しい」は個人の感覚に依存するので、発言が 妥当か否か を字面だけで判定するには多数の他者の意見も集めない限り無理でしょう。そして妥当か否か定かでない発言が フェアか否か は、どんな態度で、声色で、それを言ったかで決まる所が極めて大きい、ように思います。

思考実験2. 文脈の中で、立場を逆転してみる

そこで今度は、ある発言態度がフェアか否かを判別するための思考実験として、 以下のように(文脈の中で)突如、立場が逆転したケースを考えてみましょう。

  • 学校で「夏休み明け、クラスメートに、背を抜かれていた」
  • 職場で「以前の部下が、今度は上司になった」
  • 職場で「以前は自分が相手のバグを指摘する側だったが、今度は自分が相手にバグを指摘される側になった」
  • 時代劇で「邪険に扱ったジジイが、黄門様だった」

ここで強い立場から弱い立場に移っても、全く同じように振る舞える人は、万人にフェアに接する努力をしている人ではないかと思います。逆に「居心地悪く・気まずく」感じたり、「仕返しされないか」怖くなる人は、「上下関係と上下意識が生む、強い立場の力」から不当な利益を得ていた、んじゃないカナ〜

強い立場にある人が、その立場の力を乱用すると、どんな害がある？

  • 無駄が無くならない、増えていく
  • そこを理不尽に感じる、不幸に感じる人が増える
  • 組織・社会に閉塞感が蔓延する
  • アノミー(無連帯)が現出する？？

真のハッカーならどうするか

真のハッカーは、無駄や理不尽を嫌うはずです。何故なら、その無駄こそ、ハッカーの愛する計算機が解くべき問題だからです。無駄を無駄のまま放置することを心の底から憎悪し、それを強要する者には (実行できなくとも) 心の中では殺意に近い感情を抱く、それがハッカーの自然な感情であるように、私は理解しています。

また同時に、真のハッカーは、矛盾を嫌い一貫性を追求する心を持っている、ように私は思います。論理や構成の一貫性は、プログラムの美しさと通じる部分があるからです。

それ故に、真のハッカーを目指す人は、自分の中から上下意識を駆逐せねばならない。上下意識に基づく行動を、注意深く見分けて、自分がそれをせぬよう避けねばならない。さもなくば、 無駄への殺意 か 自分の中のダブルスタンダードへの殺意 が自分を殺す日が来るからです。

Q1: 体育会系的な上下関係が全て悪だと言うのか？

いいえ。「敬意を表現する方法」の訓練システムとして、体育会系の上下関係には一定の価値があるでしょう。名誉への敬意を表現するフォームを多くの日本人が学んできたことは、社会の安定に役立って来たのではないでしょうか。

問題は、その敬意を受け取った側が、相手を「目下の者」として扱いがちなことだと、私は思います。敬意には感謝で返せば済むだけなのに。ちゃんとした武道教育にはこれも含まれていたはずですが…

Q2: 具体的に何から始めれば？

例えばコンビニの店員さんに敬語で接するとか…

おまけ

「 自分の力をフェアに使う 」とはどういうことか、主人公と一緒に悩んでみると、学びがある、かも？

Landreaall: 1【イラスト特典付】 (ZERO-SUMコミックス)

Landreaall: 1【イラスト特典付】 (ZERO-SUMコミックス)

Amazon

世捨て人の(胡散臭い) まじない師ならではの「力の正しい使い方」から、学べることもある、かも？

イクストランへの旅(新装版)

イクストランへの旅(新装版)

Amazon

もう少し真面目に、権力闘争と正義について考えたい人には、 兵頭軍学 をオススメしたいです。それについてはまた今度…

「納品のない受託開発」、フリーランスな私の場合

先日、「納品」をなくせばうまくいく、という本を買いました。タイトルに近いことを自分も長年感じていたので、即買いでした。

「納品」をなくせばうまくいく

「納品」をなくせばうまくいく

私は(この本の著者さんと違って)フリーランスですが、 (実質的に)納品のない仕事の請け方を追求してきたので、非常に納得する点が多く有りました。 また同時に、自分の現場には適用できない点や、 フリーランスな自分では辿り着けない点も多々見つけられたので、 少しまとめてみます。

本の要約

私なりに要約すると…

  • (特に Web サービス系の) ベンチャー事業にとって、従来の「一括請負⇒納品して終わり」 という形の受託開発は相性が悪い。なぜなら、
  • 一括請負型の受託開発ビジネスとは
    • 全機能の要件定義と見積もりを最初に行い、
    • 全機能をまとめて開発して、納品して完了
    • 保守・運営(運用) は別会社に、 というものである。
  • これに対し、Web サービス事業で、どの機能が当たるか予め全て予測することは困難。 事業の成否はサービス開始後の、運営しながらの継続的改良にかかっている。

つまり、発注側が「頑張って欲しい」と思っているところと、 受注側が「頑張る所」が根本的にズレている。 ズレの根っこが「納品」というゴール設定にあるので、これを取っ払って、 新しい仕事の請け方、頼み方を組み立ててはどうか？と。

フリーランスな私との比較

共通点

  • 仕様書なし、見積もりなし、納品(完了)なし
    • (作って納品して終わりでなく) 日々改良していく
    • 月額定額制
  • 一人の開発者が目標設定の打ち合わせから開発・運用まで、一貫して関与(伝言ゲームにしない)
    • 要件定義や仕様書などの「実行できないペーパー」で事前に縛ろうとしない。
    • 何を作るか、何を優先して作り始めるかのコンサルティングも、開発者の仕事
  • 顧客にも動作確認の責任を分担してもらう

私がガチガチの納品というゴールを避けるようになったのは、 本来好きで楽しいはずのプログラミングが、 仕様と締め切りを固められただけで (どんなに凄いプログラムでも) 出来て当たり前となり、 妙に苦しくなることへの疑問が有ったからでした。 そこでいつからか、エンドクライアントの居る案件でも 「お客様にお知らせする仕様＆納期にベストエフォートだと断りを入れる」 ようにした結果、精神的に随分と楽になったので、最近は全てそうしています。

異なる点：スタッフさんの訓練まで請け負うなら遠隔勤務は難しい

フリーランスであること以外で、「納品のない〜」と私の仕事の最大の違いは、 リモート作業が主か否か、です。この著者さんの会社の場合、 基本的な開発作業は自社で行い、会議もリモートで参加するようです。 ですが私の場合は、少なくとも現状では顧客のオフィスに出勤せねばなりません。 その最大の理由は、私が 「サービス運営スタッフさんへのプログラミング教育・訓練」 を請け負っているからです。

私の顧客の事業は受注案件ごとにプログラム開発(作成、と言うべきかもしれませんが)を行うもので、 (年間数百件の開発を私が直接作っていては事業がスケールしませんから) 顧客が人を雇って開発を行ってもらっています。 しかも顧客が雇うスタッフさんは、実はプログラミング未経験者ばかりです。 業務的に知名度がないことに加えて、CSを取ったプログラマーだと すぐに飽きて(辞めて)しまうようなプログラムを、次から次へと年がら年中、書かねばならないためです。 未経験の方が、何年も掛けて現場で学んでいける分、定着して下さっています。

そういう状況ですから、私の仕事は、

  • プログラム未経験者でも戦力になれるような Web App Framework と、そのための (簡易) IDE を提供する
    • プログラミング未経験者でも (頑張れば) 習得できる DSL を提供する。
    • 綴り間違いなど、陥りがちな単純ミスを、可能な限り静的に検出する。("use strict")
    • 作成作業の中で、手間がかかって思考を分断させるところや、取り違えミスの温床になりそうな所は、出来る範囲で GUI 化して、トラブルを減らしていく。
      (彼らを完全に救えている、とはまだまだ言えないのが心苦しい所です ><)
  • その WAF (や、その後継機) 上で用いる業務応用モジュール群を大量に提供する
  • スタッフのプログラミング上の質問に答え、彼ら彼女らの成長・自立を助ける。
    • 自ら受注案件間の共通部分を見出して、部品を生み出していけるように。
  • 業務のテンプレート集、業務マニュアル wiki なども書きますが、これについては 私が全部を書くのではなく、スタッフが自分で書く勇気と習慣を身につけられるよう、 うまく導かねばなりません。

です。遠隔勤務だとどうなるか、なかなか難しそうです。

フリーランスの限界

私は独りで仕事を請けています。人を雇える状況ではないので、後継ぎもいません。 つまり、 モジュールのマニュアルを読んでくれる人も、 コードレビューもペア・プログラミングの相手も居ない状況を ほぼ 10年以上、引きずってしまいました。

そうして、残念ながら、私自身が顧客の事業の SPOF - Single Point Of Failure になっている…この点が、上記著者さんの会社と見比べて、今の自分が最も見劣りする部分です。

幸い、顧客企業とは散々話し合って、この点の問題意識は共有できているので、 今後は八王子PMなどの勉強会・交流会に少しでも顔を出して、 一緒に仕事をして下さる方を増やしていこう…そういう感じです。

まとめは、ありません！

吹き荒れる OOP 批判の嵐の中で独り言〜

(自分への返信にしたから見辛いっすね...)

コード出せよと言われそうなので、一つ貼っときます＞

hktools/sqlite-explain.tcl at master · hkoba/hktools · GitHub

Hachioji.pm #41 に参加してきました

昨日は Hachioji.pm (八王子で開催される、Perl好きを中心としたプログラマーの交流会) に行ってきました。

今回も皆さんの LT、どれも面白くためになりました。 特に xtetsuji さん の パスの左側セッション の話は、やっぱ皆それ考えるよね〜と思ったり。

あと、PHP の Session 事情を uzulla さんが詳しく解説してくれたのも 非常に参考になりました。

自分の LT

LT のざっくりしたお題が Session だったので、私からは YATT::Lite から session を使う例を雑に紹介してきました＞

(git push し忘れとかリンク切れを修正してあります)

おまけ

今回のTシャツは妖精さんでした

一週間前にも間違えて八王子に向かいそうになったのは良い思い出です。

連番ファイル生成、Zsh ならこう書くなぁと...

この blog url が RT されてきたので＞

シェルスクリプトで連続処理 - 作業日記

自分だったら、Zsh でこうするなぁと。

touch hoge{001..100}.txt

マニュアルはこちら＞ Zsh - Brace Expansion

hachiojipm #37 に行ってきました

昨日は hachiojipm に行ってきました。 pm なんだけど ruby や php の話が聞けて (かつ perl 文化圏の人間に分かるように話してもらえて) 最近非常に勉強させてもらってる集まりです。

LT のお題は editor だったので tcltk 関連とか頑張って出そうかとも 思ったのですが、いかんせん、手持ちのツール群はどっぷり業務特化してしまってて断念。

代わりに小ネタとして、先日 @stealthinu 氏との対話で取り上げた "dryrun" ( make -n のように、「実際には実行せずに、何が起こるかだけを画面に出して終わる」) オプションの、私がよく使う実装イディオムについて話してきました。

My Zsh idiom. How to write dryrun behavior in Zsh.

関数 "DO" が肝です。これは引数として渡されたコマンドを画面に出し、 オプション -n が指定されていればそこで終了、 通常は引数列全体をコマンドとして実行、というものです。

あとは「何が起こるか」に相当するコマンドの頭に "DO " と書き加えるだけです。

残念ながらこの方法はパイプラインや file のようなリダイレクトがあるコマンド には適用できません(その場合は、その部分だけ関数にまとめて、関数に対して DO で prefix するのが良いでしょう)。

dryrun は真面目に作ろうとすると変更箇所が増えて大変ですが、 この方法なら、プログラミングの手間がほとんど増えないので、 投下労力対効果が良くて非常に気に入っています。

DO の最後の実行のところを "$argv[@]" にしたほうが完璧ですが、 ここでは読みやすさ優先、ということで。

謹賀新年/2014目標

あけましておめでとうございます。

昨年仲良くしてくださった皆様、ありがとうございました。

また今年もよろしくお願いします。

 

遅まきながら、今年からこの blog での情報発信・意見発信にも取り組んで参ります。初めましての方も、以後よろしくお願いします。

昨年の反省点

  1. プログラミング言語研究のために作ったはずの休日を、体力回復だけで終えてしまうことが更に増えたこと
  2. 部屋の書籍減らしが、思ったほど進まなかったこと

昨年、良かった点

  1. YATT::Lite を CPAN にリリースできたこと
  2. hachioji.pm はじめ Perl コミュニティーに定期的に参加し始められたこと
  3. 未来塾の中級コースで、自分の英語発音の改善の糸口を得られたこと
  4. 長年の顧客に、遂にプログラマー不足への組織的な行動を始めてもらえたこと

今年の目標

  1. 体力維持・向上、健康管理にもう少し労力を割く
  2. 引き続き、YATT::Lite の使用例やマニュアルを拡充していく
  3. OCaml を自分の武器になるレベルでマスターする。
  4. 嫁(彼女)探しを諦めない...諦めないよっっっっ(><)