さて、今回は「システム開発の現場寄り」で、且つ「どの現場でもよくある話」です。
いや、システム開発以外でも、応用は出来るんですけど、今回はシステム開発に限定します。
でコレ、最初は、あっさりスルーしたんですけど、
考えてみるとこれも「結構根の深い問題」だなぁと思いましたので。

まず、先週でしたか、以下の記事を読みました。

面接官　「リーダーシップ」をとった経験はありますか？　学生　「はい、サークルのリーダーをやりました」というやりとりに見る、日本人のリーダーシップ観
http://blog.tinect.jp/?p=12219

んで、読んだ直後に、以下の記事を思い出しました。

人は天沼矛を持てない
http://d.hatena.ne.jp/gallu/20090111/p2

あと、ついでに、こんな記事（話の根っ子としては、同じ話だと思います）も。

フルスタックデザイナー…？クックパッド・HolidayデザイナーがiOS開発まで手を出しちゃう理由
http://careerhack.en-japan.com/report/detail/481

で、これポイントとしては、
「リーダーシップを取る側は、
リーダーシップを取るのは良いが、取ることでスケープゴート扱いになるようなら、要注意」
「リーダーシップを取られる側は、
リーダーシップを取っている人が、スケープゴート扱いにならないように、要注意」
って事だと思うんですね。
クックパッドの事例は、一見上手くいってる様に見えますけど、
上記の後者になってると良いなぁと思いますから。

ただ、残念ながら、今まで色々な職場に行ってきましたけど、
後者の様に回っているのを見たことがなくてですね（苦笑）
例えば、以下の様なケースにおいて、リーダーシップが問われたりします。

・会議において、誰が議事録を取るのか

「誰が取っても良い」わけですよ、会議参加者なら。
といっても、大体取るのは、「新人か外注」だったりするんですけど（苦笑）
この辺なんかは、「持ち回り制」にするだけでも、結構違うとは思うんですけどね。

・誰が、会議の段取りをするのか

ちょっと分かりにくいかもしれないですけど、
例えば、「もう会議始まるけど、Aさんどこにいる？ちょっと探してくる」とか、
「アジェンダが決まっていない会議（それもどうかと思うが）の、アジェンダを提案する」とか、
これまた、「誰でも出来る」わけですね。
ここは、持ち回り制は難しいでしょうから、その時の状況に応じて対応するのが良いとは思うんですけど、
でも、大体こちらも「新人か外注」に一任されるわけですね。

・誰が、深夜対応をするのか

そもそも、頻繁に深夜対応すること自体が以下略という話なんですけど、それでも起きた時に。
勿論、「一人しかいないなら一人」としまして。
基本的には、持ち回り制で良いんじゃないだろうか（ココ、メンバーや状況にもよりますけどね）と思うんですけど、
以下の様なケースもあったりするので、要注意な所です。

「持ち回り制を提案され、受諾する」
↓
「持ち回り制になる」
↓
「しばらくすると、持ち回りを提案した人の割合が減っていく」
↓
「持ち回りを提案した人が、全く持ち回りに参加しなくなる」

まぁまぁ、だからといって、「持ち回りしなくなった人、ふざけてる」というのも、
少々短絡的だとは思いますけどね。これだけなら。

また、上記とは異なり、以下の様に「とある職種と、とある職種間」でも、似た様な話があります。

１．インフラエンジニアとサーバーエンジニア

Nginxとか、DBの設定周りで、結構「どっちがやる？」となる場合があったりしまして。
ミドルウェアのセットアップについては、インフラがやる事の方が多いとは思いますけど、
この辺は、結構「境界線が曖昧な所」ですね。

２．クライアントエンジニアとサーバーエンジニア

いわゆるスマホアプリにおいて、
以下にもあります通り、「とある処理を、クライアント側でやるか、サーバー側でやるか」というのも、
同じ話じゃないかと思います。

学習の目的とか基本的な準備とか
http://d.hatena.ne.jp/gallu/20141116/p1

ココだけは、どっちがやっても良いってわけじゃないのは、
上記リンク先にも書いてますけど、要注意な所だとは思いますけどね。

３．デザイナー（フロントエンドエンジニア）とバックエンドエンジニア（サーバーエンジニア）

jQueryとか、あとはSmartyとかのテンプレートエンジンにおいて、どっちが書くかという問題ですね。
・・・どっちが良いんでしょうねぇ。
現実では、フロント側が書いているケースの方が多い様に感じますけど、
フロント側がその辺知らない人（もしくはフロント担当がいない）だと、
バック側が書いているケースが多いと思うんですけどね。

４．プランナーとエンジニア

毎度、「プランナーじゃなくて、ゲームデザイナーでしょ？」って思うんですけど、
プランナーの方が通りが良い様にも感じるので、この記述で。
で、ココは、「CSVどっちが修正する？」というのがありますね。
そのCSVの「修正内容による」って所だと思いますけど。
例えば、仕様の追加などで、CSVの列の追加が必要になって、
プログラムから、その列の内容を読み取って何がしかするのであれば、
そこは、エンジニアが行って。
でも、ゲームバランスの調整などで、CSVの値を調整するのであれば、
そこは、プランナーが行ってとか。
あくまで、一例でしかないですし、もっと良い方法もありそうですけどね。

さて、ダラダラと書いてきましたけど、
何が問題なのか、どうすれば良いのか。

一番最初に貼ったリンク先にあります通り、

「中間に上がったフライ」を声をかけて自分からキャッチしに行くような人物が、日本企業で求められている人材だ。

というのは、はい、これは合っております。
で、人事も求めている以上、当然、そういった言動をした人は高評価の対象となるはずなんですけど、
現状においては、大半が「単なるスケープゴート」になってしまっているという（苦笑）
実際に見たことありますよ。
パっと思い出すだけでも、二人スケープゴート扱いにされ、
その職場から離れたケースは。
で、じゃあ高評価をすれば良いんでしょって事で、例えば「報奨金を支給する」とかするんですけど、
これも、また微妙でして。
従業員って、以下にもあります通り、意外と昇給は求めていないんですよね。
いや、「全く」求めていないかというと、さすがにそこまで極端ではないでしょうけど。

「お金のために働いている人」は実は少ない？ 社員が昇給よりも望んでいる4つのこと
http://www.lifehacker.jp/2015/03/150307_employees_want_more.html

端的に、「スケープゴート扱いにならない様に、周囲が支援する」しかないと思うんですね、コレ。
中間フライを取りにいったことで、「元々その人が担当している作業の進捗に悪影響が出た」り、
上記の頻度が多いと、「体調を崩した」りといった事が、微粒子レベルじゃないレベルで存在したりしますので。
また、上記の行動は、属人性とも関連があったりします（誰もやらない作業をやり続けるわけですから）ので、
スケープゴート扱いになって職場を去ってしまうと、大抵その後に問題も起きがちで、
結局、残った人は不幸になってしまいますし。

ということで、上記が対策じゃあないかと思うんですけど、
では、それが実現されそうにない場合にどうするか。
２番目に貼ったリンク内に書かれている

で、自分がもし担わざるを得ない場合。相応の覚悟と、覚悟にふさわしいだけのリソース(時間、報酬、権限その他)くらいはちゃんと請求しておきましょう

を行わないと、大変に危険だと思います。

「他の人は早く帰っているのに、どうして自分だけ遅いんだ」的な時。
単純に貴方が仕事出来ないだけの可能性も否定はし切れないですけど、、
ただ、中間フライを取りまくっているが故に、本来の自分の担当作業が終わらなくなっているのなら、
貴方はスケープゴート扱いにされている可能性が結構高いと思いますので、要注意かと思います。

すいません、年初 http://kitoku1.blog129.fc2.com/blog-entry-242.html にも書いたんですけど、
だいぶ遅くなってしまいました。

以下の様な感じでやっていきたいと思います。

１．当日は、kitokuが参加者が希望した場所に訪問する

ただ、首都圏以外（千葉の外れとかでも、頑張っていきますよw）はちょっと厳しいですけど。
首都圏以外だと、appear.in https://appear.in/ とかSkypeとかになりますかね。
あとココ、元々はコワーキングスペースが良いかなと考えていたんですけど、
「敷居は下げるだけ下げてしまおう」ということで、止めました。
なので、昨今話題の同性愛者（僕自身は、全く該当してませんけど）が集う場所とかでも、構いませんw
ただ、暴力団の事務所（面白い気がしないでもないが）なんかは、さすがに勘弁でw

２．費用は、出来るだけkitokuが負担する

もちろん、限度（一人２万円ぐらい？）はありますけど、
ちょっとお金も使わないと（仕事が出来んので）なぁと思ってましたので。
あと、見返りは他の人にやって下さい。

３．誰と雑談したかについては、一切ネットなどに公開しない

プライバシーも最近うるさいですから。
「何人と雑談したか」は書くと思いますけど、
会話内容については、個人が特定出来なさそうな情報だけ（ただ、ジャッジが難しいので、書く前には本人に確認はすると思います）は、ネット上に書くかもしれません。
ただ、参加者が自分の責任で、kitokuと雑談したとかをネット上などに書くのは構いません。

４．雑談としているが、別に会話しなくてもOKだし、遊びに行くでもOK

なので、極論、「何時間も、ただ向かい合って座っているだけ」でも構いません。
その間、僕は本でも読んでますので。
「話したいことは特にないが、ただ誰かが近くにいれば良い」というのはあるかと思いますので。
なので、犯罪行為を除いて、基本何でもアリです。
「一緒に、バンジージャンプをしましょう or 富士の樹海に行きましょう」？
う～ん、さすがにちょっと恐いですけど、前向きに検討はしますw

５．このイベントは不定期なので、次回がいつかも、そもそも開催するかどうかも不明

だって、こっちのお金が持たないかもしれませんしw
あと、仕事が忙しくなったり暇になったりなので、定期的には難しいですね。

６．基本的に１対１で対峙する

勿論、友達と二人ででも構いませんけど。
ポイントなのは、「関係の無い人は含めない」って所ですね。

７．参加申し込みは先着順

なので、早いもの勝ちです。
あと、稀に断るケースもありますが、多分９割方無いです。

８．開催の主旨

一応書いておきますと、
「個人にフォーカスをあてたイベントってあまり無いなぁ」という所と、
「お金が無ければ、したいことも出来ない」って所ですね。
前者は、勉強会でもまだまだ全体最適的だなぁと感じましたし、
後者は、昔１００万円以上借金してたので、その辺は実感してますし。
なので、「貧乏だけど心は豊か」がありえない理由 http://tm2501.hatenablog.com/entry/2015/03/18/221126 とか、
普通に分かりますしね。

あと、全体的に見ていて思うのが、詭弁とかの「異常系」に引っかかって、
無駄に被害を受けるという点。
これ、システムの開発でもそうですけど、正常系は結構簡単なんですよ。
でも、「異常系をどこまで想定できるか」ってのが難しい。
で、それに対する対処の仕方。
例えば、「嘘をつくのは良くない」は当然ですけど、
じゃあ、「嘘をつく相手に、誠心誠意対応するのは是か非か」とか。
ココら辺の対応って、一種の処世術だと思うんですけど、
そこら辺を話せると良いかなと。

あと、最近特に感じるのが、いわゆる「目利き力」。
要は、「誰が言っているのが、最も妥当なの？」ってのを見極める能力。
ココら辺は、時々言ってるサーフィンを実践することで、ある程度上達出来るんですけど、
ただ、サーフィン自体が、かなり高めの体力と精神力（HPとMPで、特にMP）を要求されるので、
もう少し、方法論に落とし込めると良いですよね、ってのはありますね。

個人のお悩み相談室とか、キャリアカウンセリングとかあるのは知ってますけど、
上記の様な、厳しい現実に対処する為の方法については、あまり充実していない印象（あくまで印象ですが）ですし、
あと、ネット上でのQAサイトとか、勉強会でも質問を受け付けたりってのはありますけど、
そもそも、「周囲に人がいると質問しづらい」ってのがあるのも知ってますので、
こんなクローズドな発想に到りましたw
以前に、ソーシャルラーニング勉強会 http://kitoku1.blog129.fc2.com/blog-entry-161.html というのもやってましたけど、
これとは全く逆ですね。公開度が高過ぎますから、こっちは。

と、真面目な話も書いてみましたけど、ぶっちゃけ「どうでも良いっちゃ、どうでも良い」ですw
別に、FEのプレイを見たいでも良いですよw

参加希望やお問い合わせは、
当日の24:00まで（ギリギリだと間に合わないかもしれませんけど）にコチラ http://www.kitoku-magic.net/inquiry.html から連絡下さい。
勿論、他の連絡手段（SNSなど）でもOKです。

これだと、僕に全くメリットが無い様に見えますけど、そんな事は全くありません。
むしろ、色々聞いてみたい所ですね。

正直、僕がやった所でという気がだいぶんしてますけど、
社会的に見て、こういうのがもうちょっと増えると良いなぁってのはありますね。

※マサカリ期待でお願いしますw

多分、凄く「中長期的な話」なので、
今すぐどうこうの話では無いんですけどね。
だって、「日本のITエンジニアの教育の話」ですから。
なので、「未来」の話だとは思います。
「未来予知」は、勿論「出来ない」んですけど、
じゃあ、「野生の勘はなぜ当たるのか」ってのもありますし、
以下の本にもちょっと書いてましたので、全くないってわけでもないんだろうなぁと。
勿論「外れる」と思いますし、そう期待したいですけどね。

知性を磨く― 「スーパージェネラリスト」の時代 (光文社新書)
http://www.amazon.co.jp/dp/4334038018

さて、今回のメインの元ネタは、以下の記事です。

まどか☆マギカに学ぶIT企業内定者の心理
http://togetter.com/li/790660

まどマギ自体は、一応以下に書いてはいますけど、今回の話とは全く関係がない（はず）なので、
無視して良いです。

魔法少女まどか☆マギカから学ぶ
http://d.hatena.ne.jp/kitoku_magic/20131229/1388303172

さて、上記から、引用スタートです。

昨日はIT企業に内定した子たちの合同懇親会というのに参加していて、
話を聞く機会があったのだけれど、
多くの大学生たちにとって「IT業界」というのはやっぱり「ブラックの代名詞」であって、
そこに入ったとなっては彼らにとっては「絶望」に他ならないそうだ。

色々情報仕入れてるんだろうなぁとは思いますね。知ってると限りだと、以下の本を読んでいる人もいたみたいです。

なれる!SE 2週間でわかる?SE入門 (電撃文庫)
http://www.amazon.co.jp/dp/4048686054

で、実は上記の本も積読ってたりしまして、少し読みましたけど、
「昔」とか、今だと「Sler？（最近、知らないですけどね）」なら、
「内容そんなに違和感ない」って感じですね（苦笑）
ただ、今のWebサーバエンジニア界隈（僕がこれなので）だと、
「上記の本の中で言われる程ブラックではないけど、問題がないわけではない（当たり前ちゃ当たり前だが）」という印象ですね。
「技術者のレベルも、結構高い（一流レベルはともかくとして）」ですし。
多分、僕は以下のイメージが強い（少し宣伝しときますw）んだと思いましたけど。

https://twitter.com/miraihack/status/572712147429412864

あ、金額が合っているか否かは「不明」ですけど、
「まぁ、そんなもんじゃない？（平均だとこのぐらいかな）」って思いますね。
あと、「社外の交流」って事ですと、
先月も二回行きましたけど、以下とかありましたね。
・・・イベントは、探し始めるとキリないですけど。

第25回Creators MeetUp
http://cmu.connpass.com/event/11870/

第87回 PHP勉強会＠東京
https://phpstudy.doorkeeper.jp/events/20806

なんというか、「負けてられねぇなぁ」とか思いましたけどね（苦笑）

次。

勿論、理系とか情報系とか元々IT業界を志望していた子にとっては
願ったりかなったりの職場である場合も多いけど、
文系卒、あるいは理系でもITとか関係ない職種を希望していて、運悪くその
志望業界に入れず、仕方なくIT業界を望んだ子たちにとっては
「絶望感」もひとしおらしい。

「文系・理系止めようよ」とか思いますね。
2010～2011年ぐらいだったと思いますけど、「数学ガールに詳しい情報系出身の新人」というのがいまして。
でも、「実務最悪で、死にそうになりました」ね（苦笑）
ただ、「数学ガール自体」は、まだ読んだことはないですけど、悪い本ではないと思います。
ただ、それを「実務」で使うのは・・・「だいぶんレベルが上がってから」だと思いますね。
数学かどうか知らないですけど、僕は最近「緯度・経度」のプログラミングは「少し」やりました。
でも、あとは「6～7年」のWebサーバエンジニア人生で・・・やったかなぁ（苦笑）
「一個人の経験」なので、あんまり参考にならないと思いますけど。

で、「ITエンジニア」であるのは確かなんですけど、
一方で「社会人」でもあると思うんですよね。
なので、エンジニアですから「ロジカルに物事を考える」とか、
あと、コミュニケーション能力だと、以下のイメージですね。

コミュニケーション能力は「ある程度」ないと困る
http://d.hatena.ne.jp/gallu/20131104/p1

あとは、書籍だと以下。

特別講義 コミュニケーション学
http://www.amazon.co.jp/dp/4408108308

あとは、これはかなり「レベルが上がってから」な気もしますけど、
以下の本は面白かったですね。
というか、以下はちょっと書きたいですけどね。

わかりあえないことから──コミュニケーション能力とは何か (講談社現代新書)
http://www.amazon.co.jp/dp/4062881772

「エンジニアリングの世界」は「深すぎる（もう、疲れますねホントw）」ので、
まずは、技術力も大切ですけど、上記も大切だと思いますね。

次。

興味無い子をIT系で頑張らせるにはお金か達成感しかないと思われるます…

お金は勿論の事（なので、残業代ゼロ法案は、生活残業とかもあるので、必ずしも否定ではないですけど、「運用」で失敗すると思います。今の「状況」見るとね）ですけど、
「達成感」、これだろうなぁって思います。
「JavaでStrutsで動物占いプログラム」とか、業界に入る前に作ってましたね。
「とにかく作った方が良い」ですよ、「動いた時が面白い」ので。
今だと、僕の技術力はあんまり参考にならないんですけど、
以下とGitHub（インフラ関連、整理しないとなぁ）でしょうね。

自作版Hit&Blow
http://www.kitoku-magic.net/game/hit_and_blow_top.html

GitHub
https://github.com/kitoku-magic

次。

四半世紀前からこの業界はそうなので、上昇指向のある人は違うかと思いますよ。

さて、ココが一番書きたい所。
人材採用したい企業は、これを望んでいると思うんですけど、
多分、以下の本とか書いている人がターゲットなんじゃないかっていうイメージなんですよね。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)
http://www.amazon.co.jp/dp/477415654X

上記の本の著者
http://labs.cybozu.co.jp/member/nishio.html

で、上記の展開になると、やっぱり「（エンジニアを大切にする）大企業強い」んですよね。
上記の、クックパッドとか、まさにそうですけど。
あ、あと「外資系企業（GoogleとかTwitterの日本法人とか）」もありますね。

あと、それ以外ですと、
そもそもやる気のある人は、「起業」しちゃってますね。あるいは、「海外逃亡」か。
あるいは、「ユーザー企業側の、内製の技術者」か。
ホント少ないです（どのくらいいるんでしょうねぇ？）けど。

なので、次。

まあ会社にもよると思いますし、それこそ名の通った大企業ならば大勢の志望者が押し寄せるからある程度取捨選択も出来るだろうけれども、
そうではない大部分を占めるIT中小企業にとっては、今後
「何で自分から技術とかに興味持たないの？」
っていうのは結構ハードルが高いのかもしれない、と。

日本の右傾化とかあまり書きたくないですけど、僕は今でも「大企業に入って安定した生活を」とか親から言われてます（まぁ、幻想なんですけど。「安定」って、システムの安定って、結構大変よ？）し、
多分、「殆どの家庭」が、そうなんじゃないでしょうかね。
「今」がというか、「バブル崩壊後は、ずっとそういう国」な印象ですけど。
だって、「相変わらず、公務員志望の人気高い」じゃないですか。
で、そんな所で「やる気のある人材を！」としても良いんですけど、
上記の通り、大半（全部だとは言いませんけど）は大企業に奪われて終わりなので。
「選択と集中」でしたっけ。
「日本の中小企業が優秀なエンジニア募集するなら、
今すぐ海外（やっぱアメリカ？）にアプローチした方が良い」と思いますね。
なんですけど、「何故か国内にアプローチしている」ので、
「中小企業における人材採用のミスマッチング」は、「解消される気配全くなし」であります。
で、以下の様に「入社（企業の規模は書いてないですけどね）して５日でクビ」というのが起きると。

某R社を５日でクビになった話
http://codeio.hateblo.jp/entry/2015/03/07/003348

ちなみに、上記の記事について、以下の記事が言及しているのを発見したんですけど、
・・・ちょっと「後半」が微妙ですね。
「技術」は、「大きく違和感は感じない」ですけど、
「営業」「契約（このおかげで最近助かってますね）」「交渉」が、フリーランスの所に「全くない」というのは・・・
「中長期的には確実に詰んで廃業して正社員戻り？」とかになると思いますけど。
一応、フリーランスの「定義」が違うのかなぁとか思いましたけど、すごいビックリしましたね。

いわゆるWebエンジニアの成長について
http://tkot.hatenablog.com/entry/2015/03/07/213709

ちなみに、Sクラス・Aクラスというのは、以下の事ですね。

「Aクラスの人はAクラスの人と仕事をしたがり、Bクラスの人はCクラスの人と仕事をしたがる」理由、への考察
http://d.hatena.ne.jp/gallu/20140517/p1

話を戻しまして。
というより「育てないなら、そもそも雇う必要ない」じゃないかと。
以下の会社とか、「一人会社」ですし、「自分でやれば良い」わけですから。

HASHコンサルティング株式会社
https://www.hash-c.co.jp/

株式会社 格子組
http://www.grid-works-guild.net/

でも、「一人じゃ出来ないから依頼する」んですよね。じゃあ、「教える」しかないかなぁと。

僕は個人事業主なので、雇うこと現状出来ない（発注は出来ますけどねw）ですけど、
法人格になったとしても、「正社員」はなぁ・・・「法改正されると良いなぁ」って感じですね（苦笑）

あと、上記とは関係ないですけど、何か、以下の記事を読んで思ったこととして、「日本出身のITエンジニア（Rubyのまつもとさんは言語開発者だし）が、世界で何か賞を受賞（既にいるかもしれないですけど、もっと増えて欲しい）」というのは、見てみたいですね。

米 「世界の勇気ある女性賞」に日本人女性
http://www3.nhk.or.jp/news/html/20150307/k10010007121000.html

なんですけど、今「AmazonもMacもLinuxもGoogleもTwitterもFacebookも」、全部「アメリカ発」ですし、
「惨敗は続きそうだ」という感じですね（苦笑）

話を戻して次。

ただ、まあネットにある情報を減らそうってのは弊社一社じゃ難しいし、それこそ社員に「会社の悪口をネットに書くな！」とか言うのはブラックの極みだから、最終的にはじゃあ自社環境を良くすることが重要だ。

「弊社一社じゃ難しい」から「業界の問題」なんですよね。
ちなみに、業界といえば、やはり「テレビ業界」は、以下の石橋貴明氏の発言の通りヤバイみたいで。

教団デビューした高島彩の娘、「俺は中途半端」石橋貴明が弱音、犬を散歩する稲葉浩志......芸能人「本当の顔」
http://spnews.auone.jp/entertainm/news/?ID=cyz_ETM201503020006

テンプレートとして、以下が完成しました（苦笑）

「そんなことより、今の｛業界名｝の状況のほうが危ない」「○○だ、△△だ、××だ、□□だって言ってる場合じゃなくて、本当に｛その業界にとって大切なこと｝を｛何らかの行動して｝いかないと、次のフィールドがなくなっちゃう」「｛業界名｝をまったく｛やらない｝やつが増えてきちゃってる中で、｛業界名｝を｛その業界にとって大切なこと｝を考えないと、『俺いつか、｛業界名｝の世界に関わってみたい』とかっていう目標が、どんどん小さくなっちゃう」

そういえば、テレビも「娯楽」ですけど、「可処分時間の奪い合い」って観点で見ると、
今は、テレビが結構ヤバイ状況でしょうね。
ただ、こういうのは、「今ヤバイ所が頑張って再浮上して、今絶好調な所がその後落ちる」ってのはありそうですけど。

あと、「中途半端」って所については、以下の記事を書いた時から更に考えたんですけど、
「中途半端である事を"認める"」のって、そんなに難しいんだろうかっていう。

近況報告
http://kitoku1.blog129.fc2.com/blog-entry-240.html

勿論、中途半端で良いとは思わないですけど、
「中途半端じゃないレベルって、それこそ上のスーパークリエータとかいうレベルじゃないか」っていう。
なので、またしてもミスマッチですね。

次。

いやでもねえ
正直、残業は現場によるし、そういう現場に入るかどうかは正直営業さんとの兼ね合いもあるし、ある程度仕方ない部分はあると俺自身は思ってるし、
勿論それに対して新人さんが困らないような体制は上司なり先輩が整えるべきだとは思ってるんだけどね。

だた一方で、ある程度は
「徹夜とかしてでも俺はいまこのプログラムを完成させて、より良い物にしてえんだ！」
ていう原動力みたいのも、間違いなくこの業界には要求されるわけで、
じゃあそういう自発性のエンジンってのをどうやって新人さんに取り付けてあげるかってのが課題。

ただ、そもそもその手のエンジンって後から取付可能なのか、ってあたりも疑問ではあるのよね。
ITの面白さ、もっと言うとプログラムとかを書いて前より早くなったとか機能が増えた、って時に「ああ楽しい！」と達成感を感じられる、ってのは
外からの動機付けで行えるものなのか、否か。

ココら辺、「一個人の経験」でしかないので、どこまで参考になるかってのがあるんですけど、
「娯楽・エンターテイメント系か否か」で、ちょっと違うかなぁと。
「非」娯楽系ですと、徹夜は「一度もしたことない（夜中の2時ぐらいがMAXだったか・・・）」ですし。
一方で、娯楽系は「徹夜ありました」ね。
ただ、非娯楽系の「利便性を追求する」ってのと、
娯楽系の「人々を感動・興奮させる」ってのだと、
後者の方が厳しいんじゃないかっていう。
なので、「徹夜だからブラック」ってのは、「違うなぁ」とは思っております。
単純に、「お金を払わないのがブラック」ってだけだと思いますよ。
ただ、ココで恐いのが、僕も最近始めて知ったんですけど、以下。

なぜ「やりがい搾取」は起こり続けるのか？
http://tm2501.hatenablog.com/entry/2014/12/25/232347

う～む、「どおりでネットで見つからないわけです」ね。
で、コレ、リアル雑談でもいつか話した人いるんですけど、
単純に、「やりがいは正直あると思うけど、お金さえ払えば良いと思うんですよね」で終了かなと。
以下にも、お金については書いてますけどね。

「深夜の即時対応から始めるクライアントに寄り添ったサービス」の醜悪な構図
http://d.hatena.ne.jp/gallu/20141028/p1

機能の大小はありますけど、「リリース前後」は、場合によってはしょうがないとは思いますね。

で、ようやく最後ですけど、コレ。

早い 安い 死亡………
http://d.hatena.ne.jp/gallu/20141022/p1

お前がいつか出会う災いは、 おまえがおろそかにしたある時間の報いだ。

重い・・・重い・・・
というのも、昨年「職人を軽視したら、職人の知識が必要な所で死にかけた」ので（苦笑）
「ビジネスの成功を目的に考えてみてはどうか」とか言ってしまったんですけどね（苦笑）
ただ、一応、以下の様な話もありますけど、
でも、「上記の状況」考えますと、以下でも「かなり絶望的」だと思いますね（苦笑）

https://twitter.com/fluor_doublet/status/574059471766339584

「教えなければ、教えなかった災いにあう」
「お金を出さなければ、逃げていって災いをもたらす人材が新たに来る」
「適切に評価出来なければ、適切じゃない人材が来る」

って事だと思いますけどね。

と、結構暗い話を書いてきましたけど、
結果として「エンジニアサイドは、初級（新人さん）と上級（スーパークリエータさん）は上記の状況で、
中級は上記をある程度経験してしまった結果、
大多数がネット（リアルではちゃんと仕事してる人も多いんですけどね）では休眠中」という「現状」となっている印象です。
休眠は、「休んでも良い（僕も休む時は休みますので）」とは思うんですけど、
とはいえ、「３年以上とかはなぁ」ってのはありますね。
さすがに、もう浮上してこないとは思いますけど。

色々書いてきましたけど、個人的には「もうちょっと成功事例みたい」ですね。
じゃないと、「この業界に投資（お金）を」とかが「増えない」と思いますから。

さて、以下のスライドについてのツッコミなどをしてみたいと思います。

ノマトピア構想
http://www.slideshare.net/miraihack/ss-44891684

> 全ての人にチャンスのある世界の実現

まぁ、五体不満足の乙武氏もそうですし、
こちら http://www.honbu.co.jp/archives/720 にもありますけど、マイノリティにもチャンスあるんですよという社会の実現というのは、
不変的課題であり、だからこそ尊いだろうとは思います。

> ブラック企業の蔓延

「何をもってしてブラックとするか」ってのがあるかと思いますけど、
これを「違法」だとするなら、「法改正による整備」が必要なのは、結構色んな法律でみかけますね。
昨今話題の、「個人情報保護法」とか。
法律って、最近思うんですけど、
制定当初はその条文で問題なくても、
社会の変化に伴い条文を守るのが難しくなっていくという一面があるかと思うんですよね。
だからといって、法治国家ですから、法律を守らないのはNGではあるんですけど、
ただ、条文がアップデートされないまま、法解釈の変更といった運用で乗り切っている法律において、
「この条文のココが守られてないから、違法なブラック企業だ！」とする消費者も、どうなんでしょうねぇと。
ココは、だからといって勿論Yesとはいえないので、議論は必要かとは思うんですけど。

> 若者はゲームの世界に没頭
> ゲーミフィケーションをを取り入れた新しいワークスタイルの形成

この後のクラウドソーシングと合わせて考えてみたいんですが。
以前に、クラウドワークスのイベント に参加した時にビックリしたのが、クラウドソーシング利用者層は、結構主婦が多め（イベント時も、男3：女7ぐらいでした。で、主婦層は結構、小遣い稼ぎ目的の模様）でして。
で、一方で、主婦って最近、結構電車の中とかでも、スマホゲーをやっているのをちょくちょく見聞きしまして、
案外、マッチするのかもしれないなぁとは思いましたですね。

ただ、一つ気になるのが、ゲーミフィケーションについてで、ココは後述。

> 国内のクラウドソーシング市場規模

まぁ、上記主婦層もそうですけど、多様な働き方の志向は進むでしょうから、拡大するとは思いますね。

> 職場の満足度

日本低すぎ（苦笑）
まぁ、バブル期のノリで「24時間戦えますか」のワークライフバランスをドン無視する様だと、
こうなりがちかもしれないですね。

>　クラウドソーシングのゲーミフィケーション

で、ココなんですけど、まずゲーミフィケーションという言葉自体が、
こちらのGoogleトレンドの通り、現在完全に一過性のバズワードになってる感じ（知ってましたけど）でして、イメージが沸くのだろうかと言う問題。
僕は、酒場チャット機能とかみて、「あぁ、真・女神転生Ⅳのチャレンジクエストの仕組みと似ているな。クエスト受注とか」って思いましたし、ゲームラーニングという方向性で こういう のも書いてますから興味ありますけど。
ただ、結構、 こういう のと紙一重だと思ってましてね。あと、「フィクションと現実の区別がつかなくなったり」とか、
あと、こういう方向性 にも応用出来そうですし（苦笑）
で、ちょっと個人的に振り返ってみたんですけど、
「ゲームから抜き出してよいポイントと、よくないポイントがあるんじゃないか」という点。
例えば、「シューティングゲームで人を撃ち殺せる」からといって、実際に人を殺しては当然いかんわけですし。
なので、ここらへん、結構「応用力」が問われる分野だと思ってるんですけど、
ただ、応用するには、「きちんとした基本」が出来てないと、危ないんじゃないかと。
で、ここら辺が、今回のこのシステムを使う分には、利用者には不都合はないかもしれないですけど、
今後の普及の足かせにはなりそうに思いますね。

> スタートアップのマネタイズ問題

以前にも、スタートアップでソシャゲの新規開発PJに関わったことありましたけど、
スタートアップは収益化するまでが大変でして、
プール金と言いますか、お金に余裕無いと、どうしても支払う側はキツキツにはなるかなと思いますね。
以前に、お金受け取る側の時に、マネタイズ化までのスケジュールが後ろになりそうって見通しになった時に、
「これは、収益化されている既存サービスも無いし、支払い大丈夫かね？」って思い、早々に撤退したことはありましたね。
で、どうも、その後、早々に潰れた情報は聞いたんですけど（苦笑）

僕自身は受注側にしか立ったことはないですけど、
ただ、この辺 http://kitoku1.blog129.fc2.com/blog-entry-242.html を見ましても、
収益化可能なビジネスモデルか否かっていうのは、
契約形態問わず、やはり気になる所ではあるので、
そこら辺は、今一度精査が必要かとは思いますね。

ここで、こちら から名言を、
「夢を見るのは良いけど、でも同じくらい、現実も見なきゃ」じゃあないかと。
どの関係性においても思うんですけど、せっかくのご縁を、
ちょっとしたすれ違いが原因で失うのは、「あまりに勿体無い」と思いますから。

> 構成技術

昨日お会いしたエンジニアも知ってましたけど、
確かに、NodeというかJavaScriptを使っているシステムって意外と多い印象ですね。
まぁ、まだPHPなんかと比べたら少ないでしょうけど、
案外、一過性のブームじゃ終わらないかもしれないですね。

あと、個人的にNoSQLだとACID性がRDBに比べて劣ると思っていたんですけど、
Redisにしても、watchなどがありますし
MySQLClusterにしても、こちら http://japan.zdnet.com/paper/30000714/30001363/ など見た感じ、案外担保してる印象ですね。

と、ひとまずそんな感想を抱きました。

えっと、最近以下の本を大変興味深く読ませていただきましたので、
今回はその感想を書いてみます。

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
http://www.amazon.co.jp/dp/4534051948

この辺、以前からちょくちょく考える事ありまして、
要は「ソフトウェアを作る事自体が目的化していないか」とか、
「時給制だと、スキル高い場合に必ずしも得しない」とか、
「仕様変更に対して、どういうスタンスで対応していけば良いのか」とか、
様々なテーマがあるかと思うんですけど、本の中からちょくちょく抜粋しつつ書いてみたいと思います。

１．納品するという罠

そもそも、「どうしてソフトウェアを作るのか？」という事を考えた時に、
ビジネス上の目的（勿論、ココは各案件によってバラバラ）を達成する為に、ソフトウェアを作るのであって、
ソフトウェアを作る事自体が目的ではないんじゃないかと。
なんですけど、これ僕も下請けでやっていて、納期とかリリース予定時期とかあって、
で、そういったスケジュールがあると、「締め切りまでに間に合わせなければ」という意識になりやすく、
結果として、「ソフトウェアを作って、ビジネス上の目的を達成する」から、
「納期までにソフトウェアを作る」に、目的がすり替わってる様に感じますね。
なので、「納品」とか「納期」という言葉が、
仕事の進め方への意識に悪影響を与えているというのが、あるのではないかと思いますね。
でも、そうじゃないでしょうよと。
で、この辺の考えって、結構「システムの作り」に影響出るんじゃないかと思ってまして、
特に「保守性」に影響出やすい印象です。
勿論、ビジネス上の目的が不明とか、
開発スケジュール自体がそもそも破綻しているとかは別としまして。
というより、時間を切り捨てれば、いわゆる「プロジェクトの４つの変数」的に、
コストが跳ね上がり、スコープや品質が切り捨てられるだけなんですけど。

あと、なんで納期を定めるのかという部分には、勿論ビジネス上の事情の場合もあるかと思いますけど、
「納期を定めないと、ダラダラ仕事して、いつまで経っても終わらないから」というのも、
何となくですけど、ある気しますけどね。
多分、「何を持ってダラダラしていると見なすか」っていう、
「ダラダラ」の定義がポイントな気がしますけど。
ずっと椅子に座っていて、何日立ってもアウトプットが出てこないなら、さすがに「ダラダラ」だと思いますし、
一方で、新しいものを作る為に「調査・検証」しているのは、別にダラダラではないと思いますし。

２．仕様変更に備えて、見積もり時にバッファを積む

この問題は、本のP22に書かれている内容は内容で確かに同意ですけど、
別のルートで、「バッファ積んだ分の作業が発生しなかったら、元の金額に戻せば良い」という話も聞いてまして、
どうだろうなという印象でした。
ただ、上記の手法も、実践したことがないので、ハッキリは言えないですけどね。

３．人月とエンジニアの時給の問題

本のP25に書かれている内容自体は、話として当たり前で同意ではありますけど、
ただ、最近は、こういった事例はあんまり見ないですね。
以前よりも、エンジニアの評価基準というものが、確立されてきているからだと思いますけど。
どっちかというと、以前に書いたコチラ http://kitoku1.blog129.fc2.com/blog-entry-167.html の方が気になりますね。
実際、「作業を終えて早く帰る人は無能」という価値観といいますか、
そういったものは、まだまだ色濃く残っている様に感じますし。
勿論、「早く帰ってはいるものの、品質グダグダ」とか、
「早く帰る事が目的になってしまっている」のは別としましても、
「必要な作業をした上で、早く帰るのは全く問題ない」と思いますし、
むしろ、「早く終わらせる事が出来る人なら、それを評価して昇給させたり権限与えた方が良い」と思いますけどね。
単純に、その方がビジネスとして上手くいくと思いますから。

４．エンジニアの評価の難しさ

P37に書かれていますけど、非エンジニアがエンジニアを評価するのは難しいってのは、
確かにそうだと思ってまして、
なので、こういうの http://www.slideshare.net/kitoku_magic/php-40141964 を書いてみたんですけどね。
このスライド、どっちかというと、非エンジニア向けですから。
で、じゃあエンジニア間なら大丈夫かというと、実は必ずしもそうでもなくて、
意外と、エンジニアによってプログラムの書き方が違ってたりします。
あと、業務上のプログラムだと、外に出せない事もありますし、
あと、現場に合わせたプログラムの書き方なのか、自分のプログラムの書き方なのかの判断が出来ないので、
どんなプログラムでも良いから、プライベートで書いたプログラムが一番参考になると思いますね。
という事から、GitHubは役に立つと思います。

５．ビジネスにおける信頼関係

P71にありますけど、確かに「本当は」契約で縛りたくはないですよね（苦笑）
アジャイルソフトウェア開発宣言 http://www.agilemanifesto.org/iso/ja/ にも書かれている通りだと思います。
契約書はリスクヘッジでしかないってのは、契約を交わしていて確かにそうだと思いますけど、
契約書って「対話で解決出来なかった時の対策」であって、
対話で解決出来るなら、少なくともガッチガッチに縛る必要はないとは思いますから。

６．銀の弾丸はないについて

P73にありますけど、もういい加減飽きたというか（苦笑）
人月の神話 http://www.amazon.co.jp/dp/4621066080 は、
もう言うまでもないですけど、
個人的には、この辺 http://www.slideshare.net/kitoku_magic/ss-26184970 の考えと特に変わってないですし。
あと、類似品で、「この機能を作って挽回する」とかも同じかなと。
「挽回」じゃないんだったら、アリだとは思うんですけど、
「挽回」したい場合は、不振の原因分析の方が大切じゃないかと思いましてね。
話を戻して、で、この本のビジネスモデルも銀の弾丸ではないと書かれていまして、
これも確かにそうだと思います。
組み込み系の様な、「物理的に納品が必要なソフトウェア」も存在しますし、
あと、この記事のやり方 http://d.hatena.ne.jp/gallu/20110225/p2 だとダメなのかってのもありますね。
まだ、整理出来てませんけど。
なので、万能の薬ではないとは思いますけど、
とはいえ一考に価するビジネスモデルだとは思いましたね。

７．エンジニアサイドの作り方の変化

P144にありますけど、
「バグが出てもすぐに直せるようにする」は、もう少し細かくすると、
「バグが出た事を検出しやすくして、バグが出てもすぐに直せるようにする」かなと。
エラーで「Noticeも出す」なんかは、検出がしやすくなるんじゃないかと思いますし。

あと、「あらかじめ作るよりも必要になるまで作らない」は、結構陥りやすい罠じゃないかと思いまして。
例えば、「最初から共通化する」とか「仕様変更に対応する為に、事前に仕込んでおく」とか。
でも、これって、システムが肥大化しやすく、いわゆる技術的負債が増えるとは思うんですよね。
ちなみに、「仕様変更が問題」という声も結構あるんじゃないかと思うんですけど、
正確には、「仕様変更したけど、締め切りが変わらなく、結果として品質などが切り捨てられるのが問題」って事だと思いますね。
仕様変更自体は、少なくすることは出来ても、ゼロにすることが出来るイメージは、ちょっと僕にはわかないですし。

８．属人性の排除について

P166辺りから書いてありまして、これはこれで分かるのと別の話として、
「属人性は徹底的に排除したい」というのは、やっぱりありますね（苦笑）
多分、ココは絶対に譲らないかもしれません（苦笑）
というのも、属人性って「徹底的に排除しても、いくつかは必ず残る」と思ってまして。
まず、「他の人が真似しようとしても、真似できない」というのがあると思います。
例えば、僕の特徴として「モチベーションが下がっても、しばらくすると再び上がる」ってのがあるかなと思いまして、
まぁ、そこかよって気もするんですけど（苦笑）
でも、真似出来ない（少ないとは思います）と思いますけどね。
そんなに難しい話でもなくて、真っ黒い話とか聞いてモチベーションが下がる事は下がって、
で、下がると「何もする気がしなくなって、実際何もしなくなる（実際にはゲームをやっている事が多いw）」んですけど、
でも、そのままだと、しばらくしたら詰むなと思い始めて、
モチベーションが再び上がる（正確には、正常に戻る）という。
だから、下がったまま再び上がらない方が、僕には不思議に感じますね。
というのと、あと「自分自身」というのは、完全に自分に属していると思いますから、
仮に上記が真似出来ても、自分自身は無理じゃないかと思いますね。
で、排除するには、教育するのが本質だと思いますけど、
だから、教育にも興味ありますね。

９．メンター制について

P192にありますけど、ココは結構議論になる部分なんじゃないかと思いまして。
個人的には、「メンター制自体は良いが、メンターに依存しない様にする為に、
複数のメンターを持ち、各メンターへの依存度を下げる様にする事と、
メンター毎に異なる部分を、上手に吸収出来るようにする」ってのが良いかなと思ってますけどね。
メンターが「一人」だと、偏ってしまいがち（メンターにもよりますけど）ですし、
かといって、メンターが「沢山」だと、言ってることがバラバラで模倣するのが難しくなると思いますし。

１０．会社の規模の差異について

まず、「小さな会社の方が、幸せを感じやすい」は、
「個人にフォーカスがあたりやすいから」じゃないかと思いますね。
マズロー的には、「所属・承認欲求」辺りに該当する様に感じますけど。
別に、大企業でも無理ではないと思うんですけど、
単純に人数が多い分、浸透させるのが難しいんじゃないかと。

会社の規模で一番違うと感じるのは、
「大企業の方が、多方面に事業が行うことが出来る」じゃないかと。
小さい企業だと、さすがにそれは難しいというか、一人でそれらは出来ないと思いますし。
で、作ったものの品質には、差異は出ないと思いますけどね。
大企業の方が、人数が多いことからマネジメントが難しくなり、
結果として品質が下がったというのはあるかもしれませんけど、
でも、それはマネジメントの問題であって、大企業という規模の問題とは別じゃないかと。

色々書いてきましたし、まだまだ本には色々書かれていますけど。
とりあえず、本のタイトルについて思う事としては、本質的には納品の有無ではない様にも感じてまして。
というのも、「何の為に、そのソフトウェアを作るのか」という目的があって、
そして、目的が達成され始めるのは、ソフトウェアを作った「後」からであって、
それは、納品があってもなくても変わらないんじゃないかと思いまして。
そんな感想を抱いた次第でした。