「感情」の大切さを実感：『モチベーションドリブン』を読んでみた
先日，「組織開発」や「人材開発」の書籍を求めて本屋をウロウロしていた時，この本と出会いました．「〜ドリブン」に弱いのか，タイトルを見ただけで「よし，買おう！」と思い，購入しました．
- 作者: 小笹芳央
- 出版社/メーカー: KADOKAWA
- 発売日: 2019/03/22
- メディア: 単行本
- この商品を含むブログを見る
著者が執筆した理由として，
- 「残業時間の削減はどのように進めていけば良いか」
- 「女性管理職の比率はどうやって上げているか」
このような質問が増えてきたが，これらは局所的な課題であり，「働き方改革」の真の目的が忘れ去られていることに危機感を覚えたため，と述べています．働き方改革の真の目的は「組織としての生産性の向上」だと考えており，これを実現するために大切な考え方として次のものを挙げています．
「One for All, All for One」
ONE を個人に置き換え，ALL を組織に置き換えると，「個人は組織のために，組織は個人のために」となる．個人の欲求に寄り添いすぎれば，組織としての成果が最大化できず，逆に，組織の成果に寄り添いすぎれば，個人が疲弊する．
こちらの本では，この「One for All, All for One」という考え方を基軸に「働き方改革」について考えていくものとなっています．
目次
- 第1章: 人間観と組織間を刷新せよ
- 01: 「カネ」と「ポスト」だけで人は動かせない
- 02: 「個人の集合体 = 組織」ではない
- 03: 「One for All, All for One」で考える
- 第2章: 個人にとっての働き方改革 〜アイカンパニーの時代〜
- 01: 個人と企業の関係性の変化
- 02: 個人はアイカンパニーの経営者となれ
- 第3章: 企業にとっての働き方改革 〜モチベーションカンパニーの時代〜
- 01: 変化する二つのの市場
- 02: 労働市場への適応は待ったなし
- 03: 企業を束ねるもの
- 第4章: 「One for All, All for One」を無視した働き方改革が会社を潰す
- 第5章: 最も重要な「従業員エンゲージメント」
- 01: 競争優位の源泉はエンゲージメント
- 02: エンゲージメント経営への道
- 03: 全社員の「視界共有」でエネルギーを創出
- 終章: 組織に潜む「モチベーション症例」とその処方箋
- 01: 「拡大ステージ」に潜む五つのモチベーション症例
- 02: 「多角ステージ」に潜む五つのモチベーション症例
- 03: 「再生ステージ」に潜む五つのモチベーション症例
各章の紹介
「第1章」では，個人と組織，それらの関係性がどのように変わりつつあるのか，新しい人間観と組織観が提示されています．人間観は「感情」を，組織観は人数ではなく「関係性の数」を見ることの大切さが書かれています．「第2，3章」では，それぞれ個人・組織の立場に立って「働き方改革」を論じています．「第4章」では，「働き方改革」の各テーマに沿って，著者の会社の事例を交えながら，個人・組織それぞれに対する施策をどうバランスよくとっていったらよいか，が述べられています．「第5章」では，企業と従業員の相互理解，相思相愛の度合いを表す「従業員エンゲージメント」の重要性について書かれています．これは「One for All, All for One」を高いレベルで実現するために必要不可欠なものとされています．「終章」では，「One for All，All for One」の実現を阻害する様々な「モチベーション症例」を，企業の成長ステージに分けて整理し，それらの対応策が提示されています．
「感情」にフォーカス！
人には「感情」があり，それを無視した施策では問題がある，としています．この重要な要素である「感情」にフォーカスします．
人間観を改めた経済学
以前は，お金のことばかりを考える「完全合理的な経済人」とした人間観でした．しかし，「行動経済学」では，人間は限定的に合理的ではあるものの，「感情」で判断が大きく左右されるものだとされました．このように，経済学が人間の感情や心理も考慮した人間観に変わってきたため，企業も人間は「限定合理的な感情人」であるという人間観を持つことが大切です．
仕事で褒めらることはありますか？
私は，チームメンバーに，ちょっとハニカミながら「〜やってくれてありがとう」と感謝された時は，「あぁ，大変だったけど頑張ってよかった．」と嬉しく思います．嬉しいという感情だけでなく，「次も頑張ろう！」，「次はもっと役に立てるよう頑張ろう！」とモチベーションがアップします！
「感情報酬」という新たな報酬
「完全合理的な経済人」であるという人間観に基づいて作られてきた仕組みの中に「報酬」があります．給料やボーナスといった「金銭報酬」や，課長・部長といった「地位報酬」が中心としてありました．しかし現在は，金銭と地位だけで人は頑張れない，「限定合理的な感情人」という人間観に立ち，次のような欲求に対する報酬が新たに必要になるのではないか，と提示しています．
- 承認欲求: 自分はかけがえのない一員だと認められたい
- 貢献欲求: 誰かのために役に立ちたい
- 成長欲求: 以前と比べてこんなことができるようになった
- 親和欲求: 良好な人間関係の中で働きたい
著者の会社では，こうした欲求・感情を満たす報酬のことを「感情報酬」と呼んでいます．金銭・地位報酬が仕事の成果に対するものであり，「感情報酬」は誰かとのコミュニケーションによって得られるものです．企業は，感情人である従業員1人ひとりをよく見て感情的な側面をくみとり，さらに感情を刺激するような施策を打つ必要がある，と説いています．
私の今のモチベーションの源泉を考えてみました．
ブログを始めたのは，新しいことにチャレンジして成長したいためです．また，今年の1月からチームで働くことを意識してモブプロ （モブワーク）をしているのは，「メンバーの成長に役立ちたい」，「コミュニケーションをたくさんとっていい人間関係をつくりたい」ためです．「承認欲求」は薄いかもしれません（汗）
チームメンバーとコミュニケーションの密が増したことで，私自身の心に変化があったと実感しています．「何かを学ぶ → チームへ貢献 → 褒められる → 学ぶ意欲アップ」という正のスパイラルに入っています．私の場合は，これを1人だけで成り立たせることは難しく，コミュニケーションの相手がいるからこそ成り立ったものかな，と思います．
まとめ
仕事において目標を立てる際には，定量的なものであることが求められます．そうでないと評価しづらい，ということもあるでしょうが，今の状況が全体のどれくらいなのか，というのが見えません．しかし，目標に向かって動くのは人ですし，動くためには動機付け（モチベーション）が必要です．どちらか一方ではなく，両方大事なことなんだと思います．
数字は重要なんだけれどもそれに捉われず，周りの人たちの「感情」を大事にしていきたいなと思える一冊でした．
いい刺激を受けたイベント「Laravel Meetup Connect」の参加レポートです！
2019/06/14（金） Laravel MeetUp Connect というイベントに参加しました！Laravel について LT を行ったりします．面白い試みとして，沖縄・宮崎・名古屋・大阪の各会場を Zoom（Web 会議）で繋いで行いました．主催者の鈴木さんが言うには，「地方で勉強会を行う課題として，なかなか発表者が集まらない．それなら各地域で繋いで発表しあおう．」という発想で，積極的に各拠点を繋いで勉強会を行なっているとのことです．
沖縄ではイベントが多くはないので，仮に主催場所が沖縄以外だったとしても，リモート参加 OK なものが増えていくと嬉しいですね．
質問は Twitter ではなく sli.do で
LT 中に質問したいことがあったらハッシュタグを付けて Twitter に投稿することが多いと思います．今回は「sli.do」という質問を匿名で集められる Web サービスを使いました．Twitter 上では，質問を見落としたり流れてしまうことが多いため，このサービスを使ってみようとなったようです．
LT 第一弾: View composer
沖縄会場から，私と同郷（神奈川）でコスプレ好きな鈴木さんの発表です．
View 側で，全てのページで共通するデータを利用したい時に効果的な View Composer の紹介でした．例として，ユーザーのプロフィール情報を表示する画面内のヘッダーやサイドバーなどで共通の変数を扱うケースでした．
実装した内容についてメモさせていただきました．
- サービスプロパイダーの用意
- app/config.php に登録
- Composer クラスの作成（ロジックを書く部分）
- ServiceProvider への登録
- Blade ファイルの修正
今回は，変数のバインドに絞って利用したけれども，Blade テンプレートの中で if 文が複雑になりそうであれば View composer に寄せていくといった使い方ができるだろう，とのことでした．
その他
沖縄で初開催となる PHP カンファレンスの告知がありました．絶対いきます！！
LT 第二弾: 駆け出しエンジニアのコードをレビューしてみた
宮崎会場から，キャンプやフェスが趣味の大塚さん．「キャンプ×プログラミング」のワークショップを行なっている，とのことです．楽しそうですね！
インターン生への課題（イベント管理システムを作る）の中で， Controller を対象にレビューをし，リファクタリングをしていく過程の紹介でした．200 行ある Fat な Controller を 3 ステップでスッキリさせていく様は気持ちよかったです．
この 3 ステップは次のようなものでした．
1. バリデーションを FormRequest で
Controller でリクエストデータのバリデーションを行なっていたのを，FormRequest クラスをタイプヒントで利用することで 200 行から 150 行へ削減！
2. アクセサと appends
イベント情報の更新処理内には，日付の加工などが行われていました．アクセサと appends を利用することで，テーブルにないカラムをイベントオブジェクトのプロパティに追加ができ，150 行から 130 行で削減！
3. Service クラスの導入
イベント情報の一覧を取得する処理などで，ビジネスロジックが含まれていたのを Service クラスへ以降し，130 行から 85 行へ削減！
その他
Laravel に関することだけではなく，初心者への教育という観点の会話も生まれました．
「初めから綺麗に書くよう指導するのがいいか．または，一度作った後にまとめてレビューをするのがいいか．」
私もすごく同意したい意見がありました．「最初から綺麗な書き方を教えてしまうと，何が綺麗で，何が汚いかが分からないだろう．なのでまずは自分で作ってもらう．」という意見です．「差」を見ることで理解度が増し，成長に繋がるのではないかと思いました．
LT 第三弾: コンシューマ向けSPA開発から得られた知見
大阪会場から，猫が大好きな jiyuujin さん．「Laravel + Vue」の SPA を開発した際に，パフォーマンスを改善するために行なった取り組みの紹介でした．
少しでもパフォーマンスを上げるため，以下の点を意識した，とのことです．
- 設計はエンティティごとに切る
- 非同期通信に注力
- Web のパフォーマンスにいい影響
- 大量データを登録する時に力を発揮
- 極力パッケージを入れない
また，おすすめなパッケージとして「google/apiclient」が挙げられていました．これは Google スプレッドシートにアクセスして扱うことができるものです．今度触ってみようかな，と興味を持ちました．
まとめ
イベントの参加レポートに挑戦するにあたって，写真撮影を試みてはいたのですが，光が反射して見えにくいものばかりになってしまいました．位置取りも重要ですね．
初めから LT 枠に申し込んでいなくても，飛び込み参加が可能な雰囲気でした．次からはいつでも飛び込み LT できるようにネタを作っておこうと思います．
イベントのテーマは「Laravel」でしたが，Laravel 以外のことで他の人の考えや意見を聞けるのは，とても刺激になるなと感じました．今後も積極的に参加していこうと思います！
3ヶ月続けたカックさん（@kakakakakku）のブログメンタリングを卒業しました
2019年3月から，カックさん（@kakakakakku）にブログメンタリングを受けていました．初めは辛いと感じた時もありましたが，「ブログめっちゃ楽しい！」と思うようになりました．この3ヶ月間をふりかえり，学んだことなどをまとめます．
メンタリングを受けた経緯
今年の1月から，会社で Tech ブログを書いていこうとなり，月1回，記事の公開を目標としていました．しかし，ブログを書いたことがなく，どう書いたらよいものか，何を書いたらよいものか悩み，2月にようやっと振り絞って1記事書きました．それを見かねた弊社 CTO から，「知り合いにブログのメンターやってくれる人いるけど，やりたい人募集ー！」という連絡を受け，「ぜひ！」と応募することになったのがきっかけです．
まず最初に得たことは「アウトプット駆動」
最初の1週間は辛かったです．ブログあるあるかもしれませんが，こんなことを思っていました．
- 何を書いたらいいか分からない
- どう書いたらいいか分からない
- 頑張って書いても，結局すでに誰かが書いてるだろう（質も高いだろう）
しかし，こんなことは気にしなくていいんですね！
未来の自分のために外部記憶装置として書き残しておけば良いのよ！
カックさんの記事を読み，気にしてる時間がもったいない，ブログを書こう！アウトプットをしよう！という精神を持つことができました．この2つの記事を読んだだけで明らかにモチベーションが高くなったことを覚えています．そして自然に，普段の業務中でも，エラーが発生したら「ラッキー！ブログネタ1つできた！」と思うようになり，常にネタが転がっていないか，ネタへの嗅覚が増しました．社内で「ブログ駆動開発だー！」と得意気にしていました（笑）
意識の方向が変わっていった：アウトプット → インプット
アウトプットのネタを探すようになったため，インプットする量が増えました．他の人のツイートや，ブログなどを読むようになり（まだまだ満足のいく量ではありませんが），気になることや勉強したいことが芋づる式に増えていきました．
社内でブログメンターをすることに
たくさん反省点はありますが，この3ヶ月間，本当に楽しかったです．世界が広がったと言っても過言ではありません！この楽しさを，自身の中に留めておくのはもったいないと感じ，6月から社内でブログメンターをすることになりました．メンティーにも自分が味わった楽しさを感じてもらえるように頑張っていきたいと思います！
今後の挑戦
メンタリング期間が終わったからといって，ブログを書くことが終わるわけではありません．むしろ始まったばかりだと思っています．これだけは言いたいです．「書きたいから書く！」と．
とはいえ，メンタリング期間中にいただいたアドバイスで，まだ実践できていないこともあり，それも踏まえて新たな挑戦事項を挙げます．
- 月曜日にブログを公開することを目標とする（少なくとも平日中に）
- 技術系，非技術系に関わらず，「書評」にチャレンジ（月2本）
- 他の人の記事を読んで，コメントを添えてシェアする（毎日）
- アウトプットの場をブログだけでなく，イベントに参加して LT で発表（月1回）
最後に
会社の目標としてブログを続けていたら，今頃放り投げていたかもしれません．そうでなくても，今のように「楽しさ」を感じることはできなかったと思います．この3ヶ月間は，ブログの楽しさ，アウトプットの楽しさだけでなく，人生観までも変わった時期でもあります．
カックさん，本当にお世話になりました．ありがとうございました！！
人事の大変さ，ありがたさがわかった「マンガでやさしくわかる人事の仕事」
私は HR Tech（Human Resource と Technology を合わせた造語）の業界にいます．『HRテクノロジー活用の教科書』では，HR Tech を「人事労務業務を効率化するクラウド型 IT サービス」と定義しています．人事がどういう仕事なのか，何を考え，何を解決したいのか．そのために Tech 方面からどう支援できるかをもっと深く考えられるようになりたいため，人事について勉強しています．初めて人事に関する本『マンガでやさしくわかる人事の仕事』を読みました．
- 作者: 株式会社トライアンフ,青木健生,神崎真理子
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2016/02/26
- メディア: 単行本
- この商品を含むブログを見る
- 作者: 榊裕葵
- 出版社/メーカー: 日本法令
- 発売日: 2019/04/19
- メディア: 単行本
- この商品を含むブログを見る
目次
- Part1 人事の仕事とは
- Part2 採用する
- Part3 評価と配置
- Part4 人を育てる・守る
- Part5 働きやすい職場を作る
人事部の役割
Part1-01「企業をとりまく変化と人事部の役割」では，企業を取り巻く環境にどのような変化があり，人事に寄せられる期待について書かれています．環境の変化は以下のものが挙げられています．
- 変化1: 社会変化のスピード化
- 変化2: 競争範囲の拡大
- 変化3: 顧客ニーズの多様化
- 変化4: 「商品」のサービス化
これらの変化により，人材は非常に重要な経営資源と位置付けられ，人事は経営貢献度の高さが求められるようになりました．以前は，労務管理などの機能が中心でした．しかし現在は，経営ビジョンを達成するため，人材をいかに確保し，育成し，活躍してもらうかの仕組み作りに大きな期待が寄せられています．
人事に向けられる期待が想像以上に大きいことを知りました．確かに，採用活動や研修，私たち社員が働きやすい環境を整備してくれている，頑張ってる姿を見てきました．それでも私が見えてる範囲は小さなものです．現場レベルで，何を・どう支援できるか，を考えさせられる章でした．
人事異動
Part3-02「人事異動」では，異動が何の目的で実施されるのか，注意点などが書かれています．「人事異動」の目的として以下のものが挙げられています．
適正配置の追求
各部門にどのような人材を何人配置するか，個人の能力や強み・弱みも考慮したうえで「適材適所」に「配置する」事を目的としています．
組織活性化
組織内の人が動くことにより，新たな人間関係に適応していこうという行動が組織の活性化につながります．
従業員の能力開発
新しい業務を習得したり，新たな人間関係の中で適応しようとすることで「能力開発」が促進されます．
「異動」には様々な目的やメリットがある事を知りました．「異動」はまだ見た事もない偉い人たちが決めるもの，というイメージを持っています．1人1人の「動機付け」が，「人」と「組織」の活性化につながる重要なポイントだと思いました．「人」が活き活きと働いている状態，「組織」が活性化されている状態はどういったものなのか？どうすれば可視化できるのか？「人」だけではなく，「組織」だけではなく，両方の視点（もっと別の視点があるかもしれない）から考えられるようになっていきたいと思いました．
まとめ
「人事」への認識が大きく変わりました．感謝の想いが込み上げてきます．HR Tech 業界で貢献していけるように勉強していきたいと思います！
理科系の作文技術を読んでみた
ブログの記事や仕事で書く文章の質を高めたく，『理科系の作文技術』を読み，実践していきたい事をまとめました．
- 作者: 木下是雄
- 出版社/メーカー: 中央公論新社
- 発売日: 1981/09/22
- メディア: 新書
- 購入: 107人 クリック: 1,559回
- この商品を含むブログ (328件) を見る
目次
- 第 1 章: 序章
- 第 2 章: 準備作業（立案）
- 第 3 章: 文章の組み立て
- 第 4 章: パラグラフ
- 第 5 章: 文の構造と文章の流れ
- 第 6 章: はっきり言い切る姿勢
- 第 7 章: 事実と意見
- 第 8 章: わかりやすく簡潔な表現
- 第 9 章: 執筆メモ
- 第 10 章: 手紙・説明書・原著論文
- 第 11 章: 学会公演の要領
準備作業（立案）
第2章「準備作業（立案）」では，「主題の選定」や「材料の探索」の必要性や心得が書かれています．そのうち 2.3「主題の選定」に次の説明があります．一つの文書では一つの主題に集中すべきです．複数の主題が混ざると，読者に与える印象が散漫になり，説得力が低下するからです．また，自分自身の経験で得た情報（なまの情報），それについての自分自身の考えに重点をおくべきです．これらは，例え不備であり未熟・浅薄であっても，オリジナリティという強みを持っています．
私はなまの情報を特に意識しています．自身が体験した事をブログにアウトプットしておくと，その時に得た情報だけでなく，その時の感情も思い出せるからです．
パラグラフ
第4章「パラグラフ」では，文章のどこで切ってパラグラフとすべきか，パラグラフの構成はどんな条件を満たすべきか，について書かれています．パラグラフはある一つのトピック（小主題）についてある一つの事（考え）を言うものです．そこで何について言おうとするのかを一口に，概論的に述べた文が含まれ，これをトピック・センテンスと言います．パラグラフに含まれるその他の文は，トピック・センテンスで要約した事の詳細を説明します．これを展開部の文と言います．
著者が勧めている習慣があります．文章を書きながら絶えず読み返し，各パラグラフに必ずトピック・センテンスがあるか，展開部の文はトピック・センテンスとちゃんと結びついているかをチェックするというものです．
私はこれまでブログを書く際に，見出しに対して何を書くか，しか意識していませんでした．「要は何が言いたいのか」が分かりにくい形になっています．ブログの記事だけでなく，仕事で書く文書も，上の習慣を意識していきたいと思います．
わかりやすく簡潔な表現
第8章「わかりやすく簡潔な表現」では，一つ一つの文を書くうえでの心得が書かれています．長い文は読み返さないと判らない文になりがちなため，短く，短くと心がけて書くべきとあります．また，頭の中にびっしり詰まっている書きたい事を文章にする時に，以下の事を心がけるように述べています．
- 書きたい事を一つ一つ短い文にまとめる
- それを論理的にきちっとつないでいく
- いつでも「その中では何が主語か」を明確に意識して書く
文を短く，短く，というのは意識していました．しかし，一つ一つの文をきちっとつないでいく，という所まではできていませんでした．文を単体に見るのではなく，全体の主語が何か，を意識していきたいと思います．
まとめ
今回初めて書評に挑戦したのですが，単純に要約しただけになっていないか，ただの感想文になっていないか，という事を気にしすぎて時間がかかってしまいました．本を読み，ブログを書き，という事はとても根気のいる事だなと感じました．しかし，それ以上に楽しさを感じました．気になった箇所に付箋を貼り，線を書き込みながら読み進め，今までの読書よりも深く考えながら読めたと思います．
今後ブログを書く時には，この『理科系の作文技術』は常に側に置いてバイブルにしたいと思います．そして，たくさんブログを書いてクオリティを上げていきたいと思います！
参考記事
マネし過ぎないように気をつけつつ，参考にさせていただきました．
チームビルディングでドラッカー風エクササイズ！（その２）
5月入社された方をチームに迎え入れることとなり、GW明け（5/7）にチームビルディングの一環としてドラッカー風エクササイズを行いました。
今回で2回目となります。この時に工夫したことや、よかったことなどをまとめます。
1回目は、4月に入社された方をチームに迎え入れた時に行いました。
ドラッカー風エクササイズについてや、その時の様子はぜひこちらをご参照ください。
目次
今回の様子
前回の立ちっぱなしで疲れるという反省をふまえ、座って会話できる高さで表を書きました（笑）
メンバーは全部で5人いまして、1人はリモートワークをしており、台上のPCごしに見ている状況です。
右の男性（中国出身の方）は決して内職をしてるわけではなく、分からない単語をググっている様子、、、のハズです。
工夫したこと
質問項目
前回は初めてのトライということもあり、教科書通りの質問項目で行いました。
- 自分は何が得意か？
- 自分はどうやってチームに貢献するつもりか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどういう成果を期待していると思うか？
しかし今回は、別の視点で他のメンバーの考えや想いなどを知りたいなと思い、質問項目を一部変えて行いました。
- スキルを何か1つマスターできるなら何がいい？
- 1ヶ月前から変わったと思うことは？
- 自分が大切に思う価値は何か？
- 最大のモチベーションは？
質問項目を自分たちで選んだということもあってか、回答がより具体的なものになり、会話も弾んだと思います。
進行
- ポストイットに回答を書き出す（10 分）
- 一人ひとりの発表（4 分 / 人）
1ヶ月前から変わったと思うことは？について、他のメンバーから見て変わったと思うことを発表（キャプチャのピンクの付箋）- 気になったことなど、ざっくばらんに会話
3以降でタイムボックスを設けるのを忘れてしまいました・・・。 会話が発散しすぎないようにするためにも、次やるときは全体的にタイムボックスを設けようと思います。
まとめ
今回特によかったこは1ヶ月前から変わったと思うことは？について、他のメンバーから見て変わったと思うことについて会話できたことだと思います。
自身のこの1ヶ月のふりかえるだけでなく、他のメンバーの成長に注目していいところを指摘したり、ありがとうを伝え合う場面もありました。
あるメンバーから「ふりかえりとか、モブプロ とか、チームでやっていくことについて色々取り組もうとしてくれてありがとう」という言葉をもらいました。
泣きそうになったのはナイショですが、むしろいつも私のフワッとした「こういうことやりたいんだよね〜」ということに対し、「よく分からないけど、まずはやってみよう！」と一緒に取り組んでくれるみんなにありがとうを伝えたいです。（ちゃんと伝えたっけ・・・汗）
これからも自身のスキルアップだけでなく、主体的に動けるチーム、強いチームづくりをするための努力は続けていきたいなと改めて思いました。
Laravel の Eloquent 検証（ローカルスコープ）
DB からデータを取得する時、様々な条件のもとに取得してくる事が多いと思います。
その度にwhereをいくつも連結して実装するのも、読み解くのも大変ですよね。
何が大変かと言うと、結局その実装で取得されるデータが何を表しているのか分かりにくい、というのが原因の1つなのではないかと感じました。
そういった事を解決してくれるクエリスコープという機能の1つであるローカルスコープについて検証しました。
参考：Eloquent: Getting Started - Laravel - The PHP Framework For Web Artisans
ローカルスコープの検証
マイグレーションファイルの準備
以下のような users テーブルを用意します。
- is_active カラム：有効なユーザーかどうかを表すフラグ
role カラム（※ 例として以下のような分類とします）
admin：管理者prime：一般よりも権限を持つユーザーuser：一般ユーザー
マイグレーションの定義
<?php public function up() { Schema::create('users', function (Blueprint $table) { $table->string('id', 36)->primary(); $table->string('last_name'); $table->string('first_name'); $table->boolean('is_active'); $table->enum('role', ['admin', 'prime', 'user']); $table->timestamps(); }); }
テストデータの準備
今回は、Fakerを使い、10人分のテストデータを生成しました。
Fakerはランダムなテストデータを生成するのに便利なライブラリです。
以下のサンプルのように人の名前だけでなく、emailや住所なども生成してくれます。
参考：[PHP] Fakerでランダムなフェイクデータを作成する - Qiita
<?php $roles = ['prime', 'user']; $faker = Factory::create('ja_JP'); foreach (range(1, 10) as $i) { // 最初の1人だけ admin にし、それ以外はランダムで prime か user ロール。 $role = $i === 1 ? 'admin' : $roles[rand(0, 1)]; User::create([ 'id' => $faker->uuid, 'last_name' => $faker->lastName, 'first_name' => $faker->firstName, 'is_active' => $faker->boolean(), 'role' => $role, ]); }
生成したデータは以下の通りです。
検証1：シンプルな定義（有効なユーザーを取得する）
scopeをプレフィックスとした function をモデルに定義する必要があります。
ただし、この function を呼び出す時は、scopeを付けません。
モデル定義
ここでは、有効状態のユーザーを操作する頻度が多い事を想定し、
以下のように User モデルにscopeActiveという名前で function を追加します。
<?php namespace App\Models; use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; class User extends Model { 〜 略 〜 protected $casts = [ 'is_active' => 'boolean', ]; public function scopeActive(Builder $query): Builder { return $query->where('is_active', true); } }
実行
定義したスコープを使って件数を取得します（想定では8人）。
<?php logger(User::Active()->count());
出力結果
[2019-05-06 08:59:09] testing.INFO: Query Time:15.99ms] select count(*) as aggregate from `users` where `is_active` = ? [2019-05-06 08:59:09] testing.INFO: array ( 0 => true, ) [2019-05-06 08:59:09] testing.DEBUG: 8
発行されるクエリがis_activeを条件にしている事、カウントも適切な値が取得できた事を確認できました。
少しハマったポイント
※ ドキュメントにはUser::active()と、aが小文字で書かれており、これを実行すると以下のようなエラーが発生しました。
試しにAと大文字から書き始めたら正常に動くようになりました。
BadMethodCallException: Call to undefined method App\Models\User::acitve()
検証2：スコープに引数を渡せるようにする（動的スコープ）
モデル定義
roleがprimeもしくはuserのリストを取得できるようにしたい、といったケースに対応できるようにするため、以下のようにscopeOfTypeという function を追加します。
<?php namespace App\Models; use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; class User extends Model { 〜 略 〜 // $type には `admin`, `prime`, `user` のいずれかを指定します。 public function scopeOfType(Builder $query, string $type): Builder { return $query->where('role', $type); } }
実行
定義したスコープを使い、primeなユーザー数数を取得します（想定では3人）。
<?php logger(User::OfType('prime')->count());
出力結果
[2019-05-06 09:21:46] testing.INFO: Query Time:20.1ms] select count(*) as aggregate from `users` where `role` = ? [2019-05-06 09:21:46] testing.INFO: array ( 0 => 'prime', ) [2019-05-06 09:21:46] testing.DEBUG: 3
このように、roleカラムを対象にprimeで絞っており、結果が3である事も確認できました。
もちろん、User::OfTypeに'user'を渡せば、roleを対象にuserで絞る事ができます。
<?php logger(User::OfType('user')->count());
[2019-05-06 09:39:39] testing.INFO: Query Time:17.09ms] select count(*) as aggregate from `users` where `role` = ? [2019-05-06 09:39:39] testing.INFO: array ( 0 => 'user', ) [2019-05-06 09:39:39] testing.DEBUG: 6
検証3：作成したスコープの合わせ技
実行
作成した2つの function を合わせて使用し、アクティブでroleがuserのユーザー数を取得します。（想定は4人）
合わせる時は単純に繋げて使用する事ができます。
<?php logger(User::Active()->OfType('user')->count());
出力結果
[2019-05-06 09:43:51] testing.INFO: Query Time:17.5ms] select count(*) as aggregate from `users` where `is_active` = ? and `role` = ? [2019-05-06 09:43:51] testing.INFO: array ( 0 => true, 1 => 'user', ) [2019-05-06 09:43:51] testing.DEBUG: 4
is_activeおよびroleカラムを対象に絞り、結果が4である事を確認できました。
感想
スコープの名称（function 名）を適切なもので定義する事で、その実装がどういうデータを取得してこようとしているか、判断しやすくなるなと感じました。 むしろ判断しやすくなるようなスコープを定義する必要があるかもしれません。
また、例えばあるカラムの名前を変更する事になった場合、そのカラムを利用するクエリ（例：where('カラム名', $value)）を、スコープの中に閉じ込めておくことで、ソースコードの修正も容易になるのかなと思いました。
スコープを積極的に使用して、メンテナンス性の高いモデルを実装していきたいなと思いました。
