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

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

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

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

Twitterにグラフをシェアできるサービスを３つ作りました！〜サービスの紹介、作った背景、使った技術など〜

サービス開発 Ruby on Rails

今月は久々にwebサービスを開発していて、似たようなサービスですが３つリリースすることができました💪 

サービスの紹介、作った背景、使った技術などをまとめたのでご興味ある方は是非ご覧ください！

いつも僕がどんな感じでサービスを作っているのかも書いています。

（記事は読まなくてもいいので是非サービスだけでも触ってみてください(> <)）

f:id:ysk_pro:20181224204243p:plain

作ったサービスの紹介

1. いちにちをシェア

自分の１日をかんたんにシェアできるサービスです。


2. いちねんをシェア

いちにちをシェアの１年バージョンです。

 

3. いちねんのさいてん

レーダーチャートで１年を振り返れるサービスです。
１年を振り返る以外の用途でも、レーダーチャートでステータスを表示して遊べます。

 

なんで作ったの？

仕事の１日のスケジュールや、休日の１日のスケジュールをTwitterでシェアしたい、また他の人のスケジュールを見てみたいなー、と思ったことが開発のきっかけです。
 
余談ですが、webサービスのアイデアは思いついたらすぐにEvernoteにメモをするようにしており、もう既に開発したものを合わせて現在64個のアイデアがたまってます。作り切れない、、、笑
 
いちにちをシェアを作った後に、年末なので1年を振り返れる機能をつけたいなーと思って、いちねんをシェア、いちねんのさいてんを開発しました。
 
手書きのデザイン案が残っていたので一応載せます。

いつもこんな感じで手書きでざっくり書いてます。f:id:ysk_pro:20181224192909j:plain

 

どんな技術を使っているの？

当初予定していた構成

バックエンド Firebase × フロントエンド Vue.js でいこうと思っていました...
 
理由はモダンでかっこいいから！
 
どちらも使ったことはなく、本やチュートリアルで勉強したりしながら頑張りましたが挫折してしまいました、、、
 
やっぱり一気に新しい技術を使いすぎるのは良くないですね...みたいなことはこの記事に書いているので是非読んでみてくださいー！

 

採用した構成

結局はいつもの構成に落ち着きました。
 
バックエンド Ruby on Rails × フロントエンド jQuery
 
jQueryをまだ使いこなせていないレベルだったので、今回はjQueryをたくさん使って使いやすいサービスにすることをテーマとしました。
 
例えば、
値を入力したら自動でグラフが生成されたり

1つ前の時間以降しか表示させなくしたりしました（触ってみてね！）

 
チャート生成は chart.js というJavaScriptのライブラリを使っています。
このドキュメントはもう暗記するぐらい読み込みました 笑
ドキュメントが日本語でしっかりまとまっているのでとてもやりやすかったです。
 
サーバーは、いつも通り Heroku です。
使いすぎて無料枠の月1,000時間をオーバーするようになってしまったので、現在は苦肉の策としてアカウントを2つに分けて運用しています。
 
画像の保存は Amazon S3 を利用しています。
 

どれくらい時間がかかったの？

Rails × jQuery で作り始めてからは土日を5日くらい使って完成させました。
 
僕の開発の仕方は、自分で書いたチュートリアルを組み合わせてベースを作り、そこからやったことがないことに挑戦していくスタイルです。
今回であれば、このチュートリアルを見ながら進めました。

 
僕が技術チュートリアルを書いているのは他の人の役に立てばいいなというのが一番ですが、このように将来の自分のためでもあります。
過去に作ったものも、コードしか残っていないと自分のコードであっても分からなくなってしまうことがありますが、チュートリアルであれば他人でもわかるように書くので自分で後から理解できておすすめです。
 
今回もできればチュートリアルにまとめたいと思ってます。
（コードがぐっちゃぐちゃなのでリファクタするのが面倒ですが、、、個人開発はどんなにコードが汚くても動けばOK、テストコードも書かない派です）
 

おわりに

みんな是非遊んでみてねー！！！

【読書まとめ17】説明がなくても伝わる 図解の教科書

デザイン

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

今回は、説明がなくても伝わる 図解の教科書 を読みました。

会社でデザイナーの方にオススメしてもらった、図解の仕方を実例を交えながら分かりやすく解説している本です。

ノンデザイナーの僕でもすぐ実践できそうな内容ばかりでとても為になったのでおすすめです。

説明がなくても伝わる 図解の教科書

説明がなくても伝わる 図解の教科書

  

f:id:ysk_pro:20181223171216p:plain

Chapter1 「図」がすべてを語ってくれる

  • 資料やスライド画面を見たときに、人が最初に目にするのはタイトルでも見出しでもなく、図解や写真といった「視覚イメージ」。人は生理的に図やイラスト、写真を見て、その資料や文書が自分にとって重要かどうかを判断し、重要であれば文章を読み始める
  • 抽象的・概念的な内容は、文字に頼らなければならない場合が多いが、文字を視覚イメージと一緒に示したり、分類方法を変えて整理したりすることで、伝わりやすくなることが多い
  • 図解をつくる基本手順は、基本原則を身につけて、伝えたいメッセージを図解の型に流し込むことである
  • デザイナーはまず手書きで始める。図をつくるときには、事前のアイデア出しやラフスケッチづくりが、最終的な品質に大きな影響を及ぼす
  • 図解のプロセスは頭文字をとってDTMと呼ばれる
    • Discovery（発見）：参考となる事例を見つける
    • Transformation（変形）：課題に合わせ、事例に手を加える
    • Making（形成）：スケッチをもとに図を仕上げる
 

Chapter2 伝わる「図」の5つのポイント

  • 図解の5つの基本機能
    • 一瞬で伝える
    • 親しみやすくなる
    • 不安を解消する
    • 真剣に受け止めてもらう
    • 誤解やミスを防止する
  • 図解づくりの目標
    • 伝えたいことを、受け手が予想できるようになる
    • 受け手が困らないように道案内をする
  • 「すでに広く使われていること」は、誰にでも理解されるための重要な要素である。すでにみんなが慣れ親しんだものを使う方が、手間もコストもいらず、人の役に立つことができる
  • どのようなプロセスで手続きが進み、どうすれば終了できるのかを、全体・部分・流れを示して提示すると読み手に安心を与えることができる。ステップを踏みながら説明するステップバイステップ技法が有用である
  • 重要部分を赤文字にすると、むしろ見えづらくなってしまうことがある。赤文字は黒文字よりも視認性が悪い。色を使わずに文字を強調するには、下線を引く、大きな字を使う、単語を囲む、太字を使うことが有用
  • 良い例と悪い例など相反する２つの例があることで、情報がより明快になる
 

Chapter3 「主題」「見せ方」「仕上げ」の３つの山を超える

  • 整理されていない情報は、情報とは言えない。つまり、整理されていない情報から価値は生まれない
  • 「立場」「作業内容」「時間軸」の３つで情報を分類すると伝わりやすい
  • 同じ分類内容に一貫して同じ形式（文字や線などの形式）を使う
  • 写真とイラストの使い分け
    • 写真：リアリティが重要で、雰囲気や広く詳細な情報を伝えたい時に役立つ
    • イラスト：焦点を絞り、必要なことだけを伝えたい時に役立つ。イラストは不必要な情報をあらかじめ省いておくことができる
  • グラフにはそれぞれ機能がある
    • 円グラフ：全体に占める割合を伝えるだけ。ある割合と別の割合を比較させる目的では使わない。また、円グラフの分割は最小限に留めるべき
    • 分割棒グラフ：割合の違いを伝えるだけ。円グラフの弱点を補う一方で、全体に占める割合は伝わりにくい
    • 折れ線グラフ：時間軸に沿った動向を伝えるだけ。時間軸は必ず等間隔に表示する
    • 棒グラフ：数値の差を伝えるだけ。必ずゼロを基準値として、バーの長さを省略しない
    • 数値一覧表：具体的な数値を伝えるだけ。大量の数値情報を１箇所に示す場合に役立つが、受け手の読み取りに大きな労力を強いるので、他のグラフによる提示方法があればそちらを優先した方がいい。使うのであれば、グリッド（格子状の線）を消し去り、平均値を示し、数値を縦に並べ、キリのいい数値で示すと理解しやすくなる
  • 図解の仕上げのポイント
    • インパクトを弱める：情報を全て強調してしまうと逆効果であり、主題に関わらない部分のインパクトは弱めるべき
    • 多様性を否定する：異なる情報は全く異なっているように見せ、同じ種類の情報は同じもののように見せる
    • 自分を信じない：自分はバイアスのかかった状態にあることを自覚し、実際に人に見てもらう
  • ポイントは箇条書きにし、可能なら図解化する。長い文章よりも箇条書きの方が目に入りやすい。文章から図解化する手順は、文章を要点ごとに分解し、それを箇条書きにして要点を絞ってから図解をする
 

Chapter4 「図」を変えれば全て伝わる

  • テキストで1行足らずのシンプルな情報でも、枠で囲んで並べるだけで図解となり情報が読み取りやすくなる
  • 手順を説明するときは、イラストと説明文を近くに配置すると、受け手の誤解や見落としが少なくなる
  • 数値は右揃え、単位は左揃えを原則とする
  • グラフは凡例を分離せずに、グラフ内に直接書き込んだ方が伝わりやすい
※ Chapter4では、50個の事例（それぞれ悪い図解と良い図解の比較）を分かりやすく解説しています
 

おわりに

ここまで読んでいただきありがとうございます。
 
会社でよく先輩に図解を交えて教えてもらっていて、言葉で説明してもらうよりもスッと入ってくる図解の威力を感じているので、本書を読み込んで図解力UPしていこうと思います。
このブログには掲載できませんでしたが、当然本書の中でも図解を多用しておりとっても分かりやすかったので是非お手にとってご覧ください。
説明がなくても伝わる 図解の教科書

説明がなくても伝わる 図解の教科書

 

最近はサービス作りに夢中で本を読めていませんでしたが、またここからどんどん本を読んでいきますー。

来週も頑張ります。

Ruby初学者の楽しい個人開発 〜 モチベーションの維持・どんなサービスがオススメ？ 〜

サービス開発 Ruby on Rails

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

先日、Ebisu.rb に初参加して初LTしてきました！

Ebisu.rb は恵比寿界隈のRubyistの交流を目的として結成された地域Rubyコミュニティです。発表を通して知見を共有しながら、懇親会で交流を深めていきたいと思います。

勉強になるLTを聞くことができ、普段関わることのない他社のRubyエンジニアの方々と交流ができ、とても有意義なイベントでした。

せっかくなので、僕が行ったLT「Ruby初学者の楽しい個人開発」をまとめてみます。

↓こんな内容について話したので、ご興味ある方は是非ご覧ください。

f:id:ysk_pro:20181201091059p:plain

僕の個人開発Life

f:id:ysk_pro:20181201092203p:plain

僕は１年前の2017/11に DIVE INTO CODE というスクールでプログラミングを始めました。

スクールの課題でオリジナルWebサービス作ったことがきっかけで個人開発にハマり、これまでに９個のサービスをリリースしてきました。

初めてサービスをリリースしたのはプログラミング歴4ヶ月の時でした。プログラミングのスキルが低くても個人開発はできます。

個人開発において大切なのはプログラミングのスキルよりも、作りたいというやる気や情熱だと思っています。

 

なぜ個人開発をやっているのか

f:id:ysk_pro:20181201092225p:plain

自分が作ったサービスが使ってもらえた時の嬉しさがやっぱり一番です。

ほんとに嬉しいです。 

（でもやっぱりいつか一発当ててみたいなぁ..）

 

モチベーションの維持

f:id:ysk_pro:20181201092240p:plain

モチベーションの維持は個人開発の中で最も難しいことの一つだと思います。

サービスを作っていると技術的にどうしようもできないことや類似サービスの存在などの壁にぶつかることも多く、やらなかったからといって誰かに何か言われることもありません。

会社の同僚などと話していても、個人開発や知人との共同開発を始めたけれど、モチベーションが続かなくて完成までたどり着けなかったという話はよく聞きます。

僕がモチベーションの維持のためにしていることは２つです。

 

① 作ったサービスは全く自信が無くてもTwitterで発表するようにしています。（使ってもらわないと意味がない！）

優しい人もいるもので、感想やフィードバックをくださる神が毎回現れます。（←嬉しい！モチベーション爆上がり）

さらに、サービスを発表するとなぜかTwitterのフォロワーが増え、フォロワーが増えるとサービスを使ってくださる方・リアクションしてくださる方も増えるという正のループが生まれていました。

僕のTwitterアカウントはこちらです → ゆうすけ@Railsエンジニア (@ysk_pro) | Twitter

 

② 個人開発者の集まりに参加しています。（ 運営者ギルド というグループです）

月１くらいで飲み会があります。すごい人ばかりですがみなさん優しくて、自分のサービスについて語り合うっていうのは思っているよりも楽しくて刺激になります。「もっとすげえサービスを作りたい」という気持ちに毎回なってます。

 

失敗談

f:id:ysk_pro:20181201092313p:plain

「Jobmiru」は僕の処女作です。

プログラミングを始めたばかりの頃は、毎日このサービスのことを考えて、デザインも頑張って整えて、4ヶ月かけてなんとか作り上げましたが、ほとんど使われませんでした...（でも転職活動で使えたので作り上げることができて良かった）

Heroku有料版 → 無料版に切り替えて現在も存続はしています。（ドメイン更新しようか迷うなぁ）

www.jobmiru.com

 

f:id:ysk_pro:20181201092349p:plain

Jobmiruがなんで使われなかったのかなー、などと色々考えたりして学んだことがコチラ↑です。

僕が作ったJobmiruのような口コミサイトは、投稿のインセンティブを作るのが難しいです。以下記事にあるように他のサービスの事例を研究して、なんとかしようと模索しましたがうまくいきませんでした。

ysk-pro.hatenablog.com

また、最近流行り（？）のマッチングサイトに関しても、多数のユーザーがいないと成立しないサービスであり、口コミサイト同様に初期ユーザーを集めるのが大変なことから、個人開発には難しいのではないかなーと個人的には思っています。 （もちろん、うまくいっているすごいサービスもありますよ）

 

個人開発にはどんなサービスがオススメか

f:id:ysk_pro:20181201092330p:plain

逆にどんなサービスがオススメかというと、こちら↑の図にあるように「Simple」×「Easy」なサービスだと思います。

シンプルなサービスでログイン無しで気軽に使えるのであれば、ちょっと使ってみるかー、と思ってもらいやすいはずです。

また、<+α> のところに書きましたが、スキルアップのために新しい言語や技術を使うのは素晴らしいですが、一度にやり過ぎてしまうとそれが挫折の原因になってしまうので少しずつにした方がいいと思っています。

実際に、最近全く使ったことのなかった Vue.js × Firebase でサービスを作ろうとして挫折しちゃって学びました...泣

 

f:id:ysk_pro:20181201092426p:plain

Simple × Easy の例として、僕が作ってきたサービスの中で気に入っているものを２つ紹介します。

 

BigTweetは画像に文字が入ったツイートを10秒でできるサービスで、ログインなしで使えます。 

bigtweet2.herokuapp.com

 

今日雨降るよちゃんは、雨が降る日の朝だけお知らせしてくれるLINE botです。

こちらは、LINE APIのお友達制限数いっぱいになってしまい、新規お友達追加ができないので、紹介ブログを掲載します。

ysk-pro.hatenablog.com

どちらもこんなサービスがあったらいいなあ、と思うことを余計な機能をつけずに最低限の機能で作ったイメージです。

 

まとめ

f:id:ysk_pro:20181201092412p:plain

個人サービス開発に必要なのは、プログラミングスキルよりも、作りたいという気持ちです！

是非楽しい個人開発Lifeを送りましょう！！

 

全スライド

全スライドはこちらです。

 

 

おわりに

ずっと気になっていた地域.rbへの参加・LTはとっても楽しかったです。（いきなりLTをすることにビビってた僕の背中を押してくれて、発表練習まで付き合ってくれた先輩方に感謝）

この記事のご感想はコチラのBigTweetから是非お願いします！！笑

bigtweet2.herokuapp.com

ここまでお読みいただきありがとうございました。

【技術書まとめ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