エンジニア立ち居振舞い: なぜ必要なのかをちゃんと聞く
なぜ必要なのかをちゃんと聞く
今の主な仕事は社外向けと社内向けのものがあって、今回は後者の話。
いわゆる「社内ツール」というようなやつで、定形作業の負荷を少しでも減らすとか、誰かの職人芸でなんとかやってる作業を、うまく仕組みにして誰でもできるようにするとか、あとはデータを上手く集めて、ちょっと扱いやすく加工したりとか、そういうこともやっている。
で、社内でそういった困り事を相談してくれる人たちは、当然ながら自分よりも彼らの業務をよく知っていて、そのうえで「こんなことをしたい」という相談をしてくれるし、自分もある程度はその業務がどのように改善されるかとか、どんな設計にしたらいいか、どんなデータを集めてあげればいいかは想像がすることができる程度の業務知識はあるけど、そういった話のなかですっぽりと抜け落ちることがあるのが「なんでそれが必要なのか」じゃないかと思う。
自分はせっかちなので、「なるほど。そういうことね」とか、「あ、これでいける」と思ったらすぐに手を動かしてしまいたくなる。そういうときこそ、ちょっと意識的に「なんでそれがあると嬉しいんだろう?なんで必要なんだろう?」というのを、ここ数年は考えたり、直接聞いてみたりするようになった。
「なぜ必要なのか?」と改めて聞いてみると、自分のイメージ通りだったりもするし、ズレてた認識を修正できるかもしれないし、それはすでに別のツールがカバーしている問題かもしれないし、もしかしたら、もっと別の大きな課題が今の状況を引き起こしていることに気づくかもしれない。特に最後に挙げたようなものが見つかれば儲けものだ。
「ユーザーは自分が何を求めているか、ユーザー自身はそれを本当に知っているのか?」というのを、この前プロダクトマネージャーカンファレンスでも聞いた気がする。ちょっとした社内ツールでも、「なんでそれが必要なのか?」を(社内の)ユーザーから引き出し、エンジニアとして彼らの困り事を本当に解決するものを作っていきたいなと思っている。
re:dashでよく使われているクエリーを調べる
re:dashのFork機能はすごく好きなんだけど、便利すぎて気軽にForkされる結果、使ってるのか使ってないのかわからないクエリーが増えてしまいがち。
この記事をみたら統計情報っぽいのが取れるようなので、ちょっといじって以下のようにした。
使用しているバージョンは 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の両日開催されたプロダクトマネージャーカンファレンスに参加してきました。
参加を直前で決めたこともあり、たびたび帰社して打ち合わせを済ませてから会場に戻ったりしていたので、Pokemon GOをやっていればたまご2つぐらい孵せたと思います(電池がなくなると困るので控えました
なぜ参加したのか
私の職種は肩書上「ソフトウェアエンジニア」なのですが、今の仕事をしてからずっと一つのプロダクトに関わっています。
物言いたがりな性格もあって、これまでもプロダクトの方向性について議論するのが好きだったのですが、最近になってプロダクトマネージャー的な役割も担うことになったため、まずはインプットを増やしたいなという気持ちで参加しました。
もちろんプロダクトマネージャーという役割については興味があって、興味をもったきっかけはRebuild.fmのこのエピソードあたりだったと思います。通勤長いしまた聴き返そうかな。
セッションの感想
いろいろな方が記事を書かれていますし、Togatterにもまとまっているので、内容についてはそちらを読んでいただくのがよいと思います。
そのうち発表資料をまとめて公開されるような話もされていたような気がします。
個人的にはfreeeの佐々木さん、クックパッドの池田さん、Increments 及川さんとNiantic 河合さんのセッションは特に共感するところが多かったような気がします。
及川さんと河合さんのセッションについては、終了後のAsk the speakerコーナーが大行列になったことを受けて、ランチタイムを返上してのセッション延長というのが胸熱な展開で、柔軟な対応が本当に嬉しかったし、いいランチタイムになりました。その場の熱量をうまく力に変えていくのがPMの本懐なのかなーと、運営のみなさまからも感じるものがありました。
他にもTwitterを眺めていると聞きたかったな。。と思うようなセッションが多かったのですが、そういうタイミングに見事なまでに打ち合わせがぶつかっていたので、あとで資料を読み返したいなと思っています。
セッション中の撮影について
このカンファレンスはセッション中の撮影について明確にルールが提示されていました。ここまでいい意味で徹底的にやるのは初めてだったかもしれません。
カメラのシャッター音は本当に耳障りですし、話している側も聞いている側も気分がいいものではないので、セッションに集中するためにもそういった取り組みをされていたのかなと思います。
(それなのにシャッター音が時折聞こえたのは、しっかりとルールを守る方が多かっただけに残念でした。。
アンカンファレンス
せっかく参加したんだし、なんか話してみたいなと思って、1日目の帰りがけにアンカンファレンスに応募してみました。
貼っておいた。字が汚い。 #pmconfjp pic.twitter.com/uieJHt21Fs
— Takuya Arita (@ariarijp) 2016年10月24日
発表では、ここ最近の体験や、これからどうしようかなーと考えていたことをただただお話した感じになります。あとからスライド読んでも全然伝わらないですね。。
かなりの釣りタイトルで申し訳ないなーと思いながらも、集まっていただいた皆様には本当に感謝しています。すごくうれしかったです。
並びを見て、最悪の場合は会場の空気に向かって話すシミュレーションしてる https://t.co/JPXqSEdkzc
— Takuya Arita (@ariarijp) 2016年10月25日
#pmconfjp のアンカンファレンスで発表しました。読み返す価値はあんまりないけど、記録としてアップロードしておく。 / 使われない機能 https://t.co/GkVyGftVfa
— Takuya Arita (@ariarijp) 2016年10月25日
発表のあとは他のブースをまわってみたりしていたのですが、ペパボのいのうえさんの発表が特によかった。
いいフィードバックを受けるための仕組みを作るというような内容で、すでにご本人による記事も公開されていたので、スライドは貼らずに記事のリンクだけ貼っておきます。
Networking Party
ぼっちを避けるためという目的もあってアンカンファレンスで発表した結果、多くの方に声をかけていただきました。
アンカンファレンスでお話した、使われなくなった機能とどうやって付き合っていくか?というような実践的な話もしつつ、プロダクトという共通の関心事について初対面の方といろいろ議論できたおかげでとても有意義な時間を過ごせました。
いろんな方に話しかけていただいて、アンカンファレンスで発表してよかったー!という気持ちになりつつ会場をあとにします #pmconfjp
— Takuya Arita (@ariarijp) 2016年10月25日
まとめ
もちろん参加前から期待はしていたのですが、期待通りに濃い内容のカンファレンスだったなと改めて思います。
各社のPMがまったく違ったプロダクトに関わりながらも、共通の価値観を持っていたり、プロダクトやチームの特性にあわせた独自の判断基準があったりするなかで、
それをある意味「ぶつけ合う」ような2日間だったと思います。
運営のみなさま、登壇者のみなさま、私の発表を聞いてくださったり、懇親会で声をかけていただいたみなさま。ありがとうございました!
SpecinfraでリモートホストのOS情報を知る
使ってみようと思ったきっかけ
とある事情で社内で使用している数多のサーバーのOS情報をまとめたりしたくなったのでSpecinfraについて調べました。
使い方を調べる
検索しても参考になりそうな記事は少なく、この記事を参考にして書き始めました。
が、追記に内容が古いと書かれているとおり、このままでは動作しませんでした。
なんとか動かすことができた
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で使えるものが、そのまま使えるようです。
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に入れて遊んだりするときに便利そうだと思ったので作ってみました。
使い方
準備
Qiitaのアクセストークンが必要なので、このあたりを参考に。権限は read_qiita
と read_qiita_team
があればいいでしょう。
インストール
$ 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ドキュメントのとおりです。
この他にもいくつかオプションがありますが、詳しくはREADMEをご覧ください。