他社からも学ぼう！エンジニア研修資料を読んでみた！
はじめに
プラコレとして、これからエンジニア組織をどんどん成長させていきたい！とメンバーと話をしている中で、エンジニアの新卒研修をより一層整備していきたいという機運になっています。
そんな中、他社がどういった研修を行なっているのかリサーチしていたところ、
サイボウズさんが新卒研修向けの資料を公開していて
大変勉強になる内容だったので
知識の整理も兼ねて、備忘録として技術用語や知識、役立つTipsをまとめてみました！
対象
・エンジニア歴1〜2年の方
・あまり技術用語に詳しくない方
・アジャイルに興味がある方
何が書いてあるか
Webアプリケーションの仕組み、データベース、Docker、コンテナ、アジャイルなどなど
Webアプリケーション編
Webアプリケーション
Webブラウザをインタフェースとして入出力するアプリケーション。
通信はHTTP、表示はHTML&CSS。実際のアプリはサーバーにある。
ネイティブアプリ、デスクトップアプリとは別。
Webサーバー
HTTPを処理するサーバー。クライアントからリクエストを受け付けて結果を返す。
主にApache、nginx、IISなどがある。
Socket
サーバーとクライアントで通信するためのAPI。主にTCP/IPを使う。
プロセス
プログラムの実行単位。コマンドやアプリを起動するとプロセスが立ち上がる。異なるプロセスは並列に動くことができる。
別のプロセスのメモリにはアクセスできない。
スレッド
1つのプロセスの中の処理の単位。プロセスより軽く、並列に実行可能。同じプロセスの別スレッドのメモリにアクセスできる。
CGI(Common Gateway Interface)
Webサーバーとプログラムがやりとりするためのインターフェース。
リクエストが来るたびにアプリのプロセスを起動する。
Webアプリケーションサーバー
Webアプリケーションを実行するサーバー。CGIと異なり、通常は起動しっぱなし。
Webサーバーがアプリケーションサーバーにリクエストを中継する。
永続化/データベース
Webアプリを作るとデータを保存したくなる。プログラムやマシンが終了してもデータが残る。
素朴にファイルに保存すると、自分で競合・不整合を回避するのは大変なので、
難しいことの面倒を見てくれるデータベース管理システム(DBMS)があります。
データベース管理システム(DBMS)
RDBMS / SQL
「関係モデル」というものを扱うデータベース。SQLという言語で操作。
NoSQL
SQLに対抗して出てきたデータベース(大抵早いがトレードオフ有り)。
・キーバリューストア(KVS)
→キーとバリューのペアの形式だけで保存。
・ドキュメント指向データベース
→1件分のデータをドキュメントとして格納することができ、柔軟な構造のデータを保存。
ログイン
Webアプリにはほぼ必要な機能。ユーザー毎にデータを保存/ユーザーを特定。
ログインした後、別のページから戻ってきてもログインされたまま。
Cookie(RFC 6265)
サーバー側からクライアントにデータを保存させる仕組み。
サーバー：「Set-Cookie： <キー>＝<値>」というヘッダーを載せてレスポンスを返す。
クライアントはそのペアを保存する。
HTTPが状態を持つことができる。
セッション
一連のアクセスでデータを保持する仕組み。
Cookieではセキュリティ的に心許ない(パスワードを毎回送る場合、勝手に書き換えられる可能性がある)
→セッション開始時(ログイン時に)ランダムなIDを発行。
→それをCookieに保持する。データはIDをキーにサーバー側に保存する。
パスワードの保存
ログインできるWebアプリを作る場合ユーザー登録が必要。
多くの場合、ユーザー名とパスワードを登録させる。
パスワードをそのままデータベースに保存すると、情報流出した時に悪用されるかもしれない。
パスワードのハッシュ化
パスワードはハッシュ関数を通したハッシュ値を保存する。
ログイン時は入力されたパスワードのハッシュ値を取り、保存されているハッシュ値と比較。一致すればOK。
ハッシュ関数は、任意の長さのバイト列から固定長のバイト列を出力。
出力から入力の値の推測が難しい。
SHA-2、SHA-1、MD5など。
HTTPS
HTTPは通信内容が丸見え。
→パスワードを送ったり、セッションIDを見られたら悪用されるかもしれない
HTTPをTLSで暗号化して通信する⇨HTTPS
・内容を見られない。改ざんされない。なりすまされない。
・現代では必須(商用なら)
Webアプリケーションフレームワーク
Webアプリを作るのに便利な機能が詰まったライブラリ。
・HTTPの処理、Cookie、データベースのアクセス、テンプレートエンジンなどなど
フロントエンド
HTML
文書に構造や意味を与えるための言語。それぞれのタグがどういう意味を持つかルールで決まっている。
テンプレートエンジン
HTMLの中にデータを埋めたり、プログラム的に表示を変える仕組み。
・JSP, PHP, eRuby...
動的にHTMLを組み立てるためのツール
CSS
HTMLの文書の見た目を決めるための仕組み。
・文字の大きさ、色、背景、・・・。
意味と見た目を分離する。
・HTMLには見た目を書かない
地道に調整しないといけないので、大変な世界・・・
JavaScript
現代のWebアプリはサーバー側だけでは完結しない
・JavaScriptを動かしてダイナミックな動作をする
・DOM操作
⇨JavaScriptを使って、画面を書き換える。
・Ajax/XHR
JavaScriptからHTTP通信を行う。画面遷移をせずに色々なアクションを行える。
・フレームワーク
⇨React, Vue, Closure Library, etc.
WebAPI
Webアプリケーションの処理をネットワーク越しに呼び出す
・HTMLではなくデータ(JSON,XML)を返す
・サーバー内のデータを更新する
・JavaScriptから呼ぶ
サーバーとクライアントの分離ができてシンプルになる傾向
※Webアプリケーションはここにないものも含め、たくさんの要素が組み合わさってできている
HTTP and DNS編
DNS
Domain Name Systemのこと。
hoge.example.comは人間が覚えやすい名前。
アクセスする際に使われるのはIPアドレス(例：103.79.14.41)。
DNSを使ってドメイン名をIPアドレスに紐付ける。※IPアドレスだけではない
名前解決
DNSにおける名前解決は、人間が使うドメイン名からコンピューターが通信時に使用するIPアドレスを検索することを指す。
HTTP
Hypertext Transfer Protocolのこと。
・汎用的なテキストベースでやり取りの為のプロトコル。
⇨やり取りはテキストベースでも送るデータは自由
HTTPリクエスト
・GET：リソースを取得
・POST：リソースを送る、処理を依頼する
・DELETE：リソースを消す
・PUT：サーバーが持っているリソースを置き換える
・PATCH：リソースを部分的に更新する
ヘッダー
・リクエストに対する追加情報
・Host: 同じIPアドレスで複数サービスを立てる時に必要
・他にも
⇨User-Agent
⇨Accept-Encoding
⇨Connection
Body
・使うHTTP methodによってクライアントからデータを送る場合もある
⇨POST/PUT等
・その時はヘッダーの後にリクエストの中身(body)を入れる
HTTPレスポンス
Status code
・リクエストの処理結果
・1xx：コネクション情報
・2xx：成功系
・3xx：リダイレクト系
・4xx：クライアント側のエラー
・5xx：サーバー側のエラー
Reason
・Status codeに合わせて理由がつくこともある
⇨例えば200の場合：OK
・主に人間に読まれるためにある
・Reasonメッセージは自由なので、あてにできない
HTTPS
HTTP Secureのこと。
・HTTPは平分プロトコル＝攻撃者が簡単に情報を盗める
・HTTPS：HTTPをTLSの上に構築
・暗号化されるので盗聴されても解読が難しい
Docker編
コンテナとDocker
・コンテナとは
⇨アプリケーションごとに隔離された環境を提供する仮想化の仕組み
・Dockerとは
⇨代表的なコンテナ実行ソフトウェア
⇨コンテナランタイム、コンテナイメージの作成ツール、イメージを共有する仕組みなども提供
サイボウズのコンテナ事情
・開発
⇨kintoneやGaroonチームでは開発環境としてDockerを使用
・テスト
⇨CircleCIやJenkinsの実行環境としてDockerを使用
・運用
⇨YakumoとNecoでは、ほとんどのソフトウェアをKubernetes上でコンテナとして動作させている
コンテナ利用のメリット
・アプリケーションの動作環境を丸ごとパッケージング
・開発・テスト・本番でソフトウェアの実行環境のギャップを小さくすることができる
・軽量であるため扱いやすくリソースの利用効率も高い
VM(Virtual Machine)とコンテナの違い
■VM：
・イメージサイズが大きい
・起動が遅い
・ホストと異なるOSの利用が可能
■コンテナ：
・イメージサイズが比較的小さい
・起動が遅い
・ホストとカーネルを共有
コンテナを実現するための技術要素
・Linux namespace
⇨プロセスに対して、PID、ネットワーク、ユーザー、ホスト名などのリソースを分離することができる
・cgroups
⇨CPUやメモリなどのリソースを制限・隔離することができる
・Linux capability
⇨特権ポートへのアクセスやiptablesの操作などの権限を制御することができる
MacやWindows上のDockerは？
■軽微なLinux VM上でDockerを動かしている
・Docker Desktop for Mac / Windows
・Docker toolbox(legacy)
■注意点
・Mac版はホストとコンテナ間で共有するファイルのアクセスが遅い
・コンテナ向けの実行ファイルはLinux用にビルドする必要がある
Dockerの構成要素
■Dockerfile
・コンテナイメージの作成手順を記述したファイル
■コンテナイメージ
・コンテナの実行に必要なファイルなどをまとめたアーカイブファイル
■コンテナ
・実際に実行されているコンテナ
■Dockerコンテナランタイム
・コンテナを実行するソフトウェア
■コンテナレジストリ
・コンテナイメージを共有するためのサービス(Docker Hubなど)
コンテナオーケストレーションツール
・複数のコンテナを組み合わせたアプリケーションを実行したり管理するための仕組み
・docker-compose
⇨シングルホスト上で複数のコンテナを組み合わせて実行するためのツール
・Kubernetes
⇨複数のホスト上にコンテナを適切にスケジューリングしたり、コンテナの自動復旧やアップグレードなど様々な管理をおこなってくれる。
Dockerfileのベストプラクティス
・野良コンテナイメージは使わない
・コンテナイメージはできるだけ小さく
・コマンドを正しく使う
・タグを正しく使う
・Lintツールを使う
野良コンテナイメージは使わない
・脆弱性や悪意のあるコードが含まれているかも
・Docker Official Imagesは比較的安全
・どれを使うにしてもよく調査すること
コンテナイメージはできるだけ小さく
■大きなコンテナイメージ
・ディスク容量を圧迫
・ダウンロードに時間がかかる
■コンテナイメージを小さくする方法
・小さなベースコンテナイメージを使う
・レイヤーを意識する
・multi-stage buildを使う
アジャイル・クオリティ編
より良い価値のあるソフトウェアを提供し続けることを目指す。
品質
品質は誰かにとっての価値である。
誰か＝使っていただいているお客様
[価値]
・サービスを使って満足している
・今後も使っていこうと思っている
・もうこれなしでは仕事はできないと感じている
・効果の実績が出ている
⇨その[価値]の対価として、お金をいただいている
品質が良い悪いという評価は誰ができるか？
A.お客様
⇨では、どんどんデリバリして、お客様に使ってもらえば品質がいいかわかるのでは？
悪ければ、すぐ直してすぐデリバリすればいい
CI/CD
Continuous Integration / Continuous Deliveryの略。
お客様にデリバリし、直すところがあれば、すぐに直して素早くデリバリしよう。
デリバリの前に
当たり前品質は十分に確保しておきたい。
魅力的品質も、できるだけ吟味し、自分たちの価値観の範囲でよいものにしておきたい
より、魅力的な価値を創造し、それを提供するには
よいフィードバックの仕組みがあり、それが上手く回らなければならない
よいフィードバックとは
価値のアイディア：
こうすると、このようになってもっと嬉しい
顧客からの信頼、期待がある状態・関係
よい品質＝価値を提供し続ける目的
顧客からの信頼関係-"きずな"を作り上げること
よい品質＝価値を提供し続けるためには
よい品質＝価値を提供し続ける
↓
よい品質＝価値を提供する作業
↓
人間がやっています
↓
チームメンバーの肉体的にも精神的にも
健康でなければ続けられません
⇨チームメンバーを肉体的にも精神的にも健康に保つ
支える人々：
人事、総務、経理、本部長、取締役、社長、関連アシスタント、アジャイルコーチ、アジャイルクオリティ...etc
品質＝価値をどのようにして提供し続けるのか
・どんな価値を提供すればよいのか：「計画」
・どのようにしてその価値を作り上げるか：「設計・実装・テスト」
・作り上げたものは、その価値を満足するものなのか：「設計・実装・テスト」
⇨私たちは、作り上げたものの価値に自信が持てるか：「品質の自信」
・顧客は、その価値に本当に満足しているか：「モニタリング」
⇨顧客からのフィードバックから何を学ぶか：「学び」
・よりよい価値を、よりよく提供するにはどうしたらよいか：「改善」
とあるその会社：組織＝サイロ
マネージャー：経営
/ | \
営業 開発 品質保証
管理主義、部分最適、上意下達⇨価値のフローが流れにくい
品質は誰かにとっての価値である
誰か＝使っていただいているお客様
[価値]
・サービスを使って満足している
・今後も使っていこうと思っている
・もうこれなしでは仕事はできないと感じている
[フィードバック]
もっとこうなれば、もっとよくなるアイデアが浮かぶ
⇨私たちにとっての価値：より品質がよくなるアイデア
[結果として期待していること]
私たちの狙いに共感して
多様性を持った人たちのチームワークのネットワークを用いて
よりよい仕事の成果を、楽しく出し続けていく現場のチームの状態
サイボウズのメンタリティ
・心理的安全性が高い
・発言平等性が高い
・お互いをリスペクトする：謙虚
・新しいものを受け入れる：好奇心
最後に
サイボウズさんの新人研修資料、とても勉強になる内容でした！
実際の研修資料では、ハンズオン形式で学べる章もあったので、気になる方はみてみるといいかもしれません！
自分もまだ途中なので、見てみようと思います！
一緒に働きたい！と思った方、是非仲間になってください！
面白いサービスを一緒に作り上げていきましょう！
また記事書きます〜！ありがとうございました！