はてなキーワード: 技術書とは
旧字で旧仮名使いの古い本を読むわけでもないのに、どうしても活字の本の中での描写が頭の中でイメージしきれない。
読めない本の種類としては圧倒的に小説が多い。
一番の問題は、風景などの視覚的な描写を頭の中でしっかり思い浮かべるのができてないことだと思う。
知識が足りてないという事もあるし、ひとつひとつのパーツは理解できてもそれを頭の中で映像化するのが難しいのだ。
例えば
私は墓地の手前にある苗畠の左側からはいって、両方に楓を植え付けた広い道を奥の方へ進んで行った。 するとその端れに見える茶店の中から先生らしい人がふいと出て来た。
夏目漱石はかなり分かりやすい素直な文体の作家だと思うけど、自分にはこういったちょっとした描写ですらイメージするのが難しく感じる。
墓地は思い描ける、苗畑は普通の畑とは違うのか?と不安になったのでググった画像で補完するがまあ大丈夫。
楓、広い道、茶店、どれも単体では想像できるけど、問題はこの光景が俯瞰で見えない、地図のように絵を描こうとしてもかけないのだ。
まず「左側」でつまづいて、苗畑と広い道の位置関係もわからない。
漫画ならこれらが全て背景絵として描かれてると思うので、なんの引っ掛かりも感じないだろうと思う。
小説だと光景を事細かに描写する必要もない場合もあるわけで、そういう時はある程度読者が好きにイメージすればよいんだけど、自分の場合あまりに曖昧にしかイメージできなくてその場面の全てがぼんやりしたものになってしまう。
小説自体は、場面ごとの描写がはっきりと頭の中で映像化できてなくても読み進めることはできる。
でも頭の中で映像化されていないとぼんやりした空間に登場人物がそれぞれ現れるだけという味気ないものになる。
ミステリー小説なんかでトリックとして建物の構造だとかが描写されてる時もだいたいよくわからない。
特に空間把握能力が著しく欠けているのかなとも思う、実際地図を読むのは下手だし方向音痴だし。
ただそれだけじゃなくてちょっとしたディテールとかも掴めない事が多いし、それが気になって中々先に進めなくなったりする。
小説の中で描かれる描写が、全部ちゃんと自分の頭の中で思い浮かべることができたらどんなにいいだろうと思う。
でもどうしてもそれができなくて、結局集中しきれず最後まで読みきらないことが多い。
子供の頃からあまり読書はしてこなかったし、漫画ばかり読んでいた。
今は漫画はたくさんあるから漫画でいいじゃんと開き直ってもいいんだけど、やっぱり小説をもっと読み込めたら楽しいんだろうなと思う。
なにか特訓の方法などあるんだろうか?
追記:
コメント色々ありがたい。
一番驚いたのは「そこまでイメージする必要はないのでは」という意見が多いことだった。
みんな小説など読んでる時は頭の中である程度具体的にイメージしながら読んでるものだと思いこんでいた。
ただ、言われてみれば登場人物の顔はおぼろげなまま読んでるのにそこは気になってないとか、自分の中に矛盾もあることに気づいた。
アファンタジアではないかという意見もあり、初めて知った言葉だけどこれも興味深かった。
自分がアファンタジアかどうかは分からないが、記憶をイメージとして思い出すことはできるので、そういうのとはちょっと違うのかもしれない。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
312あとで/1768users 漫画で学ぶNISAとiDeCo|資産形成のポイントを解説|日経電子版
243あとで/1598users 45分間で「ユーザー中心のものづくり」ができるまで詰め込む | Yoshiki Hayama | slideshare
233あとで/1752users 見積・提案書に書いておくと不幸を減らせる前提条件 | Atsushi Nakamura | Zenn
215あとで/1290users サイバーエージェントが公開した“300ページ級のUnity技術書”がスゴい!しかも誰でも無料で読める|Unity Japan(ユニティ・テクノロジーズ・ジャパン)|note
210あとで/1775users なぜ投資をさっさと始めないのか - 本しゃぶり
209あとで/1465users 「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita
196あとで/1631users 引越しが決まったらやるべきことのあれこれがめっちゃ参考になると話題「ありがてぇ…」補足あり | Togetter
194あとで/1830users やばすぎるAI画像生成サービス「Stable Diffusion」始まる。 【簡単解説 & 応用 & Prompt付生成事例集】|やまかず|note
189あとで/1680users 鈴木孝佳|姿勢改善オンラインレッスン on Twitter: "「あれこれストレッチ面倒だから1個教えてくれ」に対する解はこれです。「世界で最も偉大なストレッチ」と名前がつくだけあって、フルコンボ感ある。 https://t.co/UbfDw4F8SN"
187あとで/1623users 相手に動いてもらえないのは、一言目で“地雷”を踏んでいるから 仕事でも私生活でも役に立つ、人を動かす「伝え方」の極意 | 高橋浩一、荒木博行 | logmi
184あとで/948users Amazon VPCを「これでもか!」というくらい丁寧に解説 - Qiita
168あとで/919users 「リーダーの作法」マネジメントに限らず、エンジニアとして仕事の作法について書かれた良書 | hurutoriya
161あとで/1231users スタンフォード大学が無料で提供している英語プログラムがすごすぎる...様々な高校生向け教育プログラムをまとめました | Togetter
161あとで/1444users Seiya on Twitter: "クイーンズランド大学が開発したHIITがすごい。HIIT WBというエクササイズで、たった4分間の運動で30分の有酸素運動を遥かに凌ぐ効果を発揮する。心肺機能と筋肉量の増加、脂肪減まで期待でき、抗老化に繋がる。動画をそのまま真似し… https://t.co/FWvRp0RAaR"
159あとで/1503users 精度はGoogle翻訳を越える… 無料の国産「TexTra」が地味にスゴイ | ビジネスジャーナル
156あとで/1582users 横浜中華街いろいろ食べたくなるガイド|47AgDragon(しるどら|note
155あとで/736users 設計の考え方とやり方 | 増田 亨 | SpeakerDeck
151あとで/1290users なぜ日本の郊外には「タダ同然の住宅地」が大量にあるのか…「限界分譲地」という大問題を告発する 無責任の体系によって「都市の荒廃」が進んでいる | PRESIDENT Online
151あとで/1225users 『りぼん』編集部が作った「生理カンペキBOOK」が永久保存版すぎる。無料公開した思いを聞いた | HUFFPOST
147あとで/1209users Seiya on Twitter: "自宅にこもり切りの超運動不足の方、筋トレ超初心者の方へ。まずは2分だけ動画の真似をしてみて欲しい。難易度は低いが、鈍り切った体に刺激が入り、眠っていた身体の活力を取り戻すキッカケになると思う。 「独房式・脂肪燃焼全身サーキット新… https://t.co/pMQHBJAlIA"
139あとで/1768users 世界変革の前夜は思ったより静か|深津 貴之 (fladdict)|note
133あとで/1188users 「酒場で見ず知らずの人と親しく話し、取材する方法」を書いた朝日新聞記者の記述が面白かった(「ルポ トランプ王国2」) - INVISIBLE D. ーQUIET & COLORFUL PLACE-
128あとで/1292users 魔術として理解するお絵描きAI講座|深津 貴之 (fladdict)|note
127あとで/1379users 夫が裏垢で70人と不倫していたのが発覚した日の話①|ego@離婚協議中|note
126あとで/1146users 三谷幸喜さんが勧める「読書感想文」の書き方。「子どもの頃知りたかった」と反響呼ぶ | HUFFPOST
123あとで/811users キャリアアッププログラム「Google Career Certificates」日本版を開始 | Google Japan Blog
122あとで/1083users マルク on Twitter: "元銀行員として伝えたい。日銀に金融庁、FP協会に財務省。エリートが作ったお金を学ぶサイトが超有益。給与明細から投資、保険にクレカ、インフレやつみたてNISA、仮想通貨まで。小学生から、わかったつもりの大人も。もちろん0円。各資料で… https://t.co/rZ6zflv5HK"
121あとで/1298users 安倍晋三元総理とは何者だったのだろうか(田中良紹) - 個人 - Yahoo!ニュース
121あとで/1241users 【ドドンッ!】有名YouTuberが使ってる『効果音ラボ』の実態に迫る | ジモコロ | イーアイデム
116あとで/679users 正規表現の先読み・後読み | USAMI Kosuke | Zenn
元記事はこれ
内容としては、C100に参加したが1部も売れずに終わってしまって、筆者の方が思ったことについてまとめられています。
当然、元記事の筆者を批判する意思は当然なく、元記事筆者の売るための努力が不十分で、こういうやり方をしたほうが良いと思った次第でこの日記をまとめました。多分何百部も売っているような人たちに取っては何の参考にもならない記事でしょうが、毎回の頒布数1桁とか10部くらいであれば少しは役に立つのではないでしょうか。
特別、元記事の筆者本人に読んでほしい訳ではなくて、自分はこうやって色々な人に読んでもらって、買ってもらっているというだけの話で、それが他の誰かの役に立てば嬉しいと思って書いています。
そして、同人誌頒布の喜びを知る人が1人でも増えれば嬉しいと思って、そのノウハウをシェアするために書いていますのでご参考になれば嬉しく思います。
出店は同人ソフト。いわゆる技術書と呼ばれるものを出しています。
若干詳細は伏せますが
C9Xから毎回参加していて、概ね毎回新刊数十部と既刊を何冊か保っていて書く10数部ずつ売って最近ようやく1回の頒布部数が100部を超えた程度です。TwitterなどSNSのフォロワーは元記事の筆者と大差なく、むしろ私のほうがツイートなどに対するインプレッションは少ないでしょう。
さて、弊サークルはハードウェア・ソフトウェアについてまとめた本をメインに出していて、コミケの中では間違いなくマイノリティに属すると思います。マイノリティであるが故に毎回当選するが、ジャンル的に人通りが少ないので、当然売る顧客が少ないとも言えます。一方で、マイナージャンルであるが故に、特定の顧客に刺さりやすい分野なので頒布部数が0になることも少ないかも知れませんが。それはさておいて、泡沫サークルであることに違いありませんので偉そうなこと書いているねと嘲笑ってもらっても構いませんが、実際に弊サークルがやっていることについて説明します。
元記事の著者が書いている通り、事前準備は重要です。とは言え、C100に私がやったことは元記事の著者よりも劣化しています。
こいつ本当に前準備が重要と思っているのか疑わしいけれども、本当に大事だと思っています。出来れば事前にしっかりとシェアして何とかいいねやリツイートをして誰かに刺さることを期待するほうが良いでしょう。一方で、いいねやリツイートしてくれた人がコミケに来る確率は決して高くないので、いいねが100個ついたからと言って、100冊買ってくれるとは限りません。なので、事前準備が不十分だからと言って気にせずに行きましょう。
当日の陳列はとりあえず本が客側に見えるように、陳列しましょう。ポスターやイーゼルがあればそれを使って見せるようにしましょう。
特に「どんな」本なのかが分かるように陳列することが重要です。作品に対する情熱であるとか、どこが良いのかが分かるような見せ方であるほうが望ましいと思います。自身の本の質が他人に技術やクオリティで劣ったとしても、唯一無二である点をアピールしましょう。
例えば、本屋さんに行けばポップが付けられているかと思いますが、それを参考にすると良い用に思います。小説の表紙だけを見て買おうという人よりも、ポップに書かれた内容(例えばジャンルやどういう書籍、読みどころはどこかなど)を見て買う人のほうが多いのではないでしょうか?それこそ、販売のプロが付けたタイトルに、表紙絵がセットになって、なおポップを付けてアピールがなされているのです。そこをサボることは当然許されないのではないでしょうか?
開場後にすべきことはあると私は思っています。そもそも、Twitterで宣伝しただけで本を買ってくれるのであれば、Boothとかで頒布しても売れているでしょう。もちろん、コミケだからと財布の紐が緩んでいる人が多いという事実もあるでしょうが、それ以外にも同人誌即売会だからこそできることもあります。
例えば、営業。サークルの前を通る人に声を掛けるのを躊躇っていませんか?
まずは、自分の本を手にとってもらうことが重要だと思っています。なので、通りがかる人に声を掛けて本の中身を見てもらいましょう。特に、数秒程度見ている人には必ず声を掛けましょう。この時、必ず本の方を指指して、あなたが欲しい本はこれだとアピールしても良いでしょう。
自分のサークルを一切見ていない人は別の目的地に向けて移動している可能性があるので、声をかける意味があまりないかもしれませんが、数秒見ている人は、もしかしたら時サークルの潜在的な顧客かもしれません。数秒見ている人は自分が探しているジャンルや方向性(性癖とか好奇心と言い換えるほうが良いかもしれません)に合っているか本やサークルの値踏みをしているかもしれません。もし、そこで表紙が琴線に触れたならば買ってくれるでしょうが、泡沫サークルに取ってはハードルが高いものです。なので、そのきっかけと成るように、お客さんに声を掛けましょう。
特に友達連れで行動している人には必ず声を掛けましょう。団体行動では、ちょっと気になる程度じゃ足を停めづらいこともあります。例えば観光している時に気になる土産屋があっても、「少し気になるけど、みんなの足を止めるほどでもないな」と思うことはよくあると思います。少し歩いてから「何かあったの?」と質問されたら「○○があったんだ」と答えるだけで終わってしまうことはよくあります。それでも土産屋から声を掛けられれば、友達含めて足を止めさせることもできるかもしれません。
そうなれば、本の中身を見てもらうチャンスです。
10~30秒程度で本の内容と売りを説明します。その時、相手の表情や仕草で微妙そうな顔をしていれば、別の本を勧めても良いでしょう。とにかく、相手に本を買ってもらうための一押をしましょう。
性癖や情熱で保って、何が書かれていて、どういうところを見て欲しいのかをアピールしましょう。同人誌を書くほどの情熱があれば必ずできると思います。
コミケに参加するたびに思うけど、通り過ぎる人に声を掛けている人はどちらかと言えば少数派なように思います。もう少しアグレッシブに声を掛けても良いのではと思います。あまり喧しくては周りに迷惑かもしれませんが、人を選べばそう騒がしくはならないでしょう。
最初に書いた通り、この記事を書いた目的は同人誌頒布の喜びを知る人が1人でも増えれば嬉しいと思ってそのノウハウをシェアするためです。
元記事の著者の方が書かれている通り、「1冊も売れなかったなら、創作活動の目的は達成できたとは到底言えないだろう」ということは真理かと思います。また、同人誌を初めて作って、初めて頒布したときの喜びはひとしおです。壁サークルに鎮座するレジェンドの中にもコミケでの手渡しに拘る人は一定数いらっしゃるそうですので、その喜びは頒布部数に依らないのでしょう。何とか、その喜びを知る同士が1人でも増えればと思っているので、より沢山本を売ってらっしゃる先駆者がいらっしゃれば、そのノウハウをシェアいただければありがたく思います。
GAFAMに入るために必要なのは基本的には基礎的なアルゴリズムとデータ構造の知識、それらを応用したコーディング能力、システムデザイン知識です。ほぼ全部受験勉強のように体系化されているし対策も出回っているので実際に凄いシステムを作り上げなければならないとか四六時中コーディングしているような人でないと受からないといったことはありません。受験勉強と同じですね。もちろん土日も勉強したりするような技術大好きオタクな人もたくさんいますがそうでなくても入ることは可能です。
基本的にこれらの大企業に入りたい人というのは高学歴の金目当ての人間です。普段からアンテナを張って技術を追いかけているような人は半分もいないでしょう。
ITエンジニアは業務外でも常に勉強し続けなければならないなどという人達は負け組です。もちろん勉強をしたいならすれば良いですがそれは趣味ですよね。業務に必要な知識の吸収は業務中に行う。要領の良い人達は皆そうしています。業務外で勉強するオタク気質な人であっても業務とあまり関係のない勉強をすることの方が多いでしょう。
業務外で勉強を続けなければならないと思い込んで業界の裾野を狭めるような負け組のITエンジニアの人達には黙っていてもらいたいものです。
ふつうのエンジニアは世間一般ではかなり勉強している
実は、ふつうのエンジニアは一般的にはかなり勉強している方にあたる。土日にコードを書いたり技術書を読んだり、仕事終わりに技術書を読むとか、そういうことは上澄みのエンジニアじゃなくてもしているというのが当然なので、当然みんなしているものだと思っている。とても怠けている人でもやっているのでそういうもんだと思っている。それに未経験エンジニアの中にはあまり技術に興味がない人も多く、働き方や収入などの面に惹かれているように見える。
エンジニアはわざわざ自分の休みをつかって学習する行為をべつに地獄だとは思っていないし、身の回りの人はみんなやっているから「誰でもやっているふつうのこと」だと思っている。認識に大きなズレがある。
「勉強を勉強と思っていないだけだ」という人が多いですが間違えています。この発言の裏にはみんな土日も勉強をしているという思い込みがあります。それがそもそもの間違いなのです。土日も技術的な勉強をしている人は多くないです。する必要がないからです。もちろんする人もいますが多数派ではないです。
「オレの知っているGAFAMエンジニアはみんな常に勉強している」と言う人も多いですが、それはあなたの知っている人達が日本人しかいないが故のサンプリングバイアスです。日本は割と最近までIT技術者は高給な職と見なされていませんでした。そんな業界には物好きなオタクしか集まりません。日本人技術者にはオタクしかいないので、そういう人達が技術の勉強が好きなのは当然ですね。一方、IT技術者が高給とされる社会ではオタク以外も集まります。金目当ての高学歴ですね。こういうオタクでない人達が普段から業務に関係のない技術の勉強をするかというとしない人も多いわけです。日本で高給とされる業界にいる人達のことを考えてみると分かりやすいかもしれないですね。
土日にコードを書いたり技術書を読んだり、仕事終わりに技術書を読むとか、そういうことは上澄みのエンジニアじゃなくてもしているというのが当然なので
これをやってる側の人間だけど、当然とは思っていなかった。
本当にみんなやってるの?
具体的に未経験でも光るものがあったとか、そういうところをもうちょっと知りたい。
「やってくれそうだった」「期待できそうだった」くらいのレベルでいいんで。
採用が困難な時期に妥協して未経験エンジニアを採用したけど、それが失敗だった。なぜ失敗なのかを話していきたい。
ただし未経験エンジニアといってもいろいろあって、子どものころからずっと学習してきたような人はただ実務が未経験なだけというように考えている。こういう人はあまり未経験と考えない。
自分への戒めもこめて。
失敗点
リターンがほぼ回収できない
エンジニアの生産性の違いが10倍、100倍になることは別におかしいことではない。
そのため、未経験エンジニアに費やした時間がリターンを産むまでにとてつもない時間がかかる。
たとえば、生産性100/営業日の人が10営業日かけて教えるのなら、教えられた人は、1000の生産をしなければ当然マイナスになる。これは泣こうが喚こうが世界の理なのでここは変えられない。
1000の生産は、生産性1/営業日であれば4年2ヶ月かかる。つまり生産性100倍の人を用いる場合は、教えられた人の基礎能力を4倍にしてようやく1年でペイ、半年でペイさせるためには8倍の能力向上が必要になるといえる。20営業日かけた場合は必要な生産性がさらに倍になる(1年でペイさせるには8倍の能力向上が必要)。1年の営業日を240日としている。
つまり能力1の未経験状態から1年で4倍の能力向上(当社比)が見込めない未経験エンジニアはだいたいその会社には不要ということになる。
それから未経験エンジニア以外も成長はするので、他のエンジニアの能力向上の速度がたとえば年間で2倍になるとするなら、10営業日を教育に使うと考えるとそうしたエンジニアが102%になる成長機会を奪ったことになり、これは機会損失という【(2^(1/(20*12)))^10】。これによりもともと1年後に生産性200/営業日になるはずだったエンジニアの能力が194/営業日になることになる。この差は大きい。
すべてを教えなければいけない
彼らは基本的に「すべてを教えてもらおう」とする。これによって他の人が疲弊する。どのように考え、何をやり、どう仕事をすすめるか、その手がかりを何ももっていないため、何もかも教えなければならなくなる。
未経験といっても新卒とは違うが、新卒の何も経験のなくバックグラウンドのない人を育てるのとほとんど変わらない。一方で放置すればただお金が出ていくだけとなる。
実は、ふつうのエンジニアは一般的にはかなり勉強している方にあたる。土日にコードを書いたり技術書を読んだり、仕事終わりに技術書を読むとか、そういうことは上澄みのエンジニアじゃなくてもしているというのが当然なので、当然みんなしているものだと思っている。とても怠けている人でもやっているのでそういうもんだと思っている。それに未経験エンジニアの中にはあまり技術に興味がない人も多く、働き方や収入などの面に惹かれているように見える。
エンジニアはわざわざ自分の休みをつかって学習する行為をべつに地獄だとは思っていないし、身の回りの人はみんなやっているから「誰でもやっているふつうのこと」だと思っている。認識に大きなズレがある。
仮に土日や平日終わりに勉強することも仕事だと考えると、エンジニアの給料は割に合わなくてかなり低い。地獄になると思う。
チームの空気が悪くなる
チームの他のメンバーはすでに状況を理解している中で、その人のためだけに説明しなければいけない事態が頻発する。これがコストになり、説明する人が「押し付けられた」という感覚を持ちやすい。
失敗しても解雇できない
日本の法律上解雇することができないため、その人を使っていくしかない。つまり失敗したらその失敗は永続し、取り返しのつかない失敗である。
他のエンジニアが辞める
早々に見切ったエンジニア・未経験エンジニアに疲弊したエンジニアから辞めていく。「未経験エンジニアが入れるレベルの会社」になってしまっているので、そもそも全体のレベルが落ちているという証明にもなっている。
「未経験を採用する」という行為は、それだけ既存の人員を舐めてると言ってもいいと思う。「誰にでもできるかんたんな仕事です!」と。
未経験エンジニアの人も仕事中に時間を費やして成果を出そうとしているが、成果がほとんど出ない。そして遅い。しょうがない部分もある。ただ、時間を使っているので「仕事をやっている」というふうに考えられてしまう。時間を使えば体力も使うから、疲れもするし、それは当然だと思う。
ただ、後始末されていることが理解できない。後始末されているということを言ってもわからない。「そんなことはない」「自分は仕事をしている」と思っている。仕事ができていないことがわかっていない。認めることは自己肯定感を破壊することに繋がるからだろう。「100営業日かけたのに生産は5」という事実を認識してもらえない。自分を過大評価しがち、人を過小評価しがちである。
彼らも別に努力していないわけではないので、「もっとやれ」と言ってもしょうがないし、結局そのやり方もわからない。「努力していないわけではない」というのも肝だ。頑張っているのはわかる。
書類上は、人員 +1 ということになっているため、生産性向上が求められる。たとえば3人チームに人員として投入された場合、単純に133%の生産性が期待される。これが正常な人間の感覚なのだからしょうがない。そのため、未経験だからとざっくり差し引いても、人員を追加したらまさかチームが70%の生産性になるとは思われない。3+1は2になる。
もちろんいいこともある
一応、ダメなことばかりじゃなかった。たとえば未経験エンジニアは会社の下限という明確なバロメーターなので、社内に「この人よりも生産性が低くなるのはまずい」という圧倒的な焦燥感をもたらすことができた。
逆に言えば、その未経験エンジニアの人さえ能力向上すれば、他のエンジニアは自動的に能力向上していく。自分の存在価値・生きている意味・今までやってきたこと・これまでの努力が懸かっているからだ。
ある意味、超優秀な未経験エンジニアを採用することはそれだけで引き締めになるとは思う。
なぜ採用したのか?
根本的には未経験エンジニアを採用することに決めた自分の無能さに原因がある
採用のときにそれを見抜けなかった自分が100%悪い。そのため、基本的には自分の能力不足が招いたことだと思っている。
もともと未経験エンジニアをとるつもりはなかった。でも、本当に全くエンジニアが採用できないということで優秀そうな未経験エンジニアを採用することになった。
これが浅はかな考えというか、未経験エンジニアというのは2〜3年目レベルのエンジニアとは違う。この差を軽く見ていた。「すぐに稼働できるようになるだろう」と、自分や自分の周りのエンジニアの能力を侮っていた。ある程度できるようになると、距離感がおかしくなってくるのかもしれない。実際には大きな隔たりがある。
これが分かってるのは有能。
ポンコツの非エンジニア(肩書はエンジニア)は全員が生産性が0.5倍であるべきと思っていて、それが仕事だと思っている
採用が困難な時期に妥協して未経験エンジニアを採用したけど、それが失敗だった。なぜ失敗なのかを話していきたい。
ただし未経験エンジニアといってもいろいろあって、子どものころからずっと学習してきたような人はただ実務が未経験なだけというように考えている。こういう人はあまり未経験と考えない。
自分への戒めもこめて。
失敗点
リターンがほぼ回収できない
エンジニアの生産性の違いが10倍、100倍になることは別におかしいことではない。
そのため、未経験エンジニアに費やした時間がリターンを産むまでにとてつもない時間がかかる。
たとえば、生産性100/営業日の人が10営業日かけて教えるのなら、教えられた人は、1000の生産をしなければ当然マイナスになる。これは泣こうが喚こうが世界の理なのでここは変えられない。
1000の生産は、生産性1/営業日であれば4年2ヶ月かかる。つまり生産性100倍の人を用いる場合は、教えられた人の基礎能力を4倍にしてようやく1年でペイ、半年でペイさせるためには8倍の能力向上が必要になるといえる。20営業日かけた場合は必要な生産性がさらに倍になる(1年でペイさせるには8倍の能力向上が必要)。1年の営業日を240日としている。
つまり能力1の未経験状態から1年で4倍の能力向上(当社比)が見込めない未経験エンジニアはだいたいその会社には不要ということになる。
それから未経験エンジニア以外も成長はするので、他のエンジニアの能力向上の速度がたとえば年間で2倍になるとするなら、10営業日を教育に使うと考えるとそうしたエンジニアが102%になる成長機会を奪ったことになり、これは機会損失という【(2^(1/(20*12)))^10】。これによりもともと1年後に生産性200/営業日になるはずだったエンジニアの能力が194/営業日になることになる。この差は大きい。
すべてを教えなければいけない
彼らは基本的に「すべてを教えてもらおう」とする。これによって他の人が疲弊する。どのように考え、何をやり、どう仕事をすすめるか、その手がかりを何ももっていないため、何もかも教えなければならなくなる。
未経験といっても新卒とは違うが、新卒の何も経験のなくバックグラウンドのない人を育てるのとほとんど変わらない。一方で放置すればただお金が出ていくだけとなる。
実は、ふつうのエンジニアは一般的にはかなり勉強している方にあたる。土日にコードを書いたり技術書を読んだり、仕事終わりに技術書を読むとか、そういうことは上澄みのエンジニアじゃなくてもしているというのが当然なので、当然みんなしているものだと思っている。とても怠けている人でもやっているのでそういうもんだと思っている。それに未経験エンジニアの中にはあまり技術に興味がない人も多く、働き方や収入などの面に惹かれているように見える。
エンジニアはわざわざ自分の休みをつかって学習する行為をべつに地獄だとは思っていないし、身の回りの人はみんなやっているから「誰でもやっているふつうのこと」だと思っている。認識に大きなズレがある。
仮に土日や平日終わりに勉強することも仕事だと考えると、エンジニアの給料は割に合わなくてかなり低い。地獄になると思う。
チームの空気が悪くなる
チームの他のメンバーはすでに状況を理解している中で、その人のためだけに説明しなければいけない事態が頻発する。これがコストになり、説明する人が「押し付けられた」という感覚を持ちやすい。
失敗しても解雇できない
日本の法律上解雇することができないため、その人を使っていくしかない。つまり失敗したらその失敗は永続し、取り返しのつかない失敗である。
他のエンジニアが辞める
早々に見切ったエンジニア・未経験エンジニアに疲弊したエンジニアから辞めていく。「未経験エンジニアが入れるレベルの会社」になってしまっているので、そもそも全体のレベルが落ちているという証明にもなっている。
「未経験を採用する」という行為は、それだけ既存の人員を舐めてると言ってもいいと思う。「誰にでもできるかんたんな仕事です!」と。
未経験エンジニアの人も仕事中に時間を費やして成果を出そうとしているが、成果がほとんど出ない。そして遅い。しょうがない部分もある。ただ、時間を使っているので「仕事をやっている」というふうに考えられてしまう。時間を使えば体力も使うから、疲れもするし、それは当然だと思う。
ただ、後始末されていることが理解できない。後始末されているということを言ってもわからない。「そんなことはない」「自分は仕事をしている」と思っている。仕事ができていないことがわかっていない。認めることは自己肯定感を破壊することに繋がるからだろう。「100営業日かけたのに生産は5」という事実を認識してもらえない。自分を過大評価しがち、人を過小評価しがちである。
彼らも別に努力していないわけではないので、「もっとやれ」と言ってもしょうがないし、結局そのやり方もわからない。「努力していないわけではない」というのも肝だ。頑張っているのはわかる。
書類上は、人員 +1 ということになっているため、生産性向上が求められる。たとえば3人チームに人員として投入された場合、単純に133%の生産性が期待される。これが正常な人間の感覚なのだからしょうがない。そのため、未経験だからとざっくり差し引いても、人員を追加したらまさかチームが70%の生産性になるとは思われない。3+1は2になる。
もちろんいいこともある
一応、ダメなことばかりじゃなかった。たとえば未経験エンジニアは会社の下限という明確なバロメーターなので、社内に「この人よりも生産性が低くなるのはまずい」という圧倒的な焦燥感をもたらすことができた。
逆に言えば、その未経験エンジニアの人さえ能力向上すれば、他のエンジニアは自動的に能力向上していく。自分の存在価値・生きている意味・今までやってきたこと・これまでの努力が懸かっているからだ。
ある意味、超優秀な未経験エンジニアを採用することはそれだけで引き締めになるとは思う。
なぜ採用したのか?
根本的には未経験エンジニアを採用することに決めた自分の無能さに原因がある
採用のときにそれを見抜けなかった自分が100%悪い。そのため、基本的には自分の能力不足が招いたことだと思っている。
もともと未経験エンジニアをとるつもりはなかった。でも、本当に全くエンジニアが採用できないということで優秀そうな未経験エンジニアを採用することになった。
これが浅はかな考えというか、未経験エンジニアというのは2〜3年目レベルのエンジニアとは違う。この差を軽く見ていた。「すぐに稼働できるようになるだろう」と、自分や自分の周りのエンジニアの能力を侮っていた。ある程度できるようになると、距離感がおかしくなってくるのかもしれない。実際には大きな隔たりがある。