エリート育成とか

エリート育成

いわゆる育成(教育、スポーツも含め)には2つの側面があるが、

  • 上位層を伸ばし、エリートを輩出する
  • ボトムアップを促し、全体の質を上げる

スポーツについては「上位層を伸ばす」方針がしばしばとられ、これは何となく納得できる。
そもそもスポーツで生計を立てようとする場合、エリートの資質がないと困難だからだ。

ただ、教育についてはどうなのか。
そもそもエリートは必要とされているのか。

未踏事業

IPAが行っている事業に未踏事業というものがある。

www.ipa.go.jp

「未踏事業」は、ITを駆使してイノベーションを創出することのできる独創的なアイディアと技術を有するとともに、これらを活用する優れた能力を持つ、突出した若い人材を発掘・育成することを目的としています。

未踏事業は「エリートこそがイノベーションを起こす。エリート育成はそれを邁進させる」という発想に基づいている。
ところでどれほどの未踏出身者が大きなイノベーションを起こしているだろうか。
否、大きな成功を収めた起業がどれほどあるか。
日本国内の有名IT企業で未踏から生まれたものは?

というか、国がエリート育成を通じて、IT産業を伸ばす、という発想自体が滑稽なのかも。
IT産業を他の産業に置換すれば、そのおかしさに気付くだろう。

ところでイノベーションはどのように起こるのか 

過去に読んだ本だが、

能力構築競争-日本の自動車産業はなぜ強いのか 中公新書

能力構築競争-日本の自動車産業はなぜ強いのか 中公新書

 

 自動車産業の昭和史からイノベーションを紐解く本。
イノベーションなんて単語は一言も出てきませんが。
創発イノベーション)に対する経営の計画性の効果を半分は肯定し、半分は否定している。

MOTの達人―現場から技術経営を語る

MOTの達人―現場から技術経営を語る

 

 革新的な製品が生まれた時、現場では何が起こっていたか?を語る本。
モチベーションコントロールの重要性が記憶に残る。

この2冊を読んだ結果、イノベーションを起こすには、運を除外すれば「気合を持て!」という極めて雑な感想。

結果としての天才

オチとしては、結果天才だった、という話しかない気がする。
産業のエポックメーカーとなるようなエリート・・・天才を計画的に作れるというのはそうなかなかない。

 

参入障壁とか

だらだら書く。

独立起業は正しいか

SIer業界がややすればブラックな状況になりがちなのは、資本力の弱い中小零細が非常に多い為と個人的には考えている。

通常産業は成熟するにつれ大資本に集約される行くものだ。
ただし、幾つかの産業はそれに当てはまらない。

  • 身一つで起業できる。大きな資本を必要としないもの。
  • 資格や条件などが不要。参入障壁が極めて低いもの。
  • 属人性が高く、規模の経済が効かないもの。
  • レモン市場。企業の評価やブランドが一般化されにくいもの。

こういった産業は個人でやった方が儲かるんじゃないの?という期待を暫し抱かせる為、多くの人間を独立起業へと駆り立てさせる。
結果、資本は集約しない。低資本の企業が乱立することになる。

かつての弁護士や士業のように供給量がコントロールされていれば、供給と需要のバランスが保たれ価格も一定額を維持できるのだが、そうでない場合、単なる安売り競争となり、それは労働環境悪化の遠因となる。

参入障壁

供給と需要を適切な関係に保つ為、何らかの参入障壁を設けるということが考えられるが、歴史を振り返ってみる必要がある。

特定産業振興法

特定産業振興臨時措置法案 - Wikipedia

特定産業振興臨時措置法案(とくていさんぎょうしんこうりんじそちほうあん)は、1963年から1964年にかけて日本の内閣が国会に3回にわたって提出した法律案である。いずれも審査未了のまま廃案となった。通称は特振法案。 

 散々議論になった末に廃案になったらしいが、貿易自由化を前に、自動車産業や鉄鋼産業を統制し(実質的な新規参入制限)、海外企業に対抗しうる産業にしようと一部の官僚は考えていたらしい。

これに猛反発したのが当時自動車産業未参入だったホンダである。

www.honda.co.jp

「どうにも納得できないということで、僕は暴れたわけで。特振法とは何事だ。おれにはやる(自動車をつくる)権利がある。既存のメーカーだけが自動車をつくって、われわれがやってはいけないという法律をつくるとは何事だ。自由である。大きな物を、永久に大きいとだれが断言できる。歴史を見なさい。新興勢力が伸びるに決まっている。そんなに合同(合併)させたかったら、通産省が株主になって、株主総会でものを言え!、と怒ったのです。うちは株式会社であり、政府の命令で、おれは動かない」

 さて、この法案が廃案になり、その後、日本の自動車業界はどうなったか?
ここであえて述べるものでもないが、世界の自動車企業TOP10に複数日系企業がランクインしている。

タクシー業界

参入規制について考えるなら、近年だとタクシー業界が参考になるだろう。
小泉改革時、規制緩和されたが、結果競争が劇化、業界団体からも「労働環境の悪化、サービスの低下につながる」との反論があり、規制強化に揺り戻されたという経緯がある。
ただし、近年ウーバーなどライドシェアサービス(一般ドライバーによる送迎マッチング)の解禁の流れがあり、再び規制緩和に傾くと思われる。
更に言えば、今後10年以内には自動運転の実現すると見られており、タクシー業界がその影響を諸に受けるのは間違いない。

参入規制の功罪

参入規制は確かにその業界の人間を守るには有効だが、業界全体の成長にプラスの影響を与えているか?となると相当疑わしい。 

MVCが嫌いな理由とか

MVCが嫌いだ。
積極的に取り入れる気にはなかなかなれない。

関心の分離、ファイル構造の複雑化

MVCはその特性上、関心の分離が重要視され、その結果、ファイル構造が複雑化することが多い。
正直、分かり難い。
慣れれば大丈夫・・・、とは結局ならなかったし、そこを乗り越えて採用するメリットを見出すこともできなかった。

もう一つの理由

もう一つの理由として、デザイナーにとって最も重要な見た目の定義(VIEW)が隠されているから。

改修のレベル

システム運用業務だと改修業務が発生する。これは致し方ないことだ。

  1. 見た目の改修
  2. ロジックを含めた改修
  3. データベースを含めた改修
  4. サーバやDNSの設定変更まで必要となる改修

実際には、軽微な改修である1、2のパターンが多い。
で、1についてはデザイナー自身に任せたい。

VIEWについて

通常、htmlファイルはURLに対応するフォルダに配置される。
システム化を行った結果、htmlは他のファイル形式に変更されるのだが、多くのMVCフレームワークは別フォルダに配置を移すことを要求する。
この時、関心の分離という名目で、デザイナーからVIEWが隠される。
彼らはエンジニアの手を借りなければ、文言一つ修正できなくなる。

継続的テストなどロジックの運用改修に程よく対応しているMVCフレームワークは多いが、デザイナー自身がHTMLを修正できるレベルでVIEWを修正できることを重視しているものはあまりないだろう。

せめて、システム化前後でVIEWの場所が変わらなければ。

世の流れ

個人的に魅力を殆ど感じてないのに反し、開発案件の委託をお願いすると「MVCフレームワークを採用させてもらいます」という開発会社が割と多い。
世の流れなのだろう。

初期開発は外部にお願いしても、その後の運用自体は社内で完結させることが通例である為、覚えざるを得ないのか、とは思っている。
運用時のメリットは全く感じないが。

既存アプリの改修として

委託先の開発会社の個性に引き摺られない為に(その後の運用をスムーズに行う為に)可能な施策として、既にあるアプリケーションを引き渡し、これを直して使ってくださいというのがある。
開発会社本来の力が発揮できなくなるのは、致し方ないといったところか。

労働組合とか

ぼくのかんがえたさいきょうの職場

技術手当、社内ランチ、誕生日休暇、書籍購入、アーロンチェア、ビリヤード・・・、
まぁなんでも良い。
問題は「その報酬や福利厚生はどうやって決めたのか?」だ。

例えば、社員会だったり、総務部が意見を吸い上げる仕組みがあるか等、「彼らの意見を吸い上げらるシステム」があればまだ良いのかもしれない。
問題は経営者の思いで決められる時だ。
「彼らの為に自分は色々考えている」と、その思いは果たして届いているか。
たまたま側にいる従業員の声を全てだと思ってないか。
「ぼくのかんがえたさいきょうの職場」になってないか。

エンジニアは特殊な労働者なのか?

「エンジニアとは○○という生き物」と嘯く人が少なくないことに驚く。
個人的には○○とくくれるような性質なんてあるんかいな?とは思う。
経営者も色々だし、社員も色々、当然、エンジニアも色々だ。
だから、
「エンジニアは○○という生き物だから、××を与えるのが良い」
は時として大きく間違える。

向き不向きはあるのだが、これは他の職種にも言えることである。
彼らを他とは異なる「特殊な労働者」と考えるのはおかしい気がする。

「欲しい」と叫ぶ

経営者、社員がお互いに「何かをしてくれるだろう」と期待するのは筋違いなのかもしれない。
突き詰めれば、お互いに「法的に定められたこと」「雇用契約で定められたこと」以外を行う義理はないのだろう。
「自分たちの願いを察して実現しろ」というのは些か乱暴な話だ。
「欲しいものがある人が『欲しい』と叫ぶこと」が正しいと思う。

経営者が「こうして欲しい」という願いは「業務命令」と形で雇用契約が保障している一方で、社員が「欲しいものを欲しいと叫ぶ(場合によってはサボタージュも辞さない)」願いも憲法労働三権として保障されている。
そして、労働三権を具体化したものが労働組合法になる。

労働組合について

なぜ労働組合に入らないのか

労働組合の組織率は年々下がっており、現在20%を切っている。
組合員数は1000万を下回る。
加入率が下がる原因は幾つか考えられるのだが、 

  • 労組活動の時間や組合費を払うコストがメリットに見合わない
  • 労働組合の本質は「経営者と社員との対話による解決」の筈なのだが、幾つかの過剰な労働争議が組織を弱体化させた
  • 社員とは関係性の薄い政治性が強調されているイメージがある
  • ユニオンショップからオープンショップへの移行、組合加入が強制化されない

労働組合が既にある企業・・・、歴史の長い企業が多いと思うのだが、そういったところは既に十分な雇用環境を作り出せているので、労働組合が必要とされる状況は少ないのだろう。

労働組合の作り方

労働組合の作り方

労働組合をつくろう 1:組合結成まで|安心して働きたい - 労働組合のつくり方 -

www.kumiaitaisaku.com

  • 基本的には自由設立主義の為、届け出や許可といったものは必要としない。
    そもそも団体交渉権憲法の権利であり、使用者がそれを断ることはできない。
  • 団体交渉拒否の場合、労働委員会へ救済命令の申し立てを行うことになるが、その場合に「労働組合法に準じた組織」という資格審査をクリアする必要が出てくる。
  • 法制労働組合労働組合法で定義された組織」)は「労働組合規約」「活動方新」「予算」「役員」など一定のものを揃える必要がある。
  • 「経営者や役員」「人事権のある者」は法制労働組合に参加できない。
    逆に「部長」という肩書きであっても人事権がなければ参加は可能。
  • 親睦会など使用者から経費などの援助を受けている組織は法制労働組合とは認められない。

IT系労働組合

数は少ないがあるところにはあるところにはある。

ヤフー労働組合 | ヤフー労働組合公式ホームページへようこそ!

www.sbwu.jp

 

ユニットテスト書き方希望とか

昔こんなの書いてたのか

かれこれ7年ぐらい前。

dev0000-1.hatenablog.com

dev0000-1.hatenablog.com

<?php
class Hoge { function say($a) { return true; } }

#test begin

$h = new Hoge();

assert($h->say(1),true);

#test end

?>

ってな感じで #testブロックにテスト処理を記述できて、"php --test hoge.php" で実行。

 

<?php

if (in_array('--test', $GLOBALS['argv'])): // テストコード

endif; // test end

?>

テストコードは対象クラスと同じファイルに記述する

クラスに対するテストコードは同じファイルに記述して、分散させないのが本当は嬉しい。
そもそも、専用のテストクラスとして作成するのは、Javaの名残りじゃないの?とか思っている。

っていうか、管理するファイルは少ない方がいい、というのは昔から思ってたんだな。

RSpec

qiita.com

同一ファイル内にテストクラスを記述しても問題ないのかな。
これはこれで良さそうだ。

 

「ググれ」とか

teratail.com

teratail.com

  • 最近、質問されたら、「よし!代わりに頑張ってググりますよ!」という言葉を覚えた(皮肉)
  • 調べ物で辿り着いたサイトで、「ググれ」としか回答がない残念感
  • そもそも「ググれ」という回答の書き込み自体、ノイズ以外の何物でもない
  • 調べ物で辿り着いたサイトで、「ここを見ろ」というリンク先しかなく、そのリンク先がなくなっている残念感2
  • 調べ物で辿り着いたサイトで、「質問としては初歩過ぎます。○○から勉強をやり直すべきです」という説教しかない残念感3

 

 

二重サブミット対策とか

qiita.com

バズっていたので個人的感想。
コメントつけようかと思っていたが、第三者的には有効な情報ではない気もしたので、ここで。

記事の内容

二重サブミットが発生する状況

  1. サブミットボタンをダブルクリックする
  2. 戻るボタンで戻って、再度保存ボタンを押す
  3. 完了ページでブラウザリロードする
  4. CSRF攻撃による不正な更新リクエスト

対策

  1. トークンによるチェック
  2. JavaScriptでのサブミットボタンのDisable化
  3. PRGパターン

でもって、

ここから個人的な感想。

そもそも二重サブミット対策をするか?

単純な問い合わせフォームやアンケートフォーム等については、PRGパターンのみ採用し(完了画面リロードによる登録防止)、他はしないかもしれない。
同一人物の複数登録チェックが必要な場合、どのみちそれはデータクリーニング時に必須な工程となるから。

そう考えると、「トークンによるチェック」等は認証前提の会員系サイトへの対応で限定される気がする。

「トークンによるチェック」

CSRF対策としては、最近この手法を使うことが多い(自分の記事)。

qiita.com

ただ、この場合、1ページ1トークンの為、「戻るボタン」の処理が行えない。
(CSRFチェックのエラーとなる)

「戻るボタン」を有効にするか?

入力ー確認ー完了でトークンを同じにすることで、戻るボタンで画面を戻ってリクエストを再送信しても、完了画面以外はエラーにならず(!)、ユーザビリティが確保されます。
例えば、確認画面に「入力画面へ戻る」ボタンをつけなくても、ブラウザの戻るボタンで遷移することができ、トークンエラーにもなりません!

 ユーザビリティが落ちるのは承知だが、「確認ページから入力ページへの遷移の為の戻るボタン動作は保証しません」と言い切ることが多い。

  • 動作ブラウザや状況によって、キャッシュの扱い状況がバラバラ過ぎて、サーバサイドで管理するのが難しい。
  • 「入力エラー発生時ページ」も合わせて考える必要がある。
  • JavaScriptによる動的な画面更新や入力値補完が行われていた場合、それが全て残っているとは限らない。

もし対応する場合、最近であれば、pushState機構を用いて遷移を制御するのが正道なのかな、と思う。

「入力」=>「確認」=>「完了」について

そもそも「確認ページが必須」というのが割と日本的文化の為、多くのフレームワーク自体はその機能を持っていないのでは?とは思っている。

(項目数の関係で)入力画面が複数にわたる場合、文化に関わらず、確認画面は必要になると思うのだが、それはそれで一般化しにくい仕様なので、標準機能としては備えてないのだろう。

JavaScriptでのサブミットボタンのDisable化」

古いWEBアプリケーションの場合、Disable化対応が原因で誤動作を起こしているものがたまにあるので、個人的にイメージがあまり良くないが、

ただ、回線が遅く遷移前にブラウザの停止ボタンを押した場合は、ボタンを二度と押せなくなってしまうため、↑の方式に一定時間でボタンをenabledにするようにした方が親切です。

ダブルクリック対策の参考として良いかも。

「PRGパターン」

リダイレクトさせる方法は知っていたが、パターン名がついているのは知らなかった。