【感想】仕事の速度と精度を上げるために「仮説思考」を読んでみたら目から鱗だった話。
皆さんこんにちは。管理人のPaZooです。
エンジニアとして働き始めて早数年が経ちますが、仕事に向かっても時間ばかりが経過してしまい成果が思うように出ないことが多いのが悩みでした。
そんなときに出会った本が「仮説思考 BGC流問題発見・解決の発想法」です。この本を読んだ感想について簡単にまとめていきます！
本書の要点
1. 仮説とは、情報収集の途中や分析作業以前にもつ「仮の答え」のこと。そして、仮説思考とは、情報が少ない段階から、常に問題の全体像や結論を考える思考スタイル、あるいは習慣というべきもの。
2. 仮説思考を身に付ければ、わずかな情報でも初期段階で分析することができる。
こんな人におすすめ
- 物事を始めるときに情報を集める人
- 失敗を恐れてしまい、完璧な答えを出したがる人
- 分析するにも時間が足りなくなってしまう人
どんな本なの？
迅速に問題を発見・解決していくための思考法についての本です。例えばですが、あるテーマに取り組むときを考えてみてください。
まずテーマに対して網羅的に情報を集めるとなると、資料の収集に時間がかかったり情報洪水に飲まれてしまうケースがあるため、結果的に仕事で思うように成果を上げることが難しくなりがちです。
そこで、「まずは少ない情報から仮説を立てて検証するというスタンスで仕事を進めていくと素早くテーマの本質に迫ることができるようになるよ！」というのがこの本から学ぶことができます。
仮説思考を身に付けるメリット
ここで、私の失敗談をお話したいと思います。
現場である企画を提案するために、プレゼン資料を作ることになりました。
まずはあらゆる情報を集めて資料を作成しようとしたのですが、膨大な情報と分析に時間がかかってしまい結局最後まで分析できずにタイムアップしてしまいました。
今となってはいい経験でしたが、思い出してみるとかなり恥ずかしいです。
きちんと目的を決めないまま仕事に取り組んでしまったので、成果としてどのような解決策を出す必要があるのか結論を導き出せずに終わった苦い思い出です。。。
この時に、仮説思考で結論から考えれば良かったのです。
具体的に言うと、先にプレゼン資料の目的を決めて(例えば顧客を増やす等)、それの裏付けになりそうな情報を収集する。
こうすれば締め切りまでに満足のいく資料を作成することができたかもしれません。また、裏付けが取れる情報がなかった場合すぐに別の仮説を立てて検証していく時間もあったと思います。
仮説思考を身に付けることで得られるメリットは、問題を素早く捉え解決に対して仮説を立てながらスピーディーに検証を行うことで結論を出す速度が早くなることだと私は思います。
私の最強上司も「資料で何を伝えたいのか、まずはストーリーから考えて！」と言われてましたが、今思えばこの発言そのものが仮説思考だったのです。さすがだなあ。
本を読んだ感想
個人的に、とても満足いく書籍でした。
仕事の課題や問題を解決するために問題点をすべてピックアップするのではなく、答えを「仮定」することで仮説に対して検証を進めていく。
これを繰り返して行くことでよりスピーディーに、より質の高い解決を実現することができます。
私自身、この本と出会うまで「網羅思考」タイプの人間だと自負していました。
まずは情報から！と情報を集めてみたのはいいけれど、問題点をすべてピックアップしていくとどの問題に対してアプローチをかけていくのか意思決定が遅くなるため成果を出すのに時間がかかりがちでした。
しかし、この本と出会ってからというもの、一つの仮説に対して検証をするために情報を集めてみたりヒアリングしたり検証を繰り返すことでブラッシュアップされていきよりスピーディーに、より生産性を向上させることができつつあると感じています。
出会ってよかった。ありがとう、仮説思考！
まとめ
実例も多く取り上げられており、実践的に使える知識を学ぶことができる「仮説思考」をご紹介させていただきました！
ちなみに、同じ著者より「論点思考」という本も出ておりましてそちらも非常にお勧めですよ！！
この投稿を機に、本が気になった方はぜひ読んでみてください！
見てる割合と反応している割合がほぼ1割なので自分の投稿について整理してみた話。
どーも皆さんこんばんわ。管理人のPaZooです。
さて、今回書いていく内容は「閲覧数から見るアクション率について考えてみた」というお話です。
気になった背景と概要
今回の気になった背景として、自社用SNSを活用している中で閲覧数から見たときのアクション率を算出しているのですが毎回1割なんです。
その数値を見るたびに思うのです。なして1割なん？？？と。
約500名閲覧したら50名は反応してくれます。もちろん投稿するスレッドが違えばリーチ数も変わってきますが、ここでは大多数が閲覧できるスレッドでの閲覧数をリーチ数としています。
下記の計算式はアクション率を算出する式です。
| アクション率＝（いいね！数＋コメント数＋シェア数＋クリック数）÷リーチ数 |
ここで言うアクションとは、「いいね！」やコメント、シェア数、画像やURLなどのクリック数のこと。つまり、投稿に対するリアクション(＝ユーザーが起こした行動)ということです。
また、計算式の最後にある「リーチ数」は、実際に投稿を見た人数を指します。投稿がどれだけユーザーの行動を喚起させたのかを知る目安になるので、投稿内容の改善や検討材料として役立つことが多いです。
つまり、アクション率を見れば、リーチされた人の何割がアクションを起こしたのかがわかりますね。ちなみに平均アクション率は0.5%～2％なので、自分の投稿に対するアクション率はやや低いように思えます。
アクション率から自分の投稿について考えてみた
「なんでアクション率なんか気になるの？？」という声が聞こえてきそうですねｗ
なぜ気になるのかですって？そりゃ皆さんに良いコンテンツを届けるためですよ！…というのも理由としてありますが、自分の投稿が周りに対してどんな影響を与えているのか気になるからです。
周りがどんな反応をするのか考えずに投稿するのは、あまり意味のないことのように感じます。
アウトプットの練習だったり、ネタや知識を共有することはエンジニアとして大事なところ。しかし、ただ発信するだけではアウトプットとは言えないように思うのです。(最近思ってきただけなのですが…ｗ)
自分が得た知見に対しての感情や経験をプラスαすることで、ほかにはない素晴らしいコンテンツになるのではないかと思います。
アクション率を上げる方法をまとめてみた
アクション率を上げるには、結論からいくと「ユーザーを喜ばせる良質な投稿」と「アクションを起こしやすくする仕組みづくり」を心がけることだと考えました。
やっぱり興味のある投稿だったり、一目見て何を伝えたいか分かりやすいほうがいいですよね！
| ユーザーを喜ばせる良質な投稿をするためには？ |
- どんな人に伝えたいのかペルソナの設定を行うことで、ニーズを捉えやすくする
- 一貫性のある投稿でファンの心を掴む
- 飽きられないコンテンツ発信をする
技術寄りな投稿が多いのですが、技術に興味がある人もいれば興味がない人もいるのでアクション率が低いことは見て取れます。
飽きられないコンテンツを発信するというのは、動画を取り入れたり旬のネタを取り入れたりすることだと解釈しています。
誰にでもウケるコンテンツを作るのはとても難しいですね…。
あと、考えたのは「私のことを知らない人にとってアクションすることは難しいのではないか」ということ。私自身のことを知らない人からすれば、どんな人なのかも見えない状態でアクションを起こそうとは思わないなあと。。
私からアクションを起こすことで、向こうに知ってもらうチャンスが来るというのも今回の分析から見えました。
まとめ
もっとジャンル別にアクション率を取れば細かい分析ができそうなので、今後も分析していきたいと思います！
皆さんの中で「投稿するときはこんなことを気を付けている」というのがあればぜひ教えてください！
それでは。
July Tech Festa 2020に参加してきたのでレポートがてら書いてみる
皆さんこにゃにゃちわ、PaZooです。
四連休最終日ですね。私は応用情報の勉強を進めていますが、離散数学がさっぱりです('ω')
今日はインフラエンジニアの祭典 July Tech Festa 2020参加レポートと題してブログを書きました！
いや～～本当に良かった。めっちゃ勉強になったので、ぜひ次回も参加したいです。
- はじめに
- 常松祐一さん：組織に良い開発文化を植え付ける「Software Engineering Coach」という役割
- 小倉真人さん：組織企業グループを超えたエンジニアのつながりを広げるイベントをしている話。
- まとめ
はじめに
エンジニア歴3年生なので、インフラエンジニアの祭典 July Tech Festa 2020に参加してきました。
新型コロナウイルスの懸念もあり、なんとフルオンラインでの開催！場所や時間も制限されないような環境が整っていたので個人的にはかなり良かったです。アーカイブがYouTubeで配信されているので当日参加できなかった方はぜひご覧ください！
(可能であれば、今後もYouTube配信をやっていってほしいです…!)
さて、今年のテーマが「Extend Your Engineering Life」ということで、カテゴリー的には自分のキャリア観についての話が多かったように感じました。
その中でも特に印象に残っている方のレポートを書き連ねていきます。
常松祐一さん：組織に良い開発文化を植え付ける「Software Engineering Coach」という役割
常松さんのお話は、特に開発者とPMに聞いてほしい内容でした。
「良いソフトウェア開発」から考えさせられ、良いソフトウェア開発を行うためにはどうすれば良いのか。
その中で、より良い開発プロセスを組織に植え付ける役割である「Software Engineering Coach」に出会ったことで自分が組織の中でどう立ち回るべきか考えたこと。
TeachingとCoachingの違いも共感の嵐でした！
- Teaching：上下の関係性で答えを教えるため、相手は受動的になる
- Coaching：対等の関係で相手の中にある答えを導くため、相手は能動的になる
確かにそれ。とてもわかる。
とはいえ自分がCoachingできているかと聞かれると首を縦には触れないので精進あるのみです。トホホ。
常松さんのお話の中で一番共感したのは「PMだから～だからとか役割に関係なくアイデアを提案して良い開発プロセスを根付かせていく」というところでした。
シンプルに問題をとらえ、解決する。そして、日々の業務の中でアイデアを見つけみんなに共有していく。
このサイクルは開発者にとって前に前に進んでいけるような言葉でした。強く残っています。がんばろ。
↓SpeakerDeckのリンクはっておきます。
小倉真人さん：組織企業グループを超えたエンジニアのつながりを広げるイベントをしている話。
小倉さんのお話は、「エンジニアのイベントについて」でした。
NTTグループで勤めていらっしゃる小倉さんが、エンジニアのための勉強会を内部から外部に向けて開催するときにどんなことを考え、どんなことに注意を払っているのかを簡潔にお話してくださりました。
NTTグループといったら知る人ぞ知る大企業ですが、いくつもの事業に分かれていて担当している内容も全く異なるそうです。
同じ会社なのに接点も交流もない…そんな中で作られたのが「NTT Tech Conference」や「NTT Enginier’s Festa」だそう。
会社で勉強会は行われず、支援も期待できない。
そんな中で自分たちの知識をより広げ、交流を行うためにイベントを開催する運びになったとのことでした。
私自身も社内でイベントを開催する機会が多いので、小倉さんのお話はとても参考になりました。
- 目的
- 開催する時期
- 予算
- コンテンツ
- 参加者へのアンケート内容の検討
- 運営スタッフでの振り返り
上記の内容はかなり共感するところがありました。
特に、参加者へのアンケート内容の検討や運営スタッフでの振り返りというところは現状できていないところでしたので次から真似してみようと思います！
↓SpeakerDeckのリンクはっておきます。
まとめ
今回、初めてJTFに参加しましたがとても刺激を受けました。
色んな人の知見を聞いて自分の経験にしたり、作成された資料の構成を見たり話し方を見てプレゼンテーションのやり方を盗んだりかなり勉強になるので、やっぱり定期的にこんな感じのイベントに進んで参加していきたいと思いました。
業務ばかりだと、どうしても周りが見えなくなってしまうので自分のエンジニアリングを鍛えるためにもこれからも学び続けます！
【SQLserver】大量のデータを爆速にinsertする方法
こんにちは、管理人のPaZooです。
性能調査など負荷試験を行う時に、SQLServerのテーブルに大量のデータをinsertするケースがありましたのでその時に調べた内容を記事にしました。
データを大量に作成するとなると時間がかかって大変でしたが、とても良い経験になりましたのでお役に立てれば幸いです。
テスト環境を整える
まずは実行する環境を整えます。
【実行環境】SQL Server2019 Express(64bit)
サンプルデータベースの作成
テスト用にまずはデータベースを作成します。データベースの作成は下記の記事が分かりやすかったので、ぜひ参考にされてください。
私はサンプルデータベースとして、「mstDB」を作成しました。
サンプルテーブルの作成
では次に、サンプルデータを格納するためにサンプルテーブルの作成を行います。
USE [mstDB] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [usrDB].[test_usertbl]( [id] [int] NOT NULL, [Name] [nchar](15) NOT NULL, [RegDate] [date] NOT NULL, CONSTRAINT [PK_usertbl] PRIMARY KEY CLUSTERED ( [id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO
ループを使ってレコードを作成するクエリ
まずは単純にループするだけのクエリを作ってみました。
SET NOCOUNT ON
DECLARE @insertNumber INT
SET @insertNumber = 0
WHILE @insertNumber < 1000000
BEGIN
INSERT INTO [mstDB].[usrDB].[test_usertbl] (
[id]
,[Name]
,[RegDate]
)
VALUES
(@insertNumber ,
'test'
, GETDATE())
SET @insertNumber = @insertNumber + 1
END
ループ処理でデータをinsertした結果、なんと5分もかかりました…。
100万件で5分なので、もし1000万件のレコードを作成するならば単純に考えても50分はかかります。
さらにカラム数が多い場合やデータ件数が増えてしまうと、より性能面で不安を感じますね…。こんなクエリは検証環境でも実行したくありません。。。
再帰SQLで大量のテストデータをinsertする
再帰SQLとは、前に行った処理の結果を利用し同じ処理を繰り返す場合に使われます。
今回はwith句を使っています。with句とは、メインクエリの中で同じクエリを何度も呼び出す場合に使用されます。
下記のクエリを管理人の環境で実行したところ、20秒ほどで100万件のデータをinsertできました！
USE [mstDB] GO DECLARE @insertNumber Bigint -- INSERTする行数 SELECT @insertNumber=1000000; -- 100万に設定 WITH Base AS ( SELECT 1 AS n UNION ALL SELECT n + 1 FROM Base WHERE n < @insertNumber ), Nums AS ( SELECT Row_Number() OVER(ORDER BY n) AS n FROM Base ) INSERT INTO [mstDB].[usrDB].[test_usertbl] SELECT n , 'test' , GETDATE() FROM Nums WHERE n <= @insertNumber OPTION (MaxRecursion 0); -- 再帰SQLの再帰回数の上限を無制限にする
ちなみに再帰SQLでは、再帰回数を指定していない場合に無限ループを考慮し、再帰可能上限値の規定値が100となっています。
ですので、上限最大値を変更するためには「MaxRecursion」を指定してください。
MaxRecursionで設定できる値は、「0」から「32,767」までとなっており「0」は上限なしです。
今回は100万件のレコードを作成するために、インクリメントさせてます。
まとめ
100万件のデータを扱うとなると性能面を最も気にしなきゃいけないので、今回調べた再帰クエリはとても勉強になりました！
データを更新するときにも使えるので、大量のデータを扱う際はぜひ再帰SQLを使ってみてはいかがでしょうか？
【DBflute】DBの変更に強いDBflute！特定のTBLだけ実行したい場合の方法！
皆さんおはようございます、管理人のPaZooです。
緊急事態宣言ももう少しで解除となりますが、気を引き締めたいところですね。
さて、話が逸れてしまいましたが今回は「DBfluteで指定したTBLに対して実行したい時の方法」を書き残そうと思います。
DBfluteとは
DBへの接続をしてくれるORマッパーのフレームワークです。
このフレームワークの特徴として、「DBの変更に強いこと」が挙げられます。
DBのEntityを読み込み、対応するクラスとメソッドを自動生成してくれる優れもの！
DDLを修正することなくレコードの取得 や更新、追加、削除を行うことが可能です。
基本的な使い方は、公式ドキュメントが最&高で分かりやすいのでリンクを記載しておきます。
特定のTBLに対して実行したい場合
DBfluteの基本的な動きについて先ほど説明させていただきました通り、デフォルトで全てのTBLに対して自動生成します。
そんな時に、ある特定のTBLに対してのみ実行したい場合など細かい設定を行いたい場合について手順をまとめてみました。
対象ファイル：databaseInfoMap
スキーマのメタ情報を取得する上での接続情報や細かい設定を行うDBfluteのプロパティです。
DBfluteクライアントのdfprop配下にある「databaseInfoMap.dfprop」という名前のテキストファイルが対象ファイルです。
必須プロパティとなっており、接続情報に関しては"自動生成実行前"に設定されることを前提としています。
ちなみにMap型のプロパティです。
自動生成対象のオブジェクトを記載するのは、「objectTypeTargetList」というリストを持つプロパティに記載してください。
TBLだけでなく、ViewもTBLと同じように扱うことが可能です。ちなみにこんな感じ。
; variousMap = map:{
; objectTypeTargetList = list:{TABLE ; VIEW ;}
}また、自動生成対象から除外したい場合は「tableExceptList」に対象TBL名を記載してあげると除外されます。
tableExceptListでは正規表現を使うことができるので、非常に便利です。
基本的に大文字小文字の区別はなく、tableTargetList(自動生成対象リスト)に記載されている場合は、tableExceptListに記載しても無効となります。
DBfluteは特定のカラムを自動生成対象から除外すれば自動生成されなかったりと、プロパティ設定でかなり自由が効きますので知識として知っておくと開発が楽になりますよ！
まとまらないまとめ
DBflute is God！！！
【SQLserver】トリガーについて
こんにちは、管理人のPaZooです。
トリガーとは、何かのイベントをきっかけに実行される特殊なストアドプロシージャです。
SQLserverのトリガーには、ログオントリガー、DDLトリガー、DMLトリガーの3種類があります。
今回は、トリガーについて調べてみました。
ログオントリガー
ログオントリガーは、ログオン時にユーザーセッションが確立される時に実行されます。
例えば、ログオントリガーを使って「既にセッションが確立されているユーザーが、他のセッションでログオンしようとした場合は拒否する」というようなことが可能です。
DDLトリガー
DDL(Data Definition Language)トリガーは、CREATE・ALTER・DROPステートメントのようなDDLイベントと呼ばれるデータベースのスキーマを変更するようなイベントをきっかけに実行されます。
DMLトリガー
DML(Data Manipulation Language)トリガーは、テーブルやビューに対してINSERTやUPDATE・DELETEステートメントのようなデータの挿入・変更・削除などが起こった時に実行されます。
トリガーを起こしたステートメントと同じトランザクションとして扱われるため、トリガー内でエラーを起こすことによりトランザクションをロールバックさせることもできます。
DMLトリガーを使って、データの変更履歴を残したり特定のカラムに対して変更された時に、他のテーブルの値を更新するなどの追加の処理をしたりすることが可能です。
また、INSTEAD OFを指定することで、元の処理の代わりに別の処理をさせることも可能です。
DMLトリガーについては下記記事でご紹介しておりますので、ぜひご覧ください！
（作成中です）
【SQLserver】権限まわりのクエリを調べてみた
こんにちは、管理人のPaZooです。
最近、DB周りについて調べていて、ユーザー権限を調べることが多いので備忘録としてまとめてみました。
オブジェクトについて
--オブジェクトに読み取り権限を付与する
GRANT SELECT ON オブジェクト名TO ユーザー名またはロール名
--オブジェクトのインサート権限を剥奪する
REVOKE INSERT ON オブジェクト名TO ユーザー名またはロール名
--指定したオブジェクトの権限一覧を表示する
SELECT
OBJECT_NAME(major_id) AS オブジェクト
,USER_NAME(grantee_principal_id) AS ユーザー
,permission_name as 権限名
,state_desc as 権限の状態
FROM sys.database_permissions
WHERE major_id = OBJECT_ID('オブジェクト名')
--指定したユーザー（ロール）の権限一覧を表示する
SELECT
USER_NAME(grantee_principal_id) AS ユーザー
,OBJECT_NAME(major_id) AS オブジェクト
,permission_name as 権限名
,state_desc as 権限の状態
FROM sys.database_permissions
WHERE grantee_principal_id = USER_ID('ユーザー名またはロール名')
ユーザー個々に権限を設定するのは手間すから考えても実用的ではないです。
なので、グループ単位でDBへのアクセス権限を設定する方法を使って制御することも可能です。
その方法については、愛読書(？)である「@IT」様で紹介されているのでこのブログからリンクを送らせていただきます＾＾
まとめ
DB周りはまだまだ自信がありません。。
データの母体なので、もっと勉強せねばです！
