エンジニアに気持ち良くコーディングしてもらうために実施している11の施策

# この記事の対象者
・開発会社の経営者（CEO/CTO）
・エンジニア組織のリーダー（VPoE/TechLead/Lead Engineer）
・その他のエンジニアに気持ち良くコーディングしてもらいたい人たち

# 記事の投稿者
iOS/Androidアプリを中心としたシステム開発会社の経営者です。最近までバックオフィスメンバーが皆無のエンジニアだけの組織で、「エンジニアに気持ち良くコーディングしてもらうこと」を目的として、過去にやって来たことをまとめました。

# エンジニアに気持ち良くコーディングしてもらうために実施している11の施策
## 1. ディスプレイを用意しよう
コーディングする画面、ターミナルを触る画面、検索する画面が物理的に分かれていると生産性が上がる。1台で充分と言う人もいれば2台欲しいと言う人も。

## 2. 良い椅子を用意しよう
コーディングに詰まっている時に座り心地が悪いと気が散ってしまう一つの要因。長く座っても疲れない椅子を用意しよう。当社の椅子は全てHerman Miller社のセイルチェア。

## 3. 統合開発環境（IDE）へ投資しよう
こだわり

技術同人誌執筆の楽しさ、効果

この記事は KLab Engineer Advent Calendar 2019 23日目の記事です。
Advent Calendar は一昨年、去年に続き参加する mizusawa-k です。よろしくお願いします。

# はじめに

昨今、技術同人誌イベントの盛り上がりが出てきており、中でも特に大きなイベントである技術書典では
来年開催される第8回にてこれまでの一日開催から二日開催にするという試みが取られています。

本記事ではこのような技術同人誌の執筆とイベントへの参加を
過去5回会社の有志で行い、個人でも行なってみた筆者が思う技術同人誌執筆の
楽しさ、効果について紹介したいと思います。

**技術同人誌イベントとしては最も規模の大きなイベント、技術書典のサイトページ**
【Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本】を段階的にまとめた

#これってなんなの？
**【ど素人状態＝社会人になって初めてプログラミングを勉強したぜ！（特に新卒）】〜【Webエンジニアの３年生ぐらい】になるまでに読むと良い本まとめです。「どんな目的で学ぶか？」*「いつぐらいまでに読むといいか？」を段階的にまとめました。**「これだけ読めばいい！」と、そんな簡単な話ではありませんが、「今いるレベルより少し上の人がどんなジャンルのことを学んでんだろ？」という方の参考になれば嬉しいです。過去の自分に向けてでもあります、自戒。これからWebエンジニアになる人、なって間もない人の参考になれば幸いですm(__)m

# ”Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本”の段階的まとめ（一部外部記事あり）
## ど素人の方々が手を動かしながら１〜６ヶ月以内に学ぼう！
### ◆どの職種のエンジニアも全員学ぼう！
#### 「1つの言語を理解し、動作させることができるレベルになろう！」
* [たのしいRuby](https://www.amazon.co.jp/%E3%81%9F%E3%81%A

markdownで技術書を書いてpandocでpdfやicml(indesign)に変換する

本記事は　Pandoc Advent Calendar 2019　17日目担当しています。
https://adventar.org/calendars/4338

#　概要
私は技術書を執筆する際に、gitでのバージョン管理が行えることから、markdownを使用しています。
その際にpandocを併せて使用することで、markdown原稿をお手軽に形式変換することが可能です。
（pandocは別途brewなどでPCへインストール済なことを想定した記事です）
形式変換することで、組版などをindesignで行ったりとmarkdownを扱いやすくすることが可能になります。

本記事ではコマンドを応用したものとして、シェルスクリプトでmarkdown原稿を一括で処理することをテーマに書いています。

## indesignで組版をするためにicmlに変換
“`shell

cd `dirname $0`
for fname in *.md;do
pandoc $fname -s -o ${fname%.md}.icml
echo convert comp!
done
“`
i

達人に学ぶSQL徹底指南書第2版を読んで

自分なりに所感とまとめ。

## 構成

– 1部がSQLのサンプルケースと使い方について
– 2部が歴史や背景・概念などについて
– 3部が1部の演習問題の解答、参考文献

と言った形になっています。
お忙しい人は1部のサンプルケースをつまみ食いして読むのも良いかも。

## 個人的に参考になったところ

再認識させられたところやなるほどな～となったところを抜粋。

– CASE式はELSEを必ず書こう
– MySQLでSELECT句とGROUP BY句に同じCASE式を書かなければいけない場合、SELECT句のCASE式部分に別名を付けて別名をGROUP BY句で指定する
– CASE式はどこにでも書ける
– ウィンドウ関数のフレーム句で異なる行のデータを1つの行に持ってこれる＝行間比較が容易になる
– NULLは値でも変数でもない
– NOT INのサブクエリで使用されるテーブルの選択列にNULLが存在＝SQL全体の結果は常に空
– テーブルはファイルではない。行も順序を持たない。そのためSQLでは”原則”ソートを記述しない。
– ソートを回避する
– 余計な中間テーブルを減らす

やってよかった読書会技術書7冊

## はじめに

テックタッチアドベントカレンダー1日目を担当する[@taisa831](https://twitter.com/taisa831)です。

エンジニアとして35才を迎えたのもあり、振り返りも兼ねてこれまでやってきた読書会の技術書についてまとめてみました。本記事では主に「書籍について」よりも、「その時なぜその本の読書会をしたか」「やってどうだった」を主に書いていこうと思います。覚えている限り時系列順に並べています。

## 増補改訂版Java言語で学ぶデザインパターン入門参照にされがちな技術書3選

技術書の中で他の技術書の内容が引用されてることって結構ありますよね。
独断と偏見でこの技術書よく出てくんなーってやつ紹介します。

先に参照されている本の内容を知っていると、理解しやすくなるので、技術書読みはじめたい！って人向けに。

統計とか撮ってるわけではないんであくまで感覚です。

##オブジェクト指向における再利用のためのデザインパターン 増補改訂版Java言語で学ぶデザインパターン入門 ##

https://www.amazon.co.jp/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%86%8D%E5%88%A9%E7%94%A8%E3%81%AE%E3%81%9

Webエンジニア1年目の自分に捧げたい本・記事を超まとめ

そろそろWebエンジニア3年目の折り返しになるので、Webエンジニアとして働く中でこれまで読んできた情報たちをまとめようと思い立ちました。

エンジニア3年目の今だからこそまとめられる情報として、「エンジニア1年目の１年間で読んでおきたかったな〜。」という本と記事をまとめておきます。
まとめ始めたら楽しくなってしまい、情報量が多くなってしまった…。全部手に取るのは不可能だと思うので、サーっと目を通して見て興味が湧いた本や情報を手にとっていただけると良いかと。

これからWebエンジニアになる人、Webエンジニア1年目の人の参考になれば幸いです。

これは何？

Webエンジニア1年目が仕事を進める上で絶対に求められるであろう知識を、技術力・Web知識・仕事の進め方・キャリアの観点からまとめました。

「これだけ読んでおけば絶対大丈夫！！」という安易なものではありませんが、「どんな知識を学べばいいのさ？！」という方の参考になればと思います。

↓この記事で紹介している本も含め、2019年12月9日まで半額セールになっている技術書を目的別にまとめたこちらの記事も合わ

プログラマのモチベをアゲる本 7選

「より良いプログラムを書きたい」と思うプログラマへ

プログラマとして、
エンジニアとして、
モチベーションを高めたい方へ
おすすめの名著7選をご紹介させていただきます。
***
**1. 達人プログラマー システム開発の職人から名匠への道**
[](https://www.amazon.co.jp/%E6%96%B0%E8%A3%85%E7%89%88-%E9%81%94%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC-%E8%81%B7%E4%BA%BA%E3%81%8B%E3%82%89%E5%90%8D%E5%8C%A0%E3%81%B8%E3%81%AE%E9%81%93-Andrew-Hunt/dp/427421933X/ref=pd_sbs_14_t_0/352-

プリンシプルオブプログラミング まとめ 【技術書アウトプット その１】

##はじめに

[プリンシプルオブプログラミング](https://www.amazon.co.jp/%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B7%E3%83%97%E3%83%AB-%E3%82%AA%E3%83%96-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B03%E5%B9%B4%E7%9B%AE%E3%81%BE%E3%81%A7%E3%81%AB%E8%BA%AB%E3%81%AB%E3%81%A4%E3%81%91%E3%81%9F%E3%81%84%E4%B8%80%E7%94%9F%E5%BD%B9%E7%AB%8B%E3%81%A4101%E3%81%AE%E5%8E%9F%E7%90%86%E5%8E%9F%E5%89%87-%E4%B8%8A%E7%94%B0-%E5%8B%B2/dp/4798046140/ref=pd_bxgy_14_img_3/356-8587740-5501147?_encoding=UTF8&pd_rd_i=4798046140&

Ruby、Rails を学ぶ上でのおすすめの本まとめ

# これは何？
Ruby、Rails に関して何によってどう学んできましたか？というのをよく聞かれるので、まとめた。
あくまで個人の経験に基づく感想です。

(書籍へのリンクはアフィリエイトではありません)

# 対象
とりあえず Ruby でちょっとしたスクリプトは書けるし、Rails も軽く触ったことはあるよ、という方。
(全くRuby触ったことない人向けではないと思います)

# 本

## Rubyの言語仕様を学ぶ
### 効能
* Ruby っぽい書き方ってどんな書き方なんだろう？を学べる(map 使うとか)。
* Rails を読む上でのおまじないが減る。
* なぜ attr_accessor を書くとセッター/ゲッターが生えるのかとか、モデルがActiveRecord を継承していることの意味とかがわかるようになり不安が減る。

### 紹介
* [Effective Ruby](https://www.amazon.co.jp/dp/B00SF6JN4K/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)
* リ

貧乏プログラマ向け技術書の選び方

#はじめに
　本記事は、貧乏人の3年目SE（~~貧乏人歴は24年目）~~の私が、限られた資金の中で技術書を購入する際の指標としているものを書いています。
　主に給与が少ない若手SE、やりたいことが多いけどスキルアップがしたいSE向けです。
　**なお、本記事は、Javaを使うソフトウェアエンジニアの私が書いているため、Javaに情報が偏る可能性があります。**

#技術書を買って勉強しろ!と先輩に言われた
　かつて初めて開発案件に参画した際に、見出しの内容を言われました。
　しかし当時の私は（今も）お金があまりなく、生活がかつかつだったこともあり、
　主に以下の2点で吟味した技術書を購入していました。
　　**自分のレベルと書籍のレベル**
　　**発行年月**

　以下でそれぞれの項目を解説していきます。

#自分のレベルと書籍のレベル
　言うまでもないですが、自分のレベルが足りなくて理解ができない場合、買った書籍は埃かぶってしまいます。
　しかし、自分のレベルというものを把握するのは意外と難しいです。
　そこで、以下の3ステップを行っていました。
**1.目次をみる**

技術書を書く技術

# Intro
こちらの技術書を執筆しました。[15Stepで踏破 自然言語処理アプリケーション開発入門](https://www.amazon.co.jp/dp/4865941320)

本稿は書籍そのものの紹介ではなく、私が技術書を執筆するために利用した技術・用意した環境についての解説です。

私が執筆を始めた当時（2017年下旬）はWebを漁ってもあまり技術書執筆のノウハウがなく、本稿の内容も割と手探りでした。今ググってみると技術書展のおかげで大量に情報が出てきますね。それらと被る部分もありそうですが、自分が１冊書いてみて得たノウハウみたいなものをここに吐き出してみたいと思います。

# 執筆フォーマットの決定

まずは執筆に使うツールを決めます。
商業誌の場合、出版社（編集者）がそのフォーマットでの入稿を受け付けてくれるかどうかにも依るため、執筆者の一存で決められないこともあるようです。
私の場合は幸運にも、こちらの希望に合わせてくれる編集者が入ってくれました。

色々調べて↓あたりが候補だった気がします（漏れているかも）

* Markdown
* Pandoc
* Sphi

『リーダブルコード』を全然理解してないので、もう一度読んでみる

エンジニア界隈で評価の高い『リーダブルコード』。
この本を読む事によって、コードを読みやすくするテクニックや習慣をが身につくはず・・・だったのですが、レビューで指摘される事があり、うまく実践出来ていませんでした・・・
もう一度読んで内容をアウトプットすればもう少し身につくかなと思ったのでまとめます。

# 第I部 表面上の改善

## 1章 理解しやすいコード
優れたコードとは、理解しやすいコードである。この本で取り扱うテーマ。

## 2章 名前に情報を詰め込む

* **明確な単語を選ぶ**
def GetPage(url)という名前があるとする。
この場合getの意味合いが広すぎるので、インターネットから取ってくるのであれば、FetchPage()やDownloadPage()の方が明確。

* **汎用的な名前を避ける(あるいは、使う状況を選ぶ)**
tmp、retval、fooより値や目的を表した名前を選ぶべき。
tmpを単に一時保存の変数として使うなど、場面によっては使用しても問題ない。

* **抽象的な名前よりも具体的な名前を使う**
抽象的な名前を避け、具体的な

技術書典を楽しもう part3～アプリでお会計編～

# 目的

– 技術書典でのアプリ会計の方法を知る。
– アプリ会計の不安を解消する。

# この記事のターゲット

– アプリ会計は便利そうだけど使い方が分からなく困っている方
– 小銭をたくさん用意することが面倒な方
– クレジットカード・デビットカードでお支払いをしたい方
– サークル出店側の方の労力を少しでも軽くしたい方

※技術書典開催前日までの内容も別記事でまとめています。もしよければご覧ください。
[技術書典を楽しもう part2 ～当日偏～](https://qiita.com/miriwo/items/a2d857694dd18ef97b25)
[技術書典を楽しもう part3～アプリでお会計編～](https://qiita.com/miriwo/items/af9fc79224199d547297)

# アプリ会計とは

– 各サークルにあるQRコードを読む事でお会計できるよ。
– 公式アプリを使って会計するよ。
– 購入者とサークル側それぞれでメリットがあるよ。
– その場で引き落とされず、PayPalなどを使って後日支払うよ。

# 支払方法の概要

1.

技術書典を楽しもう part2 ～当日偏～

# 目的

– 技術書典当日にやっておくとよいこと、当日の流れなどを知る。
– まだ技術書典に参加したことのない方の参加ハードルを下げる。

# この記事のターゲット

– 技術書典に参加したいけどどの様に参加したらいいか分からない方
– 技術書典当日の雰囲気が知りたい方
– 何かしらの技術系イベントに参加したい方

※技術書典開催前日までの内容も別記事でまとめています。もしよければご覧ください。
[技術書典を楽しもう part1 ～参加サークル公開前から前日まで偏～](https://qiita.com/miriwo/items/a2d857694dd18ef97b25)
[技術書典を楽しもう part3～アプリでお会計編～](https://qiita.com/miriwo/items/eea6a0658719d1148383)

# 当日の流れの概要

1. 池袋のサンシャインシティにある文化会館に向かう(早速若干の難関)
1. 運営さんの指示に従い前売り一般入場整理券を持っている方は入場待機列に並ぶ
1. 入場して技術同人誌を購入する(アプリでの購入方法は別途記事を用意する予定

オープンデータコミュニティとして技術書典7にサークル参加してみた

2019年9月22日に開催された[技術書典7](https://techbookfest.org/event/tbf07)で[LODハッカソン関西](https://techbookfest.org/event/tbf07/circle/5630263371497472)というサークル名で技術書を頒布しました。LODハッカソン関西は、オープンデータの利活用の技術を広めるために活動しているコミュニティで、オープンデータをテーマとした技術書を頒布しましたが、今回、技術書典にオープンデータを扱うサークルとして実際に参加していたのは我々だけのようでした。

参加してみて、技術書典(または技術同人誌即売会)がオープンデータコミュニティとして参加して、オープンデータを扱う技術を広める場としても良いイベントだと感じ、そのニーズも少なからずあるように思いました。次回以降、オープンデータコミュニティからのサークル参加が増えることを期待して、参考になればと思い、我々の頒布するまでの過程を投稿します。

# 準備

サークルのメンバーは、執筆者が私含め3人とデザイナー1人の計4人です。サークルの窓口は私が

技術書典を楽しもう part1 ～参加サークル公開前から前日まで偏～

# 目的

– 技術書典前日までにやっておくといいことを知る。
– まだ技術書典に参加したことのない方の参加ハードルを下げる。
※長い記事を読むことが面倒な方のために最後に伝えたい情報を記載する。

# この記事のターゲット

– 技術書典に参加したいけどどの様に参加したらいいかわからない方
– 技術書典の前売り一般入場整理券を購入したが、その他にも準備する方法を知りたい方
– 何かしらの技術系イベントに参加したい方

※技術書典開催前日までの内容も別記事でまとめています。もしよければご覧ください。
[技術書典を楽しもう part2 ～当日偏～](https://qiita.com/miriwo/items/af9fc79224199d547297)
[技術書典を楽しもう part3～アプリでお会計編～](https://qiita.com/miriwo/items/eea6a0658719d1148383)

# 技術書典とは？？

– とっても楽しい技術系イベントだよ
– 技術同人紙の販売会だよ
– 技術書のコミケみたいなものだよ
– ニッチな技術書が買えるよ
– 池袋

「ITエンジニアのためのビジネスアナリティクス」読書メモ【更新途中】

## 書籍情報

[ITエンジニアのためのビジネスアナリティクス](https://www.amazon.co.jp/gp/product/4822285030/)
2019/07/20読了

## 個人的に印象に残った個所とメモ(※更新途中)

### ビジネスルールからのソリューション構築
– ビジネスの整合性とアジリティというもろ刃の剣
– ビジネスルール⇒構造化言語 RuleSpeak
-「ゾウを見よう」⇒盲人とゾウ

### 第1章
ビジネスアナリシスの基本原則

– ビジネス担当者とビジネスについて話すときには、日常的に使用する用語以外のものを用いてはならない
– 「ユーザー」という語を用いないこと。

「エンジニアリング組織論への招待」読書メモ

2019/07/18 読了
個人的に印象に残った内容や用語の記録、メモ

## マーカー／メモ
– エンジニアリングは「実現」の科学
– 仮設法。わずかな痕跡から、それを説明可能とする大胆な思考展開、モデル化を行い、その証拠を探す
– BSとP/Lは微分積分の関係
– アジャイルは3倍の成功率、1/3の失敗率。大規模プロジェクトほど効果あり
– トヨタの特殊工と多能工
– 心理的安全とは、高い生産性を実現するための追込み法。ぬるま湯的な安心ではない
– エントロピー増大の法則に対しての散逸構造論、自己組織化
– 単純なルールが複雑な構造を作る「創発」。管理者のいない中で秩序を構築していく様子
– クールエイドを飲むな
– 役割を分けない
– 経験のみを知識に変える
– プリンシパル、エージェント理論
– CCPM、ToC理論。サバ取り。プロジェクトバッファ
– 見積り手法の一つ、Tシャツサイズ。
– 生産性とは
– 技術的負債、最初のコードは借金と同じ。固定的箇所と変動的箇所を設計。ジェンガの例
– 社内における取引コスト
– 管理会計の罠。企業内部に技術組織を持つのは取引コストを減少