まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

はじめに 「ユーザーエクスペリエンス(UX)デザイン」という言葉を、よく耳にするようになりました。UXデザインの分野には、エンドユーザーのニーズをつぶさに拾いあげることで、プロジェクトやビジネスを成功に導くためのノウハウが集まっています。 UXデザインの基本のひとつは「エンドユーザーにインタビューにいく」ことです。 本連載を通じて、ユーザーインタビューの「はじめの一歩」を体験していきます。第1回、第2回では、「そもそもユーザーニーズはどのようにすればわかるのか」について解説します。 「エンドユーザーにうれしいものづくりをしよう」と考える UXデザインでは「私たちは、誰を『しあわせ』にするために、ものをつくっているのだったか?」を強く意識します。 UXデザインの根本的な思想は、「エンドユーザーにうれしいものづくりをしよう」と考えることです。エンドユーザーにうれしいものをつくり、ビジネスがうま

エンジニアを目指して今プログラミングを勉強している人向けに、開発に関してより知識を深められる新人研修スライドをまとめました。 Progateやプログラミングスクールだけでは学べない内容ばかりなので、新人エンジニアの人は目を通しておくといいです。 各企業で新人研修で実際に使われた資料なので、どんなことが開発の現場では求められるのかということが掴めます。 ここにある内容を100%理解することは難しいですが、少なからずインターンや就職をする時に役立つはずです(わからない箇所は本などを読んで補足しましょう)。 ▶プログラミングを効率良く勉強したい人はこちらの記事 もオススメ 全員共通で読むべきスライド Cookpad★ この資料で学べること リクルートテクノロジーズ★ この資料で学べること Git/コードレビュー GMOペパボ この資料で学べること GMOペパボ この資料で学べること GMOペパボ

エンジニア（ここでは主にプログラマー）に必要な知識や経験って、ざっくりベース、カテゴリ、実行環境というレイヤー分けられると思ってて、それぞれに対してはだいたい以下のような定義で考えている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの低レイヤー②カテゴリ フロントエンド / バックエンド / クライアントアプリなど③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど最近の潮流で言うと、③の部分から入る人が多いと思う。 ③は比較的習得が楽なこともあって、初心者がプログラミングを始める際には一番コストパフォーマンスが高い。中身はブラックボックスであってもなんとなく動くものは作れるので、自己満足にしろ仕事にしろ成果として見えるものにはなる。 ただし、流行り廃りが速く、手を動かし続けないとキャッチアップしていけない。 ①は習得するのに時間かかる。その

こんにちは koogawa です。最近は Stack Overflow だけにとどまらず、エンジニア向けQAサイト teratail でも回答しております。teratail はスコアが上がっていくと色んなバッジをゲットできるので気に入っています。 teratail【テラテイル】｜思考するエンジニアのためのQAプラットフォーム ところで今日は次の質問に回答しました。 teratail.com これ、めちゃくちゃ良い質問だと思うんです。何より自分がわからないことをちゃんと言語化できている。 すでに回答もいくつか付いていたので内容を見てみると。。 ぐぐる。これに尽きます 普通にググれば見つかるのに 何がわからんの？ だいたいこんな感じでした。 うーん、皆さんなかなか手厳しい回答です。。これだと質問者の方も、ここで挫折してしまうのではないでしょうか。 回答してみた というわけで「自分ならどうググる

こんにちは。加藤泰明と申します。 特定派遣やSES（準委任契約）にて客先常駐で働くインフラエンジニアです。 ※職務経歴書をGitHubで公開しています。 私は勤務先の企業（以下、自社）から単独で客先に送り込まれることが多く、1人ぼっちの現場でいかに生き延びるかを探究してきました。 今回は、たった1人で客先に送り込まれたエンジニアが、そこで生き延びるにはどうすればいいのか、具体的な8つのテクニックをお伝えします。 ※ここでは、客先常駐するエンジニア（一般・特定派遣、SES含めて）のことをパートナーと記しています。 第1条　客先プロパーの期待値を調整するIT業界の慣習として、パートナーとして我々が客先常駐する前に、我々と客先のプロパーが直接会話する機会が設けられることがほとんどです。 （職場見学、お打ち合わせ、面談等、企業によってその機会の名称が異なります） 正直に申し上げますと、その際に、パ

先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変

ふるまいやセキュリティ意識など技術以外も磨け！N高講師が教えるプロエンジニアに必要な要素 この春から「プロのエンジニア」として働き出す方々に知ってほしい「技術以外の心掛け」を、N予備校プログラミングコースのプログラミング講師＆全教材を制作する吉村総一郎さんに教えてもらいました。 大学や専門学校などを卒業し、この春から「プロのエンジニア」として働きだす方々も多いかと思います。プロのエンジニアとして「技術」をしっかり習得し、磨くことはもちろん大切ですが、いざ組織やチームで働きだすと、同じくらい重要視されるのが「技術以外の部分」です。 今回は、はてなブックマークやブログなどで大きな反響を集めている「N予備校 プログラミングコース」のプログラミング講師を務め、全ての教材の制作を行った吉村総一郎さんに「これからプロとして働く若手エンジニアに伝えたい技術以外の重要なこと」をまとめていただきました。 は

はじめに ※大層なタイトル書いてるけどただの日記みたいなもんです ※あくまで個人の見解であり、所属する団体・組織の見解ではありません 現在自分は客先常駐型でエンジニアの派遣を行う事業をメインとする会社で、小規模ながら社内で受託開発を行う部署に在籍している。その組織の仕組みは「プロジェクトマネージャー」と「組織の管理職という肩書としてのマネージャー」が兼任になることが（自分も含め）ほとんどだった。なんでもできるマネージャーがタスクを分解、できそうなメンバーにアサインし、メンバーはタスクをこなすのみに注力という構図で、以下のような問題が起こっていた。 マネージャーが非常に多忙でSPOFになるケースが多々。とてもじゃないが休めない できる人のみにタスクが集中し、できない人は本当に何もしてない メンバー間での責任の押し付け合い マネージャーからメンバーに対する高い圧力 やる気があるメンバーのモチベ

この記事を書いている動機 Twitterである方が「ほとんど専門外だけどもっとテストのことを知りたい」みたいなことを書かれているのを見かけて、最初はその人に直接リプライしようかと思ったのですが、もしかしたらガチの初歩からテストの勉強したいって人は他にもいて、意外に需要あるのかも？と思ったのでブログとして書くことにしました。 目次はこちら。ガチの初心者の方でもわかるような資料を選んでいます。 この記事を書いている動機 テスト入門にちょうど良さそうなスライド（手前味噌含む） テストをやることになった新人が読むべき最初の記事 この3冊は必読。しかし最初から全てを読まなくてもいい 何はともあれ「第１章（導入部）」は絶対に読もう 「仕様書通り」だけがテストではない テストプロセスについて テスト観点 is 何 問題 テスターと開発現場 おわりに テスト入門にちょうど良さそうなスライド（手前味噌含む）

本エントリーはBacklog Advent Calendar 2017 の12/17の記事になります。 上京してからの10年 23歳で上京し、ITエンジニアとして仕事を続けています。最初は順調にキャリアを積んでいけましたが、3.11 のあの日から、私の人生は大きく変わりました。 年月 出来事 2006年10月 第二新卒でIT系インフラエンジニアになる 2011年3月 東日本大震災で帰宅困難に 切迫流産で倒れて療養、プロジェクトリーダーから降格 2011年9月 長男出産 2012年4月 保育園に全部落ちる 2012年5月 復職のため執筆や資格取得をはじめる LPIC304に合格。産休・育休中のスキルアップについて - Mana Blog Next 2013年4月 長男の保育園が決まる クラウドエンジニアとして転職 2013年12月 長男が肺炎で入退院を繰り返す 看護に専念するため退職 息子の

2017年12月15日にエンジニアのためのデザイン思考入門という本が発売されました。 www.shoeisha.co.jp 東京工業大学のエンジニアリングデザインプロジェクトという講義が元になっているのですが、 デザイン思考の基礎を学ぶにはピッタリな本だと思います。 僕は会社の事例を寄稿しています。是非読んでみて下さい！ 感想や疑問点などあれば教えていただけると嬉しいです。 『エンジニアのためのデザイン思考入門』をいただきました！僕も寄稿しています📖東工大EDPの内容が気になる方やデザイン思考の事を学んでいる方は是非読んでみてください！😃