代々木で働く19歳エンジニアのブログ

思ったこととか、技術的なこと書きます。

Gemfileのバージョン指定の書き方

  • 1.0.0 バージョンを固定。
  • >= 1.0.0 1.0.0以上のバージョンが必要
  • >= 1.0.0, < 2.0.0 1.0.0以上、2.0.0未満のバージョンが必要、ex) 1.x.x
  • ~> 1.0.0 1.0.0以上で利用可能で、1.0.9などは問題なく、1.1にバージョンが上がると利用不可 ex) 1.0.x

reference from

面白い記事を読んだ

qiita.com

なるほどという感じ。 イメージは、go, ruby, jsしか書かないって絞れば勉強時間集中するから、そこそこ強くなれる気がする。

クリティカルパス

  • クリティカルパスとは、プロジェクトの中で「開始から終了までに最も長い時間を要するタスクの連なり」
  • フロート日数とは、クリティカルでないタスクの作業上の余裕日数

所感

  • クリティカルパスを理解することで、そのプロジェクトにおいて絶対に遅れてはいけないタスクがわかるということを学んだが、そもそもそのタスクの切り分け単位が適切でなかったり、タスクごとの見積もりが間違っていると全てにおいてズレが生じるので、そっちの見積もりも正確にやる必要があると感じた。

Reference from

第8回 クリティカル・パスをみつける:タイム・マネジメントの心得 ~あなたを多忙から開放する10の方法~ | エンジニアマインド … 技術評論社

仮説思考―BCG流 問題発見・解決の発想法 を読んで

今回この本を読んだ目的

  • 仕事のアウトプットのスピードを上げるため
  • 新規事業をより深い思考で考えるようになるため。

仮説思考とは

  • 仕事ができる人は人より答えを出すのが早い。まだ十分な材料が集まっていない段階、あるいは分析が進んでいない段階で自分なりの答えをもつ。この答えを仮説と呼ぶ。仕事の遅い人の特徴はとにかく沢山の情報を集めたがること。
  • 仮説思考とは物事を答えから考えること。課題を分析して答えを出すのではなく、まず答えを出し、それを分析して証明する。
  • 常に自分の仮説を持つ。あなたの仮説は何かと問い続ける

情報収集

  • 情報は集めるよりも捨てるのが大事
  • 意思決定をするときは、今すでにある選択肢を狭めてくれる情報だけが役立つ。情報コレクターでは、アクションに繋がらない。
  • 迅速な意思決定のためにはいかに絞り込むかという視点で情報収集すべき
  • 網羅思考は非効率。
  • 全ては相対的であり、自社が何をするかによって相手の動きも変わる。自分がこう動くという実行案志向、すなわち答えの仮説から入るアプローチをとるべき。

先に枝葉ではなく幹を作る

  • 十分な分析や証拠がない状態でも問題に対する解決の方向性や具体的な打ち手まで踏み込んで、全体の仮説を作る。そうすると、ごく一部の証拠は揃っているけれども大半は証拠がない状態になり、自分が作った仮説を検証ために必要な証拠だけ集めればいいので、無駄な分析や情報収集の必要がなくなり、効率が良くなる
現状分析をするとこういう分析結果が得られるだろう。その中でもこの問題の真の原因はこれでその結果としていくつかの戦略が考えられるが、最も効率的なのはこの戦略だ。
  • あまりに間違った仮説だと、ストーリーの正しさを証明するために証拠集めを始めた段階で仮説を肯定するような証拠がなかなか集まらない。そのため自分の作ったストーリーが間違いであることにすぐに気がつく。

f:id:tenshotanaka:20170926031120j:plain

空パッケージ

  • 中身が埋まっていないスライドがたくさんあるパッケージ。具体的に言えば30枚くらいのスライドのパッケージのうち、大半が埋まっていないか、あるいは言いたいこと、証明したいことは書いてあるが、内容は書かれていない、あるいは分析されていないスライドの集まりのこと。
  • ストーリーラインのみがわかるもの、そして言いたいことを言うために必要な資料のイメージだけのパッケージのこと。
  • 自分が何を考えているか明白になる
  • すでに証明されていることがわかる
  • 何が足りないのか、そのためにどんな情報収集や分析をやらなければいけないかがわかる。

f:id:tenshotanaka:20170926030853j:plain

プレゼン

  • 聞き手の立場で再構成する
  • プレゼンを通して成し遂げたいことを明確にしたうえで、そのために何をどういう順番で話すのが良いのかを逆に考えて行く。

仮説構築のためのインタビュー技術

目的三種

1.業界、業務を理解する 2.問題を発見、整理する 3.仮説を構築、検証する

  • 深く掘り下げた質問ができるかがカギ
  • hogeと言われた時に、hogeかと納得するのではなく、hogeなのはなぜかちゃんと聞く。相手が言ったことに対して5w1hを投げる。
  • インタビューで大切なことはたいての本音を引き出すこと。インタビューは和やかに話を進めるだけではいけない。ときには相手の嫌がる質問も必要。相手に自分から気づいてもらう、あるいは勘違いしてたかもしれないと思ってもらうような質問の仕方をする。

  • インタビューが一件終わるたびに結果を咀嚼し、インタビューの目的と照らし合わせながら質問の内容を変えたほうがいいかどうかを考え、次のインタビューに臨む。相手の出方や答えに応じて臨機応変に質問の内容を変えていくのが重要。

  • インタビューメモ 頭の整理、メモの構造化をする。時系列→内容別 仮説の検証結果を書く。自分の仮説が相手に受け入れられたのか、拒絶されたのか、概ね受け入れられたけれど、いくつかの問題点を指摘されたなど。

  • 他人とシェアするために、客観と主観を明確に区別する

ヒラメキ

  • 顧客、消費者の視点 一人のユーザーになりきる
  • 現場の視点
  • 競争相手の視点 自分が競争相手の社員なら
  • 両極端に振って考える どちらかに振り切ってみる
  • ゼロベースで考える 目的にたいして、白紙の段階から考えようとする姿勢

よい仮説

  • 掘り下げられている
  • アクションに結びつく
  • 問題発見が早くなる
  • 解決策が早く立てられる
  • 解決策が絞り込める

仮説の構造化

  • イッシューツリー、論点の構造化、立てた仮説を検証して絞り込む

f:id:tenshotanaka:20170926030955j:plain

仮説を検証する

  • 実験による検証(消費者刺激型開発戦略, テストマーケティング)

    • 商品開発のスピードが重要
    • まだ世にないコンセプトの商品を開発する場合市場調査はあてにならない。
    • ユーザーは必ずしも自分のニーズを的確に表現できないし、自分でも何が欲しいのかわかっていないことが多い。
    • コストが大きすぎるものは実験に向かない。
  • ディスカッションによる検証

  • 分析による検証(まず仮説ありき、次に分析)
    • 分析のコツは、最小限の要素だけを急いで簡単にやるようにすること。
    • クイックアンドダーティー、バックオブエンベロップ
    • 経営に必要な数字は有効数字1桁
    • 分析の目的とは、問題を発見する, 相手を説得する, 自分を納得させること
    • 定量分析の基本技(比較・差異, 時系列, 分布, 因数分解

仮説思考力

  • 仮説と検証の経験によって直感が生まれる。
    • so whatを常に考える
    • なぜを繰り返す
    • 信じていない仮説の正しさを証明する

名言

  • 世の中には、こうした思いつきの意見を言って仕事のやり直しを命じる上司が多く、部下が苦労している。
  • 何も実行しないことが大きなリスクになる今日、いつまでも選択肢を広げる情報収集を続け、意思決定のタイミングを遅らせるわけにはいかない。
  • リーダーに求められるものは、先見性、決断力、実行力

Reference from

仮説思考 BCG流 問題発見・解決の発想法

仮説思考 BCG流 問題発見・解決の発想法

最近RTFMについて思ったこと

生産性を上げるためには情報へのアクセス手段が必要で、それこそwebであり、document, manualと呼ばれるものなのではないか。基本的にggrksとかRTFMとかなるたけ、同期的なコミュニケーションをなくすことで時間のロスをなくそうという方針があり、それには大いに賛成である。でもそもそもその参照先が間違っていれば、RTFM!と言っても、間違っていると言われてしまってかっこわるい。だからその参照先のドキュメントもしっかり書く必要がある。そして、自分が書くようなドキュメントはweb上の公式ドキュメントの補足のようなもので、極論ドキュメントは書かれない、つまり公式ドキュメントでこと足りるという状態になることが理想である。したがって、ドキュメントを書く場合は正確にかつわかりやすく書く必要がある。

じゃあどうすれば、わかりやすく書けるのかというとそれはおそらく、ありとあらゆる事象の命名をきちんとすることである。これはプログラミングにかぎらず他人と意思疎通を図る上でもっとも大事なことなのではないのだろうか。そもそもその語の命名がうまくできていなければ、その語が指しているものが何かわからずコミュニケーションとるまえに自分がその事象を理解することができない。だから命名ってプログラミングにかぎらず大事なのだと思った。それは商品名をつけたりとか、会社とか、人の名前もそうで、ものをある意味で定義する名前という概念になんか感動した。

https://www.slideshare.net/masuda220/ss-59756718

今日も一日、We Go Fast!!

(随時更新)gitよく使うやつまとめ

git addしたファイルをもとに戻すとき

$ git reset HEAD hoge.html

commitを取り消ししたいとき

$ git reset --soft HEAD^

or

$ git reset --hard HEAD^

空コミット

$ git commit --allow-empty -m "initial commit"

stashしているものを見るとき

$ g stash list

diff単位でstashするとき

$ g stash -p
stash this hunk?

最新のmasterを今いるブランチに反映させたい場合

$ git rebase master

特定のブランチを今いるローカルで使いたい

$ git fetch origin -p
$ git checkout -t origin/hoge

ローカルのブランチの名前を変えたい

$ git branch -m <old branch> <new branch>

そのキーワードの最新のdiffを見たい時

$ git show `g log -S hoge --oneline | awk '{print $1}'`

プルリク作成

$ hub pull-request --push -f -o -l wip -a tenshotanaka

直前のコミットに特定のdiffを含める

$ git add hoge
$ git commit --amend --no-edit

GitHubでFork/cloneしたrepositoryを本家repositoryに追従する

$ git clone git@github.com:youraccount/hoge.git(forkしたrepositoryのurl)
$ git remote add upstream git://github.com/hoge.git(本家のrepositoryのurl)
$ git checkout master
$ git pull upstream master

HEADのsha1を取得する

$ git rev-parse HEAD

ref

qiita.com

Google HTML/CSS Style Guide を読んで意外だと思った点まとめ

HTML

-<!-- Not recommended -->
-<a class='maia-button maia-button-secondary'>Sign in</a>
+<!-- Recommended -->
+<a class="maia-button maia-button-secondary">Sign in</a>

CSS

-/* Not recommended */
-border-top-style: none;
-font-family: palatino, georgia, serif;
-font-size: 100%;
-line-height: 1.6;
-padding-bottom: 2em;
-padding-left: 1em;
-padding-right: 1em;
-padding-top: 0;
+/* Recommended */
+border-top: 0;
+font: 100%/1.6 palatino, georgia, serif;
+padding: 0 1em 2em;
Do not use units after 0 values unless they are required.

flex: 0px; /* This flex-basis component requires a unit. */
flex: 1 1 0px; /* Not ambiguous without the unit, but needed in IE11. */
margin: 0;
padding: 0;
Do not use put 0s in front of values or lengths between -1 and 1.
font-size: .8em;
-/* Not recommended */
-color: #eebbcc;
+/* Recommended */
+color: #ebc;

Alphabetize declarations.

-/* Not recommended */
-a:focus, a:active {
-  position: relative; top: 1px;
-}

+/* Recommended */
+h1,
+h2,
+h3 {
+  font-weight: normal;
+  line-height: 1.2;
+}
-/* Not recommended */
-@import url("https://www.google.com/css/maia.css");

-html {
-  font-family: "open sans", arial, sans-serif;
-}

+/* Recommended */
+@import url(https://www.google.com/css/maia.css);

+html {
+  font-family: 'open sans', arial, sans-serif;
+}