銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

当ブログではアフィリエイト広告を利用しています

【技術書まとめ16】マスタリングTCP/IP 入門編

技術書

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第16弾です。

今回は マスタリングTCP/IP 入門編  を読みました。

インターネット接続のための標準プロトコルである「TCP/IP」について丁寧に解説した技術書です。

読んでいるうちにインターネットの通信の仕組みが分かってきて、夢中になるくらい面白かったです。

この記事を読むだけでも概要は掴めると思うので、是非読んでみてください。

マスタリングTCP/IP 入門編　第5版

マスタリングTCP/IP 入門編　第5版

 

f:id:ysk_pro:20181126211020p:plain

第1章 ネットワーク基礎知識

  • OSI参照モデルとは、通信に必要な機能を7つの階層に分け、機能を分割することで、複雑なネットワークプロトコルを単純にしたモデルである。各階層は、下位層から特定のサービスを受け、上位層に特定のサービスを提供する。上位層と下位層の間でサービスのやり取りをするときの約束ごとを「インターフェース」と呼び、通信相手の同じ階層とやり取りするときの約束ごとを「プロトコル」と呼ぶ
  • プロトコルの階層型は、ソフトフェアを開発するときのモジュール化に似ている。システムのある階層を変更しても、その影響がシステム全体に波及しないため、拡張性、柔軟性に富んだシステムを構築できる
  • OSI参照モデルの各層の役割
    • アプリケーション層：利用されるアプリケーションの中で通信に関係する部分を定める。ファイル転送や電子メールなどを実現するプロトコルがある
    • プレゼンテーション層：アプリケーションが扱う情報を通信に適したデータ形式にしたりするなど、データ形式に関する役割を持つ。機器固有のデータ表現形式などをネットワーク共通のデータ形式に変換したりする
    • セッション層：コネクション（データの通信路）の確立や切断、転送するデータの切れ目の設定など、データ転送に関する管理を行う
    • ネットワーク層：どの経路を使うかなどの経路選択をし、宛先までデータを届ける役割を持つ
    • データリンク層：物理層で直接接続されたノード間での通信を可能にする。0と1の数字を意味のあるかたまりに分けて相手に伝える
    • 物理層：ビットの列（0と1の数字の列）を電圧の高低や光の点滅に変換したり、逆に電圧の高低や光の点滅をビットの列に変換したりする
 

第2章 TCP/IP基礎知識

  • TCPはTransmission Control Protocol、IPはInternet Protocolの略称で、TCP/IPはインターネット環境の通信を実現するための最も有名なプロトコルである
  • 多くの場合、TCP/IPという言葉は、TCPとIPという2つのプロトコルだけでなく、IPを利用したり、IPで通信したりするときに必要となる多くのプロトコル群の総称として使われる
  • IPはネットワークをまたいでパケットを配送し、インターネット全体にパケットを送り届けるためのプロトコルである。IPによって、地球の裏側までパケットを届けることができる。それぞれのホストを識別するために、IPアドレスという識別子を使う
  • TCPは、コネクション型（通信相手と接続できたことを確認してからデータを送る）で信頼性のあるトランスポート層のプロトコルである。両端のホスト間でデータの到達性を保証し、もし経路の途中でデータを運んでいるパケットがなくなったり、順番が入れ替わったりしても、TCPが正しく解決する。TCPのヘッダには、送信ホストと受信ホストのアプリケーションを識別するためのポート番号、そのパケットのデータが何バイト目のデータなのかを示すシーケンス番号、データが壊れていないことを保証するためのチェックサムなどが含まれる
  • ブラウザとサーバー間の通信で使われるプロトコルがHTTP（HyperText Transfer Protocol）で、送信に使われる主なデータフォーマットがHTML（HyperText Markup Language）である。WWW（World Wide Web）では、HTTPがOSI参照モデルのアプリケーション層のプロトコル、HTMLがプレゼンテーション層のプロトコルと言える
  • 各層のプロトコルのそれぞれのヘッダには少なくとも「宛先と送信元のアドレス」、「上位層のプロトコルが何かを示す情報」が含まれている
 

第3章 データリンク

  • 実際に機器の間で通信を行う場合には、データリンク層と物理層が共に必要となる。コンピュータの情報は、全て2進数の0と1で表されるが、実際の通信媒体でやり取りされるのは電圧の変化や光の点滅、電波の強弱などである。これらと2進数の0と1とを変換する働きを担うのが物理層であり、データリンク層では、単なる0と1の列ではなく、フレームという意味のあるかたまりにまとめて、相手の機器に伝える
  • MACアドレスは、データリンクに接続しているノードを識別するために利用される
 

第4章 IPプロトコル

  • IPは（IPv4、IPv6）は、OSI参照モデルの第3層のネットワーク層に相当する。ネットワーク層は、通信経路になっているデータリンクの違いを覆い隠し、異なる種類のデータリンクであったとしても、その間の連携を取りながらパケットを配送することによって、別のデータリンクに接続されているコンピュータ同士の通信を可能にする
  • ホスト：IPアドレスが付けられているが経路制御（パケットを中継すること）を行わない機器。ルーター：IPアドレスが付けられていて経路制御を行う機器。ノード：ホストとルーターを合わせた呼び方
  • 旅行を例にすると、電車などの区間内の移動をするための切符がデータリンク層、旅の全行程が書かれている工程表がネットワーク層の役割にあたる。工程表だけで切符がなけれが乗り物に乗ることができず、切符だけでもどの順番で乗り物に乗ればいいかわからず最終目的地にたどり着くことができない
    • 終点ホストまでのパケット配送（ルーティング）：IPパケットがルーターに到着すると宛先IPアドレスが調べられ、次に転送されるルーターが決まり、そのルーターに転送される。これを繰り返して、IPパケットは最終的な目的地まで届けられる
    • IPパケットの分割処理と再構築処理：データリンクによって転送できるデータの大きさが決まっており、大きなIPパケットは小さなIPパケットに分割して、宛先のホストで再び1つにまとめられてIPの上位層に渡される
  • IPはコネクションレス型で、パケットを送信する前に通信相手との間にコネクションの確立を行わない。上位層に送信すべきデータが発生しIPに送信要求をしたら、すぐにIPパケットにデータを詰めて送信する。コネクションレス型にしている理由は、機能の簡略化と高速化のため。コネクション型のサービスが必要となる場合は、上位層が提供すれば良く、信頼性を高めるのは上位層のTCPの役割である
  • IPアドレスはネットワーク部とホスト部から構成される
    • ネットワーク部：データリンクのセグメントごとに1つ値が割り当てられる。同じセグメントに接続されているホストには、全て同じネットワークアドレスを設定する
    • ホスト部：セグメント内で重ならない値を割り当てる
  • IPパケットが途中のルーターで転送されるときには、宛先IPアドレスのネットワーク部が利用される。ホスト部を見なくてもネットワーク部を見ればどのセグメント内のホストであるかを識別できる
  • IPアドレスのどこからどこまでがネットワーク部で、どこからどこまでがホスト部かについては、歴史的に2種類の区別がある。初期のIPでは、クラスによって分けられており、現在ではサブネットマスクによって分けられている
  • クラスによっての分類：クラスA、クラスB、クラスC、クラスDという4つのクラスに分類され、IPアドレスの先頭から4ビットまでのビット列の組み合わせによってネットワーク部とホスト部を決めていた
    • クラスA：IPアドレスの先頭1ビットが0で始まる場合。クラスAでは、IPアドレスの先頭から8ビットまでがネットワーク部、下位24ビットがホストアドレスとして割り当てられる
    • クラスB：IPアドレスの先頭2ビットが10で始まる場合。クラスBでは、IPアドレスの先頭から16ビットがネットワーク部となり、下位16ビットがホストアドレス
    • クラスC：IPアドレスの先頭3ビットが110で始まる場合。IPアドレスの先頭から24ビットまでがネットワーク部、下位8ビットがホストアドレス
    • クラスD：IPアドレスの先頭4ビットが1110で始まる場合。IPアドレスの先頭から32ビットまでがネットワーク部となる。クラスDにホストアドレスの部分はなく、IPマルチキャスト通信（特定のグループに所属する全てのホストにパケットを送信する）に使われる
  • クラスによってネットワーク部とホスト部を分けるのは無駄が多いので、無駄を小さくするサブネットマスクを使った仕組みが導入された
 

第5章 IPに関連する技術

  • DNS（Domain Name System）は、アルファベットのホスト名とIPアドレスを自動で変換するシステムである。DNSでは、通信したいユーザーがホスト名を入力すると、自動的にホスト名やIPアドレスが登録されているデータベースサーバーが検索され、そこからIPアドレスの情報を得るようになっている。これにより、ホスト名やIPアドレスの登録や変更をした場合でもその組織内だけで処理すればよく、他の機関に報告や申請をする必要はない
  • ICMP（Internet Control Message Protocol）は、IPパケットが目的のホストまで届くかを確認する機能や、何らかの原因でIPパケットが廃棄された時にその原因を通知してくれる機能、不十分な設定をより良い設定に変更してくれる機能などがある。これらによって、ネットワークが正常かどうか、設定ミスや機器の異常がないかを知ることができる
 

第6章 TCPとUDP

  • TCP/IPには、TCP（Transmission Control Protocol）とUDP（User Datagram Protocol）という2つの代表的なトランスポートプロトコルがある。TCPは信頼性のある通信を実現し、UDPは同時通信や、細かい制御をアプリケーションに任せた方がよい通信に使われる。つまり、必要となる通信の特性により、使用するトランスポートプロトコルを選択することになる
  • IPヘッダのプロトコルフィールドに定義されている、どのトランスポートプロトコルにデータを渡すかの番号で、IPが運んでいるデータがTCPなのかUDPなのかが識別される。同様に、トランスポート層であるTCPやUDPにも、自分が運んでいるデータを次にどのアプリケーションに渡せばよいかを識別するための番号が定義されている
  • トランスポート層は、データを渡すプログラムを指定する役割を持っており、この役割を実現するためにポート番号という識別子を使用する
  • TCP/IPのアプリケーションプロトコルの多くは、一般的にクライアント／サーバーモデルという形式で作られている。サーバープログラムは、UNIXではデーモン（ホスト・サーバー上で常時起動されていて特定の処理を行うプロセス）と呼ばれる。要求がどのサーバー（デーモン）へ向けられたものかは、受信したパケットの宛先ポート番号を調べれば分かる。例えば、TCPの接続要求パケットを受信した場合、ポート番号が22番ならsshdで、80番ならhttpdにコネクションを確立させる。そして、そのデーモンがそれ以降の通信の処理を受け持つ。トランスポートプロトコルのTCP、UDPは、受信したデータが誰宛かをこのポート番号から判断する
  • ポート番号とは、トランスポートプロトコルのアドレスのようなもので、同一のコンピュータ内で通信を行なっているプログラムを識別するときに利用される
  • ポート番号の決め方は、ウェルノウンポート番号という標準で決められている番号を使う方法と、動的に割り当てる方法がある。ウェルノウンポート番号の例として、80番はHTTPで利用される。また、HTTPの通信では必ずTCPが使われる
  • TCPは、ネットワークの途中でパケットが喪失した場合に再送制御、コネクション制御などデータを送信するときの制御機能が充実しており、この機能によってIPというコネクションレス型のネットワークの上で、信頼性の高い通信を実現することができる
  • アプリケーションが細かい制御をした方が良い場合にはUDPを使うべきで、データの通信量が比較的多く、信頼性を必要としているができるだけ考えたくない場合には、TCPを使うべきである。TCPやUDPには、それぞれ長所短所があるので、アプリケーションを作成するときにはシステムの設計者がきちんと考えてプロトコルを選定する必要がある
 

第7章 ルーティングプロトコル（経路制御プロトコル）

  • インターネットは、ネットワークとネットワークがルーターで接続されて作られている。パケットを正しく宛先ホストへ届けるためには、ルーターが正しい方向へパケットを転送しなければならない。この正しい方向へパケットを転送するための処理を経路制御またはルーティングと呼ぶ
  • ルーターは経路制御表（ルーティングテーブル）を参照してパケットを転送する。受け取ったパケットの宛先IPアドレスと経路制御表を比較して、次に送信すべきルーターを決定する
  • 経路制御表の作成・更新には2種類ある
    • スタティックルーティング（静的経路制御）：ルーターやホストに固定的に経路情報を設定する方法
    • ダイナミックルーティング（動的経路制御）：ルーティングプロトコルを動作させ、自動的に経路情報を設定する方法。隣り合うルーター間で自分が知っているネットワークの接続情報を教え合うことによって行われる
 

第8章 アプリケーションプロトコル

  • ネットワークを利用するアプリケーションには、Webブラウザ、電子メールなどがあり、それぞれのアプリケーション特有の通信処理が必要である。このアプリケーション特有の通信処理を行うのがアプリケーションプロトコルである。TCPやIPなどの下位層のプロトコルは、アプリケーションの種類によらず使えるように設計された汎用性の高いプロトコルである。これに対してアプリケーションプロトコルは、実用的なアプリケーションを実現するための、アプリケーション間で通信する際の取り決めである
    • SSH（Secure SHell）：暗号化された遠隔ログインシステム
    • FTP（File Transfer Protocol）：異なるコンピュータ間でファイルを転送するときに使われるプロトコル
    • SMTP（Simple Mail Transfer Protocol）：電子メールサービスを提供するためのプロトコルである。電子メールの配送先の管理はDNSによって行われている
    • POP（Post Office Protocol）：電子メールを受信するためのプロトコル
    • IMAP（Internet Message Access Protocol）：POPと同様に、電子メールなどのメッセージを受信するためのプロトコル。POPは電子メールの管理をクライアント側で行うが、IMAPはサーバー側で管理を行う。IMAPであれば、サーバー上の電子メールをダウンロードしなくても読むことができる
 

第9章 セキュリティ

  • ファイアウォールの考え方は、危険にさらすのを特定のホストやルーターに限定する、というものである。全てのホストに不正侵入の対策を施すのには大きな手間がかかるため、ファイアウォールによってアクセス権限をかけて、インターネットから直接アクセスできるホストを数台に限定する。さらに安全なホストと危険にさらされるホストを区別して、危険なホストにのみ集中してセキュリティ対策をする
  • ファイアウォールは基本的にポリシーと合致した通信は通過させる。IDS（侵入検知）システムは、内部に侵入して不正アクセスを行う通信を見つけて通知する
  • VPN（virtual Private Network）は、インターネットを利用した仮想的な私的ネットワークである。パケットを送信するときに、暗号ヘッダや認証ヘッダを付け、パケットを受信するときにこれらのヘッダを解釈し、送信されたデータを復号して、通常のパケットに戻す。この処理により、暗号化されたデータは解読できなくなり、途中の経路でデータが改ざんされたときには判別できるようになる
  • Webでは、TLS/SSLという仕組みを使ってHTTP通信の暗号化が行われる。暗号化された通信はHTTPSと呼ぶ。HTTPSでは共通鍵暗号方式で暗号化処理が行われる。この共通鍵を送信するときには公開鍵暗号方式が利用される
 

おわりに

ここまで読んでいただきありがとうございます。
インターネットの通信の仕組み、とっても奥が深くて面白くないですか？
本書では、図や具体例、たとえ話を使ってより分かりやすく解説してくれているので、興味が湧いた方はぜひ読んでみてください。
マスタリングTCP/IP 入門編　第5版

マスタリングTCP/IP 入門編　第5版

 

来週は、アンダースタンディング コンピュテーション ―単純な機械から不可能なプログラムまで という、計算理論をRubyでわかりやすく解説している技術書を読む予定です。

これも面白そう...！

来週も頑張ります。

【読書まとめ15】Team Geek ―Googleのギークたちはいかにしてチームを作るのか

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第15弾です。

今回は Team Geek ―Googleのギークたちはいかにしてチームを作るのか を読みました。

Googleのエンジニアが書いた、チーム作りについての本です。

先週読んだ チームが機能するとはどういうことか もチーム作りについてでしたが、Team Geekは内容がエンジニアに特化しており今回も学ぶことが多かったです。

読み終わった今、チーム作りへの興味が猛烈に出てきています。チーム作りに興味がある方はこの記事をぜひ読んでみてください。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 

f:id:ysk_pro:20181117192904p:plain

はじめに

  • プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。自分が思っている以上に、チームは個人の生産性や幸福に直接影響する
  • ソフトウェア開発はチームスポーツであり、技術的要因と同じくらい人的要因が影響する。何十年もかけてプログラミングの技術面を学んだとしても、人間的要因を学んでいない人がほとんどである。成功するにはチームでのコラボレーションについても学必要がある
 

1章 天才プログラマの神話

  • エンジニアリングチームで成功するには、以下3つ原則に基づいて行動する必要がある。この３つは、頭文字をとって「HRT」（ハート）と呼ばれる
    • 謙虚（Humility）
    • 尊敬（Respect）
    • 信頼（Trust）
  • あらゆる人間関係の衝突は、謙虚・信頼・尊敬の欠如によるものである
  • 早い段階から成果を共有することで、つまづきを回避したりアイデアを検証したりできるようになる。共有を防いでしまうのは、未完成のものを見せたら何か言われたり、バカだと思われてしまうのではないかという不安である。しかし、一人で仕事をして間違ったことで時間を無駄にしてしまうことの方がリスクが高いと考えるべきである
  • コードレビューをするときに最も重要なのは、同僚を尊敬することである。建設的な批判をする人は、心から他人を思いやり、成果を改善して欲しいと願っている
  • コードレビューを受ける側で大事なのは、自分のスキルに謙虚になるだけでなく、他の人が恩恵をもたらしてくれると信頼し、自分をバカだと思わないこと。
  • プログラミングはスキルなので、練習すれば必ず向上する
  • 過ちから学ぶには、失敗を文書化することが有用。謝罪や言い訳ではなく、何を学んだか、何を変更するかを記述する。書き終わったら見つけやすい場所に置いて、変更を継続できるようにする。失敗を適切に文書化しておけば、他人がそれを読んで学習し、歴史を繰り返さずに済む。以下は優れた失敗の文書のフォーマット
    • 概要
    • イベントのタイムライン（調査開始から解決に至るまで）
    • イベントの根本原因
    • 影響と損害の評価
    • すぐに問題を解決するための行動一式
    • 再発を防止するための行動一式
    • 学習した教訓
  • 間違いや能力不足を認めることは、長期的に立場を向上させる。謙虚さを見せ、他人の意見を信頼すると、その正直さと強さによってみんなが尊敬してくれるようになる。ときには「わからない」ということも大切である
 

2章 素晴らしいチーム文化を作る

  • 強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的である。すぐれたチームの文化は、ソフトウェアを届けることに集中している。強い文化は、集中・効率・強度を与え、それがみんなを幸せにする
  • 強固な文化を構築すると「自己選択的」になる。クリーンでエレガントで保守性の高いコードを書くことに集中すると、クリーンでエレガントで保守性の高いコードを書く人たちが興味を持ってくれる
  • 会社では採用の時にチームが自己選択をする。応募者にスキルや強みがあるかどうか、文化が合致しているかどうかを見極める。新しいチームメンバーが文化に合致するかを確かめる唯一の方法は、そのことについてインタビューすることである。Google含め多くの会社では、応募者が文化に合致するかどうかを採用基準にしている。採用ミスを回避するために、技術のインタビューの前に文化のインタビューをする会社もある。文化は偶然に生まれるものではなく、創業者や初期の従業員が継続的に作り出すものである
  • コミュニケーションの原則は、同期コミュニケーション（ミーティングなど）の人数を減らし、非同期コミュニケーション（メールなど）の人数を増やすことである。また、できるだけ多くの人が、プロジェクトの文書から全ての情報を取得できることが重要である
  • エンジニアリングチームのミッションステートメントであれば、チームの方向性を定義して、プロダクトのスコープを制限するだけで良い。ミッションステートメントを書くには時間や手間がかかるが、やること／やらないことを明確にしておけば、年単位で仕事の節約になる可能性もある
  • ミーティングを開くときの５つの簡単なルール
    • 絶対に必要な人だけを呼ぶ
    • アジェンダを作ってミーティング開始前に配布する
    • ミーティングのゴールを達成したら時間前でも終了する
    • ミーティングを順調に進める
    • ミーティングの開始時間を強制的に中断される時間（お昼休みや就業時間）の前に設定する
 

3章 船にはキャプテンが必要

  • 船にキャプテンが必要なように、チームにはリーダーが必要である
  • 伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考え、どうやって仕事を完了させるかはチームに考えてもらう
  • Googleのエンジニアリングディレクターからのアドバイスは、管理したくなる衝動を抑えることであった。新人のマネージャーは労働者を管理しようとしてしまい、管理するのがマネージャーの仕事であるという思い込みは、悲惨な結果につながる
  • マネージャー役割で最も重要なのは、執事や召使いのようにチームに奉仕することである。謙虚・尊敬・信頼（HRT）の雰囲気を作り出し、エンジニアでは対処できない社内の障害物を排除することや、チームの合意形成を支援したりする
  • チームメンバーがアドバイスを求めてきたら、問題解決のチャンスである。エンジニアが相談を持ちかけるのは、問題解決をしてほしいからではなく、問題解決をするのを手伝ってほしいからである。そのためには質問をすればよく、問題を整理したり調査したりすることで、自力で問題解決できるように支援するのである
  • リスクのとれる文化を育てるには、失敗してもいいことをチームに知らせればいい。同じ失敗を繰り返さない限り、失敗によって多くのことがすばやく学べる。犯人捜しや責任のなすりつけをするのではなく、失敗を学習の機会と考えるべきである
  • フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかどうかを意識する。相手を防御的にするような伝え方では、どうすれば改善できるかを考えることができずに、逆にこちらが間違っていると反論されてしまう
  • チームの幸せを追い求めるには、1on1ミーティングの後に「何か必要なものはある？」と質問するとよい。チームメンバーが生産的で幸せになるために必要なものを簡単に把握できる
  • モチベーションには外発的動機と内発的動機の2種類がある。外発的動機は外からの力（対価など）で生まれるものであり、内発的動機は自発的なものである。人を幸せで生産的にするのは外部的動機（例えば札束）ではなく、内発的動機を高めることである。そして、内発的動機には、以下3つの要素が必要である
    • 自律性：自分で考えて行動すること。自律性のあるエンジニアは、プロダクトの大まかな方向性を示せば、あとはどうやってそこに行くかを自分で決められる。プロダクトのオーナーシップが感じられることがモチベーションに繋がる
    • 熟練：エンジニアが新しいスキルを学び、既存のスキルを向上させるための機会を作ること
    • 目的：顧客からの役に立ったというフィードバックがチームのモチベーションを高める
 

4章 有害な人に対処する

  • 有害な人を追い出すのではなく、有害な振る舞いを排除する
  • 有害な振る舞いに対応するときは、以下の二つの質問について考え、答えが「ノー」であれば、出来るだけ早くその振る舞いを中止する必要がある
    • 短期的にはチームの注意や集中をムダにしても、長期的にはプロジェクトにメリットがあるだろうか？
    • その衝突は有益な方法で解決できるだろうか？
 

5章 組織的操作の技法

  • 組織の悪い習慣を排除するのは難しく、悪い習慣を止めることはできない。止めるのではなく、良い習慣と置き換える必要がある
  • 運のいい人はチャンスに気がつく。規則通りに仕事をやって、自分の仕事を完了させることだけに集中し、他のことを排除しているとチャンスは少ない。自分の仕事に関係なくても、他の人の仕事を手伝うようにすれば、いずれ誰かが喜んで手伝ってくれるようになる
  • 権力を持つ人たちは、問題解決を喜んでやる。そして、短いメールの方が返事をもらえる確率が高い。「3つの箇条書きと行動要請」（問題について説明する最大3つの箇条書きと1つだけの行動要請を書くフレームワーク）を使えば何かをやってもらえる確率が向上する
 

6章 ユーザーも人間

  • ソフトウェア開発プロセスは、プロダクトが完成したら終わりではない。ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくことである
  • Googleはプロダクトの機能を事前に予告しないという、よく考えられたポリシーを持っている。そのおかげで、新しい機能を公開した時に嬉しい驚きがある。非現実的な期日に間にあわせるためにデスマーチをすることもない。ソフトウェアは、実際に準備されて利用できるようになってからリリースされる
  • Googleのモットー：ユーザーに集中すれば、他のことはすべてついてくる
  • プロダクトは最初の体験が最も大事である。ソフトウェアを初めて使うときにどれだけ難しいと感じるかを考える
  • 信頼は最も大切なリソースであり、残高に気を配るべきである。短期的な利便性ではなく、長期的なイメージを大切にする
  • ユーザーを驚かせて幸せな気分にさせよう。ちょっとした喜びやユーモアを取り入れることで、ユーザーのことを考えていることや、関係性を大切にしていることが伝わる
  • プログラマは多忙の中で、ソフトウェアを書く理由を忘れてしまう。ソフトウェアは自分のためでも、チームのためでも、会社のためでもない。ユーザーの生活を豊かにするためである。ユーザーがプロダクトについて何を考えているか、何を言っているか、何を体験しているかに注目することが、長期的に重要なことになる

 

おわりに

ここまで読んでいただきありがとうございます。

当然のことではありますが「HRT」はどんな時も忘れずに仕事したいですね。

本記事では書ききれませんでしたが、各項目でGoogleでの具体例がたくさん書かれていてとても分かりやすかったのでオススメです。（kindle版がないのが残念）

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 

２週連続でチーム作りに関する本を読んだので、チーム作りに関する興味がかなり出てきて、将来はマネジメントに進むのもいいなーと思うようになりました。

 

来週からはまた技術書を読んでいこうと思います。

来週も頑張ります。

【読書まとめ14】チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

毎週１冊技術書を読んでブログでアウトプットすることを目標にしています。

今回は技術書ではないのですが、学ぶことがとても多かったのでまとめました。

チームが機能するとはどういうことか を読みました。

「チーミング」という概念をもとに、学習する強い組織の作り方を書いた本です。

最近よく耳にする「心理的安全性」についてもこの本の中で詳しく解説されています。

最近読んだ本の中で一番衝撃を受けたというか、学ぶことが多かったので、少し長いですが是非この記事を読んでいただけると嬉しいです。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

 

f:id:ysk_pro:20181111215458p:plain

まえがき

  • 集団的学習（小さなグループの中で、そのグループによって学ぶこと）は、組織学習の最も重要な手段だと考えられている。複雑で変わりやすいビジネス環境で成功するためには、人々はチームで働き、かつ学ばなければならない
  • しかし多くの組織が、工業化時代に成長性と採算性を飛躍的に高めたトップダウンの指揮統制アプローチに、今なお依存している。そうした経営スタイルの最も基本的な信条（確実な支配、相違の排除、順応に対する報酬）の中には、協働や組織学習を抑制してしまうものがある
  • チーミングとは協働する活動を表す造語であり、組織が相互に絡み合った仕事を遂行するための、より柔軟な新しい方法を示している。チーミングは静的な集まりではなく、活動的なプロセスである
  • リーダーが、管理ではなくエンパワーメントをするようになったら、適切な答えを与えるのではなく適切な質問をするようになったら、そして規則の遵守を主張するのではなく柔軟性に着目するようになったら、メンバーはもっと高いレベルで仕事を行えるようになる
 

第1部 チーミング

第1章 新しい働き方

  • チーミングは動詞である。チームワークという考え方やその実践によって、生み出されるものである。チーミングは、休む間のないチームワークである
  • マネジャーはなぜ、チーミングに心を配るべきなのか。チーミングは組織学習の原動力なのである。変わり続ける世界の中で成功を収めるために、組織は学習をする必要がある
  • 社会として、私たちは相変わらず不安に基づいた職場環境を当たり前のように受け容れてしまっている。不安によって支配力を増大でき、支配力は確実性や予測精度を高めると思っている人もいる。しかし、そういう環境は組み立てラインの労働者には効果をもたらせたものの、今日のような知識ベースの経済においてはもはや競争上の強みにはならない
  • 今後、真に卓越した存在になるのは、組織内のあらゆるレベルで、人々のコミットメントや学習する力を引き出す組織である。学習は不可欠であり、究極的には支配を手放すことが求められる。成功するためには、実行のための組織づくりから、協働やイノベーションや組織学習を支持する新たな働き方へとシフトすることが不可欠である
  • チーミングには、率直に述べたり質問したり考えを共有したりすることを後押しするタイプのリーダーシップが必要である。チーミングに不可欠なリーダーシップの考え方は、学習を促す環境を作ろうとするものである
  • 本当に素晴らしいパフォーマンスとは、何かに挑戦して失敗し、代わりにどうすれば成功したかを理解し、さらにその挑戦について成功したことも失敗したこともすべてを洗いざらい仲間に話すことである。そうした発見プロセスによって、人々はいくつもの領域の専門知識を統合し、その仕事に対する新たなアプローチを理解することになる
  • 学習しながら実行するというのは、絶え間ない学習と高いパフォーマンスを結びつける組織としての活動の仕方である。簡単に言えば、仕事をこなしながら同時にどうすればもっとうまくできるか探し続けることである
  • 職場を新しい形へと変える数々の技術的・地政学的変化に直面する多くのリーダーが、チーミングや絶え間ない学習という現実を日常の当たり前のこととして理解しようと奮闘している。権威やヒエラルキーといった時代遅れの、しかし当然になってしまっている概念を手放す努力が必要である
  • 今日必要とされているダイナミックで柔軟性のあるチームのリーダーに必要とされているのは、答えがなくても前進するにはどうすればいいか、その方法を見つける想像力と勇気である。明確な方向性を示し、リスクや失敗に対して寛容で、他人と緊密に協力することを率直に求めるリーダーである
 

第2章 学習とイノベーションと競争のためのチーミング

  • うまいチーミングに必要なのは、さまざまな分野からの意見をまとめること、専門知識が多分野にわたる中でコミュニケーションを図ること、どうしても生まれる意見の衝突を管理することである
  • 成功しているチーミングは次の四つの特別な行動を伴っている
    • 率直に意見を言う：チーミングの成功は、個人間でじかに、誠実な会話ができるかどうかにかかっている。会話には、質問すること、意見を求めること、過ちについて話すことが含まれる
    • 協働する：協働の姿勢と行動があって初めて、チーミングはプロセスを推し進めることができる
    • 試みる：チーミングでは何度も試みが行われるが、これにより個人と個人の交流につきものの新奇さと不確実性を受け容れることになる
    • 省察する：チーミングでは、プロセスと結果をしっかり観察し、明瞭に質問し、よく話し合うことが重視される
  • 職場では、ピラミッド型組織において自分の上にいる人を怒らせてしまう不安が、当たり前に広がっている。つまり、意見をはっきり述べるというチーミングになくてはならない行動は、すでに存在しているわけではなく、作っていかなければならないのである
  • チーミングが特に役に立つのは、変わりゆく状況の要求に応えるために、組織が新たな業務を考えたり新技術を実装したりする場合である。この手の組織の変化がチーミングを必要とするのは、そうした変化には部門や分野を超えた理解と調整が不可欠だからである。チームというのは組織にとって最高の変化の請負人である
  • チーミングは、人々の職場での経験によい影響をもたらす。さまざまな知識やスキルを持つ人たちと直接交流し合うと、職場はより面白く、充実した、意義深いものになる。チーミングが当たり前になっている組織では、従業員は互いから学び、仕事のことも仕事が最初から最後までどのように行われるかももっと広く理解できるようになり、それに基づいて行動できるようになる
  • チーミングを妨げる主な障害は不安である。同時に、明確な共通の目標がないことも、チーミングに伴う努力を要する行動を妨げる。官僚式の煩雑な手続きや、管理者層や、矛盾するインセンティブ・システムもやはり妨げになる
  • 対立を緩和し、チーミングの成功に欠かせない協調的な取り組みができるようにする四つの戦略
    • 対立の性質を見極める：個人として衝突し、個性がぶつかり合うのは生産的ではない
    • 優れたコミュニケーションを具現化する：うまくコミュニケーションを図ると、意見が合わない本当の理由を理解し、それぞれの立場の背後にある論理的根拠を認識できるようになる
    • 共通の目標を明らかにする：チームは尊敬の念を損なう根本的な帰属の誤りを克服し、信頼し合う環境を築けるようになる
    • 難しい会話から逃げずに取り組む：本物の会話は、少々のことでは壊れない関係を築き、考え方の違いや個人的な不和を乗り越えるのに役立つ
  • 四つのリーダーシップ行動
    • 行動１　学習するための骨組みを作る
    • 行動２　心理的に安全な場を作る
    • 行動３　失敗から学ぶ
    • 行動４　職業的、文化的な境界をつなぐ
 

第2部 学習するための組織作り

第3章 フレーミングの力

  • フレームとは、ある状況についての一連の思い込みや信念のことである。どんな時もフレーミングは自然に行われる。私たちは、歩んできた人生や社会状況によって作られた見えないレンズを通して、周囲で起きていることを解釈する。問題は、私たちのフレーミングは主観的なものに過ぎないのに、真実を表していると思い込みがちであることである
  • リーダーは、状況をフレーミングあるいはリフレーミングすることで、その状況に対する人々の対応の仕方や関わり方に強力な影響をもたらせる
  • 一時的なチームを組んで取り組むプロジェクトの場合、メンバーの役割をフレーミングするのに欠かせないのは、メンバーは理由があって選ばれているのだと明確に伝えることである。メンバーがプロジェクトのために厳選された素晴らしい人たちであることをリーダーが強く述べると、専門技術の上でも気持ちの上でも深く関わる意思が生まれるのである
  • チーミングは、全員がそれがうまくいくように取り組むとしっかり機能する。イノベーションや新技術の導入に伴う避けがたい障害を克服しようとメンバーが一致団結すると、学習が生じる。また、よく考えられた前向きなフレーミングによってメンバーは一層密にコミュニケーションを図ろうとするようになり、やがてピラミッド型組織の境界が薄れていく
  • 取り組むべき仕事を効果的にフレーミングすると、なぜ特定のプロジェクトが存在するのかという疑問に対する説得力ある答えを提供することになる。プロジェクトはどんな目的を果たすのか、従業員や顧客や社会に、どんな価値をもたらすのか。リーダーの仕事は、そうした共通の目的を中心に人々を一つにまとめ、彼らが団結する手助けをすることである
  • 自然に生まれてしまう保身のフレームを学習本位のフレームに変え、それを強固にするためのステップ
    • 登録：プロジェクトのメンバーが、プロジェクトや役割のために特別に選ばれていることを本人にはっきり伝える。自分が加わることが結果に影響を及ぼすのだというワクワク感や自信を与える
    • 準備：既存の方法をなぜ変える必要があるのかについて話し合う
    • 試行：実際に仕事をして、その仕事を多くの学びを得る実験として前向きにフレーミングする。ここでの目標は、一度で完璧に作業を進めることではなく、将来の成功のためにどんな調整や変更が必要になるかを素早く認識することである
    • 省察：うまくいったこととうまくいかなかったことから学習する。一連の試行が終わるたびに、重要な観察結果を使って、改善できそうなところを探る
  • 個人がリフレーミングするための四つの戦術
    • このプロジェクトはこれまでに関わったどんなプロジェクトとも違っていて、新たなアプローチを試し、そこから学習する胸の踊るような機会に満ちている、と自分に言い聞かせる
    • 自分はプロジェクトの成功に不可欠だけれども、他のメンバーが意欲的に参加しなければ成功を収めることはできないと考える
    • 他のメンバーはプロジェクトの成功に欠かせない存在で、自分には予想もつかない重要な知識を提供したり提案したりするかもしれない、と自分に言い聞かせる
    • 以上の3つが本当だったら他人にどのように話すだろう。それと全く同じように、実際に他の人に話す
  • フレームを変える上で最も困難なのは、状況に対する現在の知覚の根底にあって当たり前になっているフレームを認知することである。行動を変えて異なる結果を得るには、潜在する認知を変えて望ましい行動を引き起こさなければならない。個人がリフレーミングするための四つの戦術は、新たな状況においては繰り返し用いる必要がある
 

第4章 心理的に安全な場をつくる

  • 心理的安全とは、関連のある考えや感情について人々が気兼ねなく発言できる雰囲気をさす。簡単なことに思えるが、同僚が見ているところで支援を求めたり失敗を許したりできるというのは思いのほか難しい場合がある。しかし、チーミングによって様々な意見の違いを超えて協働できるようになると、率直に会話したり失敗を隠さず話したり出来るようになる
  • 心理的安全があれば、厳しいフィードバックを与えたり、真実を避けずに難しい話し合いをしたりできるようになる。心理的に安全な環境では、何かミスをしても、そのために他の人から罰せられたり評価を下げられたりすることはないと思える。そうした信念は、人々が互いに信頼し、尊敬し合っているときに生まれ、それによって、このチームでははっきり意見を言ってもばつの悪い思いをさせられたり拒否されたり罰せられたりすることはないという確信が生まれる
  • 面白いことに、仕事を妨害することは学習にとってプラスになる。仕事を中断させることによって、知識のやりとりが増え、新たな手順の習得が早まることが明らかになっている
  • 職場で心理的安全を重視すべきなのは、それによって率直に話すことが促されるのが最大の理由である。率直に話すことには、支援を求めたり試したりミスについて話し合ったりといった、学習行動の機会を増やすことが含まれる
  • リーダーは、メンバーを尊敬していることを、とりわけメンバーが持っている専門知識やスキルを認めていることをはっきり伝えなければならない。率直に話したりミスを報告したりすることを大いに促す必要もある。そのようにメンバーを導くと、リーダーは心理的に安全な環境を生み出し、支援していけるようになる
  • 心理的安全を高めるためのリーダーシップ行動
    • 直接話のできる、親しみやすい人になる
    • 現在持っている知識の限界を認める
    • 自分もよく間違うことを積極的に示す（例えば「君たちの意見が必要だ。私はきっと何かを見落としているだろうから」とメンバーに伝える）
    • 参加を促す（自分たちの意見を重視していると理解してもらう）
    • 失敗は学習する機会であることを強調する
    • 具体的な言葉を使う
    • 境界を設ける（望ましいことをリーダーができるだけ明確にする）
    • 境界を超えたことについてメンバーに責任を負わせる
 

第5章 上手に失敗して、早く成功する

  • ほとんどの人が、成功を目指すようにと教え込まれてきた。結果として、大半の人が失敗を許されないものだと思うようになった。失敗は必然であり、学習する重要な機会を生み出すものだと分かっていても、なんとかして避けたいと思ってしまう。そのため人々は職場において、自分が経験した学びが多々あるかもしれないミスや問題について、口を閉ざしたままでいることが少なくない。しかしそれによって会社は、失敗から得られたかもしれない学びを逃してしまうことになる
  • 失敗を、厄介な出来事としてではなく学習する機会として捉えられるように常にリフレーミングする
  • 早く成功するために、頻繁に失敗しよう。一つ一つの失敗がもたらす教訓を学ぶ限り、どんどん失敗する方が早く成功を手に入れられる
  • 世界中の企業の幹部たちでさえ大半が、よくない知らせを上司や同僚の耳に入れたがらない。問題を報告した人を罰するのは今なお解決されることなく続く悪い現実であり、リーダーとしては失敗の報告が罰せられることなく上司や同僚に伝わる状況を生み出すことが必須である。そのために、リーダーは三つの基本的な行動をとる必要がある
    • 問題を報告した人を歓迎する
    • データを集め、意見を求める
  • グーグルをはじめとする、イノベーションのために知られている会社は、一つの新製品や新サービスがヒットする陰で、積極的に試したが失敗に終わったアイデアが数え切れないほどあることをよく知っている
 

第6章 境界を超えたチーミング

  • 「境界」という言葉は、ジェンダーや職業や国籍を含め、人々の間にある目に見える領域と目に見えない領域の両方に当てはまる。また、境界は人々が様々なグループの中で持つ当たり前になっている思い込みや多様な考え方が元になって存在する
  • チーミングを成功させるには、マネジャーとチームメンバーは自分たちが多様な見方を持って集まっていることを、しばしば自分の信念や価値観にとって正しいことを当たり前だと思うようになっていることを認識しなければならない。つまり、団結しようと言うだけで万事が上手く行くわけではない
  • 境界を超えたチーミングの必要性が増しているのは、二つの関連する傾向があるため
    • 知識が専門知識がかつてない速さで進歩しており、人々は相当の時間を費やさなければ自分の専門領域の最新の情報に精通できなくなっていること
    • 国際競争のせいで、タイムフレームがかつてないほど圧縮されていること
  • 境界を超えたコミュニケーションを促進するためにリーダーにできる行動
    • 共通の目標をフレーミングして、人々を一つにまとめ、コミュニケーションの障壁を乗り越えようとする意欲を高めること
    • 関心を示し、情報を共有したり質問をしたりするのを適切な行動だと認めること
    • プロセスの指針を示して、コラボレーションの構築を後押しすること
 

第3部 学習しながら実行する

第7部 チーミングと学習を仕事に活かす

  • 学習しながら実行するという姿勢で仕事をするには、あえて困難な道を選ばなければならない。学習しながら実行することを仕事の仕方として受け容れるというのは、どんなプロセスでも必然的に不十分であり、わずかだとしても改善できる可能性が常にあると受け容れることである
  • 学習しながら実行する場合、リーダーは答えを与えるのではなく、方向性を定める。方向性を定めるとは、その組織にとって最も重要な優先事項を述べることである。実現する方法については、リーダーははっきり言わないし、言うこともできない。そのため、答えは示された方向へ向かいながら皆で協力して見つける、あるいは改善することになる
  • 学習しながら実行するための基本的なステップ
    • 診断：組織に迫っている状況やチャンレンジや問題を診断する
    • デザイン：学習しながら実行するための適切な行動計画をデザインする
    • アクション：新たなデザインに基づいて行動し、その行動を学習するための試みとして考える
    • 省察：次のサイクルを始めるために、プロセスと結果について省察する
  • 成功している会社は、プロセスや製品をより良いものにしようと常に努力している。「我々は何を学ぶことができるか。もっと上手くできることは何か」を毎日自らに問いかけている
 

第8章 成功をもたらすリーダーシップ

  • これからの最も成功するリーダーはおそらく、他の人たちの才能を伸ばせる人である。また、最高の形で活かされれば、チーミングは人々の能力を明らかにして高めることができる。ただ、チーミングはチャレンジを伴うものであり、常識やこれまでの経験に反することが少なくない。しかし人々が安心して、意見を率直に述べ、互いから学び、試すことができる状況を整えると、生み出されるもの、達成できるものをぐっと広げられる
  • 組織が学習しながら実行する姿勢を持って行動すると、境界を超えて共有することが当たり前になる。実行と学習が絡み合うと、パイの一切れの大きさをめぐって争うのをやめて、パイ全体の大きさを大きくすることへ自然と意識が集中するようである。問題を解決するためのアイデアを生み出すことは未来への切符だ。そしてチーミングはそうしたアイデアを発展させ、取り入れ、改善する手段なのである

 

おわりに

ここまで読んでいただきありがとうございます。

チーミング、心理的安全性、リフレーミングなど面白いですよね！ 

↓この本を読めばもっと深く理解できるのでとてもオススメです。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

 

次もチームで働くノウハウの本「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」を読みます。

読書楽しいですね！

来週も頑張ります。

DIVE INTO CODEのイベントに登壇してきました！〜転職活動 / 入社後の仕事について〜

DIVE INTO CODE 転職

こんにちは。ゆうすけです。

今日僕が通っていたプログラミングスクール / DIVE INTO CODEのこちらのイベントに登壇させていただいたので、発表した内容をブログにもまとめてみました。

diveintocode.doorkeeper.jp

↑のイベントページからの抜粋ですがこんなイベントです。

理想と現実のハザマの最前線にいるスクール卒業生エンジニアの方々にお越しいただき、

  • 就活の手段選び
  • 企業選び
  • 失敗談
  • 工夫した体験談
  • 評価された点
  • 入社前とのギャップ
  • 将来の目標

等、 セキララな本音 を余すところなくさらけ出し、スクールの実態と就業までの道を公開いたします。

僕が行ったwebエンジニアになるための転職活動・入社後の仕事についてをスライドをベースに極力分かりやすくまとめています。

自分がエンジニアへの転職活動をする前に知りたかったなーということを書いたので、エンジニアへの転職活動を考えている方の参考になれば嬉しいです。

1. 転職活動について

1-1. 会社選びの軸

f:id:ysk_pro:20181110202916p:plain

僕が会社選びの軸としたのは上記3点でした。

それぞれの理由は以下の通りです。

1. Ruby on Rails エンジニアになること

DIVE INTO CODEでRuby on Railsを学んでいたこと、Ruby on Railsのサービスを高速で開発出来るところに魅了を感じ、Ruby on Railsエンジニアになることを1つ目の軸突しました。

2. 自社サービスの開発をすること

自分でサービスを作ることが好きで、自分たちのサービスを開発・改善する仕事がしたかったので、自社サービスの開発をすることを2つ目の軸としました。

3. ビジネスサイドに関われること

ビジネスサイドのことを考えるのが好きなので、ビジネスサイドに関われることを3つ目の軸としました。

これらの3点を満たすのはベンチャー企業だと思い、ベンチャー企業の求人が多く掲載されているWantedlyを使って転職活動を行いました。（結果、Wantedly以外は使用しませんでした）

 

1-2. スケジュール

f:id:ysk_pro:20181110202931p:plain

図の通りです。

働きながらの転職活動で、業後の時間を使って約1.5ヶ月かかりました。

業後だったので、面接等は平日の19時以降でお願いしていました。

 

1-3. 面接で聞かれたこと

f:id:ysk_pro:20181110202943p:plain

ほとんど実務未経験からの転職だったこともあり、技術面よりも、考え方などの非技術に関することを多く聞かれました。

考え方や過去の行動が、自社のカルチャーに合うかどうかをしっかり見ていただけたという印象を受けました。

 

1-4. 今の会社に決めたポイント

f:id:ysk_pro:20181110202959p:plain

いい会社ばかりで決められなかったので、↑のように自分が重視していることを点数化して、定量的に決めました。

どこの会社も一緒に働きたいと思う人がいたので1つに選ぶのは辛かったです...

 

1-5. 良かったこと

f:id:ysk_pro:20181110203016p:plain

エンジニアとしての実務経験がほとんどなく、スキルを証明できるものが自分で作ったサービスしかないので、サービスをしっかり作り込みました。

また、DIVE INTO CODE の DEMODAY という、オリジナルwebサービスを80人の人の前で発表するイベントに申し込むことで自分を追い込み、クオリティを上げることができました 笑

↓はDEMODAYで登壇した日に勢いで書いた記事です。

ysk-pro.hatenablog.com

Wantedlyでお会いいただいた企業はどこも、オリジナルのwebサービスが面白かったので会ってみようと思った、とおっしゃってくださったので、しっかり作り込んでおいて良かったと思っています。

 

1-6. 失敗したこと

f:id:ysk_pro:20181110203039p:plain

図の通りです。

よく調べてから転職活動しましょう 笑 

 

2. 入社後の仕事について

2-1. 入社して今までにやってきたこと

f:id:ysk_pro:20181110203057p:plain

ありがたいことに、入社後1.5ヶ月間 手厚い研修を受けさせていただきました。

Rails研修は、一からToDoアプリを作りながら、チームメンバーにレビューをしていただく形式でした。

プロダクト研修は、自社サービスを理解するための研修で、開発環境でサービスを動かしたり、コードリーディングを行いました。

研修後はまず、実務に慣れるために細かいタスクを10件程度1.5ヶ月かけて行い、その後プロジェクトにアサインされて今はサービスを良くするための開発を日々行なっています。

 

2-2. 最近の1日の流れ

f:id:ysk_pro:20181110203108p:plain

ほとんどの時間、開発 or コードレビューでコードに向き合っている時間です。 

 

2-3. 苦労していること

f:id:ysk_pro:20181111075411p:plain

入社するまでテストコードはほとんど書いたことがない状態だったので、テストコード（僕の会社ではRSpecを使っています）を書くのに苦労しています。

ほとんど全てのコードにテストコードを書いており、実装よりもテストコードを書いている時間の方が長いような感じです。

限られた時間の中でテストコードの書き方までマスターするのは難しいですが、入社までに雰囲気を掴んでおけばもっとスムーズに実務に入れたかなーと思っています。 

 

2-4. 入社前とのギャップ

f:id:ysk_pro:20181110203126p:plain

前職（銀行）とのギャップの影響も大きいですが最高です。 

 

3. 質疑応答

発表後にパネルディスカッション形式で質疑応答がありました。

覚えている範囲の質問と回答です。

・入社後感じた、現場とスクールの一番のギャップはなんですか？

→ JavaScriptの実装に苦労しています。スクールではJavaScriptについて深く学びませんでしたが、Webアプリケーションのフロント側の実装にはJavaScriptは必須になっており、避けては通れません...

・スクールで学んだ内容は、現場で活きますか？

→ 活きます。Ruby, Railsの基本は当然同じなので、スクールでしっかり学んでおけば現場でも通用します。

・質問しやすい環境？

→ めっちゃしやすいです（これは会社によると思います）

・DICに入ってよかったですか？

→ 良かったです。卒業後もずっとサポートしてくれること、テキストもずっと見れるので仕事中に分からないことがあったらテキストを見たりしています。

・これからの目標は？

→ 自分のサービスを収益化すること！

 

4. おわりに

登壇緊張したけど楽しかったですー！

喉ガラガラですみませんでした...

転職活動についての更に詳細（実際の職務経歴書など）はこちらのnoteに書いていますので、もし良ければご覧になってください。

note.mu

また、DIVE INTO CODEに通って出来るようになったことや感想を、DIVE INTO CODEを卒業したタイミングでまとめたので、こちらもご興味ある方は是非ご覧ください。 

ysk-pro.hatenablog.com

個人型確定拠出年金(iDeCo/イデコ)ってなに？お得なの？〜メリット・デメリットを紹介〜

ライフハック 銀行

こんにちは。ゆうすけです。

僕が勤めている会社では、なんでも発表してOKの自由なLT会が毎週金曜日の夕方に開催されています。

僕は銀行で４年間働いていたので、お金にまつわることを発表することが多く、先日は「個人型確定拠出年金（iDeCo / イデコ）」について発表してきました。

LTを聞いてくれた方15人中1人しかこの制度を利用していませんでしたが、割とシンプルで知っておかなければ損な制度です。

「メリット・デメリットを知りたい」「で、やった方がいいの？」という方向けに、図を中心に分かりやすくまとめたので、ご興味ある方は是非ご覧ください。

正確さよりも分かりやすさを重視しています。

※ 僕の会社に企業型確定拠出年金が無いので、企業型確定拠出年金が無い方向けに書いています。

f:id:ysk_pro:20181020135132p:plain

1. 個人型確定拠出年金（iDeCo）とは？

f:id:ysk_pro:20181020135628p:plain

個人型確定拠出年金は iDeCo（イデコ）という愛称でよく呼ばれています。

ここからは iDeCo という呼び方で進めます。

 

2. メリット

2-1. 掛け金が全額、所得控除される 

f:id:ysk_pro:20181020135702p:plain

iDeCoにて積み立てを行うと、積み立てた額が、税金の計算の元となる金額から引かれ、その結果税金が安くなります。

例の条件では、なんと年間で8万2,800円も税金が安くなります。

 

2-2. 運用して利益が出ても税金０円

f:id:ysk_pro:20181020135757p:plain

通常、運用をして利益が出ると20.315%の税金がかかりますが、iDeCoでの積み立てであれば、どれだけ利益が出ても税金は全くかかりません。

例のケースでは、運用益336万円に対して通常の運用であればかかるはずの20.315%分の67万円の税金が節約できています。

 

3. デメリット

デメリットもあります。

f:id:ysk_pro:20181020135811p:plain

途中で積み立て金額を減らしたり、積み立てを中断することは出来ます。 

 

4. まとめ

f:id:ysk_pro:20181020135829p:plain

この制度の枠内で積み立てることで、年間数万円節税出来ることがあるので、やらなきゃ損な制度だと個人的には思っています。

 

 5. おわりに

いかがでしたでしょうか。

iDeCoのメリット・デメリットについて少しでも分かっていただけたら嬉しいです。

この記事ではざっくりと理解してもらうことを目的としているので、もっと詳しく知りたい、という方や企業型確定拠出年金に入っているという方は証券会社のHPをご参照ください。

（僕は楽天証券でやってます。）

↓こんな記事も書いているので良ければ合わせて読んでみてくださいー！

ysk-pro.hatenablog.com

【技術書まとめ13】UNIXという考え方―その設計思想と哲学

毎週１冊技術書を読んでブログでアウトプットすることを目標にしており、今回は第13弾です。

今回は、UNIXという考え方―その設計思想と哲学  を読んでまとめました。

50年近く使われ続けているOS、UNIXの設計思想と哲学を分かりやすく解説している技術書です。

有名な起業家 けんすうさんもオススメされています。

プログラミングの知識がなくてもサクッと読めるので、UNIXの設計思想・哲学について興味がある方は是非読んでみてください！

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

 

f:id:ysk_pro:20181028193356p:plain

第1章 UNIXの考え方：たくさんの登場人物たち

  • UNIXの考え方の定理
    • スモール・イズ・ビューティフル：小さいものは、大きいものにはない利点がいくつもある。小さいもの同士なら、簡単に独特の便利な方法で組み合わせることができる
    • １つのプログラムには１つのことをうまくやらせる：１つのことに集中することで、プログラムに不要な部分を無くせる。不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かなくなってしまう
    • できるだけ早く試作する：あらゆるプロジェクトにおいて試作は重要。一般的に、試作は設計全体のうちのほんの一部として扱われているが、UNIXにおいての試作は、効率的な設計に欠かせない重要な一部である
    • 効率より移植性を優先する：現代のソフトウェア設計では、プログラムに移植性があることは当たり前のこととなっている。これはUNIXの考え方のうち、他のシステムにも広く取り入れられているものの一つである
    • ソフトウェアを梃子（てこ）として使う：再利用可能なモジュールの重要性について、たいていのプログラマは表面的にしか分かっていない。プログラムの再利用は、ソフトウェアの梃子を最大限に利用した強力な考えである。UNIXの開発者たちは、この考え方にしたがって、非常に多くのアプリケーションを比較的短期間に開発してきた
    • 過度の対話的インタフェースを避ける：いくつかのコマンドは、ユーザーを拘束するインタフェースを持つ。そのコマンドを実行してしまうと、実行中に他のコマンドを実行することはできない。つまり、そのコマンドの実行中は、ユーザーはそこを離れられなくなってしまう。そのため、この類のものは拘束的ユーザーインタフェースと呼ばれる
 

第2章 人類にとって小さな一歩

  • プログラムには、過多にならないように適切にコメントを付ける。サブルーチンを短く保つ。必要最小限のコードだけにまとめる。このような努力をして初めて、保守しやすい小さなプログラムとなる
  • 作ったときには予期できなかったことに対しても、小さなプログラムなら直ちにそれに対処することができる
 

第3章 楽しみと実益をかねた早めの試作

  • 最初の仕様から変更がないプロジェクトなどは稀である。最初からうまくやろうとするより、最初はうまくいかないと考えて対処した方が賢明である。後で大幅な変更に取り掛かるよりは、開発の初期段階で変更を行う方がはるかに安上がりとなる
  • 「ソフトウェア開発に終わりはない。あるのはリリースだけだ」
 

第4章 移植性の優先順位

  • よいプログラムは死なず、ただ新しいハードウェアに移植される
  • 効率と移植性の二者択一を迫られた時、UNIXプログラマなら、十中八九後者を選択する。結果的に、UNIXプログラマのアプリケーションが、新しいハードウェアが登場したとき真っ先に動作するアプリケーションになることが多い
  • プログラムを移植しやすく、データを持ち運びやすくしておくことで、ソフトウェアに長期的な価値が生まれる。移植性を最優先に設計するべき
 

第5章 これこそ梃子の効果！

  • よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる。ソフトウェアを大量に書く一番よい方法は、借りてくることである。ソフトウェアを借りるということは、他人のモジュールやプログラム、設定ファイルを自分のアプリケーションで使うということ。自分の仕事に他人の成果を取り込むことで、先人の努力を活かし、コードの有用性を一段と高めることができる
  • 既存のアプリーションをゼロから設計し直すことは、模倣ではあっても創造とは言わない。むしろこれを避けることで、新しい、わくわくするような設計世界への扉が開かれる
  • ある作業を自動化すると、そこに梃子の原理が働く
 

第6章 対話的プログラムの危険性

  • 拘束的プログラムは、どこかで人間と対話することを想定しているため、ソフトウェアの梃子の効果を利用できない
  • プログラムから発生するデータの受け取り手が人間ではなく、別のプログラムかもしれないことを念頭に置いておく
  • プログラムに何ができるかという内向きのことばかり考えず、プログラムがどういう場所に入り込めそうかを考える。そうすれば、そのプログラムを一部とする大きな全体が見えてくる
 

第7章 さらなる10のUNIXの考え方

  • UNIXコマンドは、入力データが与えられなかったり、出力するデータがなかったりしてもエラーを返さないものが多い。UNIXコマンドはパイプ機構（|）で繋がれた際に、エラーメッセージでおかしな挙動になることを防ぐための設計となっている
  • 90%の解を目指す。90%の解とは、難しい部分を故意に無視することを意味している。難しい部分とは、問題の中で高くつく部分、時間のかかる部分、実装しにくい部分である。一番難しい10%を無視してよいのであれば、世界中のほとんどの問題はすぐにでも解決できる。これがUNIXの成功の一因である
  • UNIXの考え方とは、常に将来を見据えながらオペレーティングシステムとソフトウェアの開発にアプローチすることである。そこでは、常に変化し続ける世界が想定されている。将来は予測できない。一日ごとに今日が昨日になっていく日々を過ごしながら、将来に適応し、前進し続けなければならない。UNIXの理念とは、将来に向かうアプローチの一つである。その本質は柔軟であり続けることである。嵐が何度やってきても、風に揺れる木は折れることはない

 

おわりに

ここまで読んでいただきありがとうございます。

UNIXに関わらず設計思想全般に関する内容だったので、とてもいい勉強になりました。

本書自体140ページ程度でサクッと読めてしまうので、興味を持った方は是非お手に取って読んでみてください！（Kindle版が無いのは残念...） 

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

 

次は、Team Geek ―Googleのギークたちはいかにしてチームを作るのか を読む予定です。

Googleのマネージャーによる、チームで働くノウハウについての本です。

評判のいい本なので読むのが楽しみ！

来週も頑張ります。

メソッドの呼び出しエラーで学ぶRubyのインスタンスメソッド・クラスメソッド

Ruby on Rails 技術書

こんにちは。ゆうすけです。

業務で僕がハマったRubyのメソッドの呼び出しエラーについて丁寧に解説していきます。

この記事を読めばRubyのクラスメソッド・インスタンスメソッドについてざっくり理解できるようになると思います。

↓の例題をご覧になって、答えと理由を即答できなかった方は是非読んでみてください！

f:id:ysk_pro:20181028085539p:plain

1. 例題

こちらのコードの出力はどうなるでしょうか？

class A
  def self.b
    c
  end

  private

  def c
    p 'Yeah!'
  end 
end

A.b

① Yeah!
② エラーとなる

Twitterでアンケートをとってみた結果がコチラです。


　

2. 例題の答え

② エラーになる が正解です！

いかがでしたか？

Twitterアンケートでは正解者は半数以下となりました...！

3. 解説

この問題を理解するために、順を追って解説していきます。

3-1. メソッドのレシーバとは？

通常、メソッドは以下のように呼び出すと思います。

オブジェクト.メソッド名（引数1, ・・・）

このときの、オブジェクトをレシーバと呼びます。

メソッドを実行することをオブジェクトにメッセージを送る、という考え方をするので、メッセージを受け取るという意味からレシーバと呼ばれています。

3-2. インスタンスメソッド・クラスメソッドとは？

インスタンスをレシーバとするメソッドをインスタンスメソッドと呼びます。そのままですね。

同様に、クラスをレシーバとするメソッドをクラスメソッドと呼びます。

例えば、インスタンスを作るときによく使う

User.new

の .new はクラス(User)をレシーバとしているのでクラスメソッドです。

直接インスタンスを操作するわけではないけれども、そのクラスに関連する操作を行いたい場合に、よくクラスメソッドが用いられます。

3-3. インスタンスメソッド・クラスメソッドの定義の仕方

こちら↓のx がインスタンスメソッドです。よく見る形ですね。

class A
  def x
    c
  end
end

そしてこちら↓の y がインスタンスメソッドです。self. をつけるとクラスメソッドになります。

class A
  def self.y
    c
  end
end

クラスメソッドは↓の z のように定義することもでき、以下のように定義したメソッドは特異メソッドと呼ばれます。

class A
  class << self
    def z
      c
    end
  end
end

　

3-4. メソッド内で別のメソッドの呼び出す方法

メソッドの中では、そのメソッドのレシーバ自身を参照するのに self を用います。

さらに、メソッドの中ではレシーバを省略してメソッドを呼び出す出すことができます。

レシーバを省略してメソッドを呼び出すと、暗黙的に self がレシーバとなります。

すなわち、インスタンスメソッドの中でレシーバを省略してメソッドを呼び出すと、呼び出されるのはインスタンスメソッドとなり、クラスメソッドの中でレシーバを省略してメソッドを呼び出すと、呼び出されるのはクラスメソッドとなります。

＜プラス知識＞
private というのは、メソッドをレシーバを指定して呼び出せないようにしています。
つまり、レシーバを省略した形式でしか呼び出せないために、インスタンスの外側から利用できなくなっているのです。

3-5. ここで問題を再度見てみると...

class A
  def self.b
    c
  end

  private

  def c
    p 'Yeah!'
  end 
end

A.b

① Yeah!
② エラーとなる

b メソッドはクラスメソッドだということがまず分かります。

よって、その b メソッドの中で呼び出している c メソッドのレシーバはAクラスとなるため、c という名前のクラスメソッドを探しにいきます。

しかし、c という名前のクラスメソッドは存在しないため（存在するのはc という名前のインスタンスメソッドのみ）エラーとなるのです。


cメソッドをクラスメソッドにした、↓のコードであれば、出力は Yeah! となります。

class A
  def self.b
    c
  end

  def self.c
    p 'Yeah!'
  end 
  private_class_method :c
end

クラスメソッドをprivateにする方法は↑のコードの通りです。

4. おわりに

いかがでしたでしょうか。

僕は業務でクラスメソッドからインスタンスメソッドが呼べずに１時間程ハマるまで、クラスメソッドとインスタンスメソッドの区分が曖昧になっていました。

この記事で皆さまの理解が少しでも深まると嬉しいです。

ちなみに、僕がこの件でハマった際は、↓の本の解説で解決することができました。
解説がとても丁寧で分かりやすいので、Rubyについて深く知りたい方にオススメです！

たのしいRuby 第5版

たのしいRuby 第5版

改めて読んで見ても、「ああ、そういうことだったのか」という気づきが多くて面白いですよー！

Enjoy Ruby!