奇特なブログ

「殊勝に値する行いや心掛け」を意味する、奇特な人になる為のブログです

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

相談についての記事への突っ込み

えっと、最近読んだ以下の記事について、
知り合いが「相談する側に都合の良いことが書いてあるので微妙」という話でしたので、
僕の方でも検証してみたいと思います。

サイボウズ式:コミュニケーションコストがかかる人は相手にされない
http://www.huffingtonpost.jp/cybozu/cybozu-communication-cost_b_6814174.html

まぁでも確かに、「からみやすい人間の方が良い」とか、
確かに主観的ではありまして、微妙であるとは思いますね。
それは話しかけられたときにうっとおしそうにしないことであったり、聞き返すときに詰めるような物言いをしないことであったり、相手が聞きたいことではなく自分の喋りたいことを喋るような愚行を犯さなかったり
ポイントなのは、この辺が「どうして、相談される相手が、そういった態度や言動をする様になったのか?」じゃあないかと思いますね。

相談と言いつつも、「単に、相談相手に自分の仕事を無償で丸投げしたいだけ」とか、
「相談はするけど、相談相手の話は、全く聞いていない」とか、
そんな事が続けば、相談相手が、上記の様な態度を取っても無理はないと思いますし。

ただ、一方で。
「場の空気(空気読めとかの空気と一緒)」というものがありまして、
要は「話しかけやすい雰囲気を作る」というのも、やっぱり大事なポイントだとは思うんですよね。
で、この辺りを考慮して、
「また話聞かないかもしれないけど、改善するって言ってるし、もう一度だけ聞いてみよう」という心持ちで、
「不機嫌をあまり表に出さずに、相談に乗っている」人も多いんじゃないでしょうかね。
・・・希望的憶測も含んでいますけど(苦笑)

ビジネスですから、「そんな事をした所で、成果が出なければ何にもならないじゃないか」というのは、ごもっともであります。
ただ、「構築された場」が、
「失敗する確率が高いビジネスに対して、指摘するのが躊躇われる様な場」であった場合には、
十分に悪影響があるんじゃないかと思いますね。

そんな印象を持った記事でした。

テーマ:日記 - ジャンル:日記

  1. 2015/03/16(月) 18:45:05|
  2. コミュニケーション
  3. | トラックバック:0
  4. | コメント:0

人材採用のミスマッチングとか教育とかやりがいとか色々

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

某R社を5日でクビになった話
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

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

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

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

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

テーマ:日記 - ジャンル:日記

  1. 2015/03/09(月) 05:28:19|
  2. IT
  3. | トラックバック:0
  4. | コメント:0

難しい仕事が支えているということ

色々とサーフィンして分かったことですけど、
世の中には、景気の良い組織ばかりでは無くて、
法的整理を一刻も早く行った方が良い組織や、
判断に必要な情報を開示しない組織や、
脆弱なセキュリティのまま放置されているWebサイトや、
技術的負債を抱え込んでいる組織や、
やる気の無い部下や生徒や顧客と対峙する役割や、
クレーマーと対峙する役割や、
人々を興奮・感動させる芸術を生み出す役割や、
無償で匿名でゲームの攻略サイトを作ったりする役割や、
話し合いが通じそうにない相手と対峙する役割があります。

一方で、好収益・好決算な組織や、
管理が良く、ワークライフバランスも考えられている組織や、
綺麗なソースコードで運用されているITシステムや、
話し合いが通じる部下や生徒や顧客と対峙する役割や、
休日も睡眠時間も家族サービスも十分に満たせる場所があります。

おそらく、何処かのタイミングで「決断」する必要があるのでしょうね。
自分自身の人生観や、後は好みで。

ただ、誰もがやりたい仕事ってどっちでしょう。
おそらく、後者を選ぶ人が多いと思うんですけど、
それでは、前者の担い手がいなくなってしまいます。
例えが不適切かもしれないですけど、
汲み取りの様な泥水を被る様な仕事が存在するからこそ、
後者の組織や人生が存在出来る様に思います。

目的として、「社会や業界の生存と発展」を考えた時に、
手段として「社会や業界全体の底辺の底上げ」と、
「社会や業界のトップを目指す方向性」があり、
それぞれが、上述の前者と後者に対応している様に思います。

ただ、上記は選択制ではなく、両立可能だとは思います。
が、あまりそれは見ないですけど。

後者の組織や人生を批判したいわけではありません。
ただ、社会や業界には、そういった役割の組織や人がいるということ。
それらが存在する事で、自分の所には影響が及んでいないということ。
それらを忘れ、全てを自己責任にする風潮が広まると、
より、殺伐とした社会や組織が増えていく様に思いますね。
なので、それだけは忘れずにいたいと思います。

テーマ:日記 - ジャンル:日記

  1. 2015/03/02(月) 18:01:44|
  2. ビジネス
  3. | トラックバック:0
  4. | コメント:0

ノマトピア構想を読んだ感想

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

ノマトピア構想
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/ など見た感じ、案外担保してる印象ですね。

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

テーマ:日記 - ジャンル:日記

  1. 2015/02/23(月) 00:04:31|
  2. IT
  3. | トラックバック:0
  4. | コメント:0

「納品」をなくせばうまくいくを読んだ感想

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

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

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

1.納品するという罠

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

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

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

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

3.人月とエンジニアの時給の問題

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

4.エンジニアの評価の難しさ

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

5.ビジネスにおける信頼関係

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

6.銀の弾丸はないについて

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

7.エンジニアサイドの作り方の変化

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

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

8.属人性の排除について

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

9.メンター制について

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

10.会社の規模の差異について

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

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

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

テーマ:日記 - ジャンル:日記

  1. 2015/02/08(日) 01:39:56|
  2. IT
  3. | トラックバック:0
  4. | コメント:0
前のページ 次のページ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。