エンジニア立ち居振舞い: なぜ必要なのかをちゃんと聞く

お題「エンジニア立ち居振舞い」

なぜ必要なのかをちゃんと聞く

今の主な仕事は社外向けと社内向けのものがあって、今回は後者の話。

いわゆる「社内ツール」というようなやつで、定形作業の負荷を少しでも減らすとか、誰かの職人芸でなんとかやってる作業を、うまく仕組みにして誰でもできるようにするとか、あとはデータを上手く集めて、ちょっと扱いやすく加工したりとか、そういうこともやっている。

で、社内でそういった困り事を相談してくれる人たちは、当然ながら自分よりも彼らの業務をよく知っていて、そのうえで「こんなことをしたい」という相談をしてくれるし、自分もある程度はその業務がどのように改善されるかとか、どんな設計にしたらいいか、どんなデータを集めてあげればいいかは想像がすることができる程度の業務知識はあるけど、そういった話のなかですっぽりと抜け落ちることがあるのが「なんでそれが必要なのか」じゃないかと思う。

自分はせっかちなので、「なるほど。そういうことね」とか、「あ、これでいける」と思ったらすぐに手を動かしてしまいたくなる。そういうときこそ、ちょっと意識的に「なんでそれがあると嬉しいんだろう?なんで必要なんだろう?」というのを、ここ数年は考えたり、直接聞いてみたりするようになった。

「なぜ必要なのか?」と改めて聞いてみると、自分のイメージ通りだったりもするし、ズレてた認識を修正できるかもしれないし、それはすでに別のツールがカバーしている問題かもしれないし、もしかしたら、もっと別の大きな課題が今の状況を引き起こしていることに気づくかもしれない。特に最後に挙げたようなものが見つかれば儲けものだ。

「ユーザーは自分が何を求めているか、ユーザー自身はそれを本当に知っているのか?」というのを、この前プロダクトマネージャーカンファレンスでも聞いた気がする。ちょっとした社内ツールでも、「なんでそれが必要なのか?」を(社内の)ユーザーから引き出し、エンジニアとして彼らの困り事を本当に解決するものを作っていきたいなと思っている。

re:dashでよく使われているクエリーを調べる

re:dashのFork機能はすごく好きなんだけど、便利すぎて気軽にForkされる結果、使ってるのか使ってないのかわからないクエリーが増えてしまいがち。

qiita.com

この記事をみたら統計情報っぽいのが取れるようなので、ちょっといじって以下のようにした。

使用しているバージョンは 0.10.1+b1836

SELECT 
  object_id AS query_id, 
  SUM(CASE WHEN action = 'view' THEN 1 ELSE 0 END) AS view,
  SUM(CASE WHEN action = 'execute' THEN 1 ELSE 0 END) AS execute
FROM 
  events 
WHERE 
  object_type = 'query' 
  AND object_id != ''
  AND created_at BETWEEN to_date('2016-11-01', 'YYYY-MM-DD') AND to_date('2016-11-17', 'YYYY-MM-DD')
GROUP BY 
  object_id 
ORDER BY 
  execute DESC;

結果はこんな感じ。

object_id | view | execute
-----------+------+---------
 78        |  125 |      99
 68        |  123 |     106
 87        |   68 |      66
 79        |   68 |      55
 85        |   68 |      42
 103       |   63 |      50
 107       |   59 |      43
 8         |   58 |      13
 89        |   53 |       7
 125       |   52 |      28
 109       |   48 |      21
 104       |   44 |      11
 112       |   39 |      21
 100       |   39 |      19
 115       |   31 |       2
 122       |   25 |       9

この結果をみて、使用頻度の低いクエリーは積極的にアーカイブすることができそう。

おまけ

events テーブルはこんな感じ。

                                        テーブル "public.events"
          列           |            型            |                       修飾語
-----------------------+--------------------------+-----------------------------------------------------
 id                    | integer                  | not null default nextval('events_id_seq'::regclass)
 org_id                | integer                  | not null
 user_id               | integer                  |
 action                | character varying(255)   | not null
 object_type           | character varying(255)   | not null
 object_id             | character varying(255)   |
 additional_properties | text                     |
 created_at            | timestamp with time zone | not null
インデックス:
    "events_pkey" PRIMARY KEY, btree (id)
    "events_org_id" btree (org_id)
    "events_user_id" btree (user_id)
外部キー制約:
    "events_org_id_fkey" FOREIGN KEY (org_id) REFERENCES organizations(id)
    "events_user_id_fkey" FOREIGN KEY (user_id) REFERENCES users(id)

action, object_typeにはこんな値が入っていた。

action

add_data_source
add_member
api_get
archive
autorefresh
cancel_execute
change_data_source_permission
create
delete
edit
edit_description
edit_name
execute
execute_query
fork
login
pivot
remove_data_source
remove_member
search
update
update_data_source
view
view_source

object_type

dashboard
data_source
datasource
group
group_data_sources
page
query
redash
user
visualization
widget

プロダクトマネージャーカンファレンスに参加しました

10/24,25の両日開催されたプロダクトマネージャーカンファレンスに参加してきました。

pmconf.jp

参加を直前で決めたこともあり、たびたび帰社して打ち合わせを済ませてから会場に戻ったりしていたので、Pokemon GOをやっていればたまご2つぐらい孵せたと思います(電池がなくなると困るので控えました

なぜ参加したのか

私の職種は肩書上「ソフトウェアエンジニア」なのですが、今の仕事をしてからずっと一つのプロダクトに関わっています。

物言いたがりな性格もあって、これまでもプロダクトの方向性について議論するのが好きだったのですが、最近になってプロダクトマネージャー的な役割も担うことになったため、まずはインプットを増やしたいなという気持ちで参加しました。

もちろんプロダクトマネージャーという役割については興味があって、興味をもったきっかけはRebuild.fmのこのエピソードあたりだったと思います。通勤長いしまた聴き返そうかな。

rebuild.fm

rebuild.fm

セッションの感想

いろいろな方が記事を書かれていますし、Togatterにもまとまっているので、内容についてはそちらを読んでいただくのがよいと思います。

そのうち発表資料をまとめて公開されるような話もされていたような気がします。

togetter.com

個人的にはfreeeの佐々木さん、クックパッドの池田さん、Increments 及川さんとNiantic 河合さんのセッションは特に共感するところが多かったような気がします。

及川さんと河合さんのセッションについては、終了後のAsk the speakerコーナーが大行列になったことを受けて、ランチタイムを返上してのセッション延長というのが胸熱な展開で、柔軟な対応が本当に嬉しかったし、いいランチタイムになりました。その場の熱量をうまく力に変えていくのがPMの本懐なのかなーと、運営のみなさまからも感じるものがありました。

他にもTwitterを眺めていると聞きたかったな。。と思うようなセッションが多かったのですが、そういうタイミングに見事なまでに打ち合わせがぶつかっていたので、あとで資料を読み返したいなと思っています。

セッション中の撮影について

このカンファレンスはセッション中の撮影について明確にルールが提示されていました。ここまでいい意味で徹底的にやるのは初めてだったかもしれません。

カメラのシャッター音は本当に耳障りですし、話している側も聞いている側も気分がいいものではないので、セッションに集中するためにもそういった取り組みをされていたのかなと思います。

(それなのにシャッター音が時折聞こえたのは、しっかりとルールを守る方が多かっただけに残念でした。。

アンカンファレンス

せっかく参加したんだし、なんか話してみたいなと思って、1日目の帰りがけにアンカンファレンスに応募してみました。

発表では、ここ最近の体験や、これからどうしようかなーと考えていたことをただただお話した感じになります。あとからスライド読んでも全然伝わらないですね。。

かなりの釣りタイトルで申し訳ないなーと思いながらも、集まっていただいた皆様には本当に感謝しています。すごくうれしかったです。

speakerdeck.com

発表のあとは他のブースをまわってみたりしていたのですが、ペパボのいのうえさんの発表が特によかった。

いいフィードバックを受けるための仕組みを作るというような内容で、すでにご本人による記事も公開されていたので、スライドは貼らずに記事のリンクだけ貼っておきます。

blog.inouetakuya.info

Networking Party

ぼっちを避けるためという目的もあってアンカンファレンスで発表した結果、多くの方に声をかけていただきました。

アンカンファレンスでお話した、使われなくなった機能とどうやって付き合っていくか?というような実践的な話もしつつ、プロダクトという共通の関心事について初対面の方といろいろ議論できたおかげでとても有意義な時間を過ごせました。

まとめ

もちろん参加前から期待はしていたのですが、期待通りに濃い内容のカンファレンスだったなと改めて思います。

各社のPMがまったく違ったプロダクトに関わりながらも、共通の価値観を持っていたり、プロダクトやチームの特性にあわせた独自の判断基準があったりするなかで、

それをある意味「ぶつけ合う」ような2日間だったと思います。

運営のみなさま、登壇者のみなさま、私の発表を聞いてくださったり、懇親会で声をかけていただいたみなさま。ありがとうございました!

SpecinfraでリモートホストのOS情報を知る

使ってみようと思ったきっかけ

とある事情で社内で使用している数多のサーバーのOS情報をまとめたりしたくなったのでSpecinfraについて調べました。

github.com

使い方を調べる

検索しても参考になりそうな記事は少なく、この記事を参考にして書き始めました。

qiita.com

が、追記に内容が古いと書かれているとおり、このままでは動作しませんでした。

なんとか動かすことができた

Specinfraのコードを読みつつ、サンプルコードを読みつつ修正をしていたら、参考にしていた記事とは全く別物になりましたが、なんとか動かすことができました。

モジュール名がSpecInfraからSpecinfraに変わっていることに気づかなかったのが最大のハマりポイントだった気がします。

参考にしたコードの一部

specinfra/multiple_backends.rb at master · mizzy/specinfra · GitHub

specinfra/specinfra.rb at master · mizzy/specinfra · GitHub

specinfra/base.rb at master · mizzy/specinfra · GitHub

specinfra/ssh.rb at master · mizzy/specinfra · GitHub

サンプルコード

Vagrantっぽい接続情報になっていますが、ホストなどは適宜書き換えていただければリモートホストでも動作すると思います。

SSHの接続情報まわりはNet::SSHで使えるものが、そのまま使えるようです。

net-ssh 4.0.0.alpha2

require 'specinfra'

ssh_options = {
  host_name: 'localhost',
  user: 'vagrant',
  port: 2222,
  keys: ['~/.ssh/id_rsa'],
}

backend = Specinfra::Backend::Ssh.new(
  host: ssh_options[:host_name],
  ssh_options: ssh_options,
  disable_sudo: true,
)

p backend.os_info

実行してみる

Bundlerを使ったので bundle exec で実行します。

$ bundle exec ruby os_info.rb
{:family=>"ubuntu", :release=>"14.04", :arch=>"x86_64"}

感想

諸事情によりサーバーの環境がバラバラだったりするので、こういった方法で自動的にサーバーの情報を集めることができれば、辛い台帳管理などしなくてもよくなりそうだなと思って試してみました。

思ったほどハマらずに動作確認できたので、さっそく実践投入するつもりです。

Qiita/Qiita:teamの記事をJSON Lines形式で取得するqiitadumpを作った

最近ははてなブログに引っ越したのでQiitaをあまり使わなくなってしまったけど、過去に書いた記事や、社内で利用しているQiita:teamの記事をElasticsearchに入れて遊んだりするときに便利そうだと思ったので作ってみました。

github.com

使い方

準備

Qiitaのアクセストークンが必要なので、このあたりを参考に。権限は read_qiitaread_qiita_team があればいいでしょう。

qiita.com

インストール

$ go get -u github.com/ariarijp/qiitadump

実行

アクセストークンを指定して以下のように実行します。

$ qiitadump -token YOUR_ACCESS_TOKEN > dump.json

デフォルトでは20件取得しますが、 -limit オプションで件数を変更できます。

Qiita:teamの記事を取得する場合は以下のように -host を指定して実行します。

$ qiitadump -token YOUR_ACCESS_TOKEN -host teamname.qiita.com > dump.json

出力されるJSONの形式はQiitaのAPIドキュメントのとおりです。

qiita.com

この他にもいくつかオプションがありますが、詳しくはREADMEをご覧ください。