新人の方によく展開している有益な情報

新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。
あらたな、有益な情報がありましたら、随時追加してまいります。
有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。

ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。

コードリーディングについて

[1]ソースコードを読むための技術
https://i.loveruby.net/ja/misc/readingcode.html

[2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015
https://affordd.jp/libraries/affordd-conference2015-p5/

[3]ソフトウェア品質管理研究会 第6分科会「派生開発」 Aグループ，「変更の影響範囲を特定するための「標準調査プロセス」の提案」，2014
https://www.juse.or.jp/sqip/workshop/report/attachs/2014/sqip6-a.pdf

質問について

[4]@seki_uk，「質問は恥ではないし役に立つ」
https://qiita.com/seki_uk/items/4001423b3cd3db0dada7

[5]結城浩，「技術系メーリングリストで質問するときのパターン・ランゲージ」
https://www.hyuki.com/writing/techask.html

[6]安達裕哉，「なぜ「できない人」ほど、人に聞けないのか。」
https://blog.tinect.jp/?p=64018

[7]@hanhan1978，「分からないをすぐ伝えるのは、とても良いという話」
https://qiita.com/hanhan1978/items/6371b69f84d894b0a3c1

[8]tky_bpp，「Google人工知能チームの「15分ルール」」
https://tkybpp.hatenablog.com/entry/2016/08/16/173055

問題が起きた時は
【1】最初の15分は自分自身で解決を試みる
【2】15分後も解決していなかったら必ず人に聞く
前者を守らないと他人の時間を無駄にし、後者を守らないと自分の時間を無駄にする。

検索について

[9]@kaizen_nagoya，「仮説・検証（182）質問の仕方を学ぶ前に、検索の仕方を学んだ方がよいかも。」
https://qiita.com/kaizen_nagoya/items/d36e87972e6cd5f665f9

[10]@cannorin，「エラーメッセージの読み方と対処, 検索や質問の原則」
https://qiita.com/cannorin/items/eb062aae88bfe2ad6fe5

[11]TAKAKING22，「学校では教えてくれないググり方（Google検索）のコツ」
https://takaking22.com/2018/how-to-search/

[12]@chau_y，「プロのように英語でGoogleを使用する方法」
https://qiita.com/chau_y/items/6b1bbf3c5217976856cc

報告について

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

「報告を受けた人ではなく、報告をした人も、その労力に見合う成果を得られるようにする」というのが、結構大切な考え方です。

[14]@tatesuke，「「進捗どうですか？」より2015倍捗る「困ってますか？」」
https://qiita.com/tatesuke/items/fd5483be1b72727d3d34

ソフトウェア品質管理研究会の2021年度特別講義「ソフトウェア開発の真のボトルネックとは何か？」に参加し、岸良裕司氏（Goldratt Japan CEO）から、”変えられる未来に集中した進捗管理”での3つの質問フレーズを教えていただきました。「問題ない？」と聞いてもなかなか問題は出てこないので、「問題があるとしたらなんですか？」と聞くそうです。
https://juse.or.jp/sqip/workshop/lecture/index.html#kougi1

あと何日ですか？
問題あるとしたら何です？
何か助けられることはありませんか？

（進捗）報告というと、どうしても実績・過去を報告したくなります。
ただ、実績・過去を聞いても、未来を変えるアクションが起こしにくいことがしばしばあります。

[15]@kojimadev，「分報で各自の作業を可視化したら、メンバー間の協力が加速された話」
https://qiita.com/kojimadev/items/ea8825dec1b0d0d2874c

分報は自分専用チャンネルなので、気兼ねなく困ったことをつぶやけていました。そして、先輩社員が困ったことを拾って解消していました。

困りごとの早期解消をするために、まずは気兼ねなくつぶやける状態にするのが大切です。
分報により、メンバがチャットに投稿するハードルは、明らかに下げることができます。

理解について

[16]清水吉男，「「分かる」の問題について」
https://www.affordd.jp/koha_hp/LectureManager/MG.wakaru.html

「分かる」とはその人が分かったと思う範囲でのみ分かったのである。

人はどうしても自分と同じように分かってくれたと思いがちですが、実際には違いますね。

[17]西林克彦，「わかったつもり 読解力がつかない本当の原因」，光文社新書，2005
https://bookmeter.com/books/565611

「わかった状態は、安定状態。」「人は安定状態になりたがる。」「人はわかったつもりに、なりやすい。」ようです。疑問があることは、よいことのようです。書籍にも示されているように、わかったつもりを乗り越えるには、読んでいる文章とは異なる表現方法（表や木構造）で、部分間の関連付けをすることが、一つの有効な方法だと思います。つまり、深く読むために、書き直すという行為をするとよいと思います。

[18]開米瑞浩，「考えを整理し、発想するための図解」
https://www.itmedia.co.jp/bizid/spv/0708/01/news005.html

[19]柏原一雄, 長井亘, 不破慎之介, 林香織, 石川冬樹, 栗田太郎，「要求仕様の誤解釈を検出する Domain Word Modeling の提案」，ソフトウェア・シンポジウム2020 ，2020
https://researchmap.jp/reve/published_papers/33955210

[20] @t_nakayama0714，「不思議の国のSE用語」
https://qiita.com/t_nakayama0714/items/478a8ed3a9ae143ad854

推敲について

[21]@kazuo_reve，「文章の推敲・校正の個人的なノウハウ」
https://qiita.com/kazuo_reve/items/b15d99759d75f942b9f0

[22]結城浩，「数学文章作法 基礎編」，ちくま学芸文庫，2015
https://bookmeter.com/books/6574310
https://www.hyuki.com/mw/

[23]結城浩，「数学文章作法 推敲編」，ちくま学芸文庫，2015
https://bookmeter.com/books/8653540
https://www.hyuki.com/mw/

[24]阿部圭一，「情報伝達型の日本語文章に現れるあいまい表現の類型化とその改善例」，情報処理学会 デジタルプラクティス 5(1) 70-79, 2014
https://ipsj.ixsq.nii.ac.jp/ej/index.php?page_id=13&active_action=repository_view_main_item_detail&block_id=8&item_id=97817&item_no=1

[25]Japan Plain English & Language Consortium，「プレイン・ジャパニーズ10のガイドライン」
https://jpelc.org/plainjapanese/j10rules-analysis/

[26]河野哲也，猪塚修，藤森麻紀子，本間周二，茂中義典，「キーワードベースドレビュー－ドキュメントのあいまいさや不備に着目したレビュー手法－」，ソフトウェアテストシンポジウム東京2010，2010
http://www.jasst.jp/archives/jasst10e/pdf/C2-3.pdf

論理について

[27]開米瑞浩，「MECEとロジックツリー」
https://ideacraft.jp/logic/basics/mece_logictree/

[28]芝本秀徳，「誰も教えてくれない 考えるスキル」，日経BP，2015
https://bookmeter.com/books/9784210

[29]佐藤航陽，「ロジカルシンキングの弱点を考えてみた：ロジックを超えたロジックの話」，2014
http://katsuaki.co/?p=465

スティーブ・ジョブズの以下の言葉好きです。確かにその通りって感じです。

大学時代に先を見て『点を繋げる』ということは不可能でした。しかし、10年後に振り返ってみると、実ははっきりとしているのです。繰り返します。先を見て『点を繋げる』ことはできない。できるのは、過去を振り返って『点を繋げる』ことだけなんです。だから将来、その点が繋がることを信じなくてはならない。

設計について

[30]清水吉男，「『ソフトウェア開発２０１の鉄則』の解説　原理６３：設計の原理＝代替案を評価せよ」
https://www.affordd.jp/koha_hp/SCNews/hpblock110/SCNews110.html#anchor830805

[31]柴田芳樹，「ネーミングは設計の中心」
https://yshibata.blog.ss-blog.jp/2009-10-25

[32]@jnchito，「モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう」
https://qiita.com/jnchito/items/459d58ba652bf4763820

[33]@Ted-HM，「プログラミングでよく使う英単語のまとめ【随時更新】」
https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923

デザインについて

[34]「脱初心者！「デザインの4つの基本原則」を押さえて基礎を固めよう」
https://webdesign-trends.net/entry/7810

[35]Robin Williams，「ノンデザイナーズ・デザインブック [フルカラー新装増補版]」，毎日コミュニケーションズ，2008
https://bookmeter.com/books/540592

トラブルシューティングについて

[36]金子龍三，「先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明」，日科技連出版社，2005
https://bookmeter.com/books/1345074

[37]@kazuo_reve，「トラブルシューティング(デバッグ)について実体験から学んだこと」
https://qiita.com/kazuo_reve/items/d8fff990b8f2e691ad74

分析について

[38]柏原一雄，「ゴールに繋がるアクションを生み出すデータ分析活動の事例　精度より成果」，SPI Japan 2019，2019
http://www.jaspic.org/event/2019/SPIJapan/session3C/3C3_ID019.pdf

[39]暁美焔，「認知バイアス一覧で社会心理学入門〜社会科学の知の蓄積を活用した社会教育の実現に向けて〜」，2019
http://lelang.sites-hosting.com/naklang/method.html

感情バイアスや正常性バイアスにより、人はどうしても、自分の都合のよいほうに分析してしまいがちです。

• 感情バイアス
  好ましくない，精神的苦痛を与えるような厳しい事実を受け入れたがらない人の特性．
• 正常性バイアス
  自分にとって都合の悪い情報を無視したり，過小評価したりしてしまう人の特性．

[40]小川清，「一人HAZOPを組み合わせた効率的な分析作業」, WOCS2011, JAXA/IPA, 2011
https://www.ipa.go.jp/files/000005325.pdf

[41]@kaizen_nagoya，「仮説・検証（187）効率的なHAZOPの進め方」
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

[42]@kazuo_reve，「ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果」
https://qiita.com/kazuo_reve/items/c1c1d32baed5d60d55c7

一人HAZOP（ガイドワード）は想定外を抽出するために、非常に有効な手法です。ただし、体験をしてみないと有効な手法であるという実感はわかないかもしれません。

計画について

[43]@kazuo_reve，「見積りに関する情報と知見」
https://qiita.com/kazuo_reve/items/4d74723faaad1c2875a0

[44]@kaizen_nagoya，「「オープンソースプロジェクトで上手いことやってくための10の方法」を拝読し」
https://qiita.com/kaizen_nagoya/items/81265788e7cf8f7b230b

「PDCAでも、CAPDoでもなく、DoCAP」という考え方は重要です。

[45]山路厚，「自らの改善につながる「一人ひとりの日々の“仕事ぶり”を捉える」仕組みについて ―トレーニング指向アプローチによるプロセス改善―」，SPI Japan 2010，2010
http://www.jaspic.org/event/2010/SPIJapan/session3B/3B2_ID022.pdf

[46]promapedia，「ローリング・ウェーブ計画法とは何か？反復計画法の１つを解説」
https://ssaits.jp/promapedia/method/rolling-wave-planning.html

山路厚さんが時間粒度（精度）曲線という考え方を提唱しています。
必要とされる計画の粒度は、作業を実施する当日が近づくにつれて詳細になるという考え方です。
計画に必要とされる粒度は、時期によって異なるという考え方です。
PMBOKで紹介されているローリング・ウェーブ計画法と、同じような考え方のように思います。

時間について

[47]行本明説，「図解・仕事術 最強の時間力―タイムマネジメントの法則60 (図解仕事術)」，エクスナレッジ，2003
https://bookmeter.com/books/439524

私は、書籍で紹介されていた次の２つを実践しています。

• 「個人作業の開始時刻」と「人と一緒にやる作業の終了時刻」を意識する。
• 隙間の時間を使う。

[48]山路厚，「-トレーニング指向アプローチの土壌作り- 疲弊した組織を蘇らせる」，SPI Japan 2009，2009
http://www.jaspic.org/event/2009/SPIJapan/session1A/1A1.pdf

簡単なことでも忙しさを理由に後回しにしていると、簡単にできなくなります。
日々の基本動作であり、いつもはできていたことも、できなくなります。

振り返りについて

[49]清水吉男，「「反省」の落とし穴」
https://www.affordd.jp/koha_hp/LectureSE/LecSE.hansei.html

反省をするのではなく、「上手く行くパターン」を探し、繰り返すが結構大事です。
清水吉男さんに肯定眼という考え方を教えていただきました。
https://business087.com/gensisiroku/#toc4

機械学習の教師データと同じで、学習するためには、失敗だけでなく、成功と失敗の両方を経験していることが必要ですね。

頑張るについて

[50]安達裕哉，「頑張れば頑張るほど、成果が出なくなる「落とし穴」の話。」
https://blog.tinect.jp/?p=66582

学習について

[51]@kaizen_nagoya，「仮説・検証（29）勉強しているって、強いて勉めることじゃなくて」
https://qiita.com/kaizen_nagoya/items/1b55b91665cb51af701c

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

[53]@kaizen_nagoya，「仮説・検証（143）学習意欲を維持する方法」
https://qiita.com/kaizen_nagoya/items/a68063d040c81d29927a

好きなことだけ勉強すればいいと思う。

「好きなことを勉強する」という考え方は大切。
能力が高い人に「週末に○○の勉強とかしているの？」って聞いたことがあります。答えは「特に勉強してないですよ。昔から○○が好きなんですよ。」でした。好きの度合いによって、学習のスピードが全然異なるのかもしれないです。

[54]@fromdusktildawn，
https://mobile.twitter.com/fromdusktildawn/status/1483422070809952259

①好きになる→②感覚を掴む→③本で体系的に学ぶ→④実践 の優先順位でやると、質の高いスキルを素早く学べる。

私の経験則でも、③から入らず②から入るほうが学びやすいと思います。
ヤマハの小池利和さんからは、「まずは手を動かしなさい」と教えられました。「手を動かす」ということは、感覚を掴むための手段なのかもしれません。

[55]mennousan，
https://mobile.twitter.com/mennousan/status/1169400580076261377

わかったのは、成果を出してる人には共通点があること。
・よさげなものをやってみる
・いいものをマネする
・それをとことんやり抜く
・よければ続ける
・よくなかったら改善か、やめる

「いいものをマネする」って、自分の経験則からしても、すごくいいことです。いいものを自分で、一から考えるんじゃなくて、マネしちゃえばいいですね。
でも、簡単そうなんですけど、なかなかうまくできないですね。
よく、以下の状態に陥りがちに感じます。

• なにがいいものかわからない
• マネするパワーがない
• ちょっとうまくいかないと、勝手に自分には合わないと判断して、やめてしまう
• いいものではなく、よくないものをマネする（マネさせられる）

[56]牛尾剛，「プログラミングというより物事が出来るようになる思考法」，2021
https://note.com/simplearchitect/n/n388201603a28

どんなに頭がいい人でも理解には時間がかかるものなのだ。
「理解は時間がかかるもの」として、早くしようとせず、徹底的に理解する習慣をつけていく。

写経について

[57]@momotaro98，「プログラミングの勉強方法として写経は非効率？」
https://qiita.com/momotaro98/items/9d1075df13a98669d1b7

[58]@yuya_takeyama，「写経でプログラミングが上達するか」
https://qiita.com/yuya_takeyama/items/b8a8c548a4a1c6a05531

[59]@cervomansan，「プログラミング初心者の勉強方法について」
https://qiita.com/cervomansan/items/9aa3cc003807d370226b

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

情報収集について

[61]@viva_tweet_x，「エンジニアの「雑談」の効能を考える」
https://qiita.com/viva_tweet_x/items/dd9d3353d1b961fd1c71

[62]西野亮廣，「なぜ、挨拶をしなければならないのか？」
https://www.youtube.com/watch?v=Jh9ktDAnb_I&feature=youtu.be

情報を得やすくするために、挨拶以外にも重要なことがありそうです。

キャリアについて

[63]安達裕哉，「自分のキャリアの作り方。何歳までに何をやるべきか。」
https://blog.tinect.jp/?p=24552

この記事にあるキャリアの作り方は、自分の経験にかなり当てはまります。自分の経験測からすると、結構いいキャリアの作り方のように思います。

[64]斎藤昌義，「あなたに「転職力」はありますか？」
https://www.netcommerce.co.jp/blog/2020/02/09/15061

変化・挑戦について

[65]デイル ドーテン，「仕事は楽しいかね?」，きこ書房，2001
https://bookmeter.com/books/561576

[66]植松努，「失敗を恐れるのではなく、失敗によるマイナス評価を恐れる人達」
https://ameblo.jp/nyg1t10/entry-12561221953.html

[67]植松努，「思うは招く」
https://www.youtube.com/watch?v=gBumdOWWMhY

[68]清水吉男，「１日５分間トレーニング」
https://www.affordd.jp/koha_hp/LectureSE/LecSE.5min.html

[69]G.M. ワインバーグ，「スーパーエンジニアへの道―技術リーダーシップの人間学」，共立出版，1991
https://bookmeter.com/books/375446

スキルについて

[70]安達裕哉，「仕事の礎は、何よりまず「国語力」という話。」
https://blog.tinect.jp/?p=68354

[71]松尾谷徹，「テストから観た実体のモデリングと実装構造の評価　～ 検証指向設計の実現に向けて ～」，JaSST'15 Tokai ，2015
http://www.jasst.jp/symposium/jasst15tokai/pdf/S1.pdf

松尾谷徹さんがおっしゃるように、プログラミングには再現性がありませんね。「同じ仕様があれば、誰が作っても、同じコードができる」というわけではありませんね。ブリコラージュですね。

[72]Junichi Niino，「プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという」，2009
https://www.publickey1.jp/blog/09/106.html

実際、私のプロジェクトでもコードリーディングとコーディングで6倍以上のスピードの差がありそうということがわかりました。特に、コードリーディングのスキルの差が大きそうです。（6分の1の人も能力がないわけではなく普通に成果物は生み出せる、できる人が圧倒的過ぎるのです。）

育成について

[73]開米瑞浩，「頭のいい「教え方」すごいコツ!」，青春出版社，2009
https://bookmeter.com/books/205944

昔、メンバを指導している”つもり”でいました。「毎回説明しているのに、なんでできないんだろう」と思うことが多かったです。実際には、自分の教え方（説明の仕方）に問題があったのだということに、気づかされる本です。 前提知識がなければPDCAサイクルを回すことはできない。つまり成長できない。事前に知識を伝えることをサボってはいけないということに気づかされました。仕事をさせながら知識を伝えればいい（OJT）という考え方がダメだったのかもしれません。
ちなみに、今もうまくできているとは言い切れません。

[74]u_1roh，「「育てる」なんておこがましい」
https://u-1roh.hatenadiary.org/entry/20070602/1180794278

[75]安達裕哉，「「いい人」が必ずしも「良い上司」ではない理由。」
https://blog.tinect.jp/?p=62594

岡田監督の「人を育てるなんておこがましい」「人が育つのを邪魔しない」という言葉は、結構好きです。
昔、デンソークリエイトの山路厚さんにも言われた気がします。ソニーの栗田太郎さんとも同じような話をさせていただいた気がします。
自分の過去を振り返っても、育ててもらったというより、育つ場を与えてもらったというほうが、合っている気がします。
自分も、育つのを邪魔していないように、注意します。でも、これ結構、難しいことだなと感じてます。
教育や指導やしつけの名の下に、実は自分にとって都合の良い人にしようとしているだけで、育つのを邪魔してるかもしれません。自分が失敗の被害を受けたくないために、任せることをせず、手や口を出し、育つのを邪魔してるかもしれません。
仕事でも子育てでも気をつけないと。。。
ちなみに、うちのポポラスの木は、植木鉢から出して、庭に植えたら、めちゃくちゃ大きくなりました。水をあげなくても大きくなりました。