エンジニアの書籍一覧

カジュアル面談したらお祈りされた！そんなことはありませんか？
カジュアル面談を50社以上受けた筆者の体験談を元に書き上げた物です。
カジュアル面談に関する疑問について、これを読めば理解できます。
・カジュアル面談とは？
・カジュアル面談は面接と違うの？
・オンラインで行うカジュアル面談の感覚は？
ノウハウも多数書いております。
・カジュアル面談に関するノウハウ収録！
・オンライン会議ツールのノウハウ収録！
・カジュアル面談で使える文面を収録！
・筆者以外で体験した人の話、カジュアル面談を実施する会社側の話も収録！！

転職を考えている貴方に読んでほしい本です。
カジュアル面談を行っていない会社はもちろん！
カジュアル面談を行っているイケてる会社の人にも読んでほしい本です！
【目次】
第1章　カジュアル面談とは？
第2章　カジュアル面談のメリット
第3章　カジュアル面談をするときの注意点
第4章　転職サイトについて
第5章　転職サイト以外での活動について
第6章　カジュアル面談を受ける前にやること
第7章　カジュアル面談の日程を決める
第8章　カジュアル面談のときに注意したいこと
第9章　終わった後に行うこと
第10章　開催する前に行うこと
第11章　カジュアル面談の日程を決める
第12章　カジュアル面談のときに注意したいこと
第13章　終わった後に行うこと
第14章　カジュアル面談から次の段階へ
第15章　オンライン会議ソフトと日程調整ソフト
第16章　カジュアル面談に関する寄稿
第17章　一求職者のカジュアル面談への思い
第18章　コラム：話をする分量って難しいね。
第19章　「カジュアル面談のトリセツ」の体験談
第20章　カジュアル面談？いいえ、新卒採用とリクルーターの話です
第21章　非IT企業で社内SE（内製要員）を採用するのに2年弱かかった話
第22章　カジュアル面談、はじめました

本書はあらゆる技術職における、新人からベテランまでの成功体験・失敗体験についてのインタビュー集です。
新人エンジニアであれば、様々なキャリアを積んだエンジニアの成功や失敗体験に触れて自分のキャリアに活かすために。
成長途中のエンジニアなら先人から学ぶことで今後の仕事を加速させるために。
ベテランエンジニアであれば、自身の経験と照らし合わせて、今だからこそ人に学び今後につなげる
そんな情報として共有できればと思います。

【目次】
〈インタビュー1〉流通業なのに在庫数をゼロにしてしまった……
〈インタビュー2〉排気ガスの浄化システムが溶けて火災寸前に……
〈インタビュー3〉本番障害対応の解析のチャンスが……
〈インタビュー4〉明け方のシステムメンテ作業……
〈インタビュー5〉DB作成プログラムに誤りが……
〈インタビュー6〉ECUの法規不適合……
〈インタビュー7〉ひとつのシステム開発現場に長く携わりすぎた……
〈インタビュー8〉部下を活かせず雰囲気が悪く……
〈インタビュー9〉癖のある方と関わって精神面が……
〈インタビュー10〉技術に詳しくない人に目を向けなかったせいで……
〈インタビュー11〉ネットワーク工事が間に合わない……
〈インタビュー12〉ワンマン気質の社長のもとで……
〈インタビュー13〉客先からのクレーム対応に失敗……
〈インタビュー14〉NC旋盤を壊してしまった……
〈インタビュー15〉仕入れ先に無理な要求を……
ほか

本書は、筆者がスタートアップや上場企業で技術顧問に携わる中での課題や対策、提案についてまとめたものです。主な対象読者は、急にCTOやエンジニアリングマネージャーを任されることになった方や、現在テックリードとして働いており、将来のキャリアの選択肢として CTOやエンジニアリングマネージャーを考えられている方を想定しています。

【目次】
第1章　CTO、エンジニアリングマネージャーとは
第2章　採用. エンジニア採用面接でチェックするポイント
第3章　採用. 会社のフェーズで要求されるものの違い
第4章　採用. 採用広報の重要性
第5章　マネージメント. 組織透明性、生産性を高めるための施策
第6章　マネージメント. 技術選定時のチェックリスト
第7章　マネージメント. 仕組みや制度で品質を保証する
第8章　マネージメント. スケールにあわせてテストを書く量を変える
第9章　法規. 開発前に見る日本の法律一覧 その１（Web開発基本）
第10章　法規. 開発前に見る日本の法律一覧 その2（フィンテック、ハードウェア）
第11章　法規. 開発前に見る日本の法律一覧 その3（その他）
第12章　知財. 特許の基本
第13章　ファイナンス. ベンチャーファイナンスの基本
第14章　ファイナンス. 株式投資型クラウドファンディングの資本政策
第15章　ファイナンス. 資本政策の振り返り(メルカリ)
第16章　ファイナンス. 資本政策の振り返り(ラクスル)
第17章　ファイナンス. Ⅰの部読みこみ(Sansan)
第18章　新規事業. ソフトウェア設計とハードウェア設計の違い
第19章　新規事業. 論理的思考により柔軟なアイディアを生み出す方法
第20章　転職. CXOの持ち株比率

本書はエンジニア有志による「見積もり」についてのノウハウを紹介するための解説書です。見積もりテクニックとしての基本、例えば二点見積もりや工数把握の方法、可視化、また発注者、受注者としてのノウハウ、過去の炎上案件から得たものなど、盛りだくさんの内容です。

【目次】
第1章　見積もりに必要なもの（要件定義）
第2章　タスク見積もり
第3章　若手エンジニアのための作業時間見積もり入門
第4章　2点見積もりとふりかえりのススメ
第5章　アジャイルと見積もり
第6章　安全マージン
第7章　いわゆる相見積とRFPを比較する
第8章　見積もり依頼の基本（小規模Projectを発注する編）
第9章　フリーランス（受注側）にとっての見積もり
第10章　守備範囲外の開発の見積もり
第11章　スクラムとチームと統計的見積り
第12章　見積もる前に作業を終わらせろ
第13章　暖かみのある見積もりをする方法
第14章　納期と信頼
第15章　同人誌を作って見積もり体験
第16章　過小見積もりで炎上するプロジェクトから得られた学びと実践
第17章　フリーランスチームリーダーとしての見積もり失敗談
第18章　工数見積もりアンチパターン
第19章　コンシューマーゲームの見積もり（いにしえの記憶より）
第20章　見積もりきれぬ所要時間
第21章　開発時情報が得られないケースにおいての後付けでの規模見積りについて
第22章　建設業界の見積もり
付録A　フリーランスに必要な嗅覚
付録B　私の見積もり履歴書

【初級者を中級者にステップアップ！iOSアプリケーション開発者・教育者必携！】

本書はMVCやMVVMなどと呼ばれるiOSアプリケーション開発をするために必要な設計を学ぶことで、アプリケーション開発の初級者が中級者へステップアップするための各種デザインパターン学習書です。iOS初級者がスムーズに中級者になる為に必要な知識を体系的にまとめています。
〈本書の対象読者〉
iPhoneアプリ入門書を一通り読んだが具体的な作り方がわからない人
iOS歴6ヶ月未満の初級者
iOSエンジニア教育担当者
【目次】
第1章　前準備 ～おすすめ書籍
1.1　おすすめの入門書
1.2　中級者向けの書籍
1.3　その他UIやアニメーション、オートレイアウトなどの理解が深まる書籍
第2章　前準備 ～オブジェクト指向とは
2.1　オブジェクト指向とは？
2.2　クラス
2.3　継承
第3章　前準備 ～プロトコル指向とは
3.1　プロトコル指向とは？
3.2　プロトコル
第4章　前準備 ～入門書には書かれていないが重要なiOS開発Tips
4.1　コードでレイアウトを組む
4.2　IBActionを使わずコードで定義する
4.3　ViewControllerのライフサイクル
4.4　メモリ管理
4.5　Delegateを使って処理を別クラスに任せる
4.6　Closure
4.7　Grand Central Dispatch
4.8　Web API
第5章　Model View Controllerデザインパターン
5.1　MVCとは
　Model層の役割
　View層の役割
　Controller層の役割
第6章　MVCでタスク管理アプリを作ろう
6.1　Model層のレイアウト
6.2　View層のレイアウト
6.3　Controller層のレイアウト
6.4　タスク作成画面
6.5　AppDelegateでTaskListViewControllerをrootViewControllerに設定
第7章　Model View ViewModelデザインパターン
7.1　MVVMとは
　Model層の役割
　ViewModel層の役割
　View、ViewController層の役割
第8章　MVVMでGitHubクライアントアプリを作ってみよう
8.1　アクセスするAPI
8.2　Model層のレイアウト
8.3　ViewModel
8.4　View
8.5　ViewController
8.6　AppDelegateでTimeLineViewControllerをrootViewControllerに設定

本書は、エンジニアではない方が1人でSaaSを開発して販売・サポートまで行う方法を模索する本です。実現難易度は高いですが、現状存在するサービスや技術を活用してどこまでを実現できるのかを模索するための本です。
本書では、まずSaaSのアイディアを見つけてそのアイディアのニーズがあるかを探る方法を解説します。サービスが完成した想定の提案資料を作成し、Figmaで作成した画面案を用いてインタビューを行うことでアイディアを検証します。実際に筆者自身で資料や画面案を作成してインタビューを行った結果を載せています。その際、どの意見を反映してどの意見を反映しなかったのかのリアルな部分がとても参考になると思います。

【目次】
第1章　非エンジニアが1人でSaaSを開発するには
第2章　サービスのアイディアを見つけるには
第3章　アイディアへのフィードバックを得るには

If you are interested in the experiences of Bill Gates, Thomas Edison, or Soichiro Honda as an engineer, you can easily find the information by searching the web. However, there must be many other engineers in the world who have made endless efforts in addition to such well-known engineers. And each of them must have a unique and precious experience.
If you wanted to know more about the experiences of these engineers, how would you go about finding out about them? When I thought about the answer to this question, I could not find an easy way to get that information.
Imagine this.
If you are a newcomer to the world of engineering, don't you think that if you can hear in advance about the most successful and most unsuccessful experiences of engineers who have had a variety of careers, you will be able to make great use of them in your own career?
If you are a young engineer in the middle of your growth, don't you want to learn from your predecessors to further improve your skills and accelerate your work in the future?
If you are a veteran engineer, wouldn't you like to take some time to compare your past experiences and appreciate your own efforts and those of other engineers, even if only indirectly?
I had a strong desire to learn about the most successful and most unsuccessful experiences of "unknown" engineers who were not readily available in the search results.

In this book, we have interviewed engineers (with their permission) about their successes and failures in all kinds of technical fields, from newcomers to veterans, to create a collection of useful information that we can share with you.
In addition to paying the engineers for their experiences and efforts, we also interviewed them with our own money, and ordered the work of a designer to ensure that we do not treat their soulful experiences carelessly. In order to pay respect to the engineers as well as to avoid treating the soulful experience carelessly, we ordered a designer to help us with the binding and design.

I hope this will be of some help to you in your career.

October 01, 2021
KASATA

あなたがもし、 Coco ChanelさんやJihoon Suhさん、Marc Jacobsさん、佐藤可士和さんなどのデザイナーとしてのこれまでの体験について興味が沸けば、 WEBで検索をすればすぐにその情報が手に入るでしょう。しかし、 そのような知名度のあるデザイナー以外にも世の中には果てしない努力をしてきたデザイナーが世の中にはたくさんいるはずです。またそのデザイナーさん一人一人に唯一無二の貴重な体験があるはずです。
　もしあなたがそのようなデザイナーこれまでの体験について知りたくなったとき、どのような手段を取ればそれらの情報が得られるでしょうか。私がその答えを考えたときに容易にその情報が得られる方法は出てきませんでした。
想像してみてください。
　 もしあなたがこれからデザイナーとして社会に出ていく新人の立場だとして様々なキャリアを積んだデザイナーの一番の成功体験や一番の失敗体験などについて事前に聞いておくことができたら、その後の自分のキャリアに大きく活用できると思いませんか。
　もしあなたが成長途中の若手デザイナーだとしたら更なるスキルアップのため、今だからこそ先人から学びより今後の仕事を加速していきたいと思いませんか。
　もしあなたがベテランデザイナーであれば、ご自身のこれまでの経験と照らし合わせて、ご自身のされてきた努力、他のデザイナーのされてきた努力を互い間接的にでも労う、そんな時間を少しとってみたくありませんか。

私は検索をしてもなかなか出てこない”無名の”デザイナーの方の１番の成功体験・１番の失敗体験について、知りたい気持ちが強かったです。

そこで本書ではあらゆる技術職における、新人からベテランまでの成功体験・失敗体験について、ヒアリングを行い（デザイナーの方の了承を得た上で）有益な情報のまとまりとして皆さんに共有ができるものに仕立て上げました。
また、デザイナーの方々の体験や労力にはきちんとした対価を支払うべきと考え身銭を切ってヒアリングを行いました。

どうか少しでも皆さんのキャリアの一助になれば幸いです。

「プログラミングスクールに行って IT エンジニア目指します！」
最近よく聞くようになりました。
私も聞かれたら答えるのですが、いろんな思いが生まれ、うまく答えられずにいました。

本書ではこの質問を整理し、「IT エンジニアになる方法」を考え、幸せに IT エンジニアとして生きる方法を考えます。

本書で示す選択肢の一つとして「諦める」ことも挙げています。
「IT エンジニアになる方法」と言いつつ諦めることを勧めるのは、この仕事は何かしら好きになれるものが見つからないと辛く、精神を病んでしまうことも多い>からです。
タイトルと異なる結論ではありますが、不幸を減らしたいために挙げています。

当然、人によってアドバイスが違います。
本書は「もし私が現在、未経験から IT エンジニアになるとしてどうするか」を書いています>。
これは私にあった方法で、あなたに合うとは限りませんから、本書を手にとったからと言って>無理に本書に従う必要はありません。
あなたが信頼できるアドバイスをくれる人に従うのがよいでしょう。

「考える」こと、していますか？私たちは仕事においても日常生活においても考えることが山ほどあります。その際に行き当たりばったりの思考になっていないでしょうか？根拠のある解決策を選んでいると自信をもって言えるでしょうか？チームでアイデア出しをするとき、チームが一丸となって課題に対峙している感覚はあるでしょうか？ロジカル・シンキング、問題解決、アイデア発想法など、世の中には古今東西様々な「考える」方法を記した書籍があります。本書では、著者がそれらの書籍やワークショップデザイン、ファシリテーションの実戦経験から学んだことを3つのプロセスにまとめました。それが【考える枠を決める、課題を特定する、解法を特定する】です。本書が様々な人や現場の「考える」ことに役立つよう願っています。

【目次】
第1章　そもそも「考える」って何だろう？
第2章　考える枠を決める
第3章　課題を特定する
第4章　解法を特定する
第5章　チームで「考える」ために気をつけること
第6章　「考える」実践例