AIないともう無理
ちょっと前に投稿した、って記憶していたけど、それが10年前で我ながら驚いた。
最近の仕事はAIないと、もう無理な感じになっている。
そもそもコーディングの難しさって、APIのリファレンス読むのしんどい、ってのもちょっとあって、
外部仕様やらAPIやら100読み込むより、1出された正解を判定するほうが楽なのが強い。
エリート育成とか
エリート育成
いわゆる育成（教育、スポーツも含め）には２つの側面があるが、
- 上位層を伸ばし、エリートを輩出する
- ボトムアップを促し、全体の質を上げる
スポーツについては「上位層を伸ばす」方針がしばしばとられ、これは何となく納得できる。
そもそもスポーツで生計を立てようとする場合、エリートの資質がないと困難だからだ。
ただ、教育についてはどうなのか。
そもそもエリートは必要とされているのか。
未踏事業
「未踏事業」は、ITを駆使してイノベーションを創出することのできる独創的なアイディアと技術を有するとともに、これらを活用する優れた能力を持つ、突出した若い人材を発掘・育成することを目的としています。
未踏事業は「エリートこそがイノベーションを起こす。エリート育成はそれを邁進させる」という発想に基づいている。
ところでどれほどの未踏出身者が大きなイノベーションを起こしているだろうか。
否、大きな成功を収めた起業がどれほどあるか。
日本国内の有名IT企業で未踏から生まれたものは？
というか、国がエリート育成を通じて、IT産業を伸ばす、という発想自体が滑稽なのかも。
IT産業を他の産業に置換すれば、そのおかしさに気付くだろう。
ところでイノベーションはどのように起こるのか
過去に読んだ本だが、
自動車産業の昭和史からイノベーションを紐解く本。
イノベーションなんて単語は一言も出てきませんが。
創発（イノベーション）に対する経営の計画性の効果を半分は肯定し、半分は否定している。
革新的な製品が生まれた時、現場では何が起こっていたか？を語る本。
モチベーションコントロールの重要性が記憶に残る。
この２冊を読んだ結果、イノベーションを起こすには、運を除外すれば「気合を持て！」という極めて雑な感想。
結果としての天才
オチとしては、結果天才だった、という話しかない気がする。
産業のエポックメーカーとなるようなエリート・・・天才を計画的に作れるというのはそうなかなかない。
参入障壁とか
だらだら書く。
独立起業は正しいか
SIer業界がややすればブラックな状況になりがちなのは、資本力の弱い中小零細が非常に多い為と個人的には考えている。
通常産業は成熟するにつれ大資本に集約される行くものだ。
ただし、幾つかの産業はそれに当てはまらない。
- 身一つで起業できる。大きな資本を必要としないもの。
- 資格や条件などが不要。参入障壁が極めて低いもの。
- 属人性が高く、規模の経済が効かないもの。
- レモン市場。企業の評価やブランドが一般化されにくいもの。
こういった産業は個人でやった方が儲かるんじゃないの？という期待を暫し抱かせる為、多くの人間を独立起業へと駆り立てさせる。
結果、資本は集約しない。低資本の企業が乱立することになる。
かつての弁護士や士業のように供給量がコントロールされていれば、供給と需要のバランスが保たれ価格も一定額を維持できるのだが、そうでない場合、単なる安売り競争となり、それは労働環境悪化の遠因となる。
参入障壁
供給と需要を適切な関係に保つ為、何らかの参入障壁を設けるということが考えられるが、歴史を振り返ってみる必要がある。
特定産業振興法
特定産業振興臨時措置法案（とくていさんぎょうしんこうりんじそちほうあん）は、1963年から1964年にかけて日本の内閣が国会に3回にわたって提出した法律案である。いずれも審査未了のまま廃案となった。通称は特振法案。
散々議論になった末に廃案になったらしいが、貿易自由化を前に、自動車産業や鉄鋼産業を統制し（実質的な新規参入制限）、海外企業に対抗しうる産業にしようと一部の官僚は考えていたらしい。
これに猛反発したのが当時自動車産業未参入だったホンダである。
「どうにも納得できないということで、僕は暴れたわけで。特振法とは何事だ。おれにはやる（自動車をつくる）権利がある。既存のメーカーだけが自動車をつくって、われわれがやってはいけないという法律をつくるとは何事だ。自由である。大きな物を、永久に大きいとだれが断言できる。歴史を見なさい。新興勢力が伸びるに決まっている。そんなに合同（合併）させたかったら、通産省が株主になって、株主総会でものを言え！、と怒ったのです。うちは株式会社であり、政府の命令で、おれは動かない」
さて、この法案が廃案になり、その後、日本の自動車業界はどうなったか？
ここであえて述べるものでもないが、世界の自動車企業TOP10に複数の日系企業がランクインしている。
タクシー業界
参入規制について考えるなら、近年だとタクシー業界が参考になるだろう。
小泉改革時、規制緩和されたが、結果競争が劇化、業界団体からも「労働環境の悪化、サービスの低下につながる」との反論があり、規制強化に揺り戻されたという経緯がある。
ただし、近年ウーバーなどライドシェアサービス（一般ドライバーによる送迎マッチング）の解禁の流れがあり、再び規制緩和に傾くと思われる。
更に言えば、今後１０年以内には自動運転の実現すると見られており、タクシー業界がその影響を諸に受けるのは間違いない。
参入規制の功罪
参入規制は確かにその業界の人間を守るには有効だが、業界全体の成長にプラスの影響を与えているか？となると相当疑わしい。
MVCが嫌いな理由とか
MVCが嫌いだ。
積極的に取り入れる気にはなかなかなれない。
関心の分離、ファイル構造の複雑化
MVCはその特性上、関心の分離が重要視され、その結果、ファイル構造が複雑化することが多い。
正直、分かり難い。
慣れれば大丈夫・・・、とは結局ならなかったし、そこを乗り越えて採用するメリットを見出すこともできなかった。
もう一つの理由
もう一つの理由として、デザイナーにとって最も重要な見た目の定義(VIEW)が隠されているから。
改修のレベル
システム運用業務だと改修業務が発生する。これは致し方ないことだ。
- 見た目の改修
- ロジックを含めた改修
- データベースを含めた改修
- サーバやDNSの設定変更まで必要となる改修
実際には、軽微な改修である1、2のパターンが多い。
で、１についてはデザイナー自身に任せたい。
VIEWについて
通常、htmlファイルはURLに対応するフォルダに配置される。
システム化を行った結果、htmlは他のファイル形式に変更されるのだが、多くのMVCフレームワークは別フォルダに配置を移すことを要求する。
この時、関心の分離という名目で、デザイナーからVIEWが隠される。
彼らはエンジニアの手を借りなければ、文言一つ修正できなくなる。
継続的テストなどロジックの運用改修に程よく対応しているMVCフレームワークは多いが、デザイナー自身がHTMLを修正できるレベルでVIEWを修正できることを重視しているものはあまりないだろう。
せめて、システム化前後でVIEWの場所が変わらなければ。
世の流れ
個人的に魅力を殆ど感じてないのに反し、開発案件の委託をお願いすると「MVCフレームワークを採用させてもらいます」という開発会社が割と多い。
世の流れなのだろう。
初期開発は外部にお願いしても、その後の運用自体は社内で完結させることが通例である為、覚えざるを得ないのか、とは思っている。
運用時のメリットは全く感じないが。
既存アプリの改修として
委託先の開発会社の個性に引き摺られない為に（その後の運用をスムーズに行う為に）可能な施策として、既にあるアプリケーションを引き渡し、これを直して使ってくださいというのがある。
開発会社本来の力が発揮できなくなるのは、致し方ないといったところか。
労働組合とか
ぼくのかんがえたさいきょうの職場
技術手当、社内ランチ、誕生日休暇、書籍購入、アーロンチェア、ビリヤード・・・、
まぁなんでも良い。
問題は「その報酬や福利厚生はどうやって決めたのか？」だ。
例えば、社員会だったり、総務部が意見を吸い上げる仕組みがあるか等、「彼らの意見を吸い上げらるシステム」があればまだ良いのかもしれない。
問題は経営者の思いで決められる時だ。
「彼らの為に自分は色々考えている」と、その思いは果たして届いているか。
たまたま側にいる従業員の声を全てだと思ってないか。
「ぼくのかんがえたさいきょうの職場」になってないか。
エンジニアは特殊な労働者なのか？
「エンジニアとは○○という生き物」と嘯く人が少なくないことに驚く。
個人的には○○とくくれるような性質なんてあるんかいな？とは思う。
経営者も色々だし、社員も色々、当然、エンジニアも色々だ。
だから、
「エンジニアは○○という生き物だから、××を与えるのが良い」
は時として大きく間違える。
向き不向きはあるのだが、これは他の職種にも言えることである。
彼らを他とは異なる「特殊な労働者」と考えるのはおかしい気がする。
「欲しい」と叫ぶ
経営者、社員がお互いに「何かをしてくれるだろう」と期待するのは筋違いなのかもしれない。
突き詰めれば、お互いに「法的に定められたこと」「雇用契約で定められたこと」以外を行う義理はないのだろう。
「自分たちの願いを察して実現しろ」というのは些か乱暴な話だ。
「欲しいものがある人が『欲しい』と叫ぶこと」が正しいと思う。
経営者が「こうして欲しい」という願いは「業務命令」と形で雇用契約が保障している一方で、社員が「欲しいものを欲しいと叫ぶ（場合によってはサボタージュも辞さない）」願いも憲法で労働三権として保障されている。
そして、労働三権を具体化したものが労働組合法になる。
労働組合について
なぜ労働組合に入らないのか
労働組合の組織率は年々下がっており、現在20%を切っている。
組合員数は1000万を下回る。
加入率が下がる原因は幾つか考えられるのだが、
- 労組活動の時間や組合費を払うコストがメリットに見合わない
- 労働組合の本質は「経営者と社員との対話による解決」の筈なのだが、幾つかの過剰な労働争議が組織を弱体化させた
- 社員とは関係性の薄い政治性が強調されているイメージがある
- ユニオンショップからオープンショップへの移行、組合加入が強制化されない
労働組合が既にある企業・・・、歴史の長い企業が多いと思うのだが、そういったところは既に十分な雇用環境を作り出せているので、労働組合が必要とされる状況は少ないのだろう。
労働組合の作り方
労働組合をつくろう 1：組合結成まで｜安心して働きたい - 労働組合のつくり方 -
- 基本的には自由設立主義の為、届け出や許可といったものは必要としない。
そもそも団体交渉権は憲法の権利であり、使用者がそれを断ることはできない。 - 団体交渉拒否の場合、労働委員会へ救済命令の申し立てを行うことになるが、その場合に「労働組合法に準じた組織」という資格審査をクリアする必要が出てくる。
- 法制労働組合（「労働組合法で定義された組織」）は「労働組合規約」「活動方新」「予算」「役員」など一定のものを揃える必要がある。
- 「経営者や役員」「人事権のある者」は法制労働組合に参加できない。
逆に「部長」という肩書きであっても人事権がなければ参加は可能。 - 親睦会など使用者から経費などの援助を受けている組織は法制労働組合とは認められない。
IT系労働組合
数は少ないがあるところにはあるところにはある。
ヤフー労働組合 | ヤフー労働組合公式ホームページへようこそ！
ユニットテスト書き方希望とか
昔こんなの書いてたのか
かれこれ７年ぐらい前。
<?php
class Hoge { function say($a) { return true; } }#test begin
$h = new Hoge();
assert($h->say(1),true);
#test end
?>
<?php
if (in_array('--test', $GLOBALS['argv'])): // テストコード
endif; // test end
?>
テストコードは対象クラスと同じファイルに記述する
クラスに対するテストコードは同じファイルに記述して、分散させないのが本当は嬉しい。
そもそも、専用のテストクラスとして作成するのは、Javaの名残りじゃないの？とか思っている。
っていうか、管理するファイルは少ない方がいい、というのは昔から思ってたんだな。
RSpec
同一ファイル内にテストクラスを記述しても問題ないのかな。
これはこれで良さそうだ。
「ググれ」とか
- 最近、質問されたら、「よし！代わりに頑張ってググりますよ！」という言葉を覚えた（皮肉）
- 調べ物で辿り着いたサイトで、「ググれ」としか回答がない残念感
- そもそも「ググれ」という回答の書き込み自体、ノイズ以外の何物でもない
- 調べ物で辿り着いたサイトで、「ここを見ろ」というリンク先しかなく、そのリンク先がなくなっている残念感２
- 調べ物で辿り着いたサイトで、「質問としては初歩過ぎます。○○から勉強をやり直すべきです」という説教しかない残念感３
