<h2 id="h8d027c8ed3">はじめに</h2>Ruby には、畳み込み演算を行う Enumerable モジュールのメソッドとして <code>inject</code>と<code>reduce</code>というのがあります。 詳しい挙動はこちらを見ていただけると良いと思います。 <a href="https://docs.ruby-lang.org/ja/latest/method/Enumerable/i/inject.html" target="_blank" rel="noopener noreferrer">Enumerable#inject (Ruby 3.0.0 リファレンスマニュアル)</a> これらのメソッドはとても便利で、これらを使えば綺麗に書ける場合が多々あります。 しかし少し挙動が分かりにくいため、これらが使えると気付かずに冗長に書いてしまうことが良くあるなと最近思ったので、<code>inject</code> と <code>reduce</code> の活用例をまとめておこうと思います。 <h2 id="h9fde8ea989">活用例</h2><h3 id="hfef61ce4ff">商品の注文 <code>order</code> のうち飲み物の注文（<code>order.type == &#x27;drink&#x27;</code>）の金額 <code>order.fee</code> の合計額を出したい。</h3> 【書いてしまいがちなコード】<pre><code>
def sum_of_drink_order
 sum = 0
 orders.each do |order|
  sum += order.fee if order.type == &#x27;drink&#x27;
 end
 sum
end

</code></pre> 【<code>inject</code>・<code>reduce</code> を使うと...】<pre><code>
def sum_of_drink_order
 orders.inject(0) do |sum, order|
  sum + order.fee if order.type == &#x27;drink&#x27;
 end
end

</code></pre> <h3 id="h853504bd5b">ある日にアクセスされた記事の ID がアクセスされた回数分ダブって入っている配列 <code>accessed_article_ids</code> を用いて、各記事のアクセス数のデータ（<code>{ &#x27;記事ID&#x27; =&gt; &#x27;アクセス数&#x27; }</code>）を作りたい。</h3> 【書いてしまいがちなコード】<pre><code>
def article_access_count
 hash = Hash.new(0)
 accessed_article_ids.each do |accessed_article_id|
  hash[accessed_article_id] += 1
 end
 hash
end

</code></pre> 【<code>inject</code>・<code>reduce</code> を使うと...】<pre><code>
def article_access_count
 accessed_article_ids.reduce(Hash.new(0)) do |hash, accessed_article_id|
  hash[accessed_article_id] += 1
  hash
 end
end

</code></pre> <h3 id="haa9620928d">アカウント <code>account</code> の中から累計ログイン回数 <code>account.login_count</code> が 10 回以上のアカウントのメールアドレス <code>account.email</code> を配列で取得したい。</h3> 【書いてしまいがちなコード】<pre><code>
accounts.select{ |account| account.login_count &gt;= 10 }.map(&amp;:email)

</code></pre> 【<code>inject</code>・<code>reduce</code> を使うと...】<pre><code>
accounts.reduce([]) do |array, account|
 array &lt;&lt; account.email if account.login_count &gt;= 10
 array
end

</code></pre> <h2 id="hcbec2bf0d9">終わりに</h2>これらの活用例のように、<code>inject</code>・<code>reduce</code> を使うことで分かりやすいコード・効率的なコードを書くことができます。 特に３つ目の活用例は、一見複雑になっているように見えるかもしれませんが、複数の配列を作る必要のない効率的なコードだと思います。 <code>each</code>・<code>map</code>・<code>select</code> などの分かりやすい Enumerable モジュールのメソッドを良く考えずに使ってしまいがちですが、<code>inject</code>・<code>reduce</code> も結構使う場面あるよ、という話でした。 # 参考文献<ul><li>Effective Ruby</li></ul>

Ruby には、畳み込み演算を行う Enumerable モジュールのメソッドとして inject とreduceというのがあります。これらのメソッドはとても便利ですが、少し挙動が分かりにくいため、使いこなせていないことが良くあるなと最近思ったので、inject と reduce の活用例をまとめておこうと思います。

【Ruby】inject・reduce を使ってリファクタリングする

<h2 id="h7b6f8246e9">RubyKaigi に参加した感想</h2>先日、<a href="https://rubykaigi.org/2019" target="_blank" rel="noopener noreferrer">RubyKaigi 2019</a> に行ってきました。 仕事の関係もあり、３日目のみの参加。 「多分何も理解できないだろうなぁ...」と思いながらも、「それでも行った方が良い」と会社の先輩に背中を押され、行ってみることにしました。 「会場の福岡国際会議場」 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/f1cc4fc12aea497f8fbf5b8d62631fc6/20190422152245.png" alt> 結論から言うと、本当に行って良かったです。 Ruby という言語を愛している人が世界中から集まっていて、その方々とお話させていただくことで、Ruby という言語そのものに興味を持つようになりました。 今まで「技術は問題解決の手段でしかない」とどこか心の中で思っていたところがあり、言語の細かな仕様にまであまり興味が湧かなかったのですが、Ruby を実際に作っているコミッターの方々の考えていることを聞いたり、その方々が本当に楽しそうにしているのを見たりして、もっと Ruby について、プログラミング言語について勉強しようと思えました。 RubyKaigi に参加したからと言って、すぐにアウトプットが変わるわけではないですが、1 年後、3 年後の自分はこれに参加したことで大きく変わりそうな気がしています。 <h2 id="h051c86f7f3">ひたすら写真を貼る</h2>「入り口のボード」 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/94ccb1abc5a8430ba91e943b0c303bc5/20190422152534.png" alt> 「最初に参加したセッション『Ruby Committers vs the World』」 面白かったのは、Ruby が後方互換性に慎重になっていることについて話が及んだ時に Matz が「みんなもっとアグレッシブに行って良いって言うけど、文句言われるのは俺なんだよ？」と発言したところ。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/88437841546e4b10af21ebacc6427562/20190422152620.png" alt> 「次に参加した『Cleaning up a huge ruby application』」 Cookpad のエンジニアの方の発表で、必要なくなったコードを以下に消していったかと言う話。1 年間で 5 万行のコードを消したらしい。。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/0732c838821d40fbafbc3fc49e34efd0/20190422153003.png" alt> 「お昼休憩」 会場横に屋台がやってきた。福岡らしくてとても良かった。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/8c75836bb96246639abd84f719a4e8be/20190422153223.png" alt> 「いくつかある中で選んだ焼き鳥丼」 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/571c5de20e38409e841f3221cb8d83ea/20190422154333.png" alt> 「企業ブース」 本やステッカーなどがたくさんあった。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/e231b348ecdb4588a3a91b543f963de5/20190422153406.png" alt> 「Speee さんのカフェ」 Speee さんがカフェを開いていたので、カフェラテをいただいた。とても美味しかった。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/47f13136974f49d1903cbf4cf2f053c1/20190422153518.png" alt> 「wifi」 パスワードは「barikata」 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/b2e980e877134ed68b445b301f02c304/20190422153626.png" alt> 午後のセッションは写真を取り忘れる。。 次回の RubyKaigi は松本！ <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/51af1caec7e24aefa94757ce740cb5f3/20190422154014.png" alt>

先日、RubyKaigi 2019 に行ってきました。仕事の関係もあり、３日目のみの参加。「多分何も理解できないだろうなぁ...」と思いながらも、「それでも行った方が良い」と会社の先輩に背中を押され、行ってみることにしました。

RubyKaigi 2019 に行ってきた

<h2 id="h8d027c8ed3">はじめに</h2>以前、このような記事を書きました。 <a href="https://www.kaqiita.com/blogs/aa7voz3o1" target="_blank" rel="noopener noreferrer">【HTML CSS】見た目と構造は分離すべし</a> view を書くときにはデザインの見た目通りではなく、それぞれのコンポーネントの役割を抽象化して書いた方が綺麗に書けるよ、というものです。 こんな記事を書いていたにも関わらず、先日先輩エンジニアからのコードレビューで同じことを指摘されてしまったので、再度まとめようと思います。 今回は React で例を書いてみようと思います。 <h2 id="h11a3969800">今回の例</h2>以下のようなアコーディオンデザインの検索画面を実装しようとしていました。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/eff56b51c29844c782193571dede310f/20190401144928.png" alt> つまり路線名がアコーディオンデザインになっていて、クリックするとその路線の駅名が出てくるというものです。 このモックをコーディングするために、以下のようなコンポーネントを考えました。 <pre><code>
railwayLineAccordion.jsx

import React from &#x27;react&#x27;;
import PropTypes from &#x27;prop-types&#x27;;

class railwayLineAccordion extends React.Component {
  constructor(props) {
  super(props);
  this.state = { isOpen: props.initialOpenState };
 }

  handleClick = () =&gt; {
  this.setState(prevState =&gt; ({ isOpen: !prevState.isOpen }));
 };

  render() {
  const { railwayLine } = this.props;
  const { isOpen } = this.state;

   return (
   &lt;div className=&quot;railway_line_accordion&quot;&gt;
    &lt;div
     className={`accordion__bar${isOpen ? &#x27;--on-clicked&#x27; : &#x27;&#x27;}`}
     onClick={() =&gt; this.handleClick()}
    &gt;
     {railwayLine.name}
    &lt;&#x2F;div&gt;
    &lt;div
     className={`railway_line_accordion__checkbox-area${isOpen ? &#x27;--on-clicked&#x27; : &#x27;&#x27;}`}
    &gt;
     {# railwayLine に紐付く駅を rendering するためにごちゃごちゃ書く}
    &lt;&#x2F;div&gt;
   &lt;&#x2F;div&gt;
  );
 }
}

Accordion.propTypes = {
 initialOpenState: PropTypes.bool.isRequired,
 railwayLine: PropTypes.object.isRequired,
};

export default railwayLineAccordion;

</code></pre> つまり路線 <code>railwayLine</code> を <code>props</code> として渡してあげて、その路線をアコーディオンで表示させるコンポーネントです。 しかしこれはアコーディオンの役割を抽象化できておらず、良くないコード例でした。 <h2 id="h8ffb74de89">再利用性を意識してコンポーネントを切る</h2>今回の例のアコーディオンメニューは、良く見かけるデザインであるため、今後もこのデザインを別の場所で使うことが十分考えられます。 しかし、上記のようにアコーディオンが「何を表示するのか」まで知ってしまうと、別の場所でアコーディオンメニューを駅路線表示以外の目的で使いたいときに、また一からアコーディオンメニューを書くことになります。 「アコーディオンメニューの再利用性」を意識して抽象化すると、アコーディオンの役割はあくまで「開閉する」だけと捉えられるので、以下のように書いてあげるとこのコンポーネントの再利用性が高まります。 <pre><code>
Accordion.jsx

import React from &#x27;react&#x27;;
import PropTypes from &#x27;prop-types&#x27;;

class Accordion extends React.Component {
  constructor(props) {
  super(props);
  this.state = { isOpen: props.initialOpenState };
 }

  handleClick = () =&gt; {
  this.setState(prevState =&gt; ({ isOpen: !prevState.isOpen }));
 };

  render() {
  const { children, title } = this.props;
  const { isOpen } = this.state;

   return (
   &lt;div className=&quot;accordion&quot;&gt;
    &lt;div
     className={`accordion__title${isOpen ? &#x27;--on-clicked&#x27; : &#x27;&#x27;}`}
     onClick={() =&gt; this.handleClick()}
    &gt;
     {title}
    &lt;&#x2F;div&gt;
    &lt;div
     className={`accordion__children${isOpen ? &#x27;--on-clicked&#x27; : &#x27;&#x27;}`}
    &gt;
     {children}
    &lt;&#x2F;div&gt;
   &lt;&#x2F;div&gt;
  );
 }
}

Accordion.propTypes = {
 children: PropTypes.node.isRequired,
 initialOpenState: PropTypes.bool.isRequired,
 title: PropTypes.string.isRequired,
};

export default Accordion;

</code></pre> 「何を表示させるか」を <code>props</code> で渡すようにして、このアコーディオンコンポーネントは「開閉する」という役割だけ持たせるようにしました。 こうすることで、別の場所でアコーディオンメニューを作りたいときは、このコンポーネントを使って適する<code>title</code> と<code>children</code> を渡せば良いだけで良くなります。 <h2 id="hcbec2bf0d9">終わりに</h2>「再利用性を意識してコンポーネントを切る」というコンポーネント指向の基本ですが、やってみるとなかなか難しく、こうやってアウトプットを繰り返すことでいつか身に付けば良いなぁと思っています。。

以前、「見た目と構造は分離すべし」という記事を書きました。こんな記事を書いていたにも関わらず、先日コードレビューで同じことを指摘されてしまったので、再度まとめようと思います。

【React】再利用性を意識してコンポーネントを切る

<h2 id="h8d027c8ed3">はじめに</h2>『チーズはどこへ消えた？』という本を読みました。 急に本屋で見かけるようになってずっと読んでみたいと思っていて、お盆休みに読んでみることにしました。 話の内容は、二人の小人と二匹のネズミが迷路で大量のチーズを見つけ幸せを手にしますが、少しずつチーズは無くなっていきます。 そしてチーズが無くなったとき、ネズミたちは新たなチーズを探しにまた迷路の探索を続けますが、小人たちはチーズが無くなったことにパニックを起こし、なかなか行動を起こせずにチーズを手に入れることができないという話です。 これらの話を通して「変化に対応する」とはどういうことなのかを読者に伝えています。 <h2 id="hf610e3e248">本を読んでの学び</h2>本を読んで学んだことは「変化を予期する」ということの大切さでした。 チーズが減っていっていることを察知し、いつか無くなるということを予期していたネズミたちはすぐに変化に対応して次の行動を起こすことができましたが、小人たちはなかなか行動を起こすことができませんでした。 よく「変化は起きるもの」とか「変化には対応しなければならない」というような話はされますが、実際にこの話と同じ状況に立たされたときにネズミたちのようにすぐに次のチーズを探しに行ける人は少ないのではないかと思います。少なくとも私はすぐには行動を起こせないだろうなと感じました。 それは「変化を予期する」という視点が抜けているためだと気付きました。 「変化には対応しなければならない」という意識はあるのですが、予期できていないためチーズが無くなって初めて「どうしたら良いだろう」と考え始めるという具合です。 <h2 id="h8bfa934cbc">サービス運営の話</h2>普段エンジニアとしてサービスの運営をしていますが、普段の仕事でも似たようなことはあるなと感じました。 例えばある LP へのユーザーの流入数が減少していてそれが検索順位減少によるオーガニック流入の減少が原因だった場合、「変化を予期する」ということができていないと、大幅に減少して底を打って初めてリカバリープランの立案を始めるということになってしまいます。 理想は検索順位減少の兆候が見られた段階で、タイトル・ディスクリプションやコンテンツの見直しなどの SEO 施策の立案を始めて、考えられるリスクシナリオに対して先手先手で対策を打っていくというものだと思います。 その上で仮に検索順位の下落は一時的なものですぐに回復したらしたで OK で、このようにプランニングされた施策は実行の優先度は下がるかもしれませんが改善施策のストックとなるので無駄にはなりません。 このように「変化を予期」して「リスクシナリオを考え」て「リカバリープランをすぐに立案」することが大事だなと改めて思いました。 <h2 id="hcbec2bf0d9">終わりに</h2>内容が分かりやすくかつ薄い本でさっと読める本ですが、話はとても示唆に富んでいてて勉強になりました。

『チーズはどこへ消えた？』という本を読みました。急に本屋で見かけるようになってずっと読んでみたいと思っていて、お盆休みに読んでみることにしました。話の内容は、二人の小人と二匹のネズミが迷路で大量のチーズを見つけ幸せを手にしますが、少しずつチーズは無くなっていきます...

変化を予期する〜『チーズはどこへ消えた？』を読んで〜

<h2 id="h8d027c8ed3">はじめに</h2>先日、Qiita で以下の記事がトレンドに入っていたので読んでみました。 <a href="https://qiita.com/hareku/items/4bfc48e23e83e0d300f3" target="_blank" rel="noopener noreferrer">[翻訳]あなたがプログラミングに向いていない10のサイン</a> プログラミングに向いていない人の 10 個の特徴が述べられていてとても面白い記事だったのですが、特に考えさせられたのは最後のボーナスの項でした。 <h2 id="hb21d4bea96">ビジネス志向の人はプログラミングに向いていない？</h2>最後の項の大まかな内容は以下の通り（多少論理を補っています）。 <ul><li>ビジネス志向の人はプログラミングに向いていない<ul><li>ビジネス志向の人はプロセスよりも結果に焦点を当てていることが多い</li><li>そのため技術を探求し楽しむためのものではなく目標を達成するための手段と見なす傾向がある</li><li>技術を真に理解するのはとても時間の掛かること</li><li>目的達成のため本来時間の掛かる技術の勉強を焦って行なってしまい他の人よりも苦労することがある</li></ul></li></ul> ビジネス志向であることは「良いこと」として語られることが多い中で、「ビジネス志向の人はプログラミングに向いていない」という主張は自分にとってとても強烈でした。 ただ、一方で思い当たる節はあります。 私自身、ファーストキャリアをエンジニアとして歩み始めましたが、学生時代はコンサルティングファームやベンチャー企業のビジネス職でインターンをしており、いわゆるビジネス志向の人間でした。 そんな中で色々あってエンジニアとして入社後研修を受けた際に、ある程度理解してコードが書けるようになると、それ以上理解を深めようとせずに、その結果先輩エンジニアのレビューで「自分の書いているコードをちゃんと理解できていない」と何度も弾かれた経験があります。 また、研修を卒業してエンジニアとして現場に配属されてからも、現場で使うフロントエンド技術・サーバーサイド技術は積極的にキャッチアップするにも関わらず、インフラ・ネットワーク部分の知識はあまり積極的に学ぼうとはしていませんでした。 今思うと、アウトプットを出すことに焦りすぎていたのだと思います。 アウトプットに繋がりやすい分野を判断して、そこに自分のリソースを全て注ぎ込んでいました。 これは一見良いことのようですが、エンジニアとして１年働いてみて思ったのは、上記のような「自分の学習範囲を狭めてしまうような学習スタイルはエンジニアとして取るべきではない」ということでした。 インフラ・ネットワーク部分もある程度は理解していないと、フロントエンド・サーバーサイドの理解もどうしても浅いものになってしまい、遭遇したことのないバグや障害が出た時に根本原因を特定することができない or とても時間が掛かってしまいます。 ただ、ビジネス志向だとどうしてもアウトプットに繋がりやすい分野ばかり勉強してしまいます。 そこで私は、このことに気付いてからは、以下のような工夫をしています。 <h2 id="h2272113cc9">業務時間内と業務時間外で思考を切り替える</h2>まず、自分の学びたいことを必要とするタスクを振ってもらうなどして、なるべく業務時間に勉強する時間を取ります。 そして業務時間に勉強する分野は「アウトプットに繋がりやすい分野」です。 ビジネス志向の人にとっては「成果を出すために自分は今何を学ぶべきか」ということは考えやすいと思います。 業務中は「成果を出さなければならない」というプレッシャーが多かれ少なかれあると思うので、勉強も集中して効率的に行えると思います。 ただ、このような勉強だけだと上述した通り「アウトプットに繋がりにくい分野」の勉強に手を付けられず、技術をしっかり理解するということができません。 そこで、「アウトプットに繋がりにくい分野」は業務外に勉強します。 「業務外に勉強すべきなのか」ということについては、議論の余地があると思いますが、私の意見は以下の記事にとても近いです。 <a href="https://axia.co.jp/2017-07-18" target="_blank" rel="noopener noreferrer">エンジニアは業務時間外でも勉強するべきなのか</a> ただし注意していることは、業務外の時間は「自分の好奇心の赴くままに勉強する」ということです。 ビジネス志向だと、つい「どの分野を勉強するべきか」と考えてしまいますが、自分の好奇心ドリブンで学習分野を選ぶべきです。 好奇心ドリブンの勉強については、以下のような記事があります。 <a href="https://ix-careercompass.jp/series/point-of-view/planned-happenstance-learning" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;ix-careercompass.jp&#x2F;series&#x2F;point-of-view&#x2F;planned-happenstance-learning</a> そして、そもそも技術を「目的達成の手段」と捉えている人だと技術自体に好奇心を持っていないことも考えられますが、業務中の勉強を続けることで必ず「ここはもっと知りたい」という分野が出てくるはずです。 また休日に苦しい勉強をしようとしても続くはずがないとも思っています。 興味の湧く分野を、なるべくストレスの掛からない方法でマイペースに勉強を続けることで、モチベーションを落とさずに技術への理解を深めていけると思います。 <h2 id="hcbec2bf0d9">終わりに</h2>上記のような方法を実践することで、1 年前はエンジニアになるなんて夢にも思っていなかった自分がなんとかエンジニアとしてやっていけて、少しずつ技術への理解も深まっています。 業務内と業務外で思考を切り替えて、楽しみながら勉強していくことが大事だなと感じています。

先日、Qiita で「[翻訳]あなたがプログラミングに向いていない10のサイン」という記事がトレンドに入っていたので読んでみました。プログラミングに向いていない人の 10 個の特徴が述べられていてとても面白い記事だったのですが、特に考えさせられたのは最後のボーナスの項でした。

ビジネス志向の人はプログラミングに向いていない？

<h2 id="h8d027c8ed3">はじめに</h2>昨日、このイベントに参加してきました。 <a href="https://noengineering-nolife.connpass.com/event/121305" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/d20c76755106467bae75ad15b2413e66/20190321133656.png?w=660&h=271" alt></a> イベントのコンセプトは以下のようなもの。 <blockquote>デザイナーとエンジニアは決して敵ではなく、共に価値を創造する「仲間」。 イベントを通じて、デザイナーとエンジニアが互いの想いを共有し、感謝と敬意を持つことができればと思い、今回のイベントを開催します！</blockquote> 最近仕事でデザイナーと一緒に仕事をすることが増えてきて、こちらの知識不足のせいで上手くコミュニケーションが取れないことがあったので、もっとデザイナーのことを知りたいという思いで参加しました。 勉強になる話がたくさん聞けて、特に以下の３つが特に印象に残ったので忘れないようにまとめておきたいと思います。 <h2 id="h292783a573">Figma というデザインツール</h2>まず、今まで「Sketch＋Zeplin」を使っていたところを「Figma」というツールに置き換えてみたという話が印象に残りました。 「Figma」というツール自体知らなかったのと、私のチームでもデザイナーと連携を取るときは「Sketch＋Zeplin」を使っているので、それらと比較して「Figma」の使い勝手はどうなのか、という点に興味を持ちました。 「Figma」についての解説は以下の記事が分かりやすかったです。 <a href="https://qiita.com/hikaru_tayama/items/49373412ec1a515ff05d" target="_blank" rel="noopener noreferrer">Sketch はもういらない？ デザインツール Figma の紹介</a> 「Figma」の使い勝手については、普通に使う分には「Sketch＋Zeplin」と比べて特に使いやすいところはなく、「Sketch＋Zeplin」で十分だということでした。 ただ、そのチームで効果的だったのは「モック付きの UML を Figma で作ってモック作成段階からデザイナー・エンジニアでコミュニケーションを取る」という方法だったそうです。 これによって、ページの作成漏れを防ぐことができたり、ユーザーの使いやすさについてデザイナーだけが考えるのではなく、エンジニアからも意見が以前より出やすくなったとのことでした。 確かに出来上がったモックを見るよりも、エンジニアははるかに意見を出しやすいだろうなと感じました。 <h2 id="hd5c41f187c">VUI デザイナーの話</h2>VUI デザイナーという職種自体存在を知りませんでした。 でも Amazon Alexa などがあることを考えると、確かにそういう職種もあるだろうなと感じます。 VUI デザイナーについては以下のような記事がありました。 <a href="https://journal.voicy.jp/post-2968" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;journal.voicy.jp&#x2F;post-2968</a> その中で話に上がったのは「Voiceflow」という Amazon Alexa のアプリを簡単に作れてしまうというアプリ。 <a href="https://smartio.life/smartspeaker/development/blog/voiceflow-alexaskill" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;smartio.life&#x2F;smartspeaker&#x2F;development&#x2F;blog&#x2F;voiceflow-alexaskill</a> まだまだこの領域のアプリを作っている人が少ないらしく、アプリをリリースしたら注目されやすい環境にあるそうです。 <h2 id="h2eb5fc69b4">デザインの４大原則の話</h2>デザインの４大原則、デザイナーの方には常識らしいですがエンジニアの私は全く聞いたことがありませんでした。 こちらの記事にまとまっています。 <a href="https://bulan.co/swings/design4principals" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;bulan.co&#x2F;swings&#x2F;design4principals</a> LT での説明やこちらの記事を読んでみると、それほど知識としては難しくなさそうだなと感じました。 しかし「知らない」となかなか実装中に意識することは難しそうだとも感じました。 このような「ちょっと勉強するだけでプロダクトの質を大幅に上げることができる」知識がデザイン分野には他にも多くありそうなので、最低限デザイナーとコミュニケーションが取れたり、デザイナーの意図したものをしっかり作れるように学んでいきたいなと思いました。 まずは上記の記事の参考文献にも挙げられている「<a href="https://www.amazon.co.jp/%E3%83%8E%E3%83%B3%E3%83%87%E3%82%B6%E3%82%A4%E3%83%8A%E3%83%BC%E3%82%BA%E3%83%BB%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%96%E3%83%83%E3%82%AF-%E7%AC%AC4%E7%89%88-Robin-Williams/dp/4839955557/" target="_blank" rel="noopener noreferrer">ノンデザイナーズ・デザインブック</a>」を読んでみようと思います。 <h2 id="ha214098e44">まとめ</h2>他職種の方と話すのは、とても大切で今後も継続していこうと思いました。 特にエンジニアの自分は、今回のようなデザイナーやマーケターはスキルの相性が良さそうなので、積極的に今回のようなイベントに参加していこうと思いました。

「Designer × Engineer 共創 LT 祭」というイベントに参加してきました。最近仕事でデザイナーと一緒に仕事をすることが増えてきて、こちらの知識不足のせいで上手くコミュニケーションが取れないことがあったので、もっとデザイナーのことを知りたいという思いで参加しました。

「共創 LT 祭」というイベントに行ってきた話

<h2 id="h8d027c8ed3">はじめに</h2>先日、一緒に働いてくれているインターン生の子から以下のような質問をもらいました。 それは自分が書いた以下のようなコードに対してです。 <pre><code>
class HogeController &lt; ApplicationController
 def new
  @hoge = Hoge.new
  render &#x27;form&#x27;
 end

 def edit
  @hoge = Hoge.find(params[:id])
  render &#x27;form&#x27;
 end

 ・
 ・
 ・

end

</code></pre> このように異なるアクションで同じ view を render したいときに、<code>after_action</code>で処理をまとめることはできないのか、という質問です。 具体的には、「以下のように書けないのか」という質問でした。 <pre><code>
class HogeController &lt; ApplicationController
 after_action :render_form, only: %i[new edit]

 def new
  @hoge = Hoge.new
 end

 def edit
  @hoge = Hoge.find(params[:id])
 end

 ・
 ・
 ・

 private

 def render_form
  render &#x27;form&#x27;
 end
end

</code></pre> <h2 id="hdcdebfe015">after_action に render の処理を書くことはできない</h2>結論から言うと、上記のような書き換えはできません。 new アクションや edit アクションの view ファイルが存在するなら、アクションが読まれた時点で respoonse_body に値が入るので、DoubleRenderError になります。 new アクションや edit アクションの view ファイルが存在しない場合も、アクションが読まれた時点で UnknownFormat が吐かれます。 よって、<code>render</code>メソッドをコールバックでまとめることはできませんでした。

先日、一緒に働いてくれているインターン生の子から以下のような質問をもらいました。このように異なるアクションで同じ view を render したいときに、after_actionで処理をまとめることはできないのか、という質問です。

【Rails】after_action に render の処理を書くことはできない

<h2 id="h8d027c8ed3">はじめに</h2>先月、初めて「ペアプロ」なるものを先輩エンジニアに行ってもらいました。その際にとても学びになったので、その学びをメモしておこうと思います。 先輩とペアプロをする予定の新人エンジニアの方には「ペアプロからこういうことが学べるよ」ということ、ペアプロで新人を育成する予定のベテランエンジニアの方には「新人はペアプロでこんなことを感じるよ」ということが伝わると嬉しいです。 ただ学びと言っても、既にこの記事にまとめられていることが全てだったかなと思います。 <a href="https://qiita.com/hirokidaichi/items/27c757d92b6915e8ecf7" target="_blank" rel="noopener noreferrer">ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習</a> こちらの記事はベテラン×新人のペアプロで、ベテラン側から書かれた記事であったため、ここでは新人側の目線から「具体的にどういう点が学びになったのか」ということについて書ければと思います（タイトルもパクってます）。 因みに「そもそもペアプロとは何ぞや？」という方には、こちらの記事がおすすめです。 <a href="https://qiita.com/YudaiTsukamoto/items/06b426f4dbee268d5035" target="_blank" rel="noopener noreferrer">ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話</a> <h2 id="hdc12bab138">新人プログラマの成長を加速する３つの習慣</h2>先述の通り、「<a href="https://qiita.com/hirokidaichi/items/27c757d92b6915e8ecf7" target="_blank" rel="noopener noreferrer">ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習</a>」に書かれていることが全てだったかなと思うのですが、こちらの記事に書いてある「良い習慣」の中で、私が特に実感したものが３つあります。 <h3 id="h80df2758dc">よくコードを読み、理解することに時間をかける</h3>まずはこれです。以前は全然コードを読んでいなかったなと実感しました。新人から見ると、ベテランエンジニアの方はさらっとコードを書いているように見えるので、まさかそんなにコードを読むことに時間を掛けているとは思いません。 「コードを理解するために時間が掛かる」という当たり前のことが分かっていないので、大して理解していないのにどんどんコードを読み進めてしまい、途中から全く分からなくなってしまうということがあります。 ペアプロをすることで、良い意味で「ベテランエンジニアもスーパーマンな訳ではない」という当たり前のことが分かり、以前よりコードを読む時間を長く取るようになりました。 <h3 id="he994850aa1">常に目の前の問題を単純化することに知恵を使う</h3>以前は、エラーが出てきた時は大して考えずに「とりあえず自分の書いたコードをもう一回眺めてみる」「エラーコードをググってみる」ぐらいのことしかやっていませんでした。「どこまでちゃんと動いていて、どの部分がエラーを吐いていて、その原因は何なのかを考える」という当たり前のことをしていませんでした。 これもベテランエンジニアの方が、新人から見るとエラーが出た瞬間に一瞬で原因を特定しているように見えるため、エラーの原因を突き止めるために段階を踏んでいるということが分かっていないからだと思います。 ベテランエンジニアに方にとっては「当たり前」に思っているエラーの原因の特定の方法も、一から説明してもらうと新人にとっては目から鱗でした。 <h3 id="h733d8e8cd5">道具の改善および自動化をおこなう</h3>ベテランエンジニアの方は、とにかくコードを書くのが早いと新人から見ると感じます。これはスキルの差ももちろんありますが、「道具を自分の使いやすいようにカスタマイズしているかどうか」もこのスピードの差を生んでいることがペアプロをしていて気付きました。エディタの機能やショートカットキーを使いこなすだけでスピードが全然違います。 これらは使わなくてもコードを打つことができてしまうので、打ち方の「お手本」みたいなものがないと、新人にとっては「自分は効率の悪いことをしている」ということに気付くことすらできません。気付くことができないので、当然自分で改善もできません。 ペアプロで先輩がコードを打っているのを後ろで見ているだけでも、自分の問題を認識することができるので、あとは頑張れば自分で改善することができます。私もペアプロをすることで、今まで知らなかったエディタの機能を知り、開発スピードをあげることができました。 <h2 id="hcbec2bf0d9">終わりに</h2>ペアプロをしてもらった後で、自分のコードの質もコードを書くスピードも飛躍的に上がったと感じています。私の場合は、先輩の方から「ペアプロやるぞ」と声を掛けてもらって学べただけなので偉そうなことは言えませんが、新人エンジニアの方は先輩エンジニアにペアプロをお願いしてみるととても学びがあると思います。ベテランエンジニアの方は、新人とのペアプロに付き合うことで、その新人が成長してコードレビューが少し楽になるかなと思うので、是非やってみてもらえると嬉しいです。

先月、初めて「ペアプロ」を先輩エンジニアに行ってもらったので、その学びをメモしておこうと思います。先輩とペアプロをする予定の新人エンジニアの方には「ペアプロからこういうことが学べるよ」ということ、ペアプロで新人を育成する予定のベテランエンジニアの方には「新人はペアプロでこんなことを感じるよ」ということが伝わると嬉しいです。

ペアプログラミングして気がついた新人プログラマの成長を加速する３つの習慣

<h2 id="h8d027c8ed3">はじめに</h2>前回の記事「<a href="https://www.kaqiita.com/blogs/9affirsjd4" target="_blank" rel="noopener noreferrer">プログラミング未経験者がエンジニアとして配属されるまでに使った書籍と学習コンテンツ</a>」はとてもたくさんの方に読んでいただいたようで、Qiita でトレンド入りすることができました。読んでいただき、ありがとうございます。少しでも自分と同じ初心者の方に読んでもらえれば、という気持ちで書いたのでとても嬉しいです。 さて、今回は実際に配属されて１ヶ月が経って、その中で私が困ったことと、その対処法について書こうと思います。私と同じことに今現在悩んでいる方、これからエンジニアとして現場に配属される方の参考に少しでもなってもらえると嬉しいです。 <h2 id="ha06258dca4">配属１ヶ月で一番困ったこと</h2>何に困ったかと言えば、ズバリ「書かれているコードの意味が分からない」です。配属直後は、今まで書かれたコードを読み込む作業が必要かと思うのですが、新人エンジニアにとっては書かれているコードを読み込んでも全く理解できません。この分からない原因には知識ももちろんあると思うのですが、以下の３つが大きいかなと感じました。 <ul><li>コード量が膨大でどこから読めば良いのか分からない</li><li>配属直後でそのコードが書かれた思想・背景を知らない</li><li>コードを読み取るということに慣れていない</li></ul> 特に私のようなチームでの開発経験などが全く無く、本やネットのコンテンツで学んだだけの人にとっては、「他人の書いたコードを読む」ことが初めての経験で、とても苦労するかと思います。 <h2 id="h9a3099b506">対処法</h2>しかし書かれているコードが理解できなければ、いつまで経っても本格的な開発に携わることができません。そこで、私は以下の３つの方法で対応しました。 <h3 id="he733c917e7">最小単位に区切った機能ごとにコードを読む</h3>いきなり上のファイルから読んでいっても、全く理解できませんでした。そこで、まずはユーザーの立場になって、どういう機能があるのかを洗い出し、その機能を最小単位に区切っていきました。例えば、ユーザーが以下のようにアプリを使うとします <ul><li>トップページからAページに行く</li><li>AページでBという情報をユーザーが入力する</li><li>Bという情報を入力したユーザーはCページに行く</li></ul> そうしたらまず「トップページからAページにはどういう仕組みで行けるのか」ということが説明できるようになるためにコードを読みます。それができたら、次は「ユーザーが入力する情報をどうやって処理するのか」、次は「Cページにはどういう仕組みで行けるのか」というようになるべく小さな単位に区切って、その挙動を説明するという目的でコードを読むようにしました。 読む目的がはっきりすると、本当に読むべきところに集中できます。これにより、読むべきコード量が膨大という問題が少しは解消するかと思います。 <h3 id="h1a74c73bfa">過去のプルリクエストを読む</h3>過去のプルリクエストも読むようにしました。プルリクエストはある機能についてひとまとまりになっている（はず、な）ので読む量が少なくてただ上から読むより理解しやすいです。 さらにプルリクエストの良いところは、そのコードが書かれた背景も書いてあるというところです。そしてコードレビューもあわせて読めば、そのチームの思想も垣間見えます。 あまり過去のを遡るともう使われていないコードかもしれないので、最近のものから読んでいくと良いと思います。 <h3 id="h553cd48e2e">自分でコードを書きながら既存のコードを読む</h3>コードを読み込んで理解しないと本格的な開発には入れないかと思いますが、ちょっとしたレイアウト修正やリファクタリングならできることがあると思います。これができる環境なら、100%全てのコードを読み込む前からどんどん自分でコードを書いていった方が良いと思います。 私の場合は、先輩方にレイアウトの修正やリファクタリングの機会を与えてもらったため、本当に助かりました。自分でコードを書くとなると、目的が明確になるので、本当に読むべきところがはっきりします。 それに先述の通り、コードを読み取るということに慣れていないため、理解したと思っても、自分で手を入れてみると、思ってもいない挙動を起こすことがあります。そこで初めて「正しく理解できていなかった」ということに気付けるということが多々ありました。 <h2 id="hcbec2bf0d9">終わりに</h2>以上、「配属されたが書かれているコードが分からない」という自分の一番困ったことと、それについて自分がやったことについて書きました。実際は私もまだまだ理解できてないところがたくさんあって、悪戦苦闘中です。 ここに書いた他にも、「もっとこうすれば良いのに！」という先輩エンジニアの方々や「私はこうしている！」という同じく新人エンジニアとして頑張っている方々のコメントお待ちしています。

今回は実際に配属されて１ヶ月が経って、その中で私が困ったことと、その対処法について書こうと思います。私と同じことに今現在悩んでいる方、これからエンジニアとして現場に配属される方の参考に少しでもなってもらえると嬉しいです。

新卒 1 年目プログラミング未経験者が配属１ヶ月で困ったこととその対処法

<h2 id="h8d027c8ed3">はじめに</h2>プログラミングなんてやったことがない、でも勉強したい、あるいは勉強せざるを得なくなってしまった。こういう方が最近増えているのではないかなと思います。 私もその一人です。ひょんなことからプログラミングに触る機会をもらって、触ってみたら面白くて、３ヶ月半の勉強の末、エンジニアとして現場に配属されるまでになりました。 Macすら触ったことの無かった私が、エンジニアになるまでにどんな本やコンテンツを使って勉強をしたのかを自分の備忘録として、そしてこれからプログラミングを勉強しようという方に参考にしてもらうために綴ろうと思います。 特に「みんなが使っている定番リファレンス」が何なのかプログラミング初心者には分からないことが多く、それらを知らないがために無駄な努力をしてしまうという経験が私にもあったため、これから勉強する方がそのような無駄な努力をしないために書こうと思います。 以下、Rails でアプリを作れるようになることを目標にした際のリファレンスリストになります。 <h2 id="h41950024d5">実際に使った書籍・学習コンテンツ</h2><h3 id="ha018d154aa">Ruby</h3><a href="https://dotinstall.com/lessons/basic_ruby_v3" target="_blank" rel="noopener noreferrer">ドットインストール Ruby 入門</a> 一番最初は、ドットインストールから始めました。一講座当たり約３分にまとめられていて、隙間時間でも進められるのがとても良かったです。最初はこれを見るか、<a href="https://prog-8.com" target="_blank" rel="noopener noreferrer">Progate</a> がオススメです。 <a href="https://paiza.jp/challenges" target="_blank" rel="noopener noreferrer">Paiza 転職 スキルチェック</a> プログラミングの演習問題を解くことができます。このお陰で Ruby でどんなことができるのか感覚を掴むことができました。 問題ゴリゴリ解きながらインプットしたい人にはオススメです。 <a href="https://www.amazon.co.jp/3%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E3%81%A7%E3%81%97%E3%81%A3%E3%81%8B%E3%82%8A%E5%AD%A6%E3%81%B6-Ruby%E5%85%A5%E9%96%80-WINGS%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88-%E7%AB%B9%E9%A6%AC-%E5%8A%9B/dp/4774195022" target="_blank" rel="noopener noreferrer">3ステップでしっかり学ぶ Ruby 入門</a> 初心者向けの本。Progate や ドットインストールで代用できます。通勤電車の中で本が読みたかったので、最初のうちは電車でこれを読んでいました。 <a href="https://www.amazon.co.jp/%E7%8B%AC%E7%BF%92Ruby-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF%E3%82%A2%E3%83%BC%E3%83%88/dp/4798117854/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534075733&amp;sr=1-1&amp;keywords=%E7%8B%AC%E7%BF%92Ruby" target="_blank" rel="noopener noreferrer">独習 Ruby</a> 初めての本格的な技術書としてオススメです。記述がとても分かりやすく演習問題も付いていて、その場でアウトプットもできます。 <a href="https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%99%E4%BA%BA%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AERuby%E5%85%A5%E9%96%80-%E8%A8%80%E8%AA%9E%E4%BB%95%E6%A7%98%E3%81%8B%E3%82%89%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA%E3%83%BB%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E6%8A%80%E6%B3%95%E3%81%BE%E3%81%A7-Software-Design-plus%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4774193976/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534075854&amp;sr=1-1&amp;keywords=%E3%83%97%E3%83%AD%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%99%E4%BA%BA%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AERuby%E5%85%A5%E9%96%80" target="_blank" rel="noopener noreferrer">プロを目指す人のためのRuby入門</a> 超良書。Ruby を勉強する人は全員買うべき。初めての一冊にしては難しいですが、独習 Ruby を読んだ後であれば理解できます。そして読み返す度に気付きがあるので、何度も読みたい本です。 <a href="https://docs.ruby-lang.org/ja/latest/doc/index.html" target="_blank" rel="noopener noreferrer">オブジェクト指向スクリプト言語 Ruby リファレンスマニュアル</a> Ruby の公式リファレンス。ちょっとメソッドを調べたいというときは、ブログなどをググるのではなくこのページから探した方がしっかり理解できて将来のためになります。 <h3 id="h671eeb8c13">Rails</h3><a href="https://dotinstall.com/lessons/basic_rails_v3" target="_blank" rel="noopener noreferrer">ドットインストール Ruby on Rails 5 入門</a> Ruby でも使ったドットインストールを観ました。観ているだけだと頭にあまり入って来ず、後述する Progate をやれば導入は十分かなと思いました。 <a href="https://prog-8.com/languages/rails5" target="_blank" rel="noopener noreferrer">Progate Ruby on Rails 5</a> 本当に分かりやすい。Rails が初めて学ぶ web フレームワークであるなら、まずこれからやるべきだと思います。自分の手を動かしながらのインプットなので定着しやすいです。 <a href="https://www.amazon.co.jp/%E3%81%9F%E3%81%A3%E3%81%9F1%E6%97%A5%E3%81%A7%E5%9F%BA%E6%9C%AC%E3%81%8C%E8%BA%AB%E3%81%AB%E4%BB%98%E3%81%8F-Ruby-Rails-%E8%B6%85%E5%85%A5%E9%96%80-WINGS%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88/dp/4774196185/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534076437&amp;sr=1-1&amp;keywords=%E3%81%9F%E3%81%A3%E3%81%9F1%E6%97%A5%E3%81%A7%E5%9F%BA%E6%9C%AC%E3%81%8C%E8%BA%AB%E3%81%AB%E4%BB%98%E3%81%8F%21+Ruby+on+Rails+%E8%B6%85%E5%85%A5%E9%96%80" target="_blank" rel="noopener noreferrer">たった1日で基本が身に付く! Ruby on Rails 超入門</a> 初心者向けの本。これも Progate や ドットインストールで代用できます。案の定、電車で読むために買いました。基礎をざっと掴むという目的なら良い本だと思います。 <a href="https://railstutorial.jp/" target="_blank" rel="noopener noreferrer">Rails チュートリアル</a> Rails を学んだ人の９割はこれで勉強しているのではないかというくらい有名なチュートリアル。Progate ２周してこのチュートリアルに取り組むというのが Rails を学ぶ最短ルートな気がします。たかがチュートリアルと思って甘く見ていると、難しすぎて爆死します。 <a href="https://railsguides.jp/" target="_blank" rel="noopener noreferrer">Ruby on Rails ガイド</a> Rails チュートリアルの副読本。チュートリアルでもっと深く知りたいことがあった時に読むと良いと思います。 <a href="http://railsdoc.com/" target="_blank" rel="noopener noreferrer">Ruby on Rails ドキュメント</a> こちらはチュートリアルを読んでいて分からないところがあった時に読むと良いと思います。 <a href="https://www.amazon.co.jp/Ruby-Rails-5%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-%E5%B1%B1%E7%94%B0-%E7%A5%A5%E5%AF%9B/dp/4774188832/ref=pd_sim_14_3?_encoding=UTF8&amp;pd_rd_i=4774188832&amp;pd_rd_r=206decbe-9e2a-11e8-9be7-7f96e6dbe8c6&amp;pd_rd_w=d5EQ1&amp;pd_rd_wg=IPSTW&amp;pf_rd_i=desktop-dp-sims&amp;pf_rd_m=AN1VRQENFRJN5&amp;pf_rd_p=053a78c4-e34f-47d4-9426-4d23f47a211d&amp;pf_rd_r=ESM9RYWDD0TMP8RR56TC&amp;pf_rd_s=desktop-dp-sims&amp;pf_rd_t=40701&amp;psc=1&amp;refRID=ESM9RYWDD0TMP8RR56TC" target="_blank" rel="noopener noreferrer">Ruby on Rails 5 アプリケーションプログラミング</a> Rails チュートリアルを進める際にはこの本を脇に置いておくことをオススメします。辞書のように使うと使いやすく、チュートリアルでは説明が不親切な箇所が丁寧に解説されています。 <a href="https://www.amazon.co.jp/%E6%94%B9%E8%A8%822%E7%89%88-%E3%83%91%E3%83%BC%E3%83%95%E3%82%A7%E3%82%AF%E3%83%88Ruby-Ruby%E3%82%B5%E3%83%9D%E3%83%BC%E3%82%BF%E3%83%BC%E3%82%BA/dp/4774189774/ref=sr_1_2?s=books&amp;ie=UTF8&amp;qid=1534077746&amp;sr=1-2&amp;keywords=%E3%83%91%E3%83%BC%E3%83%95%E3%82%A7%E3%82%AF%E3%83%88Ruby+on+Rails" target="_blank" rel="noopener noreferrer">パーフェクトRuby on Rails</a> こちらは Rails チュートリアルより難易度が少しだけ高いです。ただ、説明はしっかり書かれているので、チュートリアルを読んで分からず、アプリケーションプログラミングにも書かれていないときには、この本で調べていました。 <h2 id="ha739b3b8f6">その他</h2><h3 id="hb78de31cd8">オブジェクト指向</h3><a href="https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E6%99%82%E4%BB%A3%E3%81%AE%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E8%84%B3%E3%81%AE%E3%81%A4%E3%81%8F%E3%82%8A%E6%96%B9-Ruby%E3%81%A7%E5%AD%A6%E3%81%B6%E7%A9%B6%E6%A5%B5%E3%81%AE%E5%9F%BA%E7%A4%8E%E8%AC%9B%E5%BA%A7-%E9%95%B7%E7%80%AC-%E5%98%89%E7%A7%80/dp/4798134651/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534076059&amp;sr=1-1&amp;keywords=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E6%99%82%E4%BB%A3%E3%81%AE%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E8%84%B3%E3%81%AE%E3%81%A4%E3%81%8F%E3%82%8A%E6%96%B9" target="_blank" rel="noopener noreferrer">アジャイル時代のオブジェクト脳のつくり方</a> プログラミング初心者にとって「オブジェクト指向」とか言われても「知らんわ」という感じなんですよね。。そこでこの本から勉強を始めました。絵が多く電車とかでも読めます。 <a href="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%A7%E3%81%AA%E3%81%9C%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%AE%E3%81%8B-%E7%AC%AC2%E7%89%88-%E5%B9%B3%E6%BE%A4-%E7%AB%A0/dp/4822284654/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534078039&amp;sr=1-1&amp;keywords=%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%A7%E3%81%AA%E3%81%9C%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%AE%E3%81%8B" target="_blank" rel="noopener noreferrer">オブジェクト指向でなぜつくるのか</a> オブジェクト指向の定番書。この本を熟読してオブジェクト指向とは何かを（多分）理解することができました。 <h3 id="hcc3250d360">Web の基礎知識</h3><a href="https://www.amazon.co.jp/%E3%80%8C%E3%83%97%E3%83%AD%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AEWeb%E6%8A%80%E8%A1%93%E5%85%A5%E9%96%80%E3%80%8D-%E2%80%95%E2%80%95%E3%81%AA%E3%81%9C%E3%80%81%E3%81%82%E3%81%AA%E3%81%9F%E3%81%AFWeb%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E9%96%8B%E7%99%BA%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84%E3%81%AE%E3%81%8B-%E5%B0%8F%E6%A3%AE-%E8%A3%95%E4%BB%8B/dp/4774142352/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534078160&amp;sr=1-1&amp;keywords=%E3%83%97%E3%83%AD%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AEWeb%E6%8A%80%E8%A1%93%E5%85%A5%E9%96%80" target="_blank" rel="noopener noreferrer">プロになるための Web 技術入門</a> Rails チュートリアルが初心者にとって難しいのは、Web に関する基礎知識がないからだと思い、チュートリアルを進めながらこの本も読んでいました。図が多くすぐ読めます。 <a href="https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%E3%80%81URI%E3%80%81HTML%E3%80%81%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus/dp/4774142042/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534078258&amp;sr=1-1&amp;keywords=web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93" target="_blank" rel="noopener noreferrer">webを支える技術</a> これも Rails チュートリアルを進めながら読みました。これも定番書でよく読まれているだけあって、記述が初心者にもとても分かりやすいです。 <h3 id="h5836d00a9c">Git・Github</h3><a href="https://prog-8.com/languages/git" target="_blank" rel="noopener noreferrer">Progate Git</a> アプリを作る上で Git の基本操作がマスターする必要があります。まずは、Progate で勉強を始めました。さっとこなせるのでオススメです。 <a href="https://www.amazon.co.jp/GitHub%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-Pull-Request%E3%81%AB%E3%82%88%E3%82%8B%E9%96%8B%E7%99%BA%E3%81%AE%E5%A4%89%E9%9D%A9-PRESS-plus/dp/477416366X/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534078434&amp;sr=1-1&amp;keywords=GitHub%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80+%7EPull+Request%E3%81%AB%E3%82%88%E3%82%8B%E9%96%8B%E7%99%BA%E3%81%AE%E5%A4%89%E9%9D%A9" target="_blank" rel="noopener noreferrer">GitHub実践入門 ~ Pull Requestによる開発の変革</a> この本に書いてあることが実践できれば、基本的な Git と Github の操作に関してはマスターできたことになるのかなと思います。記述も分かりやすく、とてもよくまとまっています。 <h3 id="h261a129b7d">HTML・CSS</h3><a href="https://prog-8.com/languages/html" target="_blank" rel="noopener noreferrer">Progate HTML &amp; CSS</a> また Progate です。でも本当に分かりやすいです。一冊本買うくらいなら一ヶ月 Progate の有料会員（月1000円）になってみっちりやる方が圧倒的にコスパ良いです。 <a href="https://www.amazon.co.jp/HTML5-CSS3%E6%A8%99%E6%BA%96%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E8%AC%9B%E5%BA%A7-%E8%8D%89%E9%87%8E-%E3%81%82%E3%81%91%E3%81%BF/dp/4798142204/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534078928&amp;sr=1-1&amp;keywords=html+css+%E6%A8%99%E6%BA%96%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3" target="_blank" rel="noopener noreferrer">HTML 5 &amp; CSS 3 標準デザイン講座</a> 辞書代わりに使っていました。説明が分かりやすいのと、適度にカラフルなレイアウトでとても読みやすいです。 <h3 id="h24f2a5a771">データベース・SQL</h3><a href="https://prog-8.com/languages/sql" target="_blank" rel="noopener noreferrer">Progate SQL</a> ここまで来ると Progate の回し者みたいですが違います。。まずはやはり Progate から始めるのが良いと思います。 <a href="https://www.amazon.co.jp/%E9%81%94%E4%BA%BA%E3%81%AB%E5%AD%A6%E3%81%B6DB%E8%A8%AD%E8%A8%88-%E5%BE%B9%E5%BA%95%E6%8C%87%E5%8D%97%E6%9B%B8-%E5%88%9D%E7%B4%9A%E8%80%85%E3%81%A7%E7%B5%82%E3%82%8F%E3%82%8A%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%84%E3%81%82%E3%81%AA%E3%81%9F%E3%81%B8-%E3%83%9F%E3%83%83%E3%82%AF/dp/4798124702/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534079431&amp;sr=1-1&amp;keywords=%E9%81%94%E4%BA%BA%E3%81%AB%E5%AD%A6%E3%81%B6DB%E8%A8%AD%E8%A8%88+%E5%BE%B9%E5%BA%95%E6%8C%87%E5%8D%97%E6%9B%B8+%E5%88%9D%E7%B4%9A%E8%80%85%E3%81%A7%E7%B5%82%E3%82%8F%E3%82%8A%E3%81%9F%E3%81%8F%E3%81%AA%E3%81%84%E3%81%82%E3%81%AA%E3%81%9F%E3%81%B8" target="_blank" rel="noopener noreferrer">達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ</a> データベースに関する定番書。この本を読めば、データベース設計に関する基本的なところは抑えられるかなと思います。具体例が豊富で分かりやすいです。 <a href="https://dotinstall.com/lessons/basic_mysql_v3" target="_blank" rel="noopener noreferrer">ドットインストール MySQL 入門</a> MySQL を使う場合は是非これを見ておくと良いと思います。Rails のドットインストールとは違って、こちらはオススメです。説明がとても分かりやすく、MySQL の全体像を学ぶためにはとても良いコンテンツだと思います。 <h3 id="h63ad3943f9">テスト</h3><a href="https://www.amazon.co.jp/%E7%9F%A5%E8%AD%98%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88-%E3%80%90%E6%94%B9%E8%A8%82%E7%89%88%E3%80%91-%E9%AB%98%E6%A9%8B-%E5%AF%BF%E4%B8%80/dp/4798130605/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1534079561&amp;sr=1-1&amp;keywords=%E7%9F%A5%E8%AD%98%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88" target="_blank" rel="noopener noreferrer">知識ゼロから学ぶソフトウェアテスト</a> テストに関する基礎知識がこれ一冊で学べます。これも定番書。あまり難しくなく平易な文章で書かれているので、さっと読めます。 <h2 id="hcbec2bf0d9">終わりに</h2>ここまでつらつらと、さも独学で全て勉強したかのように書いてきましたが、実は違います。先輩エンジニアの方に週２回各３０分ずつ、ちゃんと正しく理解できているのかレビューをしてもらったり、適宜分からないところを質問したりして進めていました。 一から完全に独学でこれらの内容を３ヶ月半で身に付けるのは、今考えると自分には無理だろうなと思います。ここまで書いておいて何ですが、一番大切なのは、自分の理解度をチェックしたり質問できたりする環境かもしれないですね。 ただ、そのような環境を自分で作ることが難しい方もいるかと思うので、この記事がそのような方々の今後の勉強の参考に少しでもなってくれると嬉しいです。

Macすら触ったことの無かった私が、エンジニアになるまでにどんな本やコンテンツを使って勉強をしたのかを自分の備忘録として、そしてこれからプログラミングを勉強しようという方に参考にしてもらうために綴ろうと思います。Rails でアプリを作れるようになることを目標にした際のリファレンスリストになります。

プログラミング未経験者がエンジニアとして配属されるまでに使った書籍と学習コンテンツ

<h2 id="h8d027c8ed3">はじめに</h2>以前 note に書いた備忘録をこちらに移行しようと思います。   私たちは仕事をすることでお金を稼ぎ、物欲を我慢することでお金を貯め、お金を使って欲しいものを買います。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/3d40df9f5a9c4aa1af35003374a18662/picture_pc_7502b93cb03fa33a107cfafcde474ac5.png" alt>   つまり、お金について「①稼ぐ→②貯める→③使う」という３つのフェーズがあります。   この中で「①の稼ぎ方」と「②の貯め方」についてはたくさんの書籍などで解説されているにも関わらず、③の使い方について述べているものは少ないのではないかなと感じます。   そこで、ここではお金の使い方についてまとめてみようと思います。   同じ金額を使うにしても使い方によって、感じる幸福度は全く異なるものだそうです。   <h2 id="hd27ff9fff9">① 物ではなく経験を買う</h2><a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=3&amp;ved=0ahUKEwiX5KrlvKjcAhWMlpQKHRWRCkgQFgg9MAI&amp;url=https%3A%2F%2Fstatic1.squarespace.com%2Fstatic%2F5394dfa6e4b0d7fc44700a04%2Ft%2F547d589ee4b04b0980670fee%2F1417500830665%2FGilovich%2BKumar%2BJampol%2B%2528in%2Bpress%2529%2BA%2BWonderful%2BLife%2BJCP.pdf&amp;usg=AOvVaw1v7s0kwNKaRQNJ0lUieXDx" target="_blank" rel="noopener noreferrer">Gilovich et al. (2015)</a> では、物質的なもの（美しい家や高級時計など）は、経験を買うこと（旅行・コンサート・特別な食事など）ほど幸福をもたらさないことが示されています。   形に残らないものを大切にする。   この結果から、物を買うときも「これを買うことでどんな経験を得られるのか」を考えて買った方が良さそうです。   <h2 id="h70712ec588">② 他人のためにお金を使う</h2><a href="http://journals.sagepub.com/doi/abs/10.1177/0963721413512503" target="_blank" rel="noopener noreferrer">Dunn et al. (2014)</a> では、自分のためではなく他者のためにお金を使う方が幸福度が高いことが示されています。   これは逆の因果、つまり何らかの理由で幸福度が高い人は他者に優しくする余裕があるために他者のためにお金を使うことも考えられます。   しかし、<a href="https://www.amazon.co.jp/%E5%AB%8C%E3%82%8F%E3%82%8C%E3%82%8B%E5%8B%87%E6%B0%97%E2%80%95%E2%80%95%E2%80%95%E8%87%AA%E5%B7%B1%E5%95%93%E7%99%BA%E3%81%AE%E6%BA%90%E6%B5%81%E3%80%8C%E3%82%A2%E3%83%89%E3%83%A9%E3%83%BC%E3%80%8D%E3%81%AE%E6%95%99%E3%81%88-%E5%B2%B8%E8%A6%8B-%E4%B8%80%E9%83%8E/dp/4478025819/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1532004692&amp;sr=1-1&amp;keywords=%E5%AB%8C%E3%82%8F%E3%82%8C%E3%82%8B+%E5%8B%87%E6%B0%97" target="_blank" rel="noopener noreferrer">アドラーは人が幸せを感じる唯一の要因は、自分は他者と仲間であるという共同体感覚であると述べています。</a>   他者のためにお金を使うことで、他者との仲間意識を深まり幸福度が上がるという仮説は十分納得的だと考えます。   <h2 id="ha7781b091c">③ 投資をする</h2>ここで言う投資とは、株式投資などのいわゆる「投資」と聞いて連想するものに限定したものではなく、「将来自分が支払った額以上のリターンが見込めるもの」としています。   ①②で経験や他人の幸せを買うためにお金を使うべきと理解しても、お金にある程度の余裕が無ければ、毎日の生活に一杯一杯ではそのようにお金を使うことは難しいと思います。   世界的な大ベストセラーの<a href="https://www.amazon.co.jp/%E6%94%B9%E8%A8%82%E7%89%88-%E9%87%91%E6%8C%81%E3%81%A1%E7%88%B6%E3%81%95%E3%82%93-%E8%B2%A7%E4%B9%8F%E7%88%B6%E3%81%95%E3%82%93-%E3%82%A2%E3%83%A1%E3%83%AA%E3%82%AB%E3%81%AE%E9%87%91%E6%8C%81%E3%81%A1%E3%81%8C%E6%95%99%E3%81%88%E3%81%A6%E3%81%8F%E3%82%8C%E3%82%8B%E3%81%8A%E9%87%91%E3%81%AE%E5%93%B2%E5%AD%A6-%E5%8D%98%E8%A1%8C%E6%9C%AC/dp/4480864245/ref=sr_1_1?ie=UTF8&amp;qid=1532004992&amp;sr=8-1&amp;keywords=%E9%87%91%E6%8C%81%E3%81%A1%E7%88%B6%E3%81%95%E3%82%93+%E8%B2%A7%E4%B9%8F%E7%88%B6%E3%81%95%E3%82%93" target="_blank" rel="noopener noreferrer">「金持ち父さん、貧乏父さん」</a>で述べられているように、なるべく早いうちから投資の習慣を作り、お金に余裕を持つことが必要だと思います。   <h2 id="hcbec2bf0d9">終わりに</h2>自分の備忘録として、一般的に言われる幸せになるお金の使い方についてまとめてみました。   これを機にこれらを実践できるようにしたいと思います。   <h2 id="h7605dc6208">参考文献</h2><ul><li>「幸せをお金で買う」５つの授業</li><li>嫌われる勇気</li><li>金持ち父さん 貧乏父さん:アメリカの金持ちが教えてくれるお金の哲学</li><li><a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=3&amp;ved=0ahUKEwiX5KrlvKjcAhWMlpQKHRWRCkgQFgg9MAI&amp;url=https%3A%2F%2Fstatic1.squarespace.com%2Fstatic%2F5394dfa6e4b0d7fc44700a04%2Ft%2F547d589ee4b04b0980670fee%2F1417500830665%2FGilovich%2BKumar%2BJampol%2B%2528in%2Bpress%2529%2BA%2BWonderful%2BLife%2BJCP.pdf&amp;usg=AOvVaw1v7s0kwNKaRQNJ0lUieXDx" target="_blank" rel="noopener noreferrer">Gilovich, T., Kumar, A., &amp; Jampol, L. (2015). A wonderful life: Experiential consumption and the pursuit of happiness. Journal of Consumer Psychology, 25(1), 152-165.</a></li><li><a href="http://journals.sagepub.com/doi/abs/10.1177/0963721413512503" target="_blank" rel="noopener noreferrer">Dunn, E. W., Aknin, L. B., &amp; Norton, M. I. (2014). Prosocial spending and happiness: Using money to benefit others pays off. Current Directions in Psychological Science, 23(1), 41-47.</a></li></ul>

私たちは仕事をすることでお金を稼ぎ、物欲を我慢することでお金を貯め、お金を使って欲しいものを買います。お金の稼ぎ方とお金の貯め方についてはたくさんの書籍などで解説されているにも関わらず、お金の使い方について述べているものは少ないため、ここではお金の使い方についてまとめてみようと思います。

幸せになるためのお金の使い方

<h2 id="h8d027c8ed3">はじめに</h2>通常 Rails では各テーブルの主キーを <code>id</code> カラムに設定します。 ただ、例えば既にあるデータを import するときなど、Rails の規約通りにテーブルを設計できないときには <code>id</code> カラムを作らずに別のカラムを主キーとしたいときもあると思います。 その際は migration ファイルに書く <code>create_table</code> メソッドのオプションでよしなに設定してやれば良いのですが、そのオプションの書き方が勘違いを起こしやすいもので、少し詰まってしまったのでここにまとめたいと思います。 <h2 id="h7c7618ed1d"> <code>create_table</code> のオプション</h2><code>create_table</code> について <a href="http://railsdoc.com/references/createtable" target="_blank" rel="noopener noreferrer">Rails ドキュメント</a>を見てみると、以下のように書いてあります。 <pre><code>create_table(テーブル名 [, オプション])</code></pre> <pre><code>
create_table テーブル名 [, オプション] do |t|
 t.型 カラム名 [, カラムオプション]
end

</code></pre> <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/65623e938f5c4af8ae4a3bd5878994fc/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-05-09%2021.32.58.png" alt> つまり、<code>:id</code> オプションがデフォルトで true に、<code>:primary_key</code> カラムがデフォルトで <code>id</code> になっているため、Rails ではテーブルを作成すると勝手に <code>id</code> カラムが作られて、その <code>id</code> カラムがそのテーブルの主キーとなります。 <h2 id="h0aaf24c14e">id: false にすると...</h2>では <code>:id</code> オプションを false に設定するとどうなるのか。 実際に以下のような migration ファイルを書いてみます。 <pre><code>
class CreateHoges &lt; ActiveRecord::Migration[5.2]
 def change
  create_table :hoges, id: false do |t|
   t.integer fuga
  end
 end
end

</code></pre> すると、<code>:id</code> オプションを false にしたため <code>id</code> カラムは作られません。 また<code>:primary_key</code> オプションはデフォルトのままなので <code> id</code> カラムを指しますが、<code>id</code> カラムが存在しないため、主キー はこの <code>hoges</code> テーブルには設定されないことになります。 <h2 id="ha1c21d3e8e">起きた勘違い</h2>ではここで先述のような理由で、<code>id</code> カラムを作らずにかつ <code>fuga</code> カラムを主キーにしたい場合を考えます。 ここで私は以下のように考えてしまいました。 <ul><li><code>id</code> カラムを作りたくないため <code>id: false</code> とする</li><li>主キーを <code>fuga</code> カラムにしたいため<code>primary_key: :fuga</code>とする</li></ul> そして以下のように migration ファイルを書きました。 <pre><code>
class CreateHoges &lt; ActiveRecord::Migration[5.2]
 def change
  create_table :hoges, id: false, primary_key: :fuga do |t|
   t.integer fuga
  end
 end
end

</code></pre> しかし、データベースを確認してみると <code>id</code> カラムは作られていませんでしたが、なんと主キーも設定されていないことが分かりました。 <h2 id="hfee5bc299a">正しい書き方</h2>では、<code>id</code>カラムを作らずに<code>fuga</code>カラムを主キーにしたい場合にはどう書けば良いのか。 結論から言えば、以下のように書くと上手くいきます。 <pre><code>
class CreateHoges &lt; ActiveRecord::Migration[5.2]
 def change
  create_table :hoges, primary_key: :fuga 
 end
end

</code></pre> つまり、わざわざ <code>id: false</code> などと書いたり<code>create_table</code>にブロックを渡さなくても<code> :primaryey</code> オプションに <code>fuga</code> を設定してあげるだけで、<code>fuga</code>カラムが作られて主キーに設定される上に<code>id</code>カラムも作られません。 実際に <a href="https://github.com/rails/rails/blob/7785417984f61a9d5e00416c13b89dce2ee02daf/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L191" target="_blank" rel="noopener noreferrer">Rails のソースコード</a>にも以下のような example が書いてありました。 <pre><code>
# ====== Rename the primary key column
#
#  create_table(:objects, primary_key: &#x27;guid&#x27;) do |t|
#   t.column :name, :string, limit: 80
#  end
#
# generates:
#
#  CREATE TABLE objects (
#   guid int(11) DEFAULT NULL auto_increment PRIMARY KEY,
#   name varchar(80)
#  )

</code></pre> つまり、「<code>id</code>カラムのカラム名を変更する」という形で望まれる挙動を実現するようです。 さらに、以下のような example もありました。 <pre><code>
# ====== Do not add a primary key column
#
#  create_table(:categories_suppliers, id: false) do |t|
#   t.column :category_id, :integer
#   t.column :supplier_id, :integer
#  end
#
# generates:
#
#  CREATE TABLE categories_suppliers (
#   category_id int,
#   supplier_id int
#  )

</code></pre> つまり、<code>id: false</code> とは「<code>id</code> カラムを作るな」という意味ではなく「主キーを設定するな」という意味だそうです。 そのため、<code>id: false, primary_key: :fuga</code> と書くと <code>id: false</code> が読み込まれて「主キーを設定するな」という命令が走ってしまうことになり、上手く主キーが設定されないようでした。 <h2 id="h67549d53ec">複合主キーにしたい場合</h2>もう一度<code>id</code>カラムを作らずに<code>fuga</code>カラムを主キーにしたい場合の正しい書き方を見てみます。 <pre><code>
class CreateHoges &lt; ActiveRecord::Migration[5.2]
 def change
  create_table :hoges, primary_key: :fuga 
 end
end

</code></pre> 主キーが１つのときには上記のように <code>:primary_key</code> オプションを設定するだけで OK でした。 これが、複合主キーを設定したいときには実は少し挙動が変わります。 例えば <code>id</code> カラムを作らずに <code>fuga</code> カラムと <code>piyo</code> カラムを複合主キーとしたいときには以下のように書くことになります。 <pre><code>
class CreateHoges &lt; ActiveRecord::Migration[5.2]
 def change
  create_table :hoges, id: false, primary_key: [:fuga, :piyo] do |t|
   t.integer fuga
   t.integer piyo
  end
 end
end

</code></pre> つまり、<code>:primary_key</code> オプションには主キーにしたい <code>fuga</code> と <code>piyo</code> を配列で渡して、かつ <code>create_table</code> に渡すブロックの中にも型と共にカラム名を書いてあげないといけません。 これは恐らくですが、主キーが１つのときは先述の通り「<code>id</code>カラムのカラム名を変更する」のに対して、複合主キーの場合は別の処理で望まれる挙動を実現するのだと考えられます。 <h2 id="hcbec2bf0d9">終わりに</h2>Rails で <code>id</code> 以外を主キーに設定したいときにどうすれば良いのかについて書きました。 オプションの書き方が少し非直感的なので、私のように誤解する方も居ると思います。 そのような方に読んでいただけたら幸いです。

通常 Rails では各テーブルの主キーを id カラムに設定します。ただ、Rails の規約通りにテーブルを設計できないときには id カラムを作らずに別のカラムを主キーとしたいときもあると思います。その際のオプションの書き方が勘違いを起こしやすいものだったのでここにまとめたいと思います。

【Rails】id 以外を主キー（primary_key）に設定する

<h2 id="h8d027c8ed3">はじめに</h2>初心者にも取っ付きやすい HTML CSS。しかし学習したての頃は、難しいと感じるところが多々ありました。 単に「見た目を整える」だけ言えば、それほど難しくはないかもしれません。ググって何とか書くことができます。しかし、所謂「良いコード」を書くのは、やはり難しいと感じました。 では具体的にどういうところが難しいと感じたか。まず一つ挙げるとすれば「見た目と構造を分離して考えなくてはいけない」という点です。同じところで躓く人がいるのではないかと思い、今日はこの「見た目と構造の分離」について書いてみようと思います。 <h2 id="h713c29ef78">見た目と構造を分離するとは？</h2>簡単に言えば、「作りたい見た目通りに上から愚直に書いちゃダメだよ」ということです。具体例で見ていこうと思います。 たとえば、以下のようなアラートを３つ作りたかったとします。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/f90db75c1855471ab758da7ca0e592fe/57d97e4e-2d8e-6a16-0677-d666297981bf.png" alt> これを HTML CSS で書いてみることにします。 <h2 id="h788d6578d0">見た目と構造を分離せずに見た目通りに構造を書いてみる</h2>まずは、見た目通りに書いてみます。 <pre><code>
alert.html

&lt;div class=&quot;success-message&quot;&gt;成功！&lt;&#x2F;div&gt;
&lt;div class=&quot;warning-message&quot;&gt;警告！&lt;&#x2F;div&gt;
&lt;div class=&quot;error-message&quot;&gt;エラー！&lt;&#x2F;div&gt;

</code></pre> <pre><code>
alert.css

.success-message {
 border: 2px solid #494;
 border-radius: 6px;
 padding: 10px;
 background-color: rgba(68, 153, 68, 0.3);
 font-size: 16px;
 color: #333;
}

.warning-message {
 border: 2px solid #DD0;
 border-radius: 6px;
 padding: 10px;
 background-color: rgba(221, 221, 0, 0.3);
 font-size: 16px;
 color: #333;
}

.error-message {
 border: 2px solid #C44;
 border-radius: 6px;
 padding: 10px;
 background-color: rgba(204, 68, 68, 0.3);
 font-size: 16px;
 color: #333;
}

</code></pre> 成功と警告とエラーの３つのアラートを作りたいので、まずは成功のアラートを作り、次は警告のアラート、最後にエラーにアラートを作っていく、というような書き方です。 これでもちゃんと作りたいものと同じ見た目のものを作ることができます。しかし結論から言えば、これは良い書き方ではありません。理由は後述するとして、次は見た目と構造を分離して書いてみます。 <h2 id="h220e74396b">見た目と構造を分離して考えて書く</h2><pre><code>
alert.html

&lt;div class=&quot;alert success&quot;&gt;成功！&lt;&#x2F;div&gt;
&lt;div class=&quot;alert warning&quot;&gt;警告！&lt;&#x2F;div&gt;
&lt;div class=&quot;alert error&quot;&gt;エラー！&lt;&#x2F;div&gt;

</code></pre> <pre><code>
alert.css

.alert {
 border: 2px solid #333;
 border-radius: 6px;
 padding: 10px;
 font-size: 16px;
 color: #333;
}

.success {
 border-color: #494;
 background-color: rgba(68, 153, 68, 0.3);
}

.warning {
 border-color: #DD0;
 background-color: rgba(221, 221, 0, 0.3);
}

.error {
 border-color: #C44;
 background-color: rgba(204, 68, 68, 0.3);
}

</code></pre> 3つ共同じアラートの仲間であるため別々に書くのではなく、まずは `alert` という「ここで言うアラートとはこういうものですよ」というのを先に定義してしまいます。その後、アラートの種類によって異なる部分を書いていきます。 このように書くことで、最初に書いた時より重複したコードが減ってスッキリしているかと思います。こちらの方が断然良いコードです。では何故こちらの方が良いコードなのでしょうか？ <h2 id="hc300becfab">見た目と構造を分離するメリット</h2><ul><li>デザイン仕様が変わっても一箇所修正すれば良い</li></ul> たとえば、このアラートメッセージを作成した後に、「文字を太字にして欲しい」と言われた場合を考えてみます。この時、前者の書き方をしていると、3つ全ての CSS に「太字にせよ」というコードを書き加えなければいけません。しかし、後者の書き方であれば <code>alert</code> の一箇所に書き加えるだけで済みます。 <ul><li>新しいアラートをすぐに作ることができる</li></ul> 次は新たに以下のようなアラートも追加で作らなくてはならなくなったとします。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/13a6f635ce2b43179713d363943553f7/f1199e85-f788-c187-73bd-41b0fdb377b8.png" alt> この時に前者の書き方をしていると、この新たなアラートがどのような見た目をしているのか一から全て記述しなければいけませんが、後者の書き方であれば以下のような僅かこれだけのコードを追加するだけで済みます。 <pre><code>
alert.html

&lt;div class=&quot;alert info&quot;&gt;お知らせ&lt;&#x2F;div&gt;

</code></pre> <pre><code>
alert.css

.info {
 border-color: #48C;
 background-color: rgba(84, 136, 199, 0.3);
}

</code></pre> このように後者の書き方の方が、コードの修正や拡張にとても強いです。この２つの理由により、後者の方が良いコードであると言えます。 <h2 id="hcbec2bf0d9">終わりに</h2>なんとなくコードを書いても作りたいものが作れてしまうのが、HTML CSS の良いところだと思っています。だからこそ、ある程度勉強すればすぐにある程度は書けるようになります。 しかしだからこそ気をつけていないと、ここでの前者のようなイケてないコードを書いてしまいがちです。イケてるコードを書くための一つのハウツーとして、「見た目と構造は分離せよ」というお話でした。 <h2 id="h7605dc6208">参考文献</h2><ul><li>Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 Web制作者のための教科書シリーズ</li></ul>

初心者にも取っ付きやすい HTML CSS。単に「見た目を整える」だけ言えば、それほど難しくはないかもしれません。ググって何とか書くことができます。しかし、所謂「良いコード」を書くのは、やはり難しいと感じました。では具体的にどういうところが難しいと感じたか。まず一つ挙げるとすれば「見た目と構造を分離して考えなくてはいけない」という点です。

【HTML CSS】見た目と構造は分離すべし

<h2 id="h8d027c8ed3">はじめに</h2>「モジュールとクラス」というのは、Ruby について勉強する中で、初心者が躓く最初のポイントなのではないかなと思います。 私自身、学び始めの時は特にモジュールとクラスが良く分からず、色んなところでクラス継承や mixin が行われているとよく分からなくなってしまうことが多々ありました。 様々な文献に当たって少しずつ理解できてきましたが、そこでふと疑問に思ったことが「あるクラスにおいて、モジュールの mixin とクラス継承が行われていて、その mixin したモジュールと親クラスに同名のメソッドが定義されていた場合はどっちに定義されたメソッドが実行されるの？」というものです。 今回はそんな疑問について調べてみました。 <h2 id="hcb9dacb773">結論</h2>結論から言ってしまうと、 <blockquote>あるクラスにおいて、モジュールの mixin とクラス継承が行われていて、その mixin したモジュールと親クラスに同名のメソッドが定義されていた場合</blockquote> このような場合は、そのメソッドは mixin したモジュールで定義されているような動作をします。その理由を以下で解説します。 <h2 id="h42b5c846a9"> コード例</h2>たとえば、以下のような <code>Human</code> クラスを定義して、<code>self_introduction</code> メソッドを実行してみます。 <pre><code>
class Human
 def self_introduction
  puts &quot;I&#x27;m a human.&quot;
 end
end

human = Human.new
human.self_introduction #=&gt; I&#x27;m a human.

</code></pre> 次に、その子クラスである <code>PerfectHuman</code> クラスを定義して <code>self_introduction</code> メソッドを実行してみます。 <pre><code>
class Human
 def self_introduction
  puts &quot;I&#x27;m a human.&quot;
 end
end

class PerfectHuman &lt; Human
 def self_introduction
  puts &quot;I&#x27;m a perfect human.&quot;
 end
end

perfect_human = PerfectHuman.new
perfect_human.self_introduction #=&gt; I&#x27;m a perfect human.

</code></pre> この場合 <code>PerfectHuman</code> クラスで定義された <code>self_introduction</code> メソッドが実行されます。 メソッドのオーバーライドというやつです。 次は <code>PerfectHuman</code> クラスでは何も定義しないで <code>self_introduction</code> メソッドを実行してみます。 <pre><code>
class Human
 def self_introduction
  puts &quot;I&#x27;m a human.&quot;
 end
end

class PerfectHuman &lt; Human
end

perfect_human = PerfectHuman.new
perfect_human.self_introduction #=&gt; I&#x27;m a human.

</code></pre> 結果は、<code>Human</code> クラスで定義された <code>self_introduction</code> メソッドが実行されます。 ここまでは当たり前の結果かと思います。 では、次のはどうでしょうか。 <pre><code>
module OrientalRadio
 def self_introduction
  puts &quot;Na Ka Ta Nakata, I&#x27;m a perfect human.&quot;
 end
end

class Human
 def self_introduction
  puts &quot;I&#x27;m a human.&quot;
 end
end

class PerfectHuman &lt; Human
 include OrientalRadio
end

perfect_human = PerfectHuman.new
perfect_human.self_introduction #=&gt; ???

</code></pre> <code>perfect_human.self_introduction</code> は何を返すのか。 「結論」でも述べたとおり、正解は以下の通りです。 <pre><code>perfect_human.self_introduction #=&gt; Na Ka Ta Nakata, I&#x27;m a perfect human.</code></pre> <h1 id="h50c0628864">継承階層</h1>これは、継承階層が以下のようになっているからです。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/1c82deab96554370a7c1fda1ba3f4adb/f56c2dfe-a89b-20dd-ded5-4fefc4b04d70.png" alt> PerfectHuman クラス の上に OrientalRadio がいます。 このように描くと、少し混乱させてしまうかもしれません。 現に <code>PerfectHuman.superclass</code> は<code>Human</code> を返します。 <pre><code>puts PerfectHuman.superclass #=&gt; Human</code></pre> しかしこれは、特異クラスが無名で見えず、<code>superclass</code> メソッド、<code>class</code> メソッドでは出てこないためです。 特異クラスについては<a href="https://qiita.com/fujishin05/items/be60f4f788f2732921a4#%E7%89%B9%E7%95%B0%E3%82%AF%E3%83%A9%E3%82%B9%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B" target="_blank" rel="noopener noreferrer">こちらの記事</a>を参照。 つまり、<code>PerfectHuman</code> クラスが <code>OrientalRadio</code> モジュールを include したことで、<code>PerfectHuman</code> クラスのすぐ上に <code>OrientalRadio</code> の特異クラスが作られたという訳です。 <h2 id="ha4540b3b91">継承階層を正しく把握することのメリット</h2>少し細かい話ですが、このような継承階層を正しく理解しておくことには、いくつかのメリットがあると考えています。 <h3 id="ha60f6ce41d">メソッドが自分の意図していない動作をすることを防ぐ</h3>これは分かりやすくて、継承階層を理解していないと、自分が意図した通りに動作しない場合が起こり得るためです。 <code>PerfectHuman</code> クラスが <code>Human</code> クラスを継承していても、コード例のような場合には、<code>Human</code> クラスのメソッドが実行されないということがあります。 <h3 id="h2ac33606bc">モジュールを正しく実装できる</h3>ところで「継承階層」の図を観て、不自然に感じなかったでしょうか？ <code>PerfectHuman</code> の上に<code>OrientalRadio</code> がいるのは少しおかしな話ではありませんか？ 階層構造を正しく理解していれば、<code>OrientalRadio</code> モジュールと<code>Human</code> クラス・<code>PerfectHuman</code> クラスの抽象度が一貫していないことに気付かれると思います。 つまり、<code>OrientalRadio</code> モジュールを後から定義するのは良い書き方とは言えず、後から定義するのであれば <code>Shout</code> モジュールなどの名前にして、掛け声の部分だけ前に付け加えるというようなメソッドを定義する方が良いと思います。 <h2 id="hcbec2bf0d9">終わりに</h2>モジュールとクラスの継承階層についてのお話でした。 私は、これを初めて知った時にモジュールの理解が深まりました。 同じように感じてくれる方が一人でもいると嬉しいです。 <h2 id="h7605dc6208">参考文献</h2><ul><li>Effective Ruby</li></ul>

Ruby について勉強する中でふと疑問に思ったことが「あるクラスにおいて、モジュールの mixin とクラス継承が行われていて、その mixin したモジュールと親クラスに同名のメソッドが定義されていた場合はどっちに定義されたメソッドが実行されるの？」というものでした。今回はそんな疑問について調べてみました。

【Ruby】モジュールとクラスの継承階層

<a href="https://hbr.org" target="_blank" rel="noopener noreferrer">Harvard Business Review</a> に面白い記事があったので、まとめてみることにしました。 原論文は<a href="https://hbr.org/2018/08/how-to-stop-saying-um-ah-and-you-know" target="_blank" rel="noopener noreferrer">こちら</a>です。 話すとき、特に大勢の人の前で話すときには、緊張して中々言葉が出てこず「えー、、」や「あのー、、」という具合に、上手く話すのは難しいと思います。 このような「えー」や「あのー」などの、意味的には不要な言葉を「フィラーワード（filler word）」と言います。 このフィラーワード、自分の次に話すことを整理したり、間を置きたい時に使えたりして必ずしも悪いものではないですが、「えー」や「あのー」を連発されるよりスラスラ話される方が聞きやすいと思います。 現に原論文にもある通り、フィラーワードを多用されてしまうと、聞き手は話に集中することができなくなるそうです。 しかし、話す側にとって緊張した場面でスラスラ話すことは難しいことです。 フィラーワードを使う最適なペースは１分間に１回だそうですが、平均的に人は１分間に５回フィラーワードを使うのだそう。 では、どうすれば良いのか。 答えは、沈黙すること。 「えー」と間を繋ぎながら思考を整理するのではなく、沈黙して整理するのです。 沈黙することは、先述したフィラーワードの良い面を享受できる上に、聞き手の集中を邪魔することもありません。 この論文を読んで、言われてみれば、名スピーチと言われるスピーチではフィラーワードはほとんどなく、かといってずっとベラベラ話しているわけでもなく「沈黙」が上手く使われているなと思いました。  <iframe class="embedly-embed" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FRWsFs6yTiGQ&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DRWsFs6yTiGQ&image=http%3A%2F%2Fi.ytimg.com%2Fvi%2FRWsFs6yTiGQ%2Fhqdefault.jpg&key=ef481becf9fd4c17aa243190ea33aa20&type=text%2Fhtml&schema=youtube" width="560" height="315" scrolling="no" title="YouTube embed" frameborder="0" allow="autoplay; fullscreen" allowfullscreen="true"></iframe>

話すとき、特に大勢の人の前で話すときには、緊張して中々言葉が出てこず「えー、、」や「あのー、、」という具合に、上手く話すのは難しいと思います。このような意味的には不要な言葉を「フィラーワード（filler word）」と言います。

上手く話すコツは沈黙すること

<h2 id="h8d027c8ed3">はじめに</h2>先日、「Google しごと検索」が日本で導入されました。 <a href="https://japan.googleblog.com/2019/01/shigoto-search.html" target="_blank" rel="noopener noreferrer">Google しごと検索で、仕事探しをもっとスムーズに！</a> ここ最近、この「Google しごと検索」について調べる事があったり、実際に構造化データを作ったりしたのでまとめておこうと思います。 結論、「Google しごと検索」はかなり良いサービスだと思っています。 <h2 id="hb83faa2d91">「Google しごと検索」とは</h2>先ほど挙げた Google のブログには以下のような説明がされています。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/55ac9706ff0048fa8a8dfaa5b8e4f877/20190204220219.png" alt> <blockquote> [ 渋谷 バイト ] [ 本屋 アルバイト ] や、[ パンケーキ シェフ 募集 ] のように、希望する職種やエリア等を入力して検索すると、関連する求人情報が検索結果内にひと目で分かりやすく表示されます。任意の求人情報をクリック、または、タップするとより詳細な求人情報が表示されます。 出典：<a href="https://japan.googleblog.com/2019/01/shigoto-search.html" target="_blank" rel="noopener noreferrer">Google Japan Blog: Google しごと検索で、仕事探しをもっとスムーズに！</a></blockquote> つまり、求人系のキーワードで検索したときに、広告でもオーガニックの検索結果でもない第３のコンテンツが表示されるようになったということです。 こちらの記事も分かりやすいです。 <a href="https://gfj-japan.com/column/entry-45.html" target="_blank" rel="noopener noreferrer">Google for Jobsとは？|大きく変わる仕事探しの体験</a> <h2 id="ha8206704d1">「Google しごと検索」がアツい３つの理由</h2>個人的にこの「Google しごと検索」はとてもアツいと思っています。 その理由は以下の３つです。 <h3 id="he7864bd8f8">1. 掲載が簡単</h3>まずは、とても掲載が簡単です。 構造化データを作っておくだけで、あとは勝手に Google がクローリングする際に読み込んでくれて掲載されるようになります。 構造化データを作るために一定の知識は必要ですが、それについては解説されている記事がたくさんあります。 <a href="https://developers.google.com/search/docs/data-types/job-posting?hl=ja#definitions" target="_blank" rel="noopener noreferrer">求人情報に構造化データを追加する</a> 私も以前パンくずの構造化データの作り方は書いたので参考までに。 <a href="https://kaqiita.com/blogs/8j5bav497gqs" target="_blank" rel="noopener noreferrer">【Rails】schema.org を使用したパンくずの構造化データを Rails で作る</a> 掲載されるまでの期間も、ページがクローリングされて構造化データが読み込まれればすぐに掲載されるようになります。 私が携わっているサービスでは、最速１日で求人が掲載されたページがありました。 <h3 id="h889cbf7152">2. 上位３件はクリックなしでユーザーに表示される</h3>クリックなしでユーザーに求人情報が表示されるのも大きいと考えています。 SEO 対策を頑張ってたとえ検索結果で上位に表示されても、そこからタイトルやメタディスクリプションの PDCA を回していかなければ、クリックされずに求人情報がユーザーの目に触れることはありません。 ただ「Google しごと検索」は検索結果にいきなり求人情報が表示されるようになり、さらにそれはオーガニック検索結果の上、もしくはページの上部に表示されるので、かなりユーザーの目に触れることになります。 類似サービスに indeed がありますが、Google というプラットホーム上ではここが indeed より大きく優れている点だと思います。 <h3 id="head00a2beb">3. 広告枠がない</h3>最後は広告枠がない点です。 求人のリスティング順はオーガニック検索結果と同じ順番です。 これも indeed より優れている点だと考えています。 indeed では「スポンサー」という一定の額を払ったクライアントの求人が上位に表示されるようになっています。 「Google しごと検索」はこのような広告枠がないので、ユーザーにとって価値あるページを作り、その情報をきちんと構造化マークアップすれば上位に表示されます。 この「ユーザーにとって価値あるページを作る」ことは「Google しごと検索」関係なく必要なことなので、実質ほとんどコストなく求人の露出を増やせるということになります。 <h2 id="h714cc41cb2">おすすめサイト</h2>「Google しごと検索」について調べる中で会社の先輩に面白いサイトを教えてもらったので貼っておきます。 <a href="https://gfj-japan.com" target="_blank" rel="noopener noreferrer">Google for Jobs知恵袋「ググチエ」へようこそ</a> 「Google しごと検索」に関する記事がまとめられたサイトです。 分かりやすい記事が多いので、興味があれば見てみてください <h2 id="hcbec2bf0d9">終わりに</h2>「Google しごと検索」についてまとめました。 まだリリース直後の機能でどうなるか分かりませんが、先述の通りとても良いサービスだと思っているので、これからも注目していこうと思います。

先日、「Google しごと検索」が日本で導入されました。ここ最近、この「Google しごと検索」について調べる事があったり、実際に構造化データを作ったりしたのでまとめておこうと思います。結論、「Google しごと検索」はかなり良いサービスだと思っています。

「Google しごと検索」がアツい３つの理由

<h2 id="h8d027c8ed3">はじめに</h2>ここ最近行なっていた開発で「条件付きアソシエーション」というものに出会ったので、それについて書こうと思います。 「そもそも条件付きアソシエーションとはどんなものなのか」ということについては、「<a href="https://railsguides.jp/association_basics.html" target="_blank" rel="noopener noreferrer">Rails ガイドの解説</a>」をご覧いただけると良いかなと思います。 ここでは、タイトルにもある通り「引数」という観点から「条件付きアソシエーション」について見ていきます。 調べていく中で私が誤解して詰まってしまった部分があり、それについて書いている記事が見つからなかったので、ここにまとめようと思った次第です。 <h2 id="h58e7a7bcd9">やりたかったこと</h2>「ぐるなび」などで見かけるような「駅ごとの一覧ページ」というものを作ろうとしていました。 たとえば、「東京駅周辺の居酒屋の一覧ページ」のようなものをイメージしていただけると良いです。 そして「ぐるなび」を見ていただけると分かりますが、たとえば「駅から 1km・3km・5km 」のように駅からの距離もユーザーが選択できる機能も実装しようと考えました。 <h2 id="h22d664e195">現状</h2>DB は以下のような設計になっていました（本来はもっと複雑ですが今回の記事に関係ある部分のみ載せています）。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/e4437ec8e66c40fa93125ba646d02f0e/20190123215626.png" alt> <code>railway_station</code> とは駅を表しており、<code>facility</code> とは一覧ページに表示させたい施設を表します。 <code>railway_station</code> と <code>facility</code> は多対多の関係となっていて、<code>railway_station_has_facilities</code> がその中間テーブルです。 <code>railway_station_has_facilities</code> テーブルの <code>distance</code> は駅と施設の距離が km 単位で入っています。 何故こんなところに <code>distance</code> のデータを持たせるんだという意見もあるかと思うのですが、色々複雑な事情でこのようなテーブル構造となっています。 この DB はここでは所与のものとして、変更は加えないこととします。 <h2 id="h99d98c13f3">着想</h2>まず、以下のような形で書けることを目標にしました。 <ul><li><code>railway_station.facilities_within_default_distance</code></li><li><code>railway_station.facilities_within_minimum_distance</code></li><li><code>railway_station.facilities_within_maximum_distance</code></li></ul> <code>default_distance</code> を 3km とし <code>minimum_distance</code> と<code>maximum_distance</code> はそれぞれ 1km と 5km とします。 上記の目標を実現するためにアプリケーション側で <code>railway_station_has_facilities</code> テーブルが、<code>distance</code> の距離によってあたかも複数の中間テーブルであるかのようにすることはできないだろうかと考えました。 これはたとえば、<code>railway_station_has_facilities_within_default_distance</code> という <code>distance &lt; 3</code> であるレコードだけを集めた中間テーブルを Rails 側で作成できないかということです。 そこで、「条件付きアソシエーション」というものが使えるのではないかと考えました。 <h2 id="haa54e59e19">条件付きアソシエーション</h2>すると rails ガイドの「<a href="https://railsguides.jp/association_basics.html#%E9%96%A2%E9%80%A3%E4%BB%98%E3%81%91%E3%81%AE%E8%A9%B3%E7%B4%B0%E6%83%85%E5%A0%B1" target="_blank" rel="noopener noreferrer">Active Record の関連付け (アソシエーション)」の「4.3.3 has_manyのスコープについて</a>」に使えそうな example を見つけました。 <pre><code>
class Author &lt; ApplicationRecord
 has_many :books, -&gt; { where processed: true }
end

</code></pre> 上記の example を使えば以下のように書くことができます。 <pre><code>
railway_station.rb

class RailwayStation &lt; ApplicationRecord
 DEFAULT_DISTANCE = 3
 MINIMUM_DISTANCE = 1
 MAXIMUM_DISTANCE = 5

 has_many :railway_station_has_facilities_within_default_distance, -&gt; { where &#x27;distance &lt; ?&#x27;, DEFAULT_DISTANCE }, class_name: &#x27;RailwayStationHasFacility&#x27;
 has_many :railway_station_has_facilities_within_minimum_distance, -&gt; { where &#x27;distance &lt; ?&#x27;, MINIMUM_DISTANCE }, class_name: &#x27;RailwayStationHasFacility&#x27;
 has_many :railway_station_has_facilities_within_maximum_distance, -&gt; { where &#x27;distance &lt; ?&#x27;, MAXIMUM_DISTANCE }, class_name: &#x27;RailwayStationHasFacility&#x27;
 has_many :facilities_within_default_distance, through: :railway_station_has_facilities_within_default_distance, class_name: &#x27;Facility&#x27;
 has_many :facilities_within_minimum_distance, through: :railway_station_has_facilities_within_minimum_distance, class_name: &#x27;Facility&#x27;
 has_many :facilities_within_maximum_distance, through: :railway_station_has_facilities_within_maximum_distance, class_name: &#x27;Facility&#x27;
end

</code></pre> これで一応最初に書きたかったように <code>railway_station.facilities_within_default_distance</code> で、ある駅から 3km 未満の距離にある <code>facilities</code> を取ってくることができ、一覧ページを作成することができます。 しかし、同じようなことが何度も書かれており、スマートではないなぁと感じました。 <h2 id="h1909def00f">引数って渡せないの？</h2>そこで次に考えたのが、「<code>has_many</code> に引数を渡すことはできないのか」ということです。 <code>scope</code> ではよく以下のように書くことがあると思います。 <a href="https://railsguides.jp/active_record_querying.html#%E5%BC%95%E6%95%B0%E3%82%92%E6%B8%A1%E3%81%99" target="_blank" rel="noopener noreferrer">「Active Record クエリインターフェイス」の「14.1 引数を渡す」の example</a> <pre><code>
class Article &lt; ApplicationRecord
 scope :created_before, -&gt;(time) { where(&#x27;created_at &lt; ?&#x27;, time) }
end

</code></pre> そこで以下のような感じで書くことはできないのかと思い、書いてみました。 <pre><code>
railway_station.rb

class RailwayStation &lt; ApplicationRecord
 DEFAULT_DISTANCE = 3
 MINIMUM_DISTANCE = 1
 MAXIMUM_DISTANCE = 5

 has_many :railway_station_has_facilities_in_distance, -&gt;(distance) { where &#x27;distance &lt; ?&#x27;, distance }, class_name: &#x27;RailwayStationHasFacility&#x27;
 has_many :facilities_within_default_distance, through: railway_station_has_facilities_in_distance(DEFAULT_DISTANCE), class_name: &#x27;Facility&#x27;
 has_many :facilities_within_minimum_distance, through: railway_station_has_facilities_in_distance(MINIMUM_DISTANCE), class_name: &#x27;Facility&#x27;
 has_many :facilities_within_maximum_distance, through: railway_station_has_facilities_in_distance(MAXIMUM_DISTANCE), class_name: &#x27;Facility&#x27;
end

</code></pre> <h2 id="hb6509f48bf">結果</h2>しかし、結果は動きません。 何 km 未満の <code>facilities</code> を取ってくるのかを引数として渡すことにしたのですが、このような書き方はできないようでした。 「<code>has_many</code> には引数渡せないのだろう」と思いながらも一応 <code>has_many</code> で行なっていることを確認するために Rails のソースコードを見に行きました。 ## Rails のソースコードを見てみる すると <a href="https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations.rb" target="_blank" rel="noopener noreferrer">Rails のソースコード</a>の 526 ~ 528 行目に以下のような example を見つけました。 <pre><code>
class User &lt; ActiveRecord::Base
 has_many :birthday_events, -&gt;(user) { where(starts_on: user.birthday) }, class_name: &#x27;Event&#x27;
end

</code></pre> ここが混乱ポイントです。 「えっ。。。引数渡してるやん。。。」と悩み、小一時間格闘しました。 <h2 id="hab6175b068">分かったこと</h2>この一見不思議に見える問題は、<code>has_many</code> の定義を丁寧に見ていくことで解決しました。 結論を言えば「<code>has_many</code> に引数を渡すことはできるが <code>self</code> しか渡すことができない」ということです。 そのため、たとえば一つ上の例で引数名を <code>user</code> から <code>hoge</code> のように書き換えても、引数には <code>self</code> が入ります。 私の書いたコードが動かなかったのは、<code>distance</code> という引数に好き勝手な定数をぶち込んでいたためです。 <code>scope</code> と書き方は似ていますが、自由な引数を渡せる <code>scope</code> とは挙動が異なるということが分かりました。 <h2 id="hcbec2bf0d9">終わりに</h2>なかなか注意深く見ていないと、私のように勘違いしてしまう方が多いところではないかなと思います。 この記事で、一人でもここに躓く人が減れば良いなと思います。 因みに格闘していた小一時間は「ソースコードに書いてある example が間違っている」と思っていました。。。

ここ最近行なっていた開発で「条件付きアソシエーション」というものに出会ったので、それについて書こうと思います。ここでは、タイトルにもある通り「引数」という観点から「条件付きアソシエーション」について見ていきます。

【Rails】「条件付きアソシエーションの引数の処理」について調べたら Rails のソースコードの example を勘違いした話

<h2 id="h8d027c8ed3">はじめに</h2>Rails でパンくずを作るとき、とても便利な <a href="https://github.com/lassebunk/gretel" target="_blank" rel="noopener noreferrer">gretel</a> という Gem があります。 簡単にパンくずリストを作成できる上に、<code>semantic: true</code> と書き足すだけで構造化データまで作ってくれるため、簡単にSEO 対策まで行うことができます。 しかし、作成される構造化データが data-vocabulary.org で、google が推奨している schema.org ではありません。 そのため google が推奨する方法で構造化データを作る場合、gretel のオプション機能だけでは作れません。 パンくずの構造化データの作り方を解説した記事は多いですが、Rails に特化していてかつ分かりやすい記事は見つけられず、初めて作るときに少し苦戦したので、ここにまとめておきます。 なお、以下では gretel を使ってパンくずリストを実装していることを仮定します。 <h2 id="h66eef2b9d7">Rails でのパンくずの構造化データを JSON-LD で作る</h2>まずはパンくずを表示させている view に以下のように記述します。 <pre><code>&lt;%= render partial: &#x27;breadcrumbs_json_ld&#x27;, breadcrumbs: breadcrumbs %&gt;</code></pre> つまり <code>_breadcrumbs_json_ld.html.erb</code> という partial に <code>breadcrumbs</code> を渡します。 上記の記述は <code>application.html.erb</code> などの layout ファイルに書いておくと、いちいち全ての view に上記のコードを書く必要がなくなるかと思います。 記述は HTML ファイル内のどこでも可能ですが、パフォーマンスの面から body 閉じタグの直前に記述すると良いです。 次に <code>_breadcrumbs_json_ld.html.erb</code> の中身ですが、たとえば以下のように書くと構造化データをマークアップできます。 <pre><code>
&lt;script type=&quot;application&#x2F;ld+json&quot;&gt;
{
 &lt;% breadcrumbs.tap do |links| %&gt;
 &lt;% if links.any? %&gt;
 &quot;@context&quot;: &quot;http:&#x2F;&#x2F;schema.org&quot;,
 &quot;@type&quot;: &quot;BreadcrumbList&quot;,
 &quot;itemListElement&quot;: [
 &lt;% links.each_with_index do |link, i| %&gt;
 {
 &quot;@type&quot;: &quot;ListItem&quot;,
 &quot;position&quot;: &quot;&lt;%= i + 1 %&gt;&quot;,
 &quot;item&quot;: {
 &quot;@id&quot;: &quot;https:&#x2F;&#x2F;example.jp&lt;%= link.url %&gt;&quot;,
 &quot;name&quot;: &quot;&lt;%= link.text %&gt;&quot;
 }
 &lt;% if i == links.length - 1 %&gt;
 }
 &lt;% else %&gt;
 },
 &lt;% end %&gt;
 &lt;% end %&gt;
 ]
 &lt;% end %&gt;
 &lt;% end %&gt;
}
&lt;&#x2F;script&gt;

</code></pre> partial に切らずに直接 script タグを書き込んでもマークアップできますが、見にくくなるのでパーシャルに切ると良いと思います。 <h2 id="h53b6edb515">正しく構造化データが作成されているかテストする</h2>では本当に正しく構造化データが作成されているのか確認してみましょう。 <a href="https://search.google.com/structured-data/testing-tool?hl=ja" target="_blank" rel="noopener noreferrer">構造化データテストツール</a>を使うことですぐにテストすることができます。 使い方も簡単で、アクセスしたらすぐに現れる下記のようなポップアップにテストしたいページの URL を記述するだけです。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/253ba36d19834bd7ac624a8faececb8b/20190930204354.png" alt> 正しく構造化データが作成されていれば下記のように BreadcrumbList というアイテムが表示されるかと思います。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/9c8e8b213e494f659ff03c57fcb934fd/20190930204558.png" alt> <h2 id="hcbec2bf0d9">終わりに</h2>以上が Rails での schema.org を使用したパンくずの構造化データの作り方でした。 <code>_breadcrumbs_json_ld.html.erb</code> の中身はもう少し上手く書けそうな気がしていたり、インデントが気持ち悪かったりするので、より良い書き方分かる方いらっしゃいましたら、ご教示いただけると嬉しいです！

Rails でパンくずを作るとき、gretel という Gem があります。しかし、作成される構造化データが schema.org ではありません。パンくずの構造化データの作り方を解説した記事は多いですが、Rails に特化していてかつ分かりやすい記事は見つけられなかったのでここにまとめておきます。

【Rails】schema.org を使用したパンくずの構造化データを Rails で作る

<h2 id="h8d027c8ed3">はじめに</h2>社会人の方も学生インターンの方も、エンジニアとして現場に出た際に最初につまずくことの一つに「Git の使い方」があるのではないかと感じます。   私も初めてエンジニアとして現場に出た際には「git は基本的な使い方はなんとなく分かるけど、たまにエラーが出るとどうして良いか分からなくなる」というような状態でした。   自分で色々なドキュメントに当たって調べても、どうも説明がいまいち理解できない、、、そんな状態で苦しみながら勉強を進めていって思ったことがこれです。   「初心者向け教材の git のブランチの説明はミスリーディングである」   今日はブランチについて、思ったことを書いていきます。 <h2 id="hed39dfc19f">よくある誤解</h2><img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/887f23f3094a45d3a82f7bf9d9d291d0/20181224210211.png" alt> 初心者向け教材では、よく上記のような図で「ブランチとは枝です」というような説明がされると思います。   恐らく直感的な分かりやすさを重視しているのだと思いますが、この図は非常に紛らわしくて誤解しやすいです。   まだ git の勉強をそこまでしていない方が、この図を見た上で以下のような質問に答えるとしたらどう答えるでしょう？   <h2 id="h499d98f7c2">branch1 を図示してください</h2>この質問に対して、以前の私はこのような誤解をしていました。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/aa62e33e943d4888a0556cb375a16248/20181224211307.png" alt> 上記のように「ブランチは枝」だと理解していると色々な誤解をします。   たとえば、ブランチを削除するために <code>git branch -D branch1</code>とターミナルで打ったら、以下のようになってしまうと思うでしょう。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/df6e6d6762e9443abed5bbfa6fe7cb0b/20181224211859.png" alt> 上記のように「コミットが消える」というように思ってしまうのではないでしょうか？   少なくとも私はそう思っていました。   しかし「コミットが消える」というのは間違っています。   「ブランチは枝」という説明からコミットの集合から形成される「枝」をブランチと理解してしまっているせいで「コミットが消える」と誤解してしまいやすいように思います。   この他にも、ブランチというものを正しく理解していないと多くのコマンドが行なっていることも誤解してしまいます。   git の学習の序盤でブランチについての理解をこのように誤ると、誤解に誤解を重ねていって、あるところで全く理解ができなくなってしまいます。   そこで git の理解につまずいている方はブランチは以下のような「ポインタ」だと考えると分かりやすいかと思います。 <h2 id="h5a542af72f">ブランチはポインタである</h2>ブランチはコミットの集合ではなく、以下の図のようなコミットを指し示す「ポインタ」のことです。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/15d520a165944967bd923ccaae617a17/20181224213139.png" alt> つまり branch1 とは上図の「青いポインタ」のことです。   このように理解しておくと、「ブランチの削除」も正しく理解しやすいです。   <code>git branch -D branch1</code> とは上記の図が下記の図になるだけです。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/2968078075d74777ab34f6c8f77f88b7/20181224213600.png" alt> つまり、コミットは消えたりなんかしません。消えるのはブランチだけです。   このようにブランチを「ポインタ」と考えることで、誤解が生まれにくくなります。 <h2 id="hf7d2ff9f1e">git reset</h2>reset についてもブランチを枝だと理解していると誤解しやすいです。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/20300ee252f44f17909d61b74cbef22c/20181224215746.png" alt> <code>git reset --hard</code> では以下のようなことが起こると勘違いしてしまいます。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/19282427213147819eec76c33b43a77e/20181224220026.png" alt> しかし、正しくは以下の通りです。 <img src="https://images.microcms-assets.io/assets/7b4f6a60946e4ae0b3745738a05ab7b2/6f51b1546c23410aba49f18ea004850e/20181224220226.png" alt> こちらもコミットは消えません。   詳細な説明は省きますが、git reset は「ブランチが移動しているだけ」です。   <h2 id="hcbec2bf0d9">終わりに</h2>このように、ブランチを枝ではなくポインタと捉えることで「コミットが消える」などの誤解をすることなく、機能を理解することができます。   このイメージを持つことで私はとても git の理解が進んだので、是非お試しください！

エンジニアとして現場に出た際に最初につまずくことの一つに「Git の使い方」があるのではないかと感じます。自分で色々調べても、どうも説明が理解できない、、、そんな状態で勉強を進めていって思ったことが「初心者向け教材の git のブランチの説明はミスリーディングである」です。

【Git】ブランチは「枝」ではない

「プリンシプルオブプログラミング」の「2.2 DRY」を読みました。その感想・学びを書いていこうと思います。 DRY とは「Don&#x27;t Repeat Yourself.」の略で、コードの重複は避けるべきという原則でご存知の方がほとんどだと思います。 今回本を読んでなるほどなと思ったのは、タイトルにもした「DRY 原則の適用範囲はコードに留まらない」ということです。 日々の業務でも DRY 原則を適用させるべきケースがたくさんあります。 定常で発生する雑務やログの集計作業など似たような作業にも DRY 原則をしっかり適用して自動化することで、「手作業の負担がなくなる」「作業が正確になる」「人によるばらつきがなくなる」といったメリットが多くあります。 何となく惰性で毎日なんとなく手動で行っていることは意外と多いように思えるので、これを機に見直していけると良いなと思いました。 またコードの話に戻りますが、DRY はあくまで原則なので例外もあります。 コードを書いている中でも「テスト」に関しては DRY 原則を捨てた方が良いケースがあります。 このことについては、少し古い記事になりますが以下の記事に分かりやすく解説されています。 <a href="https://qiita.com/jnchito/items/eb3cfa9f7db752dcb796" target="_blank" rel="noopener noreferrer">テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～</a> 以上、今日は DRY 原則についてでした。

「プリンシプルオブプログラミング」の「2.2 DRY」を読みました。その感想・学びを書いていこうと思います。今回本を読んでなるほどなと思ったのは、タイトルにもした「DRY 原則の適用範囲はコードに留まらない」ということです。

DRY 原則の適用範囲はコードに留まらない〜『プリンシプルオブプログラミング 2.2. DRY』を読んで〜

<h2 id="h8d027c8ed3">はじめに</h2>「プログラマが知るべき 97 のこと」の「36. ハードワークは報われない」を読んで考えたことについて書きたいと思います。 昨年の反省として、ハードワーク気味に働いていたために休日は寝てばかりで勉強もあまりできておらず、なんとかしないといけないなと思っていました。 そんな中でこの「ハードワークは報われない」という章を読みました。 最も印象に残ったのが以下の部分です。 <blockquote>プログラミングのプロの仕事は「舗装された道路を、あらかじめ定められたゴール地点めざして猛烈に走る」というようなものではありません。ソフトウェア開発プロジェクトは通常、オリエンテーリングをしながらマラソンをするようなものです。しかも走るのは暗闇で、頼みにするのは、大雑把な地図だけです。一方向に闇雲に、しかもすごいスピードで走れば、感心してくれる人はいるでしょう。しかしそれでプロジェクトが成功するわけではありません。第一、後先を考えずに走って途中でペースが極端に落ちることがあっては困ります。一定のペースで走りながら、自分の現在地と向かっている方向を常に確認し、コースを絶えず微調整していくことが大事なのです。</blockquote> <h2 id="h258ad6d94a">ハードワークに働く方が簡単</h2>ハードワークは良くないと分かりつつもそれに陥ってしまう原因は、がむしゃらに頑張って働く方が簡単だからです。 毎日遅くまで頑張ることは一見すると難しいことのように思えますが、全く逆だと思っています。 量をこなせば一定成果は出るし、周りからも「頑張っている」と思ってもらえ、達成感もあります。 しかし、単なるハードワークでは普通の人間の一人分の頑張りの成果しか出せない上に、仕事の後や休みの日に自分のスキルを高めるために時間を投資するなどを考えることがとても難しくなるため、どうにかしてこのハードワークの誘惑に勝たなければなりません。 <h2 id="h396a3000a9">自分のため、未来のチームのために周りとコミュニケーションを取る</h2>ハードワークを脱するために一番のポイントになるのは周りとのコミュニケーションだと考えます。 自分のタスクの処理スピードを少し上げたところで、次から次へとタスクが降ってくる環境であればハードワークからは脱せません。 それよりも、開発依頼に対して「この機能のユーザーにとっての価値は何なのか」「こっちの代替手段の方が良いのではないか」「そもそも今開発する必要はないのではないか」と、自分やチームが取り組むタスクをしっかり取捨選択する必要があります。 周りからの依頼をどんどん受けて頑張ってこなした方が有難がってもらえますが、自分のスキルに対して投資する時間を作るため、つまり未来のチームのために、周りと時にはタフなコミュニケーションを取りながら本当にやるべきことだけに取り組むことが大事だと思います。 <h2 id="h1b0cebfa59">自分の分身を作る</h2>簡単なタスクを自分がやらなくても良いように「自分の分身を作る」というアプローチも良いアプローチであることが多いです。 たとえばよく「ここのアクセスログを集計してください」などの依頼がプログラマに飛んでくることがありますが、こういった依頼を受けたときはただ集計するだけでなく次回以降は Biz 職でも誰でも任意の期間を集計できるような仕組みを作ったり、自動で集計できるようにしたりしてアウトプットを渡すようにすれば次回以降はそのタスクを引き受けなくて良くなります。 また、今まで自分しかできなかったことをチームメンバーにしっかり教えていくことで次以降は自分でなくてもできるようにするなどすれば少しずつ時間を確保できるようになってきます。 <h2 id="hcbec2bf0d9">終わりに</h2>ハードワークについて考えたことを言語化してみました。 自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。

「プログラマが知るべき 97 のこと」の「36. ハードワークは報われない」を読んで考えたことについて書きたいと思います。昨年の反省として、ハードワーク気味に働いていたために休日は寝てばかりで勉強もあまりできておらず、なんとかしないといけないなと思っていました...

楽をするために努力する〜プログラマが知るべき 97 のこと 36. ハードワークは報われない〜

<h2 id="h8d027c8ed3">はじめに</h2>最近 GLOBIS 学び放題をよく観ているのですが、その中の『出口治明が説く「これからの時代を生き抜く力」』という講演を観ていました。 <a href="https://hodai.globis.co.jp/courses/6926deb8" target="_blank" rel="noopener noreferrer">出口治明が説く「これからの時代を生き抜く力」</a> 講演の内容はざっくりまとめると、「ダイバーシティのある環境に飛び込んでどんどん学んでいかないと世界から取り残されるよ」という内容だったのですが、最後の受講者からの質問への出口さんの回答がとても良いなと思ったのでその中でも特に良いなと思ったものを忘れないように書いておこうと思います。 内容は動画そのままではなく、多少私の解釈も含めて言葉を補っています。 <h2 id="h5dd1e47962">Q. 出口さんは一見複雑に見えるような数字や事象をすごくシンプルに簡単に説明をされている。どんなことに気をつけているのか。</h2>自分の頭で考えている。 人間はそもそもそれほど賢い動物ではない。自分の頭で物事を考えていれば自ずとシンプルな考え方になるし、説明をシンプルになる。複雑なことを言っている人はまだまだ二流三流。 <h2 id="h9c3d9f19e3">Q. 人を動かすとはどういうことか語って欲しい</h2>人を動かすというとは、どんなときに人が頑張って働くのかを考えて実践するということ。 そして人は楽しかったら頑張る。そのため楽しい職場を作るということがほとんど全てである。 あとは付け加えるとしたら、各自の個性ややりたいことをしっかり把握していると動かすことができる。 <h2 id="h5665d1b066">Q. 部下やチームメンバーに勉強して学んでもらうためにはどんなことをすれば良いか</h2>早く帰すこと。そして「本を読め」「人と会ってこい」「色々なところに行ってこい」と伝えること。 <h2 id="hcbec2bf0d9">終わりに</h2>自分の頭で考える、楽しい職場を作る、チームメンバーの個性・やりたいことを把握する、皆を早く帰す、どれも大切なことなのでしっかり実践しようと思いました。

最近 GLOBIS 学び放題をよく観ているのですが、その中の『出口治明が説く「これからの時代を生き抜く力」』という講演を観ていました。講演の内容はざっくりまとめると、「ダイバーシティのある環境に飛び込んでどんどん学んでいかないと世界から取り残されるよ」という内容だった...

『出口治明が説く「これからの時代を生き抜く力」』という講演を聞いた話

「プログラマが知るべき 97 のこと」の「14. コードレビュー」を読んで思ったことについて書きたいと思います。 今回一番刺さったのは、「コードレビューは単に誤りを探すのではなく、個々のコードについて学んだり理解したりする目的でも行うと良い。」という記述でした。 私のチームは現在私含め 6 名のエンジニアがいるのですが、全員が自分以外の全てのメンバーが出す PR を出来る限りレビューするコードレビューの文化があります。 これはとても良い文化だなと思っているのですが、新たに join してくれる新卒のジュニアメンバーがいるとよく相談を受けるのは「まだ既存のコードに関する知識も使っている技術への知識も足りず、レビューを行うことができない。どうすれば良いか。」ということです。 このときによく私は「誤りを探すのではなくて自分の勉強のために PR を読んでみましょう。PR をコードを読んで 1 つでも理解できたことがあればそれをコメントとして残すようにしてみましょう。」という話をします。 ただこれは別にジュニアメンバーに限ったことではないし、自分自身ももっと明確に「自分の勉強のため」と意識して PR を読んでみようと思いました。 幸い私のチームは得意分野が各々違っており、全員がフロント・バックエンド満遍なく触れるものの、フロントが得意な人間もいればサーバー側が得意な人間、インフラが得意な人間もいます。 自分の苦手な分野が得意なメンバーの PR をしっかり読んで一つ一つ理解していくことで勉強になることは多いし、単に誤りがないかというレベルでのコードリーディングではもったいないなと思いました。

「プログラマが知るべき 97 のこと」の「14. コードレビュー」を読んで思ったことについて書きたいと思います。今回一番刺さったのは、「コードレビューは単に誤りを探すのではなく、個々のコードについて学んだり理解したりする目的でも行うと良い。」という記述でした。

コードレビューを学習機会と捉える〜プログラマが知るべき 97 のこと 14. コードレビュー〜

<h2 id="h8d027c8ed3">はじめに</h2>『エンジニアリング組織論への招待』を読みました。今回はその中の「1. 思考のリファクタリング」を読んで思ったことを書こうと思います。 よく「ロジカルシンキング」というと少し難しいイメージがあり、高度な思考スキルのように考えられている方もいらっしゃるかと思いますが、実際はそんなことはなく人間というのは基本的にロジカルシンキングというのはできていると思っています。 以前もこんな読書ログを書きました。 <a href="https://www.kaqiita.com/blogs/k2b4kp29-gxt" target="_blank" rel="noopener noreferrer">人間はみな本来頭が良い〜『ゼロ秒思考』を読んで〜</a> しかし人間の思考にはどんな人でも「バイアス」が働いてしまい、正しく物事を考えられないことが多々あります。 <h2 id="hbbecc19d56">「論理的に考える」とは「非論理的に考えない」ということ</h2>人間は論理的に考える力を持っている、しかし思考のバイアスによって正しく物事を考えられないことがある、ということは論理的に考える上で最も大切なことは「非論理的に考えないようにすること」ではないかと思います。 「1. 思考のリファクタリング」では人間が非論理的に考えてしまいがちなケースを紹介して、「このようなときに人間は非論理的に考えてしまうので注意しましょう」ということが書かれています。 個人的には以下の非論理的な考えはよくしてしまいがちだなと思いました。 <h2 id="hdab9d901ea">「すべき思考」に気を付ける</h2>すべき思考について、本では以下のように説明されています。 <blockquote>「すべき思考」とは、他人に対し、彼らは道徳的に「すべきである」「しなければならない」と期待し、それを強制するような思考パターンです。 …（中略）… また、この「すべき思考」は、自分にも向かいます。 ・「私は、社会人として就職しなければならない」 ・「私は、ちゃんとした大人として結婚しなければならない」 ・「私は、仕事なのだから理不尽も受け入れなければならない」</blockquote> 私の場合だと、依頼を受けた開発タスクが想像以上に重たいタスクで事前の見積もり通りにはいかないような場合に、「この期間でやると言ったからなぁ」とごりっと進めてしまうことが多いです。 ただこれはあまり良いことではないなと振り返ると思います。無理をしたスケジュールだと、設計を十分に考える時間がなく本当にベストな方針なのかの検討が不十分なままタスクを進めてしまうため、後から大きな負債になるというリスクが大いにあります。 やはり見積もりより大きなタスクになったらその段階で相談し、よほど急ぐ理由がなければしっかりと検討して開発を進めた方が良いケースが多いだろうなと思いました。気を付けようと思います。 <h2 id="hcbec2bf0d9">終わりに</h2>『エンジニアリング組織論への招待』の「1. 思考のリファクタリング」を読んでみた感想を書きました。 自分用のメモですが、誰かの役に立ってもらえると幸いです。

『エンジニアリング組織論への招待』を読みました。今回はその中の「1. 思考のリファクタリング」を読んで思ったことを書こうと思います。よく「ロジカルシンキング」というと少し難しいイメージがあり、高度な思考スキルのように考えられている方もいらっしゃるかと思います。

「すべき思考」に気を付ける〜『エンジニアリング組織論への招待 1. 思考のリファクタリング』を読んで〜

<h2 id="h8d027c8ed3">はじめに</h2>『ゼロ秒思考』という本を読みました。 何年か前に読んだことがあって、この本に書いてある「A4 メモ書き」という思考力トレーニングも 1 年程継続していたのですが、最近はサボっておりトレーニングしていた頃より思考力が鈍っている気がしたので再度この本を手に取ってみました。 <h2 id="ha82e8430db">人間はみな本来頭が良い</h2>この本の主張は「人間はみな本来頭が良い」ということです。「自分は頭が悪い」と思っている方は多いかもしれませんが、実際はそんなことはなく正しく頭を使えていないだけで正しいトレーニングを積めば正しく物事を考えられるようになります。 そのトレーニングが「A4 メモ書き」と呼ばれるものです。 詳細は割愛しますが、A4 の用紙に自分が決めたテーマについて頭に浮かんだことを高速で書いていくというものです。 <h2 id="hfb1cf62723">言語化能力を磨いていく</h2>このトレーニングで言語化能力がひたすら磨かれます。 上述の通り、「人間はみな本来頭が良い」です。しかし頭に浮かんだことが言語化できないためにふっと消えてしまい、結果「自分は物事を考えることができない」と思い込んでしまいます。 この頭にふっと浮かんだことを逃さずに言語化するトレーニングを積むことで思考力は抜群に上がります。 <h2 id="hb09a81ee62">頭が良い人とは</h2>この本を読む前まで、私は頭の良い人とは「ロジカルシンキング」や「仮説思考」などの思考術に長けている人のことを言うのだと思っていましたが、それは頭の使い方の一部分でしかなく、最も大切なのは「頭に浮かんだことを言語化できるかどうか」なのだということに気付きました。 実際私もこのトレーニングを 1 年間継続してかなり言語化能力が磨かれました。 最近はサボってしまっていますが、また始めようと思います。 <h2 id="hcbec2bf0d9">終わりに</h2>「自分は頭が良くない」と思っている方にはとてもおすすめの本です。 勇気が出るし、単に励まされるだけでなく思考力を鍛えるトレーニングがとても具体的に記載されているので是非読んでみてください。

『ゼロ秒思考』という本を読みました。何年か前に読んだことがあって、この本に書いてある「A4 メモ書き」という思考力トレーニングも 1 年程継続していたのですが、最近はサボっておりトレーニングしていた頃より思考力が鈍っている気がしたので再度この本を手に取ってみました。

人間はみな本来頭が良い〜『ゼロ秒思考』を読んで〜

<h2 id="h8d027c8ed3">はじめに</h2>「プリンシプルオブプログラミング」の「2.3 YAGNI」を読みました。 YAGNI とは「You Aren&#x27;t Going to Need It.」の略で、「多分必要になるだろう」で現状は不要なコードを書いてはいけないという原則です。 コーディング原則として語られることが多いですが、ソフトウェアの機能についても同じことが言え、つい先日実務でこの YAGNI 原則に則って上手く対応できたなと思えたことがあったので忘れないために書いておこうと思います。 <h2 id="h7baf786a8b">社内管理システムの機能追加依頼</h2>社内で使っている管理システムに対して、業務効率化のために機能追加の要望を受けました。 要望の内容となぜやるのかについてなんとなく想像はできたのですが、念のため要望を挙げてくれた方に以下のことについてヒアリングを行うことにしました。 <ul><li>そもそも今実務を行っていてどんな問題・課題があるのか</li><li>この機能を追加することでそれはどんな・どれくらいの事業価値に繋がるのか</li></ul> そして私の中で要望について理解でき、二種類の解決策を思いついたので A パターンの要件と B パターンの要件をメリデメと共に提示してどちらかを選んでもらうという形で機能について擦り合わせを行いました。 その擦り合わせが終わりかけた頃、「この要件とほとんど同じようなものを別のこちらの管理ページにも付けてもらうことはできるか」という提案を追加でもらいました。 ここが YAGNI 原則を適用して考えた点です。最初の要望を聞いた段階で「別のページにも同じように変更した方が良いかな」とちらっと思ったのですが、先程の A パターンにも B パターンにもそのページも同じ変更をするという要件は盛り込みませんでした。なので追加でもらった提案は一旦はお断りしています。 「多分必要になる機能」なのですが、「この機能を追加することで造られる事業価値」がまだ仮説の域を出ないため本当に機能追加が価値に繋がるのかが分かりません。なのでまずは今回元々解決しようと思っていた問題を解決して、この機能が本当に有用だと分かってから別ページにも同じような変更を行うか考えましょうと着地させました。 本当に必要になるか分からない機能を作るためにエンジニアリソースを食い潰すということを避けられて、個人的に悪くない意思決定だったと思いました。ちゃんと継続して行えるようにしていきたいと思います。 <h2 id="hcbec2bf0d9">終わりに</h2>YAGNI 原則について振り返ったことを書きました。 自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。

「プリンシプルオブプログラミング」の「2.3 YAGNI」を読みました。コーディング原則として語られることが多いですが、ソフトウェアの機能についても同じことが言え、つい先日実務でこの YAGNI 原則に則って上手く対応できたなと思えたことがあったので忘れないために書いておこうと思います。

ソフトウェアの機能にも YAGNI 原則を適用する〜『プリンシプルオブプログラミング 2.3. YAGNI』を読んで〜

<h2 id="h8d027c8ed3">はじめに</h2>「プログラマが知るべき 97 のこと」の「28.「魔法」に頼りすぎてはいけない」を読んで考えたことについて書きたいと思います。 ここでいう「魔法」とは、「仕事が上手く回るために他人が行っている工夫」という意味合いで使われています。 目に見えにくい細かな工夫で仕事が上手く回るため、「魔法」と呼んでいるのだと思います。 この章で書かれている覚えるべき原則は「他人のする仕事は実際より簡単に見える」というものです。 それは「魔法」は他人からは見えにくいからです。 この原則を改めて心に刻みながら日々の業務を振り返ったときに、気を付けるべきことがいくつかあったなと思ったので忘れないように書いておこうと思います。 <h2 id="h8c98b6e98a">誰かがいつもやってくれている作業を巻き取るときは絶対に想定以上の時間が掛かる</h2>定常業務はやればやるほど慣れてきて早くこなせるようになっているでしょうし、生産性が高い人であればそういった定常業務を効率的にこなすために細かい工夫をたくさん重ねていると思います。 そういった人の作業を巻き取るときには「時間が掛かる」ということをしっかり認識しておくべきです。 「思いのほか時間が掛かった」となってしまうことが個人的には多いです。 巻き取る際に一緒に進める上での工夫などを聞いておくと、こういったことは少し避けられるようになるかなと思います。 <h2 id="h37fae7af42">実務担当者と細かくコミュニケーションを取っていないと無理なスケジュールで依頼しがち</h2>開発タスクなどを投げる際には、自分があまり開発に関わっていない部分であればどれくらい時間が掛かりそうかを実務担当者としっかりコミュニケーションを取って擦り合わせるべきです。 自分には見えていないが実装に時間が掛かるところなどが必ず 1 つや 2 つあると思います。 こういったコミュニケーションが取れていないと、自分はバッファを含めた妥当なスケジュールで依頼していると思っていても、相手からは「いつもタイトなスケジュールで依頼してきやがる」と思われていた、みたいなことが起こりかねません。 また自身が依頼を受ける側のときにもどれくらいの工数が掛かるのかをしっかり伝えないといけないと思いました。 私の立場上、大体開発依頼は Biz 職から直接渡される場合がほとんどなので、具体的にどんなことをしているのか依頼側は分かっていません。 そのため丁寧に説明していかないと自分や自分のチームに無理をさせてしまうことになったり、チーム全体の開発ディレクション力も高まっていかなかったりしてしまうので、しっかりと話していかないとなと思いました。 <h2 id="h0d5adddce0">チームが想定以上に上手く回っているときは誰かが魔法をかけてくれている</h2>自分の想像以上にチームが上手く回っているときは、「自分の想定していたより簡単な仕事だった」のではなく「誰かが上手く回るように工夫を重ねてくれて」います。 上手く行っている要因を特定しないと再現性がありませんし、ある人がいるから上手くいっているのに、その人をチームから外してしまうなどの間違った意思決定もしてしまいかねません。 レトロスペクティブの場を設けて、「なぜ上手くいっているのか」をしっかり確認し、「この状態を継続するためにどうしたら良いか」「プロジェクトの状態をより良くしていくためにはさらにどんなことをすれば良いか」というのをチームで確認するのを忘れてはいけないなと思いました。 <h2 id="hcbec2bf0d9">終わりに</h2>「他人のする仕事は実際より簡単に見える」ということについて考えたことを言語化してみました。 自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。

「プログラマが知るべき 97 のこと」の「28.「魔法」に頼りすぎてはいけない」を読んで考えたことについて書きたいと思います。この原則を改めて心に刻みながら日々の業務を振り返ったときに、気を付けるべきことがいくつかあったなと思ったので忘れないように書いておこうと思います。

他人の仕事を理解する〜プログラマが知るべき 97 のこと 28.「魔法」に頼りすぎてはいけない〜

<h2 id="h8d027c8ed3">はじめに</h2>今のチームでフロントは React で書いており、テストは Jest を用いて行なっているのですが、「今日の日付」を表示するコンポーネントのテストを書くケースがありました。 なんらかをモック化しないとスナップショットが通らないはずなのですが、そういえば Jest でモック化ってどうやるんだっけと忘れていたのでメモしておこうと思います。 <h2 id="hcf4c0ae6f0">具体例</h2><h3 id="h2b0b5ec373">⑴ Date.now()をモック化する</h3><pre><code>Date.now = jest.fn(() =&gt; 1482363367071);</code></pre> これで <code>Date.now()</code>はいつでも <code>1482363367071</code> を返すようになりました。 参考：<a href="https://jestjs.io/docs/ja/snapshot-testing#2-tests-should-be-deterministic" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;jestjs.io&#x2F;docs&#x2F;ja&#x2F;snapshot-testing#2-tests-should-be-deterministic</a> <h3 id="h2f5bf68826">⑵ 特定の関数をモック化する</h3><pre><code>
const mockedGetDate = jest.spyOn(Date.prototype, &#x27;getDate&#x27;);
const mockedGetDay = jest.spyOn(Date.prototype, &#x27;getDay&#x27;);
const mockedGetMonth = jest.spyOn(Date.prototype, &#x27;getMonth&#x27;);

mockedGetMonth.mockImplementation(() =&gt; 4);
mockedGetDate.mockImplementation(() =&gt; 1);
mockedGetDay.mockImplementation(() =&gt; 0);

</code></pre> こちらでは <code>spyOn</code> を用いて <code>getDate()</code> <code>getDay()</code> <code>getMonth()</code> をモック化しています。 参考：<a href="https://jestjs.io/docs/ja/jest-object#jestspyonobject-methodname" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;jestjs.io&#x2F;docs&#x2F;ja&#x2F;jest-object#jestspyonobject-methodname</a> <h3 id="h2c1a50d64b">jest.fn と spyOn の違い</h3>上では <code>jest.fn</code> を使ったり <code>spyOn</code> を使ったりしていますが特に深い意味はありません。どちらも同じようなことができます。 <code>spyOn</code> はモック化する前の元の挙動に戻すことがすぐにできるので、「元の挙動も保持しておきたい」という場合に使われますが、 <code>jest.fn</code> でも同じようなことができるので好みの問題かなと思っています。 詳しいことは<a href="https://medium.com/@rickhanlonii/understanding-jest-mocks-f0046c68e53c" target="_blank" rel="noopener noreferrer">こちらの記事</a>が勉強になりました。 <h2 id="hcbec2bf0d9">終わりに</h2>Jest で日付をモック化する具体例を 2 つ紹介しました。参考になれば幸いです。

今のチームでフロントは React で書いており、テストは Jest を用いて行なっているのですが、「今日の日付」を表示するコンポーネントのテストを書くケースがありました。なんらかをモック化しないとスナップショットが通らないはずなのですが、そういえば Jest でモック化ってどうやるんだっけと忘れていたのでメモしておこうと思います。

【Jest】日付をモック化する

<h2 id="h8d027c8ed3">はじめに</h2>業務で React を書いていて久しぶりに <code>useEffect</code> を使う機会があり、ドキュメントを読んで確認していると <code>useLayoutEffect</code> という似たような hooks があることを知りました。 そこで、せっかく出会ったので少しまとめてみることにしました。 <h2 id="h5969c38c86"><code>useEffect</code> について</h2>まずは、<code>useEffect</code> の復習から。 <a href="https://ja.reactjs.org/docs/hooks-effect.html" target="_blank" rel="noopener noreferrer">公式ドキュメント</a>に分かりやすく書かれているので、この記事よりこちらを読んだ方が良いかもしれません。 以下でも公式ドキュメントの例を使って説明します。 <pre><code>
import React, { useState, useEffect } from &#x27;react&#x27;;

function Example() {
 const [count, setCount] = useState(0);

 &#x2F;&#x2F; Similar to componentDidMount and componentDidUpdate:
 useEffect(() =&gt; {
 &#x2F;&#x2F; Update the document title using the browser API
 document.title = `You clicked ${count} times`;
 });

 return (
 &lt;div&gt;
 &lt;p&gt;You clicked {count} times&lt;&#x2F;p&gt;
 &lt;button onClick={() =&gt; setCount(count + 1)}&gt;
 Click me
 &lt;&#x2F;button&gt;
 &lt;&#x2F;div&gt;
 );
}

</code></pre> <code>useEffect</code> に書かれた処理は、レンダリング後に行われます。 この例では、レンダリング後にドキュメントのタイトルを <code>count</code> という state を使ってセットし直しています。 これをコンポーネント内に書いておくことで、特別な API を使わずとも state である <code>count</code> にアクセスすることができます。 <h2 id="h3ed9044cab"><code>useLayoutEffect</code> について</h2><code>useLayoutEffect</code> は、上記で説明した <code>useEffect</code> とほとんど同じです。 ただコールバック関数が実行されるタイミングが異なります。 <code>useEffect</code> はレンダリング処理が終わった段階で渡された関数を実行しますが、<code>useLayoutEffect</code> はレンダリング処理が終わってその結果が DOM に反映された後にコールバック関数が実行されます。 つまり、<code>useEffect</code> を使っている場合はコールバック関数の処理が完了する前の DOM がユーザーに一瞬見えてしまうことがありますが、<code>useLayoutEffect</code> はこれを防いでくれます。 これはクラスコンポーネントの <code>componentDidMount</code> や <code>componentDidUpdate</code> と同じスケジューリングです。 ただその分、ユーザーへのページ表示が遅くなってしまうので大きな問題が起こらない限り <code>useEffect</code> の方を使うべきでしょう。 公式ドキュメントでも、基本的に <code>useEffect</code> の方を使うことが推奨されています。 <h2 id="hcbec2bf0d9">終わりに</h2>にしていても React Hooks は書いていて楽しいです。 フロントエンドに関してあまり詳しくなく、React Hooks 自体もフロントに強い先輩エンジニアに教えてもらっただけなのですが、これは書いていて面白いなと感じます。 <h2 id="h7605dc6208">参考文献</h2><a href="https://ja.reactjs.org/docs/hooks-reference.html#uselayouteffect" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;ja.reactjs.org&#x2F;docs&#x2F;hooks-reference.html#uselayouteffect</a> <a href="https://ja.reactjs.org/docs/hooks-effect.html" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;ja.reactjs.org&#x2F;docs&#x2F;hooks-effect.html</a> <a href="https://kentcdodds.com/blog/useeffect-vs-uselayouteffect" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;kentcdodds.com&#x2F;blog&#x2F;useeffect-vs-uselayouteffect</a> <a href="https://qiita.com/uhyo/items/246fb1f30acfeb7699da" target="_blank" rel="noopener noreferrer">https:&#x2F;&#x2F;qiita.com&#x2F;uhyo&#x2F;items&#x2F;246fb1f30acfeb7699da</a>

業務で React を書いていて久しぶりに useEffect を使う機会があり、ドキュメントを読んで確認していると useLayoutEffect という似たような hooks があることを知りました。そこで、せっかく出会ったので少しまとめてみることにしました。

【React】useLayoutEffect とは？useEffect との違いについて

この一年間はひたすらWebサービスのグロースハックに取り組み、プロダクトの KPIとして設定している指標をサービスの歴史史上最大の成長率でグロースさせることに成功しました。私自身の一年の振り返りとしてその学びを「グロースハッカーの十戒」という形で共有したいと思います。

グロースハッカーの十戒

<h2 id="h8d027c8ed3">はじめに</h2><a href="https://www.youtube.com/watch?v=lv64-2pOh38" target="_blank" rel="noopener noreferrer">Agile Practices Subway Tour #1</a> の LT 会が YouTube Live でやっていたので聞いていました。 個人的に興味のある分野だったのとみなさん発表が分かりやすく、とても勉強になりました。聞きながら取った要約メモと自分の感想・学びを書いていこうと思います。 <h2 id="h99e203cf8e">1. コードの共同所有</h2><h3 id="h9ced1f0f73">要約</h3><ul><li>コードの共同所有<ul><li>とは？<ul><li>誰が書いたコードでも全員が修正を行うことができる状態</li></ul></li><li>なぜ大事？<ul><li>トラックナンバー（何人事故にあったらプロジェクトが中断するか？）を改善するから</li></ul></li></ul></li><li>コードレビューはコードの共同所有に貢献する</li><li>しかしコードの共同所有が実現するレベルまでしっかりとしたコードレビューを常に行っていくことはかなりコストが掛かる</li><li>ペアプロ・モブプロを導入していけると良い。ただ導入はかなり大変なのでそのような文化をどのように創っていけば良いのかについてもっと議論するべき。</li></ul> <h3 id="h568eed7377">感想・学び</h3><ul><li>導入はジュニアメンバーが多いチームであれば、育成としてシニア or ミドルとジュニアでペアプロをしていくというやり方が良いと思っている。</li><li>全員が同じような歴の場合は「コードの共同所有」についてディスカッションする機会を設けてどうしたら良いかを話し合っていくとかしかないのではないかと思う。それでペアプロ・モブプロが良いよねという着地になれば納得感を持って導入できる。</li></ul> <h2 id="hcb23f7bcd9">2. Product Management と XP が交差するユーザーストーリー</h2><h3 id="h9ced1f0f73">要約</h3><ul><li>ユーザーストーリーとは BizDevOps がユーザー視点で共通の認識を持てるようになるためのもの</li><li>ユーザーストーリーはよく「[Who] として [What] がしたい。何故なら [Why] だからだ。」と書くようにと言われる。</li><li>しかし [Why] にユーザーにとっての価値が書いていなければ本質的には何故このストーリーを実現しなければならないのかが分からない</li><li>そこでユーザーストーリーは「[Who] として [What] がしたい。何故なら [Value] という価値があるからだ。」と書くようにする</li><li>[Value] が書いてあることで議論の対象が仕様ではなくユーザーにとっての価値にフォーカスされ、ユーザーにとっての価値を実現する最適な仕様が BizDevOps で共通認識を持ちやすくなる。</li></ul> <h3 id="h568eed7377">感想・学び</h3><ul><li>「ユーザーにとっての価値を書いてもらう」というのがなるほどと思った。今までいまいちよく分からないなと感じていた開発依頼・要望にはユーザーにとっての価値が抜けていたんだと気付くことができた。</li></ul> <h2 id="h3d9a2ee40d">3. 1 週間ですら見積もれなかったからイテレーションを 1 日にしてみた</h2><h3 id="h9ced1f0f73">要約</h3><ul><li>プロジェクトが複雑過ぎて 1 週間分ですら計画を立てることが難しい</li><li>やってみて<ul><li>方向転換がしやすかった<ul><li>ex. 昨日の成果を思い切って捨てる</li></ul></li><li>バッファを取らなくて良くなった</li><li>毎日計画を立て直すのはかなり大変</li><li>また目的を見失わないために 3 ヶ月スパンのロードマップは必要</li></ul></li><li>アジャイルプラクティスに縛られ過ぎないのが大事。環境の変化に適応するためにやり方を変えていく。</li></ul> <h3 id="h568eed7377">感想・学び</h3><ul><li>改めて守破離の大切さを感じた。まずはプラクティスを型通りにしっかり実践していく、そのプラクティスをメリットデメリットが理解できてきたらチームの状態に合わせてカスタマイズしていくということが大事。</li></ul> <h2 id="hce664b0664">4. ベロシティを上手く使って技術的負債を計画的に解消する</h2><h3 id="h9ced1f0f73">要約</h3><ul><li>いつか負債を解消するの「いつか」はこない</li><li>技術的負債返済用のバックログを作り毎週固定の枠を設けるべき</li><li>毎週時間を抑えるだけでは大体キリよく終わらない上にアウトプットが不明瞭になる。他の開発と同様に受入基準を明確にしてきちんと完了させる。</li><li>負債解消をやりたくなったら都度交渉は Biz と Dev どちらにも無駄な工数が掛かって双方疲弊する</li></ul> <h3 id="h568eed7377">感想・学び</h3><ul><li>いつかはこない</li><li>これは今もチームで実践しているがとても良いプラクティスだと感じている</li><li>さらに予算策定などの期初のタイミングで Biz と擦り合わせることが大事だと感じている。予算がない中で負債を返済させてくれと言われても Biz は困るため、予算を決める段階でどれくらいの稼働を負債返済に使わないといけないのかをすり合わせておくと良い。</li></ul> <h2 id="hcbec2bf0d9">終わりに</h2>イベントもオンラインが主流になりつつあって参加ハードルも下がっているので、今年はなるべくこれからも参加していこうと思いました。

「Agile Practices Subway Tour #1」のLT会がYouTube Liveでやっていたので聞いていました。個人的に興味のある分野だったのとみなさん発表が分かりやすく、とても勉強になりました。聞きながら取った要約メモと自分の感想・学びを書いていこうと思います。