ver. 0.01 初稿 20190513 昼
ver. 0.02 みだし修正 20190513 午後
ver. 0.03 日付補足 20190514 夕
ver. 0.04 見出し追記 20190514 夜
ver. 0.05 僕の先生　追記 20190516
ver. 0.06 プログラマだったら 20190517

http://b.hatena.ne.jp/guide/bbutton

IT管理職45歳定年説!?

September 14, 2019, 7:57 am

プログラマ35歳定年説

35歳プログラマ定年説というのがあった。今でも言われてるのかな？35歳くらいになったらプログラマとしてやっていけない。チームを管理して行かないとダメ！ってやつ。
キャリアパスとして早くプログラマを離れてシステムエンジニアやプロジェクトマネージャーになることがIT技術者として一人前というのは、IT後進国:日本に顕著に表れてる悪い風潮だと思う。そもそもプログラマを3年くらいやれば自然に管理する仕事もやるわけで、そういう意味で管理職になれない人なんていないはずでしょ？

45歳以上の管理職リストラブーム

でも最近は少しずつというか一気に変わってきたのかもしれない。
企業も気づいてきたわけです。口だけの管理者より、手を動かせるエンジニアが必要だって！
結果、大企業を中心に口だけのフェイクIT技術者が首を切られている。45歳以上の管理職はリストラだって。
今までは管理職になるということで：
- 自分のIT技術者としての技術力の無さを隠せる
- 隠せる上に地位も給料もベター
- 技術的な知識は一般論レベルの抽象的なものでＯＫ
- 基本的に一般論を言ってそれらしく演じていればよし

つまり管理職というのは実力のないフェイクIT技術者にとっては格好の隠れ蓑だったわけです。マネージメントといっても基本進捗管理とその報告だけで、プロジェクトの進捗はプログラマ任せなわけだから。
こうやって技術から逃げて格好だけでいい思いをしていた人たちがどんどんリストラされているんだと思います。ある意味必然ですよ。

これから先

日本におけるIT技術者のキャリアパスを考えると、こういったフェイクIT技術者は35-45歳にはもっといるかもしれない。1,2年プログラマを経験後、マネージメントという名の進捗管理と雑用業務へ・・・って人

今までプログラマがIT土方と理不尽に馬鹿にされていた風潮を破壊すべく、一般論を言うだけで高い給料をもらってるフェイクIT技術者はどんどんいなくなるべき。
リストラが加速して早く本物のエンジニアが地位的にも給料的にも報われる、IT先進国:米国のような社会が日本にもやって来ることを願っています。

「[翻訳]あなたがプログラミングに向いていない10のサイン」を確かめた

June 1, 2019, 5:28 pm

[翻訳]あなたがプログラミングに向いていない10のサイン
https://qiita.com/hareku/items/4bfc48e23e83e0d300f3

拝見して、確かにと感じた。

日本語だけだと誤解しているかもしれず心配。
翻訳がいいとか、悪いとかがきになるのではなく、
英語でどういう単語で言っているかで、日本語より英語の方がわかるかもしれず、
英語も読んで、英単語を調べて確認中。

10 Signs You Will Suck at Programming, Jonathan Bluks
https://blog.usejournal.com/10-signs-you-will-suck-at-programming-5497a6a52c5c

1. 好奇心の欠如 (Lack of curiosity)

curiosity
https://eigogen.com/word/curiosity/

cur- : L.curare = to take care of(気をつける, 世話をする

https://dictionary.cambridge.org/dictionary/english/curious

mainly uk strange and unusual:

ハリーポッターで出てくる。
ukの方にこの意味でcurousと言われたことがある気がする。間違いない。

2. 自律性と機知の欠如(Lack of autonomy and resourcefulness)

autonomy
https://eigogen.com/word/autonomy/

nom- : Gk.nomos = 管理

resourcefulness
臨機応変
https://sanabo.com/words/archives/1999/07/post_519.html

resourceful
https://eigogen.com/word/resourceful/

surg-, sur- : L.surgere = to rise(上がる), get up（起き上がる）

機知とは、臨機応変のことで、臨機応変であるためには、資源が豊富でないと駄目なんだろう。

読んだ本の数とか、resourcefulである。間違いない。

3. 問題に直面しても粘り強さが無い(Lack of persistence in the face of a problem)

persistence

persist
https://eigogen.com/word/persist/

sist-, stitus-, st-, struct- : L.sistere = to cause to stand(立てる); L.stare = to stand(立つ)

頑強だと言われる。打たれ強い。間違いない。

~~人を打って問題を解決したことにする人は、ここで脱落。~~

4. 問題解決に成功した気持ちはない(No feeling of success in overcoming a problem)

overcoming

http://www.wakaru-english.info/overtakeとovercomeの違い.html

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

失敗してもいいと言われ、何度失敗しても、人のやらないことをし続けている。

１万回に１回成功することがある。

経験則：１万人か１０万人に１人は同じ意見の人が現れる
https://qiita.com/kaizen_nagoya/items/ebb04e35d408f9d388ad

成功体験が一度もないことは辛い。
20歳代で、懸賞論文投稿など１０年間、落選しつづけた。
30歳頃、初めてあるところで第二席になった。上はいたけど、１０年つづけてそれが無かったら折れていたかも。

今でも、１０年間は評価されなくても続けていけるのはこの時の経験のおかげ。間違いない。

~~人を打って問題を成功にしたことにする人は、ここで脱落。~~

5. 学習と理解に焦る(Impatient about learning and understanding)

impatient
https://eigogen.com/word/impatient/

path-, pass- : Gk.pathein = to suffer(苦しむ)

上記に書いた。１０年続けるのが経験則。１年、２年で成果がでなくてめげちゃ駄目。間違いない。

6. 思考に飽きたり疲れたりする(Getting bored/tired from thinking)

bore
https://gogen-ejd.info/bore/

ゲルマン祖語 burona（穴を開ける）

amazon 殿堂入りNo1レビュアーになるまで
https://qiita.com/kaizen_nagoya/items/83259d18921ce75a91f4

3000冊登録あたりまで、北海道立工業試験場の掘武司さんが、書いたものを評価してくれた。それがなかったら、飽きたか、諦めたかもしれない。感謝。間違いない。

7. 自分のことを考えられない(Inability to think for yourself)

think for (oneself)
https://idioms.thefreedictionary.com/think+for+myself

To have opinions or make decisions without letting other people dictate to or influence oneself.

自分のことしか考えられない。他の人の意見は、自分と同じ意見の人を見つけてから。間違いない。

8. 堅く、狭く、そして無秩序な考え(Rigid, narrow and/or disorganized thinking)

rigid
https://eigogen.com/word/rigid/

L.regere = to rule, guide(支配する, 統治する);

disorganized
https://kotobank.jp/ejword/disorganize

柔らかく、広く、体系的な考え方が、汎用的な制御理論のあり方。間違いない。

9. 複数の答えの間の「良い」と「悪い」の連続性に気付かず、「正しい」答えを望んでいる(Needing the “right” answer instead of recognizing a spectrum of “good” and “bad” answers)

仮説・検証(93) 科学四分類と算譜
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

正しいか正しくないかを計算するのは論理科学だけ、物理化学、生命科学、社会科学では、正しいという概念は役に立たない。良し悪しが社会科学だが、立場が違えば解は逆転する。間違いない。

10 細部に注意を払っていない(Not paying careful attention to details)

細部から記述してもよい構造を作れるのが設計者。間違いない。

文書履歴(document history)

ver. 0.01 初稿 20190601 午後
ver. 0.02 １０項目記載 20190601 夜
ver. 0.03 見出しにしないと数字が増加しない 20190601 夜中
ver. 0.04 脱落する人を想定。消すかも。20190601 真夜中
ver. 0.05 消す 20190902 朝

 https://b.hatena.ne.jp/guide/bbutton

プログラマが落ち入らない方が良さそうな依存症群調べ(一部自己対策含む)

October 25, 2019, 6:36 pm

依存症と言っても悪いことだけとは限らない。

良い依存症も含めて調べ、落ち入ってもよい依存症と、落ち入らない方が良さそうな依存症を列記してみる。

犯罪分析、人間関係分析はこの記事の目的外です。一部の依存症は記述していません。ごめんなさい。

Qiitaに書き続けているのもネット依存症の一つかも。

網(net)

プログラマが陥り易い依存症の３つのうちの一つかも。もう２つは、遊興競技と過食。

プログラム

GitHub, dockerなどに創ったソースコードを上げたり、上がったソースコードやスクリプトを直したりするのは、依存症かもしれない。

プログラマ本来業務であるが、お金にならないことをしている場合には落ち入らない方がよい依存症かもしれない。
お金になったとしても、仕事依存症のように、依存症の一種かもしれない。

SNS

line, twitter, mastodon, facebookなど対話的なやりとりを毎日するだけなら依存症とは言わない。

line, twitter, mastodon, facebook, instagramなどでのやりとりで

1) 何かが前に進んだ
2) 新しいものを創った
3) 誤りや無駄が省けた

のであれば、生産活動であり負ではない。

成果は、書いた時点で評価できる事項もあれば、１日後、１ヶ月後、１年後、１０年後、１００年後でないと評価できない事項もあるかもしれない。

WEB

Youtube, sound cloud, ブログなどで、対話式でなく、ひたすらWEBにデータを上げ続けるのも依存症と呼べるだろう。

掲載している内容によって正負が決まるかもしれない。

遊興競技(game)

時間(time)

もし、１日のうち、ゲームを作ったり、評価したりするのが仕事でないのに、ゲームをしている時間が仕事時間よりも長ければ、ゲーム依存症だろう。

週で集計してゲームしている時間が、仕事時間より長ければ、ゲーム依存症の可能性がある。

ただ、仕事時間よりゲームしている時間が長いプログラマは、ゲームプログラムができるはず。本業または許可を得た副業としてゲームプログラムすればよい。
今なら、働き方改革で、多くのIT企業で副業としてのゲームプログラミングを許可してくれるはず。

PlayStationが発売になったころ、開発キットが10万円くらいで出た時に、ゲームを作ったソフトウェア企業がたくさんあった。今のIT技術を生かしたゲームや、ゲームで使ったキャラの使い回しなど、本業でも役立つことがあって、会社からゲームの一部を買ってもらえるかもしれない。

種類(type)

ネット、パッケージなどの媒体の種類。
スマフォ、ゲーム機、PCなどの機材の種類。
有償、無償などの費用の種類により依存症の状態が違うかもしれない。

ネットでは有償、無償の差が課題かも。

費用(cost)

ゲーム依存症でもお金がかからなければ、負であるとは限らない。
小学生の高学年で、携帯電話を持ち始めて、月に１万円以上使うのが２月以上続いたら、負のゲーム依存症として認定してもいいかもしれない。ただし、プログラミングで月１万円以上かせいでいれば、負とは限らない。

賭け事(gamble)

遊興競技(game)の区分との違いは、お金が中心かどうか。
遊興競技(game)であっても、例えば、パチンコ、トランプ、麻雀などでお金のやりとりが主たる目的である場合には、賭け事(gamble)に分類します。

運転(driving)

自動車(motor car)、二輪(motor cycle)
乗り物を運転する依存症があるかもしれない。

通勤に日に数時間運転し、週末に日に八時間運転するくらいなら依存症じゃないかもしれない。
トラック、バス、タクシーの運転手で、日に１２時間以上運転するのも依存症じゃないかもしれない。

依存症であるかどうかは、医学的な基準に基づくのがいいだろう。

運動(sport)

運動競技の選手などで、運動しないといられない依存症があるかも。
運動が仕事であれば、仕事依存症。

摂取(feeding)

酒(alcohol)

アルコール飲料を、過剰に摂取しつづけ、摂取しない日がないのは依存症かもしれない。

煙草(nicotine)

たばこ依存症。禁煙が厳しくなり、多数派である業種は少なくなりつつある。

薬物(drag)

合法な薬物か違法な薬物かは別にして、食物以外のものを過剰に摂取しつづけるのは依存症かもしれない。

過食(overeating)

暴飲暴食だけでなく、夜８時以降の食事等も含む。

夜、プログラムを組みながら、キャラメルコーンを食べ、コーラを飲んでいたら、
毎年２Kgづつ太った。20歳から10年間で20Kg。
肥満生脂肪肝で入院し、減量に成功。

いろいろな過食の類型は考えられる。

減量(loss weight)

減量に依存する場合もあるらしい。

購買(shopping)

平均月収より購買額が連続して１年以上継続したら依存症かもしれません。
期間が短くても、年収以上の購買をすれば、その時点で依存症と判断してもいいかもしれません。
amazonなどのネット通販依存症は、ネット依存症にも分類できるかも。

ここでは、医学的な依存症ではなく、社会的な依存症を検討しています。

窃盗(stealing)

犯罪依存症の一種。

迷惑行為(harassment)

仕事場（Workplace harassment）などなど。
依存症だと考えると習慣性を断つ方法が検討できるかも。

人関係(human relation)

家庭内暴力(Domestic Violence), 付きまとい(stalking)、恋愛、登場人物(character)など。
詳細は省略します。

定義(definition)

依存症とは？

大石クリニック
http://www.ohishi-clinic.or.jp/izon.html

物質、プロセス、人間関係の３つに分類している。

依存症には主に 2種類あります

依存症についてもっと知りたい方へ　厚生労働省
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000149274.html

「物質への依存」について：
アルコールや薬物といった精神に依存する物質を原因とする依存症状のことを指します。
依存性のある物質の摂取を繰り返すことによって、以前と同じ量や回数では満足できなくなり、次第に使う量や回数が増えていき、使い続けなければ気が済まなくなり、自分でもコントロールできなくなってしまいます（一部の物質依存では使う量が増えないこともあります）。
「プロセスへの依存」について
物質ではなく特定の行為や過程に必要以上に熱中し、のめりこんでしまう症状のことを指します。

社会通念上の分類(classification)

毎日、３時間以上やらないと気が済まないたぐいのことは、依存症の可能性あり。やらない日があれば依存症じゃないと思う。医療上の区分ではなく、社会通念上の区分です。
１時間程度なら気分転換法の一種だと理解。

　依存症と愛好家の境界(borderline)

天文、音響、無線、遊興競技、自動車・二輪車、鉄道など、愛好家の方々の行動が、依存症なのかどうかの医療的な判定は存じ上げない。
社会通念上の区分として、絶対毎日やらなければいけないと思い込んで、実行している場合に、その度合いによるかも。
自動車・二輪車のように、通勤、通学で３時間程度利用していることは生活の必須行為に含む事ができ、依存症とは言わない可能性がある。電車で行った方が便利で、時間も費用も安いのに、わざわざ両側に駐車場を借りて、車に乗っているようだと依存症の可能性があるかもかもかも。

対策(countermeasures)

依存症対策　厚生労働省
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000070789.html

個人的な対策案

遊興競技(game)

ゲームをするより作る作る側に回のが根本対策の一つ。ゲームに関わる時間でお金が稼げればよい。仕事で、ゲームを作り、その試験のためにゲームをするのなら、お金がもらえる。

2.午前中はゲームをしない
プログラマになっても、ついつい試験以外のゲームをしてしまう。そんな時にゲーム依存症にならないようにしていたことに、午前中はゲームをしないという自己規則だ。午前中にゲームをしなければ、１日のうち、ゲームをしている時間が最長になる可能性は低くなる。また、午前中に１日分のプログラムをしようとすると、仕事の密度も高くなる。ついつい午後もプログラムしていることがある。

過食(overeating)

夜はできるだけ８時までに食事をする
よく噛んで食べる（ごはんは３０回噛む）
間食はしない
麺類の汁は全部飲まない（栄養士さんからの指導：ここから上全部）
スポーツドリンクは飲まない（医師からの指導）
毎日体重を計る。

分類(category)

仕事依存症
・プログラミング
・運転
・運動
・仕事場（Workplace harassment）

遊興競技(game)依存症
・賭け事(gamble)

網(net)依存症
・SNS
・Web
・プログラミング
・購買

金銭依存症
・購買
・賭け事(gamble)
・窃盗

摂取依存症
・薬物
・ニコチン
・酒
・過食
・減量

人間関係依存症
・付け回し(stalking)
・家庭内暴力(Domestic Violence
・恋愛
・登場人物(character)

犯罪依存症
・窃盗
・家庭内暴力(Domestic Violence)
・違法賭け事(gamble)
・違法薬品
・仕事場（Workplace harassment）

参考資料(reference)

「GAFA断ち」
https://qiita.com/kaizen_nagoya/items/5fb95a9df523721377f6

プログラマが知っているとよい色使い(安全色)とカラーユニバーサルデザイン
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

文書履歴(document history)

ver. 0.01 初稿 20190623
ver. 0.02 分類追記 20190625 午前
ver. 0.03 社会通念上の分類, 依存症と愛好家の境界　追記　20190625 午後
ver. 0.04 補足 20190813
ver. 0.05 加筆 20191026

もし今後プログラムを１行も書かなくなったとしても、あんなプログラマになりたいと思う人が一人でもいる限りプログラマとして生きていると定義する。

July 3, 2019, 6:07 am

「今後プログラムを１行も書かなくなったとしても、あんなプログラマになりたいと思う人が一人でもいる限りプログラマとして生きていると定義する。」という題を決めて文章を書き始める。

この記述は、ある学会の幕間に、あんなプログラマになりたいという人物像に登場したという話を聞いたことを発端として書き始める。

そう人が亡くなっても、人の心に生き続ける限り、その人が生きるという。

プログラマの書いたソースコードが生き続ける限り、そのプログラマが生き続けるという仮説をたてよう。

それだけでは面白くないかもしれない。

あんなプログラマになりたいと思う人が一人でもいる限りプログラマとして生きているという定義も容認するのはどうだろう。

もう１種類くらいあってもいいかもしれない。

また今度。

少し表現が変わった。

やっぱ、ソースコードが生きてりゃいいよね。

仮説・検証（116）「今日死ぬとしたら」日本語が不得意なプログラマが話をする

October 8, 2019, 6:40 pm

今日死ぬとして、何を伝えておきたいか。

本当に大切なこと以外をいくら話しても、何も伝わらない。

しゃべりが上手な人ならともかく。

日本語をしゃべりたくないからプログラマしている。
日本語で何か意思疎通できるつもりは全くない。
講演、学会発表などを行うときだけでなく。
人と話をするときも。

いちごいちえ　という言葉があるらしい。

意味はよく知らない。
漢字もよくわかっていない。
今日会ったから話せることを話す。
そんな意味を含めてもいいかも。

与件分析者(data analyst)

２０代のころ、何度懸賞論文などに出しても入選しなかった。

プログラムを組めるようになって、データ解析はじめたら、すぐに２席に入賞した。
人ができないことをしたことが分かれば、分かってくれる人もいる。
プログラムやデータに語らせれば。

その意味では、自分はデータサイエンティストなのかもしれない。

理工学研究科で、理論家ではなく、実践派だから理学博士でなく工学博士を選択している。

データサイエンティストというより、与件分析者(data analyst)を自称しよう。
プログラム自体よりもデータ解析の方が先に評価されているから。

返事(response)

ときどき日本語でいただくご意見(comment)で、全く返事をしないことがあります。
英語でいただくコメントでも、１割以上は無反応かのように見えるかもしれません。

返事をする言語を持たないからかもしれません。

何かのデータを示していただくか、
プログラミング言語で書いていただければ、
コンパイルしたり、走らせたりして確かめられ、お返事できるかもしれません。

よろしくお願いします。

動画(movie)

自分が同志だと思っている三人を引用する。

最後の講義『みうらじゅん』「もし、今日が最後なら何を伝えたいか！」
~~https://www.youtube.com/watch?v=oKD-s5PXdYA~~

YouTubeから消えていました。下記からごらんください。

https://www.nhk-ondemand.jp/goods/G2019095850SA000/

2017/03/15 早野龍五教授最終講義「CERNと20年福島と6年 - 311号室を去るにあたって」
https://www.youtube.com/watch?v=utje4ctbuAQ

京都大学2016年度退職教員最終講義　阿辻哲次（人間・環境学研究科教授）「電子時代の漢字研究」2017年3月15日
https://www.youtube.com/watch?v=A3FOIkyep2I

「今昔文字鏡を使えば」という発言がある。資料はこちら。
文字鏡フォント
https://qiita.com/kaizen_nagoya/items/64c2ff25271ea8ebf2b0

参考資料（reference)

ジャクリーヌ・ベルント先生最終講義② マンガ研究の私～この20年を振り返って～　京都精華大学大学院マンガ研究科

自己参考資料(self reference)

成功体験は語っても、成功体験に頼らないために。清水吉男・田中伸明
https://qiita.com/kaizen_nagoya/items/d32adfaf7b2568bfd9d2

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

意味の集合論
https://qiita.com/kaizen_nagoya/items/9c87d0d4f0b0b70cf4af

上のみうらじゅん~~YouTube~~ 動画の「空あり」の意味も理解できるように。

文書履歴（document history)

ver. 0.01 初稿　20190704　朝飯前
ver. 0.02 データサイエンティスト　追記　20190704 朝食後
ver. 0.03 参考資料、データ追記　20190704 午前
ver. 0.04 みだし追加・文章補足 20190724
ver. 0.05 最後の講義『みうらじゅん』「もし、今日が最後なら何を伝えたいか！」,
早野龍五教授最終講義「CERNと20年福島と6年 - 311号室を去るにあたって」YouTube追記 20190806
ver. 0.06 京都大学最終講義　阿辻哲次（人間・環境学研究科教授）「電子時代の漢字研究」, ジャクリーヌ・ベルント先生最終講義マンガ研究の私～この20年を振り返って～　京都精華大学大学院マンガ研究科 20190807
ver. 0.07 文字鏡フォント　記事からのリンクなど。20190826
ver. 0.08 ３人に焦点をあてる。 20190927
ver. 0.09 動画URL補正 20191009午前
ver. 0.10 記述補正 20191009 昼

https://b.hatena.ne.jp/guide/bbutton

仮説・検証（148）プログラマが違和感を感じたときにするとよいこと

August 20, 2019, 10:06 pm

プログラマに限らず、違和感を感じた時に、することを記録する。

違和感は、いつも、至るところで感じる。

人

９割くらいの人に会って話をすると違和感を感じる。

【対策案】
解決方法は、人とは話をしない。
自分の考えたこと、思いついたことを、プログラムするか、記録する。

プログラムすれば、わかってもらえることが半分くらいある。

ああ、その人はどうでもいいことを話ししてて、自分で解決する気が無かったことに気がつく。
そういう人と話しをすることが無駄だったとわかる。

プログラム書かない人とはなるべく話しをしないに限る。

プログラム書いている人と話しをしていると、自分がやっていないことにしばしば気がつく。
あとは、それを真似るか、そのたぐいはその人に任せるかの選択。

仮説・検証（47）プログラマはどれくらい人付き合いしないといけないか
https://qiita.com/search?page=3&q=kaizen_nagoya+人

仮説・検証（7）IT業界に説教は必要か
https://qiita.com/kaizen_nagoya/items/2f088f496d8a66132ec6

建物、設備

人の手が触るところにRが取れていなかったり、
車椅子で移動できないような構造になっていると違和感を感じる。
手すりがなかったり、捉まえるものがない空間があったり。

窓が小さかったり、空気の流れがなかったり。
冷えすぎていたり。
座るところがなかったり。

【対策案】
仮説・検証（24) 高齢者・障害者設計指針(1) 点字ブロック・手すり・階段
https://qiita.com/kaizen_nagoya/items/47e0b3a83c2e250fa80c

をもう少し加筆します。今しばらくお待ちください。

配色

なんだこれはという配色のポスタが貼ってあるところがある。
流石に、最近はヌードポスターなどを貼っているところは少ない。

人肌よりも不安感を与えるような配色のポスタは辞めてほしい。

学会発表だったりしたら最悪。
ちゃんと配色教えようよ。

【対策案】
まず、次の記事を読んでもらう。

プログラマが知っているとよい色使い(安全色)とカラーユニバーサルデザイン
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

組織

組織で違和感を感じなかったのは、アメリカのIT企業に行った時と、電総研に行った時くらい。
それ以外のほとんどの組織には違和感を感じる。

仮説・検証(111) アメリカ留学、アメリカ就職の代わりに行ったこと。行なっていること。
https://qiita.com/kaizen_nagoya/items/9f8e791bd6be3bed34bb

その会社の社訓や、歴史を知ると、納得することも半分くらいはある。
その会社にいる人が、社訓を無視していることがあり、違和感を感じる。

習慣には、過去の遺産で、今の仕事なら改めた方がいいことのような気がすることもある。
個別に、昔話をお聞きするとよいかも。

女性に対する扱いが乱雑だったり、女性が半数近く（４割以上）いないと違和感を感じる。

【対策案】
女性の存在確率を４割以上を目標に

言葉

カタカナ語を連発している文書、発言に遭遇すると違和感を感じる。

英単語でなければ意味が通じないと思ったら英語で話せよ。
その方が全く違和感がない。

日本人だけの会合であっても、記録を取って海外の事務所にも配信するなら英語でもいい。
そっちは違和感を感じない。

日本語で大人になるまで生きてきた人には、英語は違和感を感じることがあっても仕方ない。
その人の人生だから。
そういう人には日本語で説明するのは嫌じゃない。

【対策案】
カタカナ語よりも英単語を使うことを推奨。
あるいは、漢字(English)表記を推奨。
略号(abbreviation)はfull spellingなどを。

まぎらわしい、間違えやすい、行き違いの多い略号worst 10(候補24)
https://qiita.com/kaizen_nagoya/items/0bff5dbb72208053489b

仮説・検証(88)用語の衝突(用語・用例募集中)
https://qiita.com/kaizen_nagoya/items/6a8eb7ffaa45eeb16624

自然言語処理で陥る罠
https://qiita.com/kaizen_nagoya/items/71093310ffc5324f15ff

Windows

Windowsでしか仕事をしていない人を見ると違和感を感じる。
あなたが見ている先のサーバはLinuxだったり、
あなたが利用しているクラウドはLinuxだったりする。

End UserならWindowsだけというのもありだと思う。
複数のOSを使う必要はない。

プログラマでWindowsだけってなによ。
Windowsだって、Unixの影響を受けて発展してきたもの。
源流を知らずに、プログラマしているのに違和感。

【対策案】
Windowsにdocker導入することをまず提案。

docker(19) 言語処理100本ノックをdockerで。python覚えるのに最適。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

docker(18) なぜdockerで機械学習するか書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

違和感を感じた時の行動

1) 横になって寝る
寝付けない時は、自分の好きな動画などを見る。映画館や、コンサートを聞きに行って寝ることも。

仮説・検証(108) 音楽映画で英語勉強（目標100作品）
https://qiita.com/kaizen_nagoya/items/7c37e4502f2f785ab104

2)ジャズ喫茶・図書館に籠る
難しい哲学の本を読むか、量子力学のプログラムを組むか。
その時々。

プログラマが国立国会図書館（本館：永田町）利用:16の関門(FD読めない！)
https://qiita.com/kaizen_nagoya/items/09252fdce118ec9e21aa

国会図書館にFDドライブを
https://qiita.com/kaizen_nagoya/items/44de2ba05e8307b29a98

3) 子供と遊ぶ
自分ちの子供が大きくなったら、近所の子供か、科学館などに行って子供たちに説明したり。
展示会に出展して子供ばかりに説明したり、子供預かり處で子守の手助けしたり。
絵本の読み聞かせや、子供向けのプログラミングの企画もお勧め。

ちょけねこ　たんじょうびのおくりもの
https://qiita.com/kaizen_nagoya/items/fc9675686c229f7a155e

効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

4) ゲームする
ゲーム依存症に要注意。

プログラマが落ち入らない方が良さそうな依存症群調べ
https://qiita.com/kaizen_nagoya/items/4d00b3fc2d9f649e0a18

5) 行動分析をするか、コンパイラ書く。
心理分析は絶対しない。
人の罠にはまっていくだけ。

仮説・検証（34）心理学の本を読むよりはコンパイラ書いた方がよくね
https://qiita.com/kaizen_nagoya/items/fa715732cc148e48880e

番外編

日本にいても、自分を異邦人だと感じる。
アメリカに行った時に、アメリカのIT企業を訪問し、違和感を感じなかった。
就職したいと思った。

日本では、電総研(現在の産総研の一部)に行った時に違和感を感じなかった。

仮説・検証(111) アメリカ留学、アメリカ就職の代わりに行ったこと。行なっていること。
https://qiita.com/kaizen_nagoya/items/9f8e791bd6be3bed34bb

海外に行った時、その国で暮らせるかをまず確認する。

地べたに横になって、その国の土の暖かさを知り、
町を歩いて、道に迷わずに、computer shop, book shop, libraryに行けるかどうか。
そこの品揃えを見て、仕事に必要な機材、書籍が入手できるかどうか。
Wi-Fiなどのネットが繋がるかどうか。

イスラエルと韓国に行った時、町を歩いて、標識、看板がわからずに違和感を感じた。
ちなみに、訪問したことがある国は、韓国、中国、香港、タイ、シンガポール、マレーシア、オーストラリア、インド、イスラエル、南アフリカ、ロシア、フィンランド、スウェーデン、デンマーク、オランダ、ドイツ、フランス、オーストリア、イタリア、スペイン、イギリス、アイスランド、アメリカ、カナダ、メキシコ、ペルー、ブラジルを記憶している。

韓国と日本のIT業界で協力できるかもしれないこと
https://qiita.com/kaizen_nagoya/items/52501f8ee4dc23f595eb

文書履歴(document history)

ver. 0.01 初稿 20190714
ver. 0.02 加筆 20190716　朝
ver. 0.03 docker URL追記 20190716 午前

 https://b.hatena.ne.jp/guide/bbutton

プログラマ:顔を見合わせて会議、テレビ会議、コメント・チャット

July 16, 2019, 4:52 pm

プログラマの意思疎通の方法

ログラマが顔を見合わせて会議をやるか、テレビ会議をするか、コメント・チャットですますか

仮説・検証（48）プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点
https://qiita.com/kaizen_nagoya/items/f322df6978853c708c99

1) GitHub, gitlab, bitbucketなどのissue, wikiなどに追記、注釈(comment)などをする。あるいは、twitter, facebook, slackなどで、chat。追記、注釈(comment)などをする。

2) テレビ会議で、カメラと画面を共有して会議をする。
この場合、一部、音声だけの参加者、chatだけの参加者がいる場合がある。

3) 直接集まって会議をする。
この場合に、一部、遠方でテレビ会議参加者がいる場合がある。

面直無し

ソフトウェアを一緒に作るといっても、部分的な道具に分かれていて、その部分は独立して作ることができる場合、一度も会ったことがなく一緒に仕事をする場合がある。

例えば、VZエディタの移植をした時に、割り込みベクタテーブルを試験する道具は、一度も会ったことがない方から提供を受けて利用した。

VZエディタはソースコードを公開する商用ソフト。
差分は無償で公開してよかった。
ソースコードは、差分も含めて全員で共有できた。
思いのままに変更して、差分を公開すると反応があった。
今のオープンソースでの反応のように。

ソースコードを通じてのやりとりなら、揉めない限り面直はいらない。
いくつもの、制約条件の違いによる分岐(fork)はあったとしても。

仮説・検証(115) VZエディタ移植に当たって実施したことと成果
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

年に１度から３年に１度

VZエディタの移植が動き始めてからは、利用者への配布を兼ねて、東京で会合を持った。
JUG/CP-Mというフリーソフトの配布団体の東京の会合には、３年に１度くらい出ていた。そのメンバが組織してくれて、東京で会合を持った。２０人以上が集まってもらえた。ほぼ全員がNEC。

ネットでは書きづらい感想などは、恥ずかしいという視点と、間違いがあるといけないという観点と、悪意がないのに相手が誤解するといやだという過去の経験などから、面直の方が言いやすいらしい。たしかに、直接言えば、外していたかどうかは直感的にわかることがある。

VZ倶楽部の発行記念パーティでも初めてお会いする方や、３年に１度くらいしかお会いできない人に会えた。IT業界だと、３年経つと、会社がなくなっていたり、会社を移っていたり、存在確認の役にも立つ。

毎年ある行事には、３年に１度は出るとよいというのが経験則か。

VZエディタのように、開発環境DOSの上にVZエディタを使い、optasmのコンパイルスクリプトまで同じであれば、環境の構築に手間はかからない。

Windows, MacOS, Linuxなどの複数のOSで、複数のコンパイラという環境では、環境の構築が容易ではない。

WindowsでAnaconda構築の Qiita記事が、Views自己最高なのも、道具の導入の困難性を物語っている。

同じ環境で作業しない限り、情報の共有は無理。環境の共有ができていないのだから。
githubでソースコードの共有ができても、それぞれの機材に違うソフトウェアが入っていれば、同じ環境の構築はできない。

docker hubに環境をあげておけば、いつでも、どこでも同じ環境で作業できる。

ソースコードと環境の共有が、情報共有の基礎。githubとdockerを使わずに、情報共有は片腹痛い。

仮説・検証（51）公開算譜は機敏だ(open source is agile)GitHub and docker
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e

docker(19) 言語処理100本ノックをdockerで。python覚えるのに最適。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

docker(18) なぜdockerで機械学習するか書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

月に１度から３月に１度

ある会社とOSの開発をしていた時に、試験プログラムとMISRA Cの検査を担当していた。
MISRA Cの検査のためには、一部プログラムを書き換えて、戻るgotoを、進むgotoに書き換えて試験する必要があった。スクリプトを同僚に書いてもらい、受け取ったら、試験のための処理の一部を自動実行して、１日で完了する体制を取った。

そのために、開発途中のソースコードを毎週もらい、順次試験をして、その時点で変更した方がいいところは報告して、場合によっては書き直す候補を提案した。
これらの作業は、すべてネットのメールなどで実行した。

月に１度か３ヶ月に１度、定例会議で会う。もう一方の作業をしている同僚と相手方とは、もう一つ前のOSの開発の際に、CPUの移植にあたって組んでいたため、そちらは面識が深く、この頻度で問題はなかった。こちらの組みも、面識はあったし、やりとりの中で、特に課題はなかった。そのため特別の面談の機会は設けなかった。

仮説・検証（50）作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab

仮説・検証（47）プログラマはどれくらい人付き合いしないといけないか
https://qiita.com/search?page=3&q=kaizen_nagoya+人

仮説・検証（7）IT業界に説教は必要か
https://qiita.com/kaizen_nagoya/items/2f088f496d8a66132ec6

週に１度から３週に１度

毎日、ネットで日報をあげてもらっている仕事の時に、週報は面直にした。
そうはいっても、出張などで出られない人は、３週に１度くらいになる。

日報は、進捗状況や、課題（個人と組織に分けて）をあげてもらうが、
週報は、自分の得意な技術の紹介や、この１週間で調べたことの報告、この１週間で書いたプログラムの報告をしてもらうことにした。

おかげで、いろいろな作業が進んだ。

１０年くらい前には、週報は、その１週間の間に読んだ本（仕事でも仕事以外でも）の紹介をしていたことがある。amazon.co.jpで１万冊感想を上げる目標をたてていた時。

７人の読んだ本を、その週の間に拝見して、読んだ人とは違う視点を感想に書くようにしていたことがある。amazon.co.jpの感想で偏っている理由の一つかも。

仮説・検証(73)プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69

仮説・検証（40）報連相　再考
https://qiita.com/kaizen_nagoya/items/013f2779bd2beba720b7

仮説・検証（116）今日死ぬとしたら　日本語が不得意なプログラマが話をすること
https://qiita.com/kaizen_nagoya/items/61a03864ac6c011e6164

毎日(daily)

組織によっては、朝会、昼会などをするところがあるらしい。
何か、助け合うことがあるならそれもいいとは思う。

実際に、会わないと聞けないことは多い。
言える雰囲気かどうか。

文書履歴(document history)

ver. 0.01 初稿 20190716
ver. 0.02 毎日追記 20190717

https://b.hatena.ne.jp/guide/bbutton

LINEの新機能オープンチャットでプログラマのコミュニティを作ってみた

August 22, 2019, 5:47 am

LINEオープンチャット

いよいよオープンチャットが利用開始になった(^^)
http://official-blog.line.me/ja/archives/79448193.html

早速開設・・・

折角なのでプログラマやエンジニアのみなさんと
コミュニケーションが取れるルームを・・・と思って作ってみました♪♪

目指せ！楽しくて稼げるプログラマー✨
https://line.me/ti/g2/xN5RGD-_b8b3i5W2g-NN2w
※入り方を最後に書いていますので是非最後までお読みください m(＿＿)m

目的

・楽しく働けるプログラマを増やしたい
・稼げるプログラマを増やしたい（搾取されないという意味も含めて）
・何が必要なのかなど、道筋が分かる場所を提供したい
・単純に聞きたいことを聞きたいｗ
・技術的な質問や動向などについても話したりしてみたい
などなど・・・という感じです！(^^)

なぜ？？

なぜ僕にそういう想いがあるのかというと・・・

元々は現在一部上場企業にまでなっているある会社で
サラリーマンプログラマをやっていたのですが、その時は正直社畜でした・・・💦

通勤途中にぶっ倒れたり、うつ手前まで行きましたし
昇進して結構な立場だったのに給料が手取りで15万円とか
ほんとに最初はかなり苦労しました (^_^;)

何とか転職をして、人生を一変させることができましたが
本当に運が良かっただけで
まだまだ暗黒の時代をお過ごしの方も多いでしょうし
プログラマがどうなっていくとどうなるのかなど
将来のことや今後のことを聞きたかったり・知りたかったりする方もいると思います。

学生さんでこれからプログラマ目指そうとしている方や
目指しているけど「実際のところどうなの？？」とか聞きたい方もいると思います。

何か手助けになれることがあればという想いはずっと持っているので
今回オープンチャットで作ってみた次第です！！✨

あっ・・・もちろん、こちらから聞きたいこととかもあるので
色んなプログラマさん・エンジニアさんが入ってくださると嬉しいです！！

入り方（2019/8/22変更）

~~オープンチャットを利用するには以下の手順で進める必要があるとのこと・・・~~
⇒オープンチャットが一般公開されて①～③の手順は要らなくなりました！！
いきなり④からルームにお入りください！！

~~①LINEアプリを最新バージョンにアップデート~~

②OpenChatスタートページを開き、[OpenChatをはじめる]ボタンを押す
https://w.line.me/openchatactivate/

~~③ボタンが緑色になったら、LINEアプリを一度終了し、再起動~~

④こちらからルームに入る
目指せ！楽しくて稼げるプログラマ＆エンジニア✨

最後に

少しでもお役に立てるならと本気で思っているので
興味のある方は是非お待ちしています！(^^)

「自分の経験も役に立てるなら」と思って入ってくださる方も、もちろん大歓迎ですので
どうぞよろしくお願いします！！

未経験からIT事務員にならないための3つのこと

October 3, 2019, 8:49 am

IT事務員とは

IT事務員というのは「契約書の確認」「パートナー会社調整」「依頼事の記帳管理」「データ入力」など
エンジニアやプログラマーとは違い、主に単調な事務作業をするお仕事をする人のことをいいます。
扱う仕事もプログラムとは全くの無縁でエクセルを扱うことが多くエンジニアとしての成長は見込めません。給与は300万程度で市場価値も上がりにくいとも言われています。
近年この「ITエンジニア」と類似していることから事務員を確保する為「IT事務員」といった名称で企業が当人の将来成長を保証しない（実質）形で募集をしているので今回はIT事務員にならない為のポイントを厳選してご紹介します。

未経験からIT事務員にならないための3つのこと

①アポイント確認
エンジニア、プログラマーとしての現場で行う仕事なのか、エクセル等事務的な単調的な仕事なのか面接の段階や面接前にきちんとコンタクトをとりましょう。
企業のホームページに行けばお問い合わせフォームやメールアドレスが記載されているので事前に連絡して確認しましょう。
メールなど返信がなければ電話で直接採用担当に聞いてみるのも良いでしょう。

②募集要項のキーワード確認
OS（Linux,Windows）や言語名(Python、Java)など具体的に募集要項に記載されているか確認しよましょう。
サーバーサイドのエンジニアかプログラマー的な職種で変わりますが、きちんと募集要項に記載されている内容が専門的内容か確認しましょう。わからない単語があればその場でググれ！

③やっぱり資格やポートフォリオが安全！
なんといっても資格やポートフォリオは便利です。というのも資格に関しては取得する間に様々な知識を得ているので非常にアピールになりますし、ポートフォリオはある程度のレベル感がわかるのでこちらもお薦めです。
ただし注意してほしいのは中には資格は勉強チックな感じが否めないので途中で挫折する可能性が高いです。なので個人的には仕事しながらでも1週間で作成できる程度のもので構わないのでポートフォリオを作成することをお勧めします。
中には3カ月程度かけて作る人もいるようですが、大作を作るまでにモチベーションが続かないこともあるでしょう。
ポートフォリオはまず1週間程度がよりベストかと思います。

最後に

未経験の人がきちんと市場価値のあるITエンジニアになる為にルートを間違えないような内容を記載させていただきました。
中にはIT事務員になってしまったという方もいるでしょうが、自分がもしIT事務員になってしまったら働きながら1週間程度でポートフォリオを作り転職活動を速攻でします。
IT事務員であった経歴も「用語には大分慣れました」とか「ベンダーとの調整をたくさんしました」とか「障害の際には大きな損害が生じることがわかったので注意して作業したい」など経験を隅から隅までアピールに変換して転職活動をします。
こちらは今経験が浅い案件にしか携わっていない方にも同様です。
参考になりましたでしょうか。
それではみなさんが最高のエンジニアライフを送れることを願っています。

自分なりのプレゼンの作り方(ゲーム系学生向け)

November 5, 2019, 8:34 pm

■自己紹介

　・愛知県のゲーム系専門学生
　　　　Twitter→https://twitter.com/kyoro1192
　・ドット絵と野球が好きな人間
　・2019東京ゲームショウアマチュア部門最終選考入りした作品(STARROLLの作者の一人)
　　　作品の動画→https://www.youtube.com/watch?v=44JJRmWt9uI
　　　　　　　　　　　　　↑今冬リリース予定↑

〇初めに

　まずはこのような記事に目を通していただきありがとうございます。この記事はあくまで僕個人のプレゼンのやり方なので鵜呑みにせず、参考程度に見ていただけると幸いです。(;・∀・)

■プレゼンとは？

プレゼンは、制限された時間内に伝えたいことを多くの人に伝えるもの！
　企業などでは、自分の企画、開発した商品などを実際に商品化、販売してもらうために、その商品がどういう理由で売れるのかを伝える必要があります。そこで行われるのが主にプレゼンだと私は勝手に思っています。
　そこで、今回はタイトルの通りゲーム系プログラマ向けに、自分なりのプレゼンの作り方を紹介していきます。

■プレゼンの作り方を考える

〇やっちゃいけないこと

１．操作説明

　聞く側にとっては苦痛な時間でしかない。なぜなら、操作説明をされても覚えきれないし、手元にゲームがあってプレイできるわけではないので、基本的には無駄でしかないと僕は思います。(操作性が売りのゲームでは別ですが…)

２．ハードルを上げる

　アドリブでやりますとか言わない。最初に言ってしまうと、「こいつできる奴だ！」と思われるもしくは、「練習してないのかよ。」と、悪いイメージを持たれることが多いのでやめましょう。

３．カンペ朗読会の開催

　これは、一番やっちゃいけないやつかもしれません。明らかにカンペばかり見てしゃべっていると印象も悪いですし、なにより伝えるためのプレゼンなので、できるだけ聞き手のほうを見るようにしましょう！
コツとしては人は見ずに壁のシミなどの他の物を見るといいと思います！僕はプロジェクターのボタンとか見てました。

４．バックミュージックを流す

　「流す人いるの？」って思う方もいると思います。いるんです。流すこと自体は別に悪いことではないと思うのですが、プレゼンより曲を聞いてしまう場合や、曲で声が聞こえないって場合もあるので特に意味がなければ流さないほうがいいでしょう。

５．スライドの背景が派手

　よくスライドの背景が明るすぎるものや、ゲームのタイトル画面もしくはゲーム画面だったりする人がいますが、スライドの可読性が損なわれるほど派手なデザインは避けましょう！プレゼンのスライドは見やすさ重視が基本です。

６．アニメーションの多様

　僕自身もアニメーションばかりつけていたことがありました。高校生のとき、企業や全校生徒の前でプレゼンすることがあったのですが、アニメーションを多用すると、次どんなアニメーションあったっけと考えながらプレゼンすることになって案の定テンパってアニメーションと話の内容がめちゃくちゃになって辛い思いをしました。なので個人的にアニメーションは、動きで人の目線を引き付けたい時のみ使うようにしましょう！

７．ぶっつけ本番

　緊張しまくります。練習した分だけ緊張が少なくなると思います。でも練習したくない人がほとんどだと思います。僕もそうです。僕の場合は頭でシュミレーションをするようにしています。声に出して練習するのが一番効果的ですが…

〇やると効果的なこと

１．デザインの統一

　これは効果的というより基本的なことです。スライドのレイアウトが毎回バラバラだったり、基本色が変わっていたりすると、聞き手はスライドを追うので精一杯になってしまいます。

２．デスクトップの背景はデフォルトかシンプルなもの

図１）
　僕はいつもプレゼンのときのデスクトップ背景はこれにしています。ミスってデスクトップが出た場合に自分の嫁とかが映ったら会場が凍ります。僕はあえて最初に見せて、聞き手の自分に対するハードルを下げています。多分下がってる…良かったら使ってみてください(=ﾟωﾟ)ﾉ

３．動画はループさせる

　ゲームの仕様や、ギミックなどの説明で動画を流して説明するということがあると思います。そこで動画をループ再生設定しておくと、説明が長くなって動画が止まってしまって、説明がしづらいってことがなくなると思うのでループはおすすめです。

図２）
青枠内の停止するまで繰り返すのチェックをつけることで、選択している動画がループ再生されるようになります。

４．伝えたいことは１スライドで１つ

　１スライドのテーマを決める。テーマを決めてスライドを作ると話しやすいですし、聞いている人も、話の内容を理解しやすいと思います。

■実際に作ってみる

〇僕がスライド作るときにやること

１．タイトル

　①ゲームのタイトルもしくは、今回話す事柄
　②プレゼンター(前に立って話す人)の名前
　
図３）タイトルの一例
割と見やすいと思います。ゲームの名前は気にしないでください。

　タイトルって意外に大事なんです。図３では、「超本格RPGをプログラム初心者が作ったの？！」と思わせるようにこのようなタイトルとサブタイトルにしました。ちょっと聞いてみたいなと思いませんか？
ここで聞き手は、あなたのプレゼンに対して興味を持ってくれると思います。

２．ゲームの内容紹介

Q.いきなりですが、どちらのほうがいいですか？

Bでもいいですが、ここではAのほうが良いと思います。なぜなら、聞き手はAのほうが今から紹介するゲームの内容を想像してくれるからです。どんな敵が出るのかは、後のスライドで詳しく話したほうが話しやすいですよね。

３．ゲームを作るうえでのノウハウ紹介

　今回のスライドはプログラミング初心者がRPGを作ったというのが聞き手の認識です。
　聞き手はゲームの紹介よりも、どうやって作ったのか？どんなツール使ったのか？自分もできるんじゃないか？といったことが気になっていると思います。そこでノウハウを紹介すればもう聞き手はあなたのプレゼンに興味深々になっていることでしょう。
　なのでゲームの紹介ばかりではなくノウハウも紹介することをお勧めします。

■お疲れさまでした！

　今回は、ゲームプログラマ向けのプレゼンの作り方について紹介しました。あんまり需要がない気もしますが参考になる方がいれば幸いです。(*‘ω‘ *)

新米エンジニアは「先人が作ったWebサービスを見つけて活用しろ」

November 13, 2019, 6:38 am

はじめに

先日「事実と解釈を見極めろ」という記事を投稿しました。
秋に入り新人さんも仕事に慣れてきたのではないでしょうか。
急に話は変わりますが、ITの業界という言うのは仕事が飽和しているにもかかわらずエンジニアが不足しています。
特に日本はエンジニア不足が顕著です。
新人のあなたのも慣れてきたとはいえ常に新しいことを覚えつつ、覚えた仕事をフルに活用して業務の消化に追われているでしょう。

新しいことを覚えることはとても重要です。
しかし、具体を構築して成果物として納めなければならない我々エンジニアに対して無神経な上司は平気で「この仕事お願いね。（＝これちょうだい）」と言ってきます。

今回はあなたの負荷を少しでも減らす方法を共有します。

新米エンジニアは「先人が作ったWebサービスを見つけて活用しろ」とは

というのはどいうこと？
言葉の通りです。
あなたがやろうとしている仕事、またはその一片は既に他のエンジニアがもうチートツールを作ってWEB上で使えるという意味です。
あなたが頑張る必要はありません。
ITの業界は日進月歩。
大体あなたがやる仕事の一片は自動化されています。
サービスを活用しましょう。
では、そのサービスをどのように見つけるか？
これも簡単です。
本題に入る前に例を出します。

「いすを取り合う遊びは何でしょうか？」

ん？
小学生でもわかりますね。
「椅子取りゲーム」です。

例を見たらピンとくる方がほとんどだと思いますが、○○○ゲームって結構耳にしますよね？
シミュレーションゲーム、人狼ゲーム、サバイバルゲームなど、知ってる言葉ありますよね？
そうです。
我々は何かの遊びを調べるとき○○○ゲームとGoogle先生に聞くと思います。

こんな感じで、WEBサービスを探せばいいんです。

次項では実際に私がよく調べるキーワードを共有します。

どのようにWEBサービスを検索するのか

○○○作る、○○○生成

基本的には下記で何かを作ってくれるサービスがヒットすると思います。

○○○ Generator（ジェネレーター）

○○○ Maker（メーカー）

○○○ Creator（クリエーター）

ダミー画像作成、パスワードの生成といったときに検索してみてください。

○○○確認

○○○ Checker（チェッカー）

○○○ Simulator（シミュレーター）

○○○ Test（テスト）

○○○ Demo（デモ）

導入予定のライブラリのデモ、実際に動かした場合のプログラムコードのシミュレーションなど。
PHPといったサーバサイドの言語もonブラウザでコードを書いて動きを確認するサービスもあります。

○○○整形

○○○ Formatter（フォーマッター）

SQLの整形、JSON文字列整形、プログラミング言語の整形といったときに。

○○○変換

○○○ Convert（コンバート）

○○○ Encode（エンコード）

○○○ Decode（デコード）

○○○ To ××× または ○○○ 2 ×××

暗号化された文字を複合するときや、ファイル形式を変換するときなど、PDFから画像、Excelから画像といったかゆいところに手が届くサービスが結構あります。
ただ注意しないといけないのはファイルの変換系はサーバへのアップロードするケースが多いため、機密的な文書をこの手のサービスに上げるのはリスクがあるため、信用できるサイトを使うか、クライアントアプリをインストールしてソフトウェアで変換する方がいいかもです。

おわりに

まだまだ○○○編集といったキーワードはあるのですが、上げるときりがないのですが、あくまでも検索前に、作業の細分化と様々な作業の抽象化することが大切だということが当記事で伝われば幸いです。

仮説・検証（177）機会は巡ってくるもの。三次元の回転でものを考えると、逆方向に進むように見えて、実は前に進めるというひねりが大事。

February 29, 2020, 5:39 pm

プログラマとしてではないが、物事を否定的に語るのは得意だった時期がある。

機会は巡ってくるもの。三次元の回転でものを考えると、逆方向に進むように見えて、実は前に進めるというひねりが大事。

５歳から場合によっては６５歳までの６０年間。
４０歳の時に、ポジティブ転換したつもりだった。

転職活動をしてみると、まだまだなところがいくつも見つかった。

転機は何度かあった。

１０歳の頃、３つの出会いがあった。

絵の先生
与謝野晶子の短歌
仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

仮説・検証（168）プログラマの「プログラムが書ける」思い込みの激しさは強みであって弱点ではない３つの理由

March 10, 2020, 7:00 pm

あるソフトウェア関連の会合で、「プログラマの思い込みの激しさ」を批判ご指摘される方がおみえだった。

「思い込みの激しさは、プログラマにとっては、生産性の高さの原動力であって弱みではないのでは」とお答えした。

この文章は、「プログラマの思い込みの激しさ」を指摘いただいた方の思い込みの激しさをあぶり出せるかどうかを確かめることが副産物として想定しています。

本題自体もまだ十分論証できていませんが、なんらかの成果がでるまで追記し続ける予定です。

なお、編集リクエストは、しばしば Qiitaの処理系がうまく処理できず、矛盾などを発生させることがあります。コメント欄でご指摘くださると幸いです。
Contributionも、編集リクエストだと Qiitaの処理系がうまく処理できないことがあると、コメントいただいた方が、著者以外の「いいね」がつく可能性があり、お得です。よろしくお願いします。

現在、Qiitaでは主にAUTOSARの資料整理にあたっており、その1日の目標作業が終わるまで他の記事の読み書きを控えています。コメントの返事が数日後になる可能性があることをあらかじめお詫びいたします。

そんなある日、
自分を忘れない事の大切さ
https://qiita.com/sk4869pw4869/items/023c2a99aa790fdb1a66

そうか、思い込みでも、プログラムが書けなくなる思い込みもあるんだ。

そこで表題を
プログラマの思い込みの激しさは強みであって弱点ではない３つの理由
を
プログラマの「プログラムが書ける」思い込みの激しさは強みであって弱点ではない３つの理由
に変更させていただきました。

普段, HAZOPで、逆も考えようと言っている割に、紺屋の白袴してしまいました。@sk4869pw4869さんありがとう。
みなさん、ごめんなさい。

背景(back ground)

ここでプログラマは、OS、言語、通信、DB、試験を含む自動化などの道具類を設計する人たちを想定しています。自分は仕事で、主にプログラマの道具類をプログラミングしてきたためです。

その分野でお付き合いいただいたことがある天才プログラマの半分くらいは、プログラム以外については思い込みが激しい性格だったような気がします。

それでも社会生活がおくれているのは、大学、企業、研究所、家族などの組織が支えているか、それぞれの組織の代表者、管理者が、いろいろ代行してくれることがあるからかもしれません。

プログラマの評価は、書いたプログラムですべきです。何を思い込んでいるかで評価しても仕方ないと思いませんか。
思い込みを止めたら、他の人が考え付かないプログラム（解法）を思いつかないかもしれない。

安全分析で、ありえないことを前提に発想して、ありえることの対応を見出すかのように。

効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

前提(premise)

リスク理論(risk theory)

リスク理論には、正と負の両方を検討する経済理論系の理論と、負だけを検討する理論がある。
どちらの理論も、その利用方法によっては、等価な境界(interface)が存在する可能性がある。ここでは、正と負の両方のリスクを扱うものとする。負だけを検討する理論についてはいつか扱うかもしれない。

強みには、その強みの影に隠れて、変動があると負の現象が起こる確率がある。これを強みの負のリスクという。強みを活かさずに、競争に負けるのも、負のリスクとして計算する。強みがどんどん伸びて、想定したよりも早く仕事が終わってしまうという正ののリスクがある。しかし、この正のリスクを見積もっていないと、早く終わった時に、やることを間違えて、台無しにするかもしれない。正のリスクはいつ負のリスクに転化するかわからないようでは管理としてよろしくないかもしれない。負のリスクも、正のリスクに転化できる方法を知らなくては、管理としてよろしくないかもしれない。

弱みは、負のリスクを考慮するよりも、正のリスクが生まれないかを検討するとよい。

技能管理(skill management)

プログラマ、音楽家、運動選手など、個々人の技能を最大限有効に利用する必要がある仕事では、技能管理が重要である。これらの専門家の技能管理においては、強いところを利用し、弱いところは使わないようにする。

製造業における製造工程でも、職能の高い人の作業を習うようにして、標準作業の効率化を測る。

複数人が一緒に仕事をする場合には、その仕事の仕方をうまく組み合わせて最大限の効率をもたらすようにするのが指導者、指揮者、監督の仕事となる。

一人で仕事をする場合でも、健康管理、精神集中管理など、管理を手助けする人たちがいる。

1. 思い込みの類型(classification)

どんな思い込みが良くて、どんな思い込みが悪いという経験則は見つかっていない。

どんなに思い込みが激しくても、作ったプログラムが、自分の思い込んだ意図通りに動かなければ、それを一生突き詰めていくか、機敏(agile)に方針変換するかどちらかの可能性がある。

1.1 突き詰め型(maniac)

一生突き詰めていけば、数学の未解決問題を解決できるかもしれない。

http://www.claymath.org/millennium-problems

多くの未解決問題は発見的で、何か正しいことを突き詰めればいいわけではない。
正しいことは、思い込みの一つとしてはいいかもしれない。
すべてではない。

Poincaré Conjecture by Perelman Grisha
https://arxiv.org/abs/math/0211159
https://arxiv.org/abs/math/0303109
https://arxiv.org/abs/math/0307245

論理科学の問題で、自然科学、生命科学、社会科学の模型が利用できるかもしれない。

数学者、プログラマは、科学分野における確率とか分布とかを捨象し、抽象的に決定できると思い込むことがある。

仮説・検証(93) 科学四分類と算譜(program)
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

抽象的に決定できると思い込むことは悪いことではない。解への近道が、あらかじめわかっているわけではない。

1.2 機敏型(agile)

プログラムが思うように動かなければ、いくつかの次候補を選ぶ。

自分が使う道具であったり、市場に出すプログラムや、オープンソースのプログラムでは、書いたらすぐに結果がわかり、検証(verification)は必要なく妥当性確認(validation)がすぐにできるかもしれない。

妥当でなければ、作り直すしかない。
できるだけすばやく設計することが大事だ。
一生かけて実現するのであれば、一生かけて設計してもよい。
その方法は上記「突き詰め型」分類に属し、この節(section)では議論しない。

1.2.1 算法(algorithm)を変える

自分は得意ではない。徐々に事例を集める。

算法を変える例は、次の記事で紹介している。

『フカシギの数え方』おねえさんといっしょ：組み合わせ爆発の凄さ: docker(111)
https://qiita.com/kaizen_nagoya/items/f309b0c2bb015bbc71c3

オープンハウス2013：基調講演「フカシギの数え方― 組合せ爆発に立ち向かう最先端アルゴリズム技術」湊真一
https://www.youtube.com/watch?v=8xqEBQc1nTo

科学分野の模型(model)を変えたり、Datarobotのようなデータ解析についての機械学習の結果を比較して洗濯するのもよい。

DataRobotは次の記事で紹介している。

「Qiitaのいろいろランキング2019」への感謝と提案
https://qiita.com/kaizen_nagoya/items/40b8557a20e8d75d62b5

1.2.2. 言語(language)を変える

アセンブラで書いていたがC言語にする。
FORTRANで書いていたがMATLABにする。
mathematicaで書いていたが、XXXにする。

専用言語を作ってもいいかもしれない。
特定の問題を解くだけの言語があってもいいかも。

「アセンブラへの道」組立語(assembler)・機械語(machine language)・CPU
https://qiita.com/kaizen_nagoya/items/46f2333c2647b0e692b2

転職(16) ６５歳からのプログラミング入門
https://qiita.com/kaizen_nagoya/items/1561f910c275b22d7c9f

1.2.3. OS(operating system)を変える

OSが言語の足を引っ張っているかもしれない。

問題専用のOSを作ってもいいかも。
自動車のエンジン、電動機(motor)などの角速度制御では、OSのタスクではなく割り込み制御を基本とし、タスクは割り込み制御の邪魔をしない設計になっている。

TOPPERS/SSP, OSEK, AUTOSARなどの最小構成がそれにあたる。

12ステップで作る組込みOS自作入門　坂井弘亮, カットシステム, 2010

https://www.amazon.co.jp/dp/4877832394

この本では、タスクなどは半分以降にしか出てこない。
OSに必要なのは、CPUの抽象化、入出力の抽象化であることがわかる。タスクは、割り込みの抽象化の一つの方法でることがわかるかもしれない。

1.2.4. 物(hardware)を変える

種記憶容量を増やす。
CPUからGPU, DSP, FPGA(verilog-HDL)、量子計算機など、今なら選択肢が沢山あるかも。

量子コンピュータプログラムへの道
https://qiita.com/kaizen_nagoya/items/37c90488c87bbe9f2d71

RTL設計スタイルガイド Verilog HDL編(System Verilog対応版）
https://qiita.com/kaizen_nagoya/items/4c02f1575db1f28310a7

トランスピュータの設計を継承するXmosの有効利用を考えるのもいいかも。

128bit CPUを設計してもいいかも。256bit CPU, 1024bit CPUがあっても多白いかも。

1.2.5 色(color)を変える

視覚は、思い込みの極致かも。自分が見えているものを、脳が処理していることに気がつかないことがある。錯視がよい例かもしれない。

色覚の分布は、個々人で分布、確率が異なるにも関わらず、同じものが見えていると思い込んでいる。

今、考えていることを見直すには、色を変えてみるといいかもしれない。色を変えてみると、それまで思っていたことと違うものが見えるかもしれない。油絵の先生から習った方法は、りんごは赤だと思わずに、部屋の中にあるものの色をりんごに置いてみるという方法。部屋の中の色をりんごに置いてみると、存在感が増すことがある。自分の思い込みを、取り払う方法の一つ。

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

プログラマが知っているとよい色使い(JIS安全色)
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

1.2.6 音(tone)を変える

人と一緒にいた方が安心するというのも思い込みかもしれない。
一人でいると安心するというのも思い込みかもしれない。

音を変えると、一つの思い込みから別の思い込みに変換できるかもしれない。

仮説・検証（54）プログラムは音楽だ (A program is a music.)
https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8

1.2.7 自然言語(tone)を替えてみる。

日本語で考えている人は英語で考えてみる。
カタカナ語を多用している人は、カタカナ語を止めてみる。

そうすると、それまでに見えていなかった発想が見えてくるかもしれない。

略号を使っていたら、全部full spellingに直してみるとよいかもしれない。
同じ略号なのに、別の意味だったものに出くわすかもしれない。

英語(1) プログラマが知っているとよい英単語の語源
https://qiita.com/kaizen_nagoya/items/9de6d47c47e2c211222b

英語(3) 仮説・検証(88)用語の衝突(用語・用例募集中)
https://qiita.com/kaizen_nagoya/items/6a8eb7ffaa45eeb16624

2.原動力(power)

何を信じていようが、何を思い込んでいようが、問題を解決できればよい。

制約条件、前提条件、初期条件に間違いがあっても、解の候補が出てから、制約条件、前提条件、初期条件の違いを加味して、解を補正してもよい。

例えば、ラプラス変換は、時間領域の問題を、空間領域（周波数領域）で解き、時間領域に戻してから初期条件を加える。
制約条件、前提条件、初期条件が正しくないと問題が解けないとは限らない。制約条件、前提条件、初期条件の何かを捨象した方が、時やすい問題の形になるかもしれない。

詳解LAPLACE変換演習大下眞二, 共立出版. 1983

https://www.amazon.co.jp/詳解LAPLACE変換演習-郎/dp/4320070917/ref=sr_1_20?__mk_ja_JP=カタカナ&keywords=演習+ラプラス変換&qid=1581221961&s=books&sr=1-20

制約条件、前提条件、初期条件を思い込みだと読み直せば、思い込みの間違いは、解の間違いになるとは限らない。解の一部を削らなくてはいけないか、解をより厳密にしなければいけないだけかもしれない。

必要なのは解くことであり、解いたものが必要なものかどうかを確かめられればよい。

プログラムでも同様で、書いたプログラムの一部に間違いがあったり、問題があってもよい。
制約条件、前提条件、初期条件などを与えて、有効な範囲を限定していけばよい。

必要なのは、解を出すのに必要な原動力だけで、解き方が合っているかどうかが重要とは限らない。

論理的に正しいものだけを並べて、最終的にも正しいものを導き出す方法もあるかもしれない。それはそれで思い込んでやっていけばいいだけで、誰が早く必要な解に至るかどうかの競争なだけかもしれない。

3 試行錯誤(trial and error)

プログラムを書いて、走らせて、結果が得られなければ、またやり直す。

どんな思い込みで書いても、解に至るかどうかが大事。

試行錯誤は天才型というよりは努力型かもしれない。

試行錯誤していれば、いつか解決するはずだというのも思い込み。

解がない問題はいくらでもあるし、特異解しかない問題は発見的なことがある。
１年で見つけられるかもしれないし、１００年かかるかもしれない。

どんな間違った思い込みでも、解が見つかるはずだと思い込んで試行錯誤しているうちに、間違った操作、間違った前提だと解がでるかもしれない。

出た解を、制約条件、初期条件などで修正すれば、求めたかった解になるかもしれない。

VZエディタ移植(porting)に当たって実施したことと成果
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

事例考察(case study)

1. 人間の資質に関する思い込み

人間の資質に関する思い込みは、多人数で協調して作業する場合には、組み合わせを考慮するとよい。ある思い込みと共存できる思い込みになにがあり、どう組み合わせると負の効果が少なく、正の効果が大きくなるか。

2. 設計機材、道具に関する思い込み

複数人で作業する場合に、共通で利用する機材、道具に関する思い込みがあると、複数の道具の境界を決めたり、自動連携の道具を用意する必要があるかもしれない。それらの労力が、複数人で作業する正の効果よりも小さければ、問題ないかもしれない。

3. 設計対象に関する思い込み

何を作らなくてはいけないかに対する思い込みは、指揮者でなければ問題ないかもしれない。
設計対象の範囲、設計・試験方法、道具類などで無駄か抜け漏れがなければよいかもしれない。

4. 論理現象に関する思い込み

すべての問題は解けるはずだとか、この問題は解けないとか、今の作業の一部にしか影響を与えないかもしれない思い込みは、管理可能かもしれない。

5. 物理現象に関する思い込み

最適解が見つかるはずだとか、最適解は存在しないとか、今の作業の一部にしか影響を与えないかもしれない思い込みは、管理可能かもしれない。

6. 生命現象に関する思い込み。

遺伝子配列が分かれば行動が予測できるとか、今の作業の一部にしか影響を与えないかもしれない思い込みは、管理可能かもしれない。

7. 社会現象に関する

特定の団体、特定の個人に対する思い込みが激しくても、今の作業の一部にしか影響を与えないかもしれない思いこみは管理可能かもしれない。

まとめ

Three proofs of the intensity of programmers' beliefs is strength, not weakness.

Qiitaで「思い込み」検索すると、いろいろな思い込みの記録がある。
自分のことを書いている場合は、思い込みに気がついた例で、細かな思い込みから、大きな思い込みまでさまざまな気付きが書かれている。

突き詰め型であれ、機敏型であれ、思い込みは大切。
解への到達も、天才型であれ、努力型であれ、解が出るまで、思い込んで諦めないことが大事かもしれない。

日程が決まっていたり、多人数での作業では、一人の思い込みが全体に悪影響を与えた例はあるのかもしれない。顧客側の思い込みで困ることは時々ある。

仮説・検証（32）顧客の勘違い、思い込みにどう対応するか
https://qiita.com/kaizen_nagoya/items/2e61f1c770b66d1a1484

顧客側にもプログラマがいて、そのプログラマの思い込みが激しくても、実際にプログラミングして、動かして貰えば、伝わることが多かった。思い込もうが、思い込まなかろうが、プログラミングしてみればわかることなら問題ない。

解の候補から解への導出は、大量のデータから帰納的に求めてもよいし、演繹的に求めてもよい。

大量のデータを解析するのに、物理科学、生命科学、社会科学の模型(model)を知っていると、いかなる分布が登場しても困らないかも。

確率論及統計論
https://qiita.com/kaizen_nagoya/items/89d0a91a56d33529e85c

転職(1) なぜ経済学徒を辞め、計算機屋になったか（経済学部入学前・入学後・卒業後対応）
https://qiita.com/kaizen_nagoya/items/06335a1d24c099733f64

参考資料(reference)

思い通りに動かないときの対処方法
https://qiita.com/FeelSoGood/items/22ac08f6fb3ea11d4688

【業界初心者向け】システム設計者がプログラマに求める1つのこと
https://qiita.com/JEo4YZZPL3zRRW7/items/cde48cd85fa86c57dc76

[ まつもとゆきひろ氏 ]若手エンジニアの生存戦略
https://qiita.com/Tsutou/items/50be50cdb200f1e31d1c

has_oneとhas_manyの違いは多重度だけという思い込み
https://qiita.com/haazime/items/4d528f8d173d654ba394

_.extendはcloneをしてくれるはず、と勘違いしていた話
https://qiita.com/sasaplus1/items/380d1fe6d5400c1beedf

rails sでサーバーが起動しなかった時に確認したい初歩的なこと
https://qiita.com/sakuraniumarete/items/46f6bd5ce9a1afdf88a7

デバッグ心得
https://qiita.com/cactusman/items/90128938db93fa8c46d3

事故参照(self reference)

「平成のうちにやめたかった『ITの7つの無意味な習慣』」に付け加えたかったこと。
https://qiita.com/kaizen_nagoya/items/e6f9c2e0afbf8ab4181c

2020年の開発者が知っておくべき11の必須技能→回答編 → 並べ替え→項目合併(8項目)→内容追記
https://qiita.com/kaizen_nagoya/items/39e1c69bddb8e608b42b

仮説・検証（38）プログラマで「飛び抜けた人が少ない」という仮説
https://qiita.com/kaizen_nagoya/items/f0d22e20f6d2c58f2c1b

仮説・検証（50）作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab

仮説・検証（51）公開算譜は機敏だ(open source is agile)GitHub and docker
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e

仮説・検証（53）日本のプログラマが世界で戦える10個の事例
https://qiita.com/kaizen_nagoya/items/a7e634a996cdd02bc53b

仮説・検証（124）IT系勉強会をすべて当たりにする方法
https://qiita.com/kaizen_nagoya/items/9f001a79ab4162220406

仮説・検証（139）新人(学生)を指導するよりも新人(学生)に指導してもらった方が効率的
https://qiita.com/kaizen_nagoya/items/db993b1536055029f7c8

IT教育の基本としてきたこと
https://qiita.com/kaizen_nagoya/items/efeed472847aa4fcc835

文書履歴(document history)

ver. 0.01 初稿 20200208 午後
ver. 0.02 湊真一　追記 20200208 夜
ver. 0.03 書籍　12ステップで作る組込みOS自作入門　詳解LAPLACE変換演習追記 20200209 午前
ver. 0.04 DataRobot追記 20200209 午後
ver. 0.05 URL追記 20200209 夜
ver. 0.06 色、音、自然言語追記 20200209 深夜
ver. 0.07 参考資料追記 20200210 朝
ver. 0.08 見出し番号補正 20200210 午前 10時
ver. 0.09 見出し英語追記 20200210 午前 11時
ver. 0.10 英語標題追記 20200210 午後２時
ver. 0.11 補足 20200210 午後３時
ver. 0.12 分野追記 20200210 午後５時
ver. 0.13 背景、前提追記 20200210 午後１０時
ver. 0.14 事例追記 20200210 午後１１時
ver. 0.15 @scivolaさんの指摘により綴り訂正　algorithm 20200210 午後９時
ver. 0.16 表題追記 20200229
ver. 0.17 @sk4869pw4869　さんの記事に基づき表題変更 20200311

https://b.hatena.ne.jp/guide/bbutton

読みやすいコードを書きたい！

March 29, 2020, 5:18 am

この記事の趣旨

　自分の学習のメモとして残します。
　どなたかのお役に立てたら光栄です。

こんな方におすすめです

　・コードが見づらいと言われる
　・初心に返りたい
　このような方には何か発見があると思います。

読みやすいコードとは？

　ズバリ『良いコード』のこと。
　良いコードは、他人がそのコードを見た時に短時間で理解できるコードのことを言います。

　逆に、分かりづらい・理解しづらいコードは解読に時間がかかります。それだけ開発の工数もかかってしまい、効率が良くありません。

　では、良いコードの条件・要素を紐解いていきましょう！

●コードの命名に規則を

　変数やメソッドは好きなように命名ができます。
　ルールがありませんので、個人の好きなようにできます。
　特に共同開発の現場などでは、「他人が見てわかる」を意識する必要があります。

　◎命名のポイント

　　【目的がわかる単語を使う】
　　　　例）new　→　new_account

　　【汎用的な名前は避ける】
　　　・一時的な変数などは避ける
　　　・可読性を意識して

　　【名前に情報を含める】
　　　大文字、小文字をルールに沿って活用
　
　　【誤解されない名前を使う】
　　　・何がしたいかが明確な名前
　　　・説明的に長くなっても良いので、可読性重視
　　　　　例）read_books → already_read_books

●コードレイアウト

　プログラムの挙動に影響はないが、可読性を大幅にあげることができる

　◎レイアウトのポイント

　　　・整列　　　　：縦列を揃える。イコールの位置など縦が揃うと見やすい
　　　・一貫性　　　：似たような構造は同じフォーマットに統一できないか検討
　　　・ブロック化　：同じ系統の変数などをまとめてグループ化すること

●コメント

　・プログラムの動作を説明
　・他の開発者がコードを読む際の理解を助ける
　　※多すぎても読むのに時間がかかるため、簡潔に

　◎コメントのポイント

　　　・理由をコメントする　　：なぜそのコードを書いたか
　　　・他の開発者へメモを残す：開発中のメモとして
　　　・実際の例を記入する　　：コメントでは伝わりづらい時は、コメントとしてコードを記載

まとめ

　結局大事なことは
　　「人に対する思いやり」だなぁと。

　複数人で仕事をする以上、「自分だけ良ければそれで良い」という考えはNG。
　誰もが見やすく、仕事をしやすい状況を自分が作り出す意識が大切。

　そのための知識や技術であると思う。

　これからしっかり学んでいきましょう。

JavaScriptのライブラリ

March 30, 2020, 5:36 am

ただのメモ書きです(^^;

ライブラリとは？

　JavaScriptで開発を行うのを簡単にするツール
　汎用性の高い複数のプログラムを再利用可能な形でひとまとまりにしたもの。
　ライブラリ＝ Rubyでいうところの gem である。
　

ライブラリの種類

●jQuery　

　　DOM操作を短く簡単に書ける
　　Web制作などではこの知識が使える

●React

　　Facebookが開発したライブラリ
　　仮想DOMの概念により、高速なアプリケーション実装が可能
　　AndroidやiOSに対しても「React Native」を使用することにより実装できる
　　最近人気のライブラリ

　　◎仮想DOMとは？
　　　構造化した仮のDOMを作成、データを更新したら仮想DOMの差分だけを
　　　DOMに反映させることで、処理速度を早くする
　　　※DOMを直接操作するのは処理が遅い

●Vue.js

　　JavaScriptのフレームワークとして使われる現場が増えている
　　仮想DOMの概念があり、冗長な記述を減らせる
　　HTML,CSSを中心にしたWebアプリ開発が可能

これから学ぶもの

　この中からjQueryについて、学んでいきます。

「Done is better than perfect 」で成長できる

April 9, 2020, 6:58 am

1　誰の言葉？

マークザッカバーグ氏の有名な言葉です。
facebookのスローガンの1つであり
DONE IS BETTER THAN PERFECT！
（完璧を目指すよりまず終わらせろ）
というような意味になりますね。

有名と言いながら私が知ったのは昨日ネットサーフィンしている時ですが。

最近は割と浸透して仕事をする上では当たり前になっているような気もします。

以下が一部引用です。

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or are content with the status quo.
ハッカーウェイというのは継続的な改良と反復による構築のアプローチだ。ハッカーは何事も常によくすることはできるし、それは終わりがないということを信じている。彼らは問題を直す、たとえ、人々が不可能だと言ったり、それが現状の姿だと言ったりしてもだ。
Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.
ハッカーは素晴らしいサービスを一気に構築するのではなく、素早くリリースして、小さな改善から学ぶことによって長い時間かけて構築しようとする。これを行うため、我々はテストのフレームワークを構築した、それはいかなるときもFacebookの何千ものバージョンを試すことができる。"Done is better than perfect" 完璧よりもやることだというポスターを壁にはって、常に出荷し続けることを意識している。
http://hyoshiok.hatenablog.com/entry/20140825/p1
「未来のいつか/hyoshiokの日記」より抜粋

2　マークザッカーバーグってどんな人？

フェイスブック創業者であり、世界長者番付常連のマーク・ザッカーバーグ。
12歳でソフト開発、18歳で自身が開発した「Synapse Media Player」はマイクロソフトから100万ドルの買収額を提示され、大学生でフェイスブックを創業した
https://forbesjapan.com/articles/detail/32035
Forbes(JPAN)より抜粋

10代で才能を発揮していたようです。世界は広いです。

3　「成長」という観点においてどういう意味を持つ？

さて、この言葉についての詳細はご自身で調べてみてください。
今回はこの言葉とその前後の文章を知った上で、これって人生における「成長」という点においても同じことが言えるんじゃないのか？
と思って考えを書いてみました。

私は前職で中学校講師をしていたので、教育や成長に興味があります。
どうせ何かをするなら今の自分にはできないことを身に付けたいですし、想像もつかないほど進化できたら満足して人生を終えることができるのではないかと思います。

1　成長とは

　人それぞれの答えがあると思いますが、　私はずばり、「今現在の自分とは別人になること」だと思っています。
　ピ◯チュウがラ◯チュウに進化するように別物になるということです。（人間の場合、姿形は変わりませんが）
　
　別の言い方をすれば
「今の自分にない知識、技術、考えを身に付けること」となるでしょうか。

2　どうすれば成長できる？

　これも人それぞれ考え方があると思います。私は以下の図のようなイメージを持っています。

「挑戦」→「失敗」→「改善」
このサイクルをいかに多く、早く回すかが鍵になると思っています。スピードのある失敗は価値があります。
「成功の反対は失敗ではなく成長だ」と言われるように、「失敗」 ≒ 「成長」なのだと思います。

自信をつけるには、「プチ成功」を積み重ねる
成長するには、「失敗→改善→再挑戦」を繰り返す

これが今回頭を整理して出てきた今の自分の回答です。

今回は「成長」をテーマに書いているので
上の言葉には触れませんが、また機会があれば書きたいと思います。

自分の回答をもとに「Done is better than perfect」という言葉について考えていきたいと思います。

ここで成長できない例を上げてみましょう。

英語が聞き取れるようになったら海外に行こう
文章を書くのが上手になったらブログを書こう
カリキュラムが理解できたらwebアプリケーションを作成しよう

などでしょうか

ここでは2つ目の例を取り上げて考えたいと思います。
「文章を書くのが上手になったらブログを書こう」

これは何がいけないのでしょうか。
1)　「上手に文章が書ける」の定義が曖昧
2)　自分だけで文章を添削しても知識、考えが偏っていて改善が見込みにくい
3)　文章を上手に書くことができるようになるには、文章を書かなくてはいけない

などが挙げられると思います。

結局文章を書いて他人に評価してもらって改善していくしかないんです。
何度も書いていけば、自然と他の人のブログの書き方に意識が向いて自分との違いに気付くことができます。

つまり

「完璧な文章でブログを書く」

ではなく

「はじめに」から「最後に」までをとりあえず書いて形にする

それを繰り返すしかないということです。

ここで上記した文章の一部を取り出してみます

Hackers believe that something can always be better, and that nothing is ever complete.
ハッカー達は何でも改善することができ、そして完璧など決してないと信じている

文章を書くことも同じで
完璧な文章などないが、いくらでも良くすることはできると言えると思います。

文章を書いて、失敗から学んで改善してまた書いてを繰り返すことで先ほどのサイクルが繰り返され、成長につながっていく。

完璧な文章を書く必要などない、まずは書き終えることが大事なんだと思います。

「Done is better than perfect」

この考えでいろいろなことにチャレンジすれば比較的早く成長できるのではないでしょうか。

4　ずさんでいいという意味ではない

　とは言え「どうせ失敗するんだし、何でもいいから書けばいい」という姿勢でも残念ながら成長はしません。
　小さくていいので目標を立てましょう。その時に気をつけるのが
　１）　期限、曜日を決めること
　２）　数値をいれること

例えば、

一週間に１つ、１０００文字程度のブログを書く
５つのブログを読んだら１つ学んだことに関する文章を書く
(月)(水)(金)の19時から21時まではブログを書く時間に充てるなどです。

漠然とチャレンジするのではなく、「目標」を定めてそこに向かって進んでいって「失敗」して、「改善」してを繰り返す。

Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once.
ハッカーは素晴らしいサービスを一気に構築するのではなく、素早くリリースして、小さな改善から学ぶことによって長い時間かけて構築しようとする。

どんな分野にも当てはまる、汎用性の高い言葉だと思いました。

「Done is better than perfect」の精神で成長していきましょう。

最後までご覧いただきありがとうございました。

プログラマーからインフラエンジニアへ、そしてまたプログラマーへ

June 6, 2020, 11:28 pm

noteに書いたプロフィールの加筆転載です。
プログラマーからインフラエンジニアへ、そしてまたプログラマーへ

概要

①プログラマー時代

SIerに新卒入社し、開発フェーズからリリースにSEとして携わる。
通販パッケージソフト運営企業に転職し、設計業務からユーザーサポートまでプログラマーとして携わる。

②インフラエンジニア時代１

コンテンツ配信企業に転職し、開発フェーズからクローズまでシステム構成からインフラエンジニアとして携わる。
キー局テレビ連動では短時間の高アクセスを実現し、パチンコ案件では100万人級システムのDBチューニングを担当。

③インフラエンジニア時代２

大手ゲームメーカーに転職後、プライベートクラウドにおける開発フェーズからクローズまでインフラエンジニアとして携わる。
クラウド全体を俯瞰したシステム構成設計や、サーバアプリ設計まで踏み込んだチューニングにより、危機対策に貢献。

④ふたたびプログラマー（予定）

深夜休日対応はもうきつい。日本の多くの企業では待機時間は就業とみなされないばかりか、評価されない。（動いていて当たり前と評価される）
インフラ領域も理解できるプログラマーに転身予定。

実績

①経験した業種

ゲーム / マスメディア / エンタメアイドル / 通販 / 省庁

②経験したシステム規模

社内システム / 携帯端末 / スマートフォンゲーム / テレビ連動
アイドルグループ

③経験したレイヤー

物理サーバ / 仮想サーバ(プライベートクラウド) / データベース
ネットワーク / ディレクトリサービス / サーバアプリケーション
Webミドルウェア / Windowsアプリ

④経験したフェーズ

開発 / リリース / アップデート / クローズ/最小化 / システム移管
イベント対策(連動) / 危機対策 / システム稼働状況の日次レポート

⑤経験したソフトウェア

Ansible / Apache / bind / BIG-IP / keepalived / lsyncd / ntpd / NetApp
memcached / MySQL / Oracle RAC / Postfix / PostgreSQL / qmail / Redis
Sybase / WordPress / VMWare vSphere / ZABBIX

⑥経験した言語

Bash / C / Perl / PHP / PowerShell / Python / VBA(Excel) / VisualBasic

⑦経験したAWS

ACM / CloudWatch / EC2 / Lambda / Route53 / S3 / VPC / WorkSpaces

思い出深いこと

①SIer

省庁システムにトラブルが20時に発覚、徹夜で準備してそのまま始発で東京→福岡出張したこと

②インフラエンジニア１

DBのシステム移行36時間デスマッチをひとりでやり遂げたこと（オフィスの椅子３つ並べて仮眠しました）

②インフラエンジニア２

ゲームのクレジットタイトルに名前が残る仕事をしたこと

noteとの棲み分け

Qiita

技術的なまとめ、備忘録。事実をベースに。

note

エピソードを中心としたノウハウまとめ。感性をベースに。

意外と知らない人が多いググり方

April 19, 2020, 9:41 am

意外と知らない人が多いぐぐり方

知り合いのエンジニアの人がこのググり方を教えたら感動されていたので、そのググり方を載せようと思います

特定の情報を知りたいという場面の時はみなさん当たり前にググると思うのですが、たまに出てきて欲しくないサイトも一緒に出てきますよね(samura.....)
そんな時に実践して欲しいのがこれ

例えば javascript 配列　と検索したら一番上に出てくる、samura.... などはよく出てきますよね！

例えばですけど特定のサイトは検索一覧に表示させたくない場合。

-site:sejuku.net と打つだけで除外することができました！

という小ネタ話でした。
決してディスるためにこれを書いたわけではありません。。。。。。

ファッション

グルメ

ライフ

お部屋

家計簿

フリマ

ワーク

レンタルオフィス

ビジネス

キュレーションサイト

ミュージック

GAME

クリエイティブ

マッチングアプリ

Tech系

メディア

その他

何かを知らなくても、作れればよい。

知っていることと、作れることは方向性が違う。

これも感性。

参考資料(reference)

文書履歴(document history)

プログラマ35歳定年説

45歳以上の管理職リストラブーム

これから先

1. 好奇心の欠如 (Lack of curiosity)

2. 自律性と機知の欠如(Lack of autonomy and resourcefulness)

3. 問題に直面しても粘り強さが無い(Lack of persistence in the face of a problem)

4. 問題解決に成功した気持ちはない(No feeling of success in overcoming a problem)

5. 学習と理解に焦る(Impatient about learning and understanding)

6. 思考に飽きたり疲れたりする(Getting bored/tired from thinking)

7. 自分のことを考えられない(Inability to think for yourself)

8. 堅く、狭く、そして無秩序な考え(Rigid, narrow and/or disorganized thinking)

9. 複数の答えの間の「良い」と「悪い」の連続性に気付かず、「正しい」答えを望んでいる(Needing the “right” answer instead of recognizing a spectrum of “good” and “bad” answers)

10 細部に注意を払っていない(Not paying careful attention to details)

文書履歴(document history)

網(net)

プログラム

SNS

WEB

遊興競技(game)

時間(time)

種類(type)

費用(cost)

賭け事(gamble)

運転(driving)

運動(sport)

摂取(feeding)

酒(alcohol)

煙草(nicotine)

薬物(drag)

過食(overeating)

減量(loss weight)

購買(shopping)

窃盗(stealing)

迷惑行為(harassment)

人関係(human relation)

定義(definition)

依存症とは？

依存症には主に 2種類あります

社会通念上の分類(classification)

依存症と愛好家の境界(borderline)

対策(countermeasures)

個人的な対策案

遊興競技(game)

過食(overeating)

分類(category)

参考資料(reference)

文書履歴(document history)

今日死ぬとして、何を伝えておきたいか。

いちごいちえ という言葉があるらしい。

与件分析者(data analyst)

返事(response)

動画(movie)

参考資料（reference)

自己参考資料(self reference)

文書履歴（document history)

人

建物、設備

配色

　依存症と愛好家の境界(borderline)

いちごいちえ　という言葉があるらしい。