■自己紹介

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

〇初めに

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

■プレゼンとは？

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

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

〇やっちゃいけないこと

１．操作説明

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

２．ハードルを上げる

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

３．カンペ朗読会の開催

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

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

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

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

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

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

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

７．ぶっつけ本番

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

〇やると効果的なこと

１．デザインの統一

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

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

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

３．動画はループさせる

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

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

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

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

■実際に作ってみる

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

１．タイトル

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

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

２．ゲームの内容紹介

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

A.

B.

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

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

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

■お疲れさまでした！

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

はじめに

先日「事実と解釈を見極めろ」という記事を投稿しました。
秋に入り新人さんも仕事に慣れてきたのではないでしょうか。
急に話は変わりますが、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から画像といったかゆいところに手が届くサービスが結構あります。
ただ注意しないといけないのはファイルの変換系はサーバへのアップロードするケースが多いため、機密的な文書をこの手のサービスに上げるのはリスクがあるため、信用できるサイトを使うか、クライアントアプリをインストールしてソフトウェアで変換する方がいいかもです。

おわりに

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

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

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

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

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

転機は何度かあった。

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

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

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

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

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

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

なお、編集リクエストは、しばしば 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

関連行事（予定）

なぜ日本がアイティーで生き残れるか 2020年2月28日金曜日 13:30〜17:00 入場無料
名古屋市工業研究所　〒456-0058 名古屋市熱田区六番3-4-41
https://www.facebook.com/events/3089406667770866/

文書履歴(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

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

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

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

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

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

-samura.... と打つだけで除外することができました！

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

この記事の趣旨

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

こんな方におすすめです

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

読みやすいコードとは？

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

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

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

●コードの命名に規則を

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

　◎命名のポイント

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

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

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

●コードレイアウト

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

　◎レイアウトのポイント

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

●コメント

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

　◎コメントのポイント

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

まとめ

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

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

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

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

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

ライブラリとは？

　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について、学んでいきます。

２０２０年３月３１日を持ちまして、４４年間勤務していた名古屋市職員を辞しました。（正式名称は解職）
本来業務である企業の技術者の方との共同研究をはじめ、
名古屋市職員のパソコン研究の教科書の作成、
愛知工業大学と大同大学の学生の卒業研究の指導合計二十年、
十年間に渡る岐阜大学の大学院の非常勤講師としての集中講義などを担当させていただきました。
仮説・検証（139）新人(学生)を指導するよりも新人(学生)に指導してもらった方が効率的
https://qiita.com/kaizen_nagoya/items/db993b1536055029f7c8
仮説・検証（52）プログラミング言語教育のXYZ
https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4
また、経済産業省の組み込み中核人材プロジェクトを担当させていただき、トヨタ自動車様、アイシン精機様、三菱電機様、ブラザー工業様、オークマ様はじめ多くの企業の方にアドバイザになっていただきました。
docker (37) Dockerをどっかーらどうやって使えばいいんでしょう。TOPPERS/FMP on RaspberryPi with Macintosh編 ５つの関門「名古屋のIoTは名古屋のOSで」
https://qiita.com/kaizen_nagoya/items/9c46c6da8ceb64d2d7af
Autosar 資料のまとめ
https://qiita.com/kaizen_nagoya/items/8511de0e6819dfa1acaf
名古屋市では1980年頃に二円茶豆という計算機を使った自主研究グループに参加し、個人でもデータ解析で名古屋市の賞をいただきました。
転職(1) なぜ経済学徒を辞め、計算機屋になったか（経済学部入学前・入学後・卒業後対応）
https://qiita.com/kaizen_nagoya/items/06335a1d24c099733f64
仮説・検証（178）Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる５つの道
https://qiita.com/kaizen_nagoya/items/c72fa39e3191ea0290df
地方のしがないプログラマが著名なプログラマの方々と一緒に仕事をさせていただけるよおになったのは、VZエディタというアセンブラで書かれたエディタの移植を行ってからです。
仮説・検証(115) VZエディタ移植に当たって実施したことと成果
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949
「アセンブラへの道」組立語(assembler)・機械語(machine language)・CPU
https://qiita.com/kaizen_nagoya/items/46f2333c2647b0e692b2
国際規格のエディタをはじめ標準化活動に従事させていただきました。C/C++言語を担当されているISO/IEC JTC1SC22とISO/IEC JTC1 SC7のリエゾン担当などもさせていただきました。
プログラマが知っているとよい色使い(JIS安全色)
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35
Autosar Guidelines C++14 example code compile list(1-169)
https://qiita.com/kaizen_nagoya/items/8ccbf6675c3494d57a76
皆様、本当にありがとうございました。
今回の記念に次の記事を贈り物として書かせていただきました。
人生で影響を受けた本100冊
https://qiita.com/kaizen_nagoya/items/16af53acbb147a94172e
現在、何冊既にお読みいただいているかを、上記記事へのコメント欄または下記facebook spa-nagoya質問票にお答えいただけると幸いです。
https://www.facebook.com/groups/341033872604382/

新たな勤務先、職業等は、自動車技術会春季大会講演集にてお知らせすることになると思います。
よろしくお願いいたします。

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」の精神で成長していきましょう。

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

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

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

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

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

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

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

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

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

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

概要

社会人未経験で29から零細SES(派遣)のIT企業で働きもうすぐ３年目となります。
いくつかの現場で働いた経験から、プログラマとして働く上で最低限のスキルとして必要だと感じたものをまとめます。

上を見ればすごい人ばかりで自信を失くしてしまいますが、プログラマとして働くことに限ってはそれほどには要求されないと思います。

定義

プログラマの定義として１行でもコードを書く機会がある仕事をしている人とします

最低限のスキル

プログラミング能力

• Paiza Bランク

プログラムを書くには論理的に処理フローを考える力が必要となります。プログラミングだけではなく、他の作業でも必要とされる論理的思考能力がこれぐらいかと思います。自社で派遣先がある程度すんなり決まる方はPaizaのBランクを解ける傾向があります。
https://paiza.jp/

コミュ力

• 質問ができる

別に雑談などはできなくても問題は全くないと思います。大事なのは個人での調査にある程度の時間で見切りをつけて確認、質問ができることです。少しの度胸が必要なだけです。

文章力

• 失礼のない文章が書ける

社会人としての必須スキルだとは思いますが、メール、そしてslackなどのチャットツールで失礼のない文章が書けるのであれば問題は起こりません。

タイピング速度

• 寿司打 1秒４タイプ

作業速度に直結するので大事です。自社数人で確認しまして、見てて大丈夫と思えるのがこの速度でした。教えてもらう時もタイピングが遅いと微妙な空気になる場合があります。
http://typingx0.net/sushida/

まとめ

目指すレベルによってはプライベートで勉強をするとか必要になると思いますが、上記のスキルを超えているならプログラマとして働けるのではと思っています。一番敷居の低いと思われる零細SES企業勤めでの経験からですが、上記スキルから経験と知識をコツコツ増やしていければ今後も働く場所はあるのではないでしょうか

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

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

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

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

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

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

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

Zennとは

プログラマーのための新しい情報共有コミュニティサービスです。
知見を記事にして公開したり、より深い知見は本として有料(無料)で公開することのできるサービスです。

情報を発信するプログラマーが対価を得られるようにというのが、このサービスを作られた方の想いなのだと思います。
サイト→ https://zenn.dev/
公式Twitter→ https://twitter.com/zenn_dev

Zennってどんな感じ？

ログインはGoogleアカウントのみ！

ログインについては、Googleアカウントでのログインのみのようです。(シンプルで良いね😊)

書ける記事は2種類！

Add Newをクリックすると、記事(Article)と本(Book)の2種類から書きたい方を選べます。

記事はマークダウンで書ける！

プログラマーには嬉しいマークダウンで記事が書けちゃいます。

プレビュー機能！

▷ボタンをクリックするとマークダウンで書いたものをプレビュー出来ます。

豊富な挿入機能！

Twiiter、CodePen、JSFiddle、YouTube、SlideShare、SpeakerDeckと記事執筆に役立つ他サービスを埋め込み出来ます。

記事の設定はシンプル！

アイコンは好きなものに変えられます。カテゴリーはテック系とアイデア系。
トピックスはQiitaを活用している皆さんならよくご存知のやつですね😊

本はチャプター式！

本の書き方としては、記事(Article)の書き方と変わらない感じで、記事をいくつか書いたのを合わせていく感じです。

本のプレビューはこんな感じ！

本のプレビューはPCだとこんな感じです。Teckpitのような感じですね😊

これは非常に面白いサービスだと思った方も多いのではないでしょうか？(^^)
僕もさっそく使ってみました。本も執筆しようかなと思ってます。良かったらチェックしてね😊
https://zenn.dev/engineerhikaru

※この記事は勝手に書いたもので、決して何かをもらっているから書いているものではございません笑

「新サービスZennが面白い！」という記事を見てサイトを見たのですが、確かにおもしろそうだし、ローカルで記事を書いて投稿することができるっぽいので、ローカルで記事が書けるところまで試してみました

環境構築の基本的な流れ

Zenn公式で以下のように紹介されています

• GitHubリポジトリでZennのコンテンツを管理する
• Zenn CLIをインストールする

これでもローカルで記事を作れますが、npxでの環境構築だったので、yarn派である私はyarnで構築、記事の作成までしました
実際の手順、記事の作成は「yarnでzenn-cli導入する」で紹介しています
最終的なGitHubの内容はこちらになります

所感

思ってた以上に使い心地が良かったです
特にエラーもなくサクッと記事の投稿まで出来ました
唯一の不満といえば、ローカルでのプレビューがホットリロードに対応してないくらいです
0.1.23以上のバージョンに上げると、ホットリロードに対応しています
しばらくはZennを使いまくります

最近、目に入るようになってきたので、どういったサービスなのか調べてみたメモ。

zenn とは

プログラマーのための新しい情報共有サービスのようです。

• https://zenn.dev/

コンセプトは：

• 有益な情報を共有する人がもっと対価を得られること
• noteのようにお互いを金銭的にサポートできる
• 知見を本にまとめて販売したりできるプラットフォーム

catnose さんのツイート URL より

CatNose さんが個人開発されたもののようです。何番煎じと言われてもよさそうなのに、わりと好意的に迎えられているのなんでだろう。そのあたりはツイートをみてみた。

どうして移行する感じになってるのか

観測した。

今日の結城メルマガにも書いたけど、noteではMarkdown使えないけど、#Zennでは使える。それどころかGitHub連携で本や記事をデプロイできる。これは技術者の書き手にとって大きい。 https://t.co/zI5hSkHrGy

— 結城浩 (@hyuki) September 22, 2020

Zenn、ポエムが区分けされてるの良さそう pic.twitter.com/D7UEJvbNAi

— 青木とと(ˊᗜˋ*) (@lycoris102) September 17, 2020

Zennは速度等の操作感やパット見のビジュアルの良さはもちろんなんだけど思想がいいと思う。
ポエムと技術記事問題に対しては「カテゴリ」で区切ってるし、エディタの使い勝手やコンテンツの場所問題に関してはGitHubとアップロード用のCLIで答えを出している。すごい！https://t.co/peL9bot3o5

— もっと@Gatsby本を改訂するぞ (@mottox2) September 17, 2020

Qiita では書きたくなくて、個人ブログを作ってた強い層が Zenn で書き始めてる。

— 静的かみむら🚀 (@kamimura_th) September 21, 2020

Zenn、なんと言ってもUIが美しい
個人開発とは思えないクオリティにただただ圧倒される pic.twitter.com/PmRgH1Xznn

— Torishima (@izutorishima) September 21, 2020

新しいサービスZennはQiita+noteみたいな感じ？アカウントだけ作った。

— 二次曲線 (@Hyperbolic____) September 23, 2020

ちょっと出遅れている感がありますがエンジニア向けの情報共有サービスの「Zenn」は面白そう。

Qiitaとnoteを組み合わせたようなサービスですが記事をGitHubで管理出来たりサービス自体のプロジェクト管理も公開しているあたりはエンジニアマインドがあって良いなと思う。https://t.co/DOTLQcvAdc

— 高橋光 | データサイエンティスト (@light940) September 22, 2020

Zennがすごいなーと思うのは、「人はお金になることにはお金や時間を投資しやすい」っていうのを2段階に重ねてサービスが作られてること。

・書き手は記事を書くと稼げる可能性があるから時間を投資する。

・読み手は仕事（=稼ぎ）に活かすために記事を購入する。

— Daigo Wakabayashi (@frnk) September 23, 2020

Zenn にあげた記事もはてブに上がってる、嬉しい pic.twitter.com/pJ6YoEMOsX

— リア (@_Ria0130) September 21, 2020

zennよさそうだけど、記事書く場所はもう https://t.co/sVCQ3PTR1kを持っているから、使うとしたら本としてまとめるときくらいかな

— lacolaco / Suguru Inatomi (@laco2net) September 18, 2020

Zennって管理画面から何文字書いたかって見えるのね。
これはどのくらいのアウトプット量があるか見えて頑張った感が出るのでいいね！#Zennpic.twitter.com/eLEZrrEGcD

— かまひと@HSS型HSPエンジニア (@kmd_htsh0226) September 22, 2020

話題になってるZenn( https://t.co/P5JibR44Ts )すごいね
Qiita, note, はてな、ごっちゃになってたけど良いとこ取りしてるしGitHubデプロイできるのは強すぎる

— うすい (@n_skij) September 20, 2020

これQiitaに書いて180LGTMまじで面白すぎるな

見てる - 新サービスZennが面白い！ - Qiita https://t.co/s1wQaafJPj#NowBrowsing

— しゃけ (@syakejs) September 21, 2020

雑にツイートを二次利用させていただいております。再利用の範囲内だと思ったのですが、ダメだったら対応します。

よくないと思われているところ

観測した。

Zenn, とても良いのだけれど, 記事の発見 という面白さが少し少なくて残念

— JUN@ツイ依存症治療のため浮上率低下 (@JUN_NETWORKS_JP) September 22, 2020

使い方

とりあえずマークダウン記法。

• Zenn公式 - ZennのMarkdown記法

プレビュー見ながら書けないから不便ってときはこれ。

• Zenn CLI使えばプレビュー見ながら記事を書ける

サンプル

この間、Qiita にあげた「Unity 開発に関する 50 の Tips 〜ベストプラクティス〜（2016 Edition）」をテストとして zenn で本にしてみました。とても読みやすくなった。

• zenn - サンプル

この記事も Unity のジャンルではぼちぼち評価いただけたようで、うれしかったです。元記事がよかっただけですが、がんばって起こした甲斐がありました😀

個人的な意見。記事の発掘はたしかにまだそれほど力が入っていない感じなので、ライターのフォロワーが少ない（私のような）人は、記事を探して見てもらえる感じでもないだろうし、どうなのかなーって思っています。読んでもらえるのかな？　個人的には書いた記事の PV 数がよくわかりませんでした。いまのところは知名度のある人なら活きるのかなぁ。

はじめに

業務中、ふと「雰囲気でコードレビューしてしまっている」ということを自覚しました。
そこで、コードレビューにおいて気をつけていること、こうすればさらに良くなりそう！を言語化してみました。

「雰囲気レビューを卒業したい」、「コードレビューの質を向上・体系化したい」といった方はぜひ読んでみてください。

✊ レビュアーの役割

レビュアーが果たすべき重要な役割として、システムの品質を保証することが挙げられます。

• 要件不十分
• 不具合
• コード品質低下

などの発生責任は、レビュアーにも共有されます。
それらの発生を防ぐために、レビュアーが心がけるべきことをについて書いていきます。

👀 コードレビューの視点

コードレビューのときに特に見るべき観点は、大きく分けると以下の３つです。

1. 仕様を満たしているか
2. バグが含まれていないか
3. コードの品質が低くないか

1と2は言わずもがな重要です。死ぬ気で見ましょう。

３はリリーススピードを優先するためにおざなりになりがちですが、品質の低下は将来的なバグ発生や開発・レビューコストの増加につながります。
忙しいからと言い訳せず、できるかぎり見るようにしましょう。

また、疑問・不安はしまいこまず、できるだけ解消するようにしましょう。
仮に意見が不適当だったとしても、あなたにとって学習の機会になり、同様の疑問を抱えている他のレビュアーの助けになります。

🗣 コードレビューの伝え方

指摘内容が妥当でも、伝え方が不適切だと反映されないという結果になりかねません。
良い意見を無駄にしないために、伝え方にも配慮しましょう。

指摘のしかた

指摘について書くべきは以下です。

1. 改善してほしいこと
2. 理由（根拠）
3. 解決方法

1. 改善してほしいこと

何が課題なのか、該当行へのリンクやコードブロックなどを用いてわかりやすく説明しましょう。
このときに、頭ごなしに拒否せず肯定から入るようにすることで、より受け入れられやすくなります。

2. 理由（根拠）

論理的な正しさを証明するためには根拠を添えることが効果的です。

• 仕様書
• 公式ドキュメントやリファレンス
• スタイルガイド
• 他参考サイト

参照元は１次情報に近ければ近いほど信憑性が高い為、その点も意識しましょう。

3. 解決方法

課題提起にとどまるのではなく、解決のサポートまでできればベストです。
思いつかない場合でも議論を喚起するなどして、必要な協力を惜しまないようにしましょう。

ただし成長を促したい場合は、あえて解決方法まで教えないことも選択肢です。

心理的安全への配慮

なぜ心理的安全に配慮するべきか

それは、「正しく意見交換をする為」です。

レビューで少しでも辛い気持ちになったことはありませんか？（私はあります）
心理的安全性の欠如は、以下のようなことを引き起こします。

• 不健全な対立によるコミュニケーションの消極化
• モチベーションおよび生産性の低下

コードレビューのコメントでは基本的に意見の違いを伝えることになります。

間違いを受容することは、決して簡単ではありません。
その上理不尽だと感じる要求は、さらに受け入れがたいものになります。

どうすればいよいか

「指摘のしかた」を遵守する

上で述べている「指摘のしかた」を心がけましょう。

レビューイがコードの指摘を人格否定だと勘違いしてしまうことが、心理的安全を損なう要因の一つです。

論理的であることは大前提です。
その上で解決方法を提案し、寄り添うスタンスを示しましょう。

褒める

コードレビューでは指摘が連なりやすく、レビューイの心は荒みがちです。
そうなりやすいことを強く念頭に置き、良い点にも積極的にリアクションするようにしましょう。

👍 のような絵文字１つでも、かなり雰囲気が和みます。

感情を表現するツールを使う

テキストコミュニケーションは感情が伝わりにくく冷淡に受け取られやすいため、無自覚に相手にネガティブな印象を与えてしまっていることがあります😿

感情の受け取られ方に気を払うことで、それを未然に防ぐことができます💪
感嘆符（！）、絵文字、顔文字は感情を表現する強力なツールなので、ぜひ活用しましょう！！

ただ、このようなコミュニケーションが合わないという方もいらっしゃると思います🙋
そういう方はコメントをする前に一度読み返し、相手に不安を与えるような表現がないか確認することを習慣づけましょう！

まとめ

コードレビューは開発者がメイン、レビュアーはサポート的立場だと考えがちですが、実際は責任を共有する立場です。
レビュアー側も当事者意識を持つことで、建設的なレビューを実現していきましょう😺

また、レビューを依頼する側の考えを理解しておくと、より歩み寄りがしやすいです。
>> コードレビューを依頼する側の心構えはこちら

はじめに

コードレビューを依頼するとき、どんな気持ちでお願いしていますか？
自分が始めたての頃は、「チェックしてもらえてありがたいなあ」くらいの考えでした。

コードレビュー依頼とは、いわば責任の共有依頼です。
つまり、本質はそれほどカジュアルなものではありません。（依頼しやすい関係性は別として）

コードレビューを通したレビュアーには、品質の保証をしたという責任が伴います。
通したコードが不利益を生んだ場合には、レビュアーも責任を負わなければなりません。

そのリスクを負ってもらうことに対し、レビュー依頼者（reviewee, 以下レビューイと呼びます）」が果たすべき義務は、レビュアーが最小限のコストで効果的にレビューできるように最大限努力することです。

その努力の具体的な方法を、以下に書いていきます。

効果的/効率的なレビューをしてもらうために

👨‍💻 開発で気をつけること

レビューに必要なコストは、開発時点で半分以上決まると言っても過言ではありません。
具体的には以下の４点です。

1. 読みやすいコードを書こう

読みやすいコードを書くことは、コード品質を高め、結果的にレビューコストを下げることができます。

意図の伝わりやすい実装、命名を心がけ、読みやすいコードにしましょう。
より詳しい読みやすいコードの書き方については、リーダブルコードなどの書籍や他の方の記事をご参照ください。

2. Linter, Formatterを利用しよう

コード規約、フォーマットに関しての指摘・修正は基本的に人間のやることではありません。

pre-commit hookやVS CodeのcodeActionsOnSaveなどを利用し、自動的に実行されるようにしましょう。

2. コミットを分けよう

コミットを細かく分けることで、小さい粒度でレビューできるようになります。

レビューにおいてのみでなく「変更の経緯を追いやすい」「ロールバックしやすい」などのメリットがあります。

3. プルリクエストが大きくならないようにしよう

差分ファイル数や変更行数があまりに多いと、レビューがちょっと億劫になりますよね。

仕様設計・工数見積もりの段階で差分が膨らみそうだと思ったら、まずは親ブランチを作り、そのブランチへのプルリクエストを小さく作るようにしましょう。
そうすることでレビュー機会を分割することができます。

4. セルフチェックをしよう

レビューでの指摘を減らす為に、あらかじめ自分で確認することで手戻りを防ぎましょう。基本的には以下のようなことです。

• 仕様を満たせているか
• 読みづらくなっている部分はないか
• 動かしてみて不具合はないか

ただし、個人的な経験ではセルフチェックでは自分を正当化するバイアスがかかりやすい為、客観性を意識的に強めるようにしましょう。

🛠 合同レビュー

レビューを依頼する相手にとって、あまり知らないシステム、大規模な変更のレビューなどは非常に読解コストが大きいです。

そのようなケースでは、合同でレビューする場を設けましょう。
仕様や実装について説明を行い、コミュニケーションをとりつつレビューを進めていきます。

🏷 プルリクエスト

概要を書こう

満たすべき要件を共有しましょう。
具体的にはIssue、チケットへの関連付けです。

「システム要件を満たしているか」は、レビューしてもらうべき重要な要素の一つ、大前提になります。

システム仕様

システム要件を実現するために、どのように実装したかを記述しましょう。

書き方は様々あると思いますが、コアになる部分と、追加した/関連するテストを書くようにしています。（カバレッジ部分から注意して見るべきロジックの場所がわかる）

「わかりにくいところをわかりやすくする」ために書く、ということを念頭に置きましょう。

画像や図

画面に変化がある場合などはスクリーンショットを添付するとより伝わりやすいです。

必要に応じて注釈を加えましょう。（Mac付属のプレビューで簡単にできます）

🗣 コミュニケーション

レビューでコメントをもらったら、必ず返信(リアクション)するようにしましょう。
必要に応じて意見を述べ、修正し、再度確認を依頼しましょう。

このときビジネスのスピードとの塩梅で、対応するべきかどうか迷うこともあると思います。

基本的にはレビューイが仕様・実装・事業的優先度を最も把握できているので、責任を持って判断してください。
もちろん、必要に応じてチームと相談するようにしましょう。

まとめ

一貫して大切なのは、相手がどうしてくれたら嬉しいのか考えること、思いやる気持ちです。

コードレビューは依頼する側、される側の双方の歩み寄りでより効果的・効率的に実施できます。
その実現のためには、逆の立場の視点を持つことが効果的です。

レビュアーの視点についても書いているので、ぜひ読んでみてください。

>> コードレビューをするときの心構え

はじめに

エンジニアには、アウトプットの文化があります。
僕自身、社外でLTメインの勉強会を２年近く運営していました。

みなさんも日頃から大小さまざまな形でアウトプットをされていると思います。

ですがそのアウトプット、「エンジニアだから」「みんながやっているから」「なんか良さそうだから」といった、なんとなくの理由でやってはいませんか？

どんなことにも言えることですが、目的意識があるかないかで得られる成果は大きく変わってきます。
アウトプットの目的、つまりはメリットを理解することで、アウトプットから得られる成果はより大きくなります。

今回はその「アウトプットで得られるメリット」について、経験を少し交えつつ、お話ししていきます。

なぜアウトプットするべきか

それはアウトプットに多くのメリットがあるからに他なりません。
その中でも、僕が特に大きいと感じるメリットはこの４つです。

1. インプットの質を上げられる
2. 「伝える力」が向上する
3. セルフブランディングができる
4. 価値のレバレッジができる

以下、それぞれについて解説します。

1. インプットの質を上げられる

アウトプットとはインプットでもあります。

「ん？どういうこと？」と思うかもしれません。
その理由を２つに分けてお話しします。

記憶の定着

エンジニアであれば、日頃からいくらかのインプットをしていると思います。
ただそのインプット、揮発的なものになっていませんか？
「確かにインプットしたけど、忘れちゃった」そんな経験が僕にもあります。

記憶を定着させるためにおすすめの手段は２つ、「使うこと」と「人に教えること」です。

まず「使うこと」、実際に業務などで使うことで、記憶として定着させることができます。
しかし実際には、インプットしたものすべてを使う機会はなかなかありません。
なので、自分で何かを作ったりすることで「使う」機会を作ります。

次に「人に教える」です。

「ラーニングピラミッド」をご存知でしょうか。
7つの学習方法を学習の定着率順に並べたものなのですが、そのうち最も効果的とされているのが、「人に教える」です。

人に教えることでの記憶の定着率は90%と、非常に高いです。
積極的に覚えたいことがあれば、人に教えることがおすすめです。

知識の確実性が増す

仮に技術の知識があったとして、「自分しか知らない情報」と、「多くの人の目に触れ、フィードバックを得ている情報」のどちらに確実性があると思いますか？

言わずも、後者であると言えるかと思います。

公開してフィードバックを受けることで、その知識はより確実性を得ることができます。

2. 「伝える力」が向上する

アウトプットでは、自分の持っている知識・スキルを言語化し、相手に伝わりやすい形にする必要があります。
つまり、「伝える力」が強く求められます。

誰にも伝わらないアウトプットは、対外的には価値がないも同然です。

「伝える力」は、仕事・日常において大いに役立ちます。
例えば、「なんて言えばいいんだろう」と仕事などで少しでも思うことがあれば、それは伝える力が不足している証拠です。

どうやったら相手に伝わるか考えてアウトプットをすることで、「言語化」「伝わりやすくするために相手に寄り添う考え方」が養われ、「伝える力」の成長に大きく役立ちます。

また、LTなどで人前で話す能力も「伝える力」の一つです。

自身運営していたLT会では、登壇や、司会を担当するなどしていました。
始めた当初は人前で話す技術や自信など全くなく、なかなか精神的に応えるものがありました。

ですがやっていく中で、人前での話し方、登壇者との対話の仕方といった、「伝える力」が確実に成長していきました。
LTは他のアウトプットと比べて心理的ハードルが高い分、達成感と経験値が段違いです。

3. セルフブランディングできる

アウトプットは、自身のブランドを作るための手軽な手段の１つです。
このブランディングとは、「エンジニアとしての能力を誇示する」ことを指します。

現在、自身のエンジニアとしての「ブランドを表すモノ」はありますか？
投稿した記事、公開しているコード、サービスなどがそれに該当しますが、大したものがない場合、それは「ブランドがない」ということです。

それがどう困るのか。
例えば、仮に転職するとします。

採用担当者にあなたのエンジニアとしての能力を伝える必要がありますが、「ブランドを表すモノ」が少ない場合、その手段は「直接話すこと」に限られます。

そのため、あなたは口頭で多くを伝える必要があります。
ここで漏れなく伝えるのは、簡単なことではありません。

できなかった場合、実際の能力より低く評価されてしまうということになります。
さらに先ほどの「伝える力」が乏しい場合は、なおの事です。

そうならないように、アウトプットをすることでブランドを創り上げていくのです。

これは会社内での評価においても似たようなことが言え、ブランドは上司が成果を評価する上での指標の１つになります。

ただ気をつけなければならないのは、より組織や社会に良い影響を与えたアウトプットほど評価されやすいという点です。

セルフブランディングという目的においては、アウトプットの質を強く意識する必要があります。

4. 価値のレバレッジができる

インプットで得た知識は、アウトプットによってその価値をレバレッジすることができます。

例として、「開発を効率化するVSCodeのショートカットキー」について学び、それを社内１０人に向けてアウトプットしたとします。
全員がその知識を業務に活用すれば、会社から見たその知識の価値は１０倍になるというわけです。

あなたがその成果を上司にわかりやすく伝えることで、評価にも繋がります。

パブリックなアウトプットであれば、ちょっとした社会貢献です。

業務を減らせる

自分の知識を共有することで、自分の業務を減らすことができます。

僕は最近「コードレビューで気をつけること」に関する記事を投稿しました。
これはもともと「社内のコードレビューの形をある程度揃えて効率化する」ために書いたものです。

チームに共有した結果、業務においてコードレビューのコストが減り、自分自身も楽ができています。

同じことを何度も伝えていると感じたら、それはアウトプットのチャンスです。
形として残し、誰でもいつでもアクセスできるようにすることで、業務の効率化が見込めます。

まずなにをするべきか

メリットについては以上ですが、現状アウトプットの習慣がない方は「まずはどうしたらいいの？」と思われるかもしれません。

そんな方に向けて、僕がおすすめする具体的なアクションは以下の２つです。

1. とにかくインプットする

まずはインプットです。
インプットなくしてアウトプットはできません。

Qiita、Zenn.dev、はてブ、Twitter、RSSなど、調べれば様々なインプットの手段があります。
今回「アンテナの張り方」については詳しく書きませんが、Qiitaを利用されている方に１つおすすめの方法があります。

それはストック機能を活用することです。

Qiitaには自分がストックした記事から検索することができる「ストック内検索」という機能があります。
名前の通りの「自分のストックした記事から検索できる機能」で、とっても便利なのですが、あまり知られていないように感じます。

例えばですが、僕は以下のような記事をストックします。

• アウトプットに使えそうな記事
• 業務でたまに使えそうだけど忘れちゃいそうな記事

そういったものをストックすることで自分専用の備忘データベースが完成します。
あとは「ストック検索」を使えば、いつでも簡単に情報として取り出せるというわけです。

また、アウトプットをしようと思った時には「ストック一覧」が題材探しの手助けになります。

Qiitaの記事は、少しでも気になったらとりあえずストックすることがおすすめです。

2. 小さく始める

アウトプットのメリットは十分伝わったと思いますが、「自分はビビリだから」とか「人に教えられるだけの知識なんてない」という方もいらっしゃると思います。

たしかに大人数相手にアウトプットをするのは心理的ハードルがありますし、１記事、もしくはLT１回分の情報をまとめるのは、なかなか骨が折れます。

そんなときはは、まず小さくアウトプットすることから始めてみましょう。

例としては、Twitterや会社のチャットなどでの発信がおすすめです。
まずは身内に向けてアウトプットすることで成功体験を積み、徐々に範囲を拡大していきましょう。

まとめ

以上のように、アウトプットには自分、組織、社会にとって多大なメリットがあります。
また、習慣がない方も小さく始めることで、いずれ大きな資産になっていきます。

この記事が、「なんとなくのアウトプット」から「目的のはっきりした質の高いアウトプット」に変えるきっかけになれば幸いです。

はじめに

タイピング練習は①指に位置を慣れさせる②スピードアップ。の順で練習をすると
正しいフォームでミスタッチの少ない効率の良いタイピングができるようになるメリットがあります。

本題

最初はスピード追わない！！
まずはゆっくりでも大丈夫なので、指に文字の位置を慣れさせる。

ルール
* 下を見ずに、前を向いて入力する練習をする
* 最初のうちは手全体で動かす
* 入力後に必ずホームポジションに戻す
* スピードアップは指の位置を覚えてから

スピードアップには１ヶ月〜３ヶ月かかると言われています。
なので1日５分だけでも良いので、まずはタッチタイピングで見ずに打つ練習して
徐々にスピードをアップさせていきましょう！

因みに私は
P検定タイピング練習（英語編）と 寿司打で練習をしています。
P検定では５分で１０００文字を目標に、寿司だでは一万円コースで2000円のお釣りを出すのを目標にしています！

参考にした記事:ブラインドタッチのコツ