よもやま話β版

よもやま話を書きます

風邪のときどうすればいいのかまだ分かってない

風邪を引いた。熱はそんなにないのだが、喉の痛み、咳、頭痛、全身の倦怠感が症状としてある。 朝に喉がおかしいなと感じたのをきっかけに、その日の午後には頭痛と声がひっくり返ったような高音になってしまうようになった。 あんまり急に体調不良になったので、まさかインフルエンザか、とも思ったが高熱もないし医者にかかったところ喉の風邪と診断をもらった。 とにかくしんどいのを改善したいと思って昼間1日中寝込んでみたが、夕方に起きても頭痛と咳は治っていなかった。

わかりやすく発熱があれば、体温を見て良くなった/悪くなったを比較できるのだが、熱はないので何を指標にしていいか分からない。 今しんどいのが風邪のせいでしんどいのか、寝込み過ぎてしんどいのかいまいち判断できない。 自分にあった鉄板の体調不良の治し方みたいなのを確立したい。

今の所の方法メモ

  • 初期症状時
    • 葛根湯の錠剤を飲む
    • ビタミンが得られるような飲食を行う
  • 本格的にやばくなった時
    • 医者に行って薬をもらう
    • 寝こむ

とりあえず薬飲んでもう一晩寝よう...。

OKRの本を読んだら半分は小説だった話

社長はむちゃくちゃ本をたくさん読んでいて、良いと思ったものが時々社員に向けて課題図書として降ってくる。自分の席には既に4冊ほど積まれている*1のだが、先日最優先としてOKRの本を紹介された。結構読みやすくて、kindleで電車の移動時間などでサクサク読み終われた。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法
https://www.amazon.co.jp/dp/4822255646/ref=cm_sw_r_tw_dp_U_x_ob-WBbP7PKPHG

 

OKRとは何ぞや

Objectives and Key Results の頭文字をとって略したもの。Objectivesは`目標`、Key Resultsは`主な結果` と翻訳されている。

原著タイトル 「Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results」が示す通り、OKRは根本的な部分に注目してゴールを達成することを助けてくれるツールであるようだ。

O(目標)は定性的で、人に刺さるような、心に響くものを1個。

対して、KR(主な結果)は数字ではっきりとわかる定量的なもので、達成がすこし難しそうだと思えるものを2~3個用意する。

具体例はぜひ本を参照してください!

 

どうやって使うか、運用するか

この本にはOKR自体の説明とセットで運用方法の詳しい解説もある。道具を持っていても使い方を間違えていてはうまくいかないので、とても合理的だと思った。

ぱっと書き出してみてもこれだけのエッセンスが詰まっている。

  • OKRの決定方法。チームへの意見の出させ方、まとめ方。付箋を使うなど。
  • OKR設定の粒度。OKRは全社から個人までそれぞれ適用することができる。
  • 4半期のOKRを掲げ、毎週、適切に進んでいるかどうか確認すること。
  • 週で設定する「やらなくてはいけないこと」は2~3個。フォーカスせよ。
  • 実施した結果、現在、KR達成にどのくらいの自信があるかを評価する。
  • OKR達成のためにおろそかにしてはいけないことがちゃんと守れているか確認する。
  • 金曜日にチーム全体で出来たことを共有してお祝いする(ウィン・セッション)。
  • 全体的に前向きな表現、発言、行動になるようにする。
  • 最初は絶対失敗すると思え。

 

50%は小説仕立て

上記で書いたエッセンスの解説は第2部で行われている。

本の第1部として掲載されているものは、架空のスタートアップ企業「ティービー」が苦しみの後にOKRに救われるという筋書きの小説である。ビジネス書では珍しい構成なのでは。

自分は正直なところビジネス書より物語のほうが好きなので、第1部を楽しく読み、第2部の理解に役立てることができたと思う。

 

2人のエンジニア

小説には、物語開始時点から主任プログラマーであるエリック、後半にCTOとなるラファエルという2人のエンジニアが登場する。

 

主任プログラマーエリック

主任プログラマーであるエリックは、ティービーの掲げるビジョンに共感して入社したが、会社が成長のために舵を切っていく方向に不満を持つ。そしてその結果、ソースコードをわざと難しく書き直すという行動にでる。

おいちょっと待て?自分がメンテしてるものを難しくしてくとか自分の首絞めてるだけでは??ん???

立場的に自分はエリックに近いものを感じているが(少人数スタートアップに在籍、プログラマー)、これにはまったく共感できなかった。ソースコードがたとえ難しくなったところで、困るのは自社内のプログラマー達自身であり、サービスを利用しているエンドユーザは使用感さえ変わらなければ気にしないだろう。

とはいえ、長期的に見ると難しいコードは仕様変更に耐えられない、つまりユーザによりよい価値の提供速度が遅れると言えるので、会社にとって間違いなくマイナス要素である。こういう事態をしでかしたエリックがどうなるのかは……お察しください。

 

CTOラファエル

また、物語の後半から突如登場するラファエルは、一見してギークとわかる雰囲気を持ち、これまでもスタートアップで実績をあげてきていて、Googleに在籍した経験があり、上場直後の会社を退職してきて、投資家経由で紹介されたティービーのビジョンを最高に気に入ってジョインしてくる。もちろんOKRの導入のノウハウを充分に持っている。

なんだそれは!?ウルトラCすぎんだろ!!!そんな人がホイホイでてきてスタートアップにジョインしてくれる??は??夢物語か??

ラファエルが出てきたシーンを読んでひとしきりそう思ったあと、あっこれ小説だったわ、ということを思い出した。

 

あくまでも解説書

やっぱりあくまでもOKR解説のための小説なので、ラファエルが登場してからの成功体験を駆け上がる感じの場所はご都合感があった。しかし、スタートアップ企業がビジョンと現実の間で苦しむ様子がすごくリアルで、読んでいて自分まで苦々しい思いを体感させられた。

OKR気になっている人、読みやすい一冊なので、ぜひ一読して欲しい。

*1:もうちょっとで1冊目読み終わるから待って!!!

Otemachi.rb#10にLT参加しました

enechange-meetup.connpass.com LT参加しました!メモ魔なので、聞いた話をメモしました。

主催 エネチェンジさん

電力会社、ガス会社を切り替えるならエネチェンジ!

Active Support のコア拡張機能について

  • 知ってた!
    • Object#blank? #=> 0.blank? == false
    • Object#present? #=> 0.present? == true
    • Object#try #=> メソッドがなければ nil を返す ぼっち演算子(&.)でも同様のことができる
    • Object#try! #=> メソッドがなければ例外を返す
    • Object#deep_dup #=> ディープコピーしてくれる
    • Moduleの拡張: delegate
    • Railsのこだわり? String拡張
      • "table".pluralize #=> "tables"
      • "tables".singularize #=> "table"
      • 他, camelize, underscore, titlizem dasherize, demodulize, deconstantize, parameterize, tableize などなど
    • to_s(:currency, unit: '£')
    • 12345.to_s(:delimited) #=> 12,345
    • [1,2,3].sum #=> 6
    • .pluck(:name) #=> とてもお世話になっているやつだ
    • .merge
    • .compact
  • 知らなかった!
    • x.presence #=> x.present? ? x : nil と同じ
    • tryはブロックも渡せる、Ruby2.5 以降の #yield_self 的な使い方もできる
    • Object#to_query #=> {c: 3, b: 2}.to_query #=> "b=2&c=3"
    • Object#with_options #=> ref: Railsで特定の条件下で走るバリデーションを作りたい
    • class_attribute #=> ref: これはMUST!ActiveSupport の Class#class_attribute を使おう!
    • cattr_accessor #=> クラス変数のアクセサ
    • to_date, to_time, to_datetime #=> Time.zone.parse よりも文字数少なくて便利
    • 100.to_s(:percentage, precision: 0) #=> 100% *これ 0.01を1%に直してくれるのないかな?ありそう
    • 123.to_s(:human_size) #=> 123 Bytes !!!知らなかった
    • .without
    • Hash#extract!
    • Hash#stringify_keys, symbolize_keys, deep_symbolize_keys #=> キー、シンボルどちらかに寄せる
  • サマリ
    • ドキュメントを熟読しよう。
    • RailsGuide, Ruby on Rails API は必読。
  • Q: Rails以外でさくっと使いたい時どうしたらいいですか?

LTx5

Rubyでbrainfxck処理系作ってみた

  • 例のアレ => Brainfuck - Wikipedia
  • 実用性はゼロだがチューリング完全
  • 思わぬところでbrainfxckの仕様を知ってしまったな... (プログラミングかるたで存在は知っていた)
  • デバッグしんどそう
  • 派生言語がたくさんある、好きに当てはめていいため

CSV出力 Viewからやるか? 他からやるか?

Rails×Messaging API × Herokuで清宮幸太郎の成績検索BOTを作成したよ

ぼっちの開発 3-Step(発表しました!)

  • ぼっちの開発 3-Step - Speaker Deck
  • 色々試行錯誤した結果、最初入っていたはずの技術要素が消し飛んでエモさで攻める話になりました
  • Q: ぼっちなのになんで普通の開発フローを知っているのか?
    • A: 昔2人体制の時期があった + 一時期受託業務ですごく良い体制のチームにお邪魔していたことがあったため、その経験が活きています!
  • みなさん、あたたかく話聞いてくださって本当にありがとうございました!!

Rubyで始めるAtCoder

  • AtCoder 日本で参加しやすいコンテスト
  • https://atcoder.jp/?lang=ja
  • 面白そう!!
  • (ブログネタが枯渇してきたのでやらざるをえないという気持ち)
  • Rubyを選んでソースコードを貼って提出する
  • まず茶色ランクを目指そう(D)
  • 毎週土曜9時から定期開催

まとめ

久しぶりに人前で発表、しかもRails要素0.01くらいのスライドでしたが、みなさん暖かく受け入れてくださってありがとうございました…!! また今度はちゃんとRubyもしくはRailsネタをもってリベンジしたいです。精進します!

Goを出す責任

自分の勤めている会社は、2018年秋の時点で正社員10名未満の極小チームで成立している。 なので誰一人として仕事内容は被っていない。 横の連携は細かくあるものの、それぞれが各自の責任を持って仕事に取り組んでいる。

自分は自社サービスの開発運用保守と社内情シス的なところもカバーする立ち位置である。

東に調子の悪いサーバ(AWS)があれば行って面倒をみてやり、
西にプリンターがおかしいと言われれば再起動ボタンを押し、
南にやばそうなバグがあればセルフPR/レビュー/マージして修正し、
北に新しいPCを見繕えと指示があれば利用用途に合わせてAmazonリンクを送り返すようなことをしている。

技術的な面で言えばあらゆる点で付け焼き刃なところが多いので、フルスタックと言えるかは微妙な線かもしれない。申し訳ない。

ダブルチェックを欠かさずやる

ところで、弊社では大学生たちがインターンという形で働きに来てくれている。 彼らは仕事内でサービスの一部データをチェックする機会が多いので、おかしい箇所に一番に気づける。それは一般名詞の間違いなどの自明な不整合で、修正作業も入力フォームにボタンポチだけの簡単な作業なので、基本的にはおまかせしている。 しかし、必ずお願いしていることとして、修正があった場合はどんな修正をしたかを必ず報告をあげてもらうようにしている。修正内容はパッと見は自明なことばかりなので、忙しいとつい自分も「まぁ良さそうだな」という気持ちが強くなってしまうが、それで済ませずに裏取りをするようにしている。ダブルチェックというやつだ。 意外と、30回に1回あるかないかくらいの確率で、自明だと思い込んでいた修正内容が実は違っていた、ということがある。報告であがってくる内容はどれも納得のいくものなので、裏取りしないとその内容に隠された思わぬ勘違い(名前の読み方が間違えていた、似たような名前のものと誤解していたなど)は絶対に気づけない。

もしも、そのままにしていたら

もし自分がダブルチェックをサボって、その間違いのデータが残り続けてしまったらそれは誰の責任なのだろうか。それは教えてくれた学生さんではなく、 適当にGoを出した自分のせい である。報告してもらった項目に対しては、その内容の正当性は自分が保証しますよ、という気持ちを込めて、slackの報告発言には :+1: のemojiをつけている。たかがemojiとはいえ、責任のある重たいemojiである。 いまはぼっちエンジニアをしているのでなかなか機会がないのだが、PullRequestのレビューについても同様のことが言えると考えている。もしレビューしたPullReqestの中にバグが混在していたら、それにOKを出した各メンバーが見逃してしまったことであるので、他人事にしてはいけないと思う。だからといって誰が悪いとかの議論も前進力がゼロなので良くなさそう。適切な再発防止策を関係者で考え、素早く実行することだけが重要なのではないかと考えている。

まぁ、ということで、かなりでかいdiffが入ったPullRequestが来たら相応の長い時間をかけてレビューしてしまうタイプです。 他人事でないからこそ時間がかかっていると思って、そこは許してほしい。

あ、許してほしいっていったけど、今許すも許さないもレビューする人/してくれる人居なかったわ!!! 絶賛募集中!!!

ちゃんと使えば怖くないDataLoader(Salesforceの話)

今、Salesforceを会社で使っている。 SalesforceCRMプラットフォーム である。 メインの利用者は自分(エンジニア)でなく営業系チームメンバーとなる。 初回導入時やデータ管理方法の検討段階では、DB設計周りの知識があったほうがやりやすかったので、自分が手を動かすシーンが多かった。しかし、運用がうまく回り始めてからは営業系メンバーに使い方は任せている。

その中でも直近まで自分にお鉢が回ってきていた作業として、データの一括インポートがある。 「取引先(Account)」「取引先責任者(Contact)」はWeb上から50,000件まで一括インポートできる機能がある。一方、「商談(Opportunity)」「ToDo(Task)」などは一括インポートする利用方法が想定されていないようで機能は見当たらない。 しかし、サービスは利用者の数だけ利用用途が存在するようだ。弊プロジェクトは商談とToDoの一括インポートをしたいという要望があった。

この要望を解決するためにDataLoaderというアプリケーションを使い始めた。

developer.salesforce.com

DataLoader怖くないよ

DataLoaderはcsvファイルを元に各種データに対してCURDが実行できるウィザードである。

f:id:beta_chelsea:20181013175804p:plain:w450

普段の利用では出てこない英オブジェクト名(取引先=>Account)があったり、使い方を覚えるより使い方を知っている自分がやったほうが速いということで一括インポート作業はエンジニアが請け負う形になっていた。しかし基本は誰でも使うことが可能なツールなので、営業系チームメンバーも不安がらずに使えるように利用方法レクチャーを実施した。

基本的な使い方の流れは次のようになっている。

  1. どんな操作をしたいのか選択する(Insert, Update など)
  2. Salesforceアカウントでログイン
  3. 操作対象オブジェクトを選択する(商談, ToDo など)
  4. csvファイルを選択する
  5. csvファイルのヘッダーとオブジェクトのfield名のマッピングを行う
  6. 結果ファイルを出力するフォルダを選択する
  7. 実行する
  8. 成功csvファイルと失敗csvファイルが出力される

一通り使い方を実際に見てもらうことで、各メンバーにもDataLoaderが「よくわからないツール」から「いざという時は個人でも扱えるツール」という認識を持ってもらえたのではないかなと思う。

若干ややこしかったポイント

レクチャーしている時に若干ややこしかったポイントを覚え書いておく。

Upsertって何?

Upsertは update + insert を示す。 既存のデータがあればupdate(更新)、無ければinsert(新規作成)をしてくれる操作方法のこと。 SQL文の扱いが念頭にないと耳慣れないキーワードの様子。 また、他のユニーク制限のかかっているカラムなどによってinsertを狙っていたけど結局失敗した、などケースがあるので、慣れない間はupdateもしくはinsertをそれぞれ使い分けるほうが良いと自分は思っている。

更新にはSalesforce IDが必要

DataLoaderの更新には、更新対象データを特定するための15桁の文字列(Salesforce ID)が必要となる。 また、大文字小文字を判別するための3文字を末尾に付与して18桁として扱うこともある。

ヘルプ | トレーニング | Salesforce

マッピングはAutoMatch可能

DataLoaderに食わせるcsvの1行目(ヘッダー)の表記を、対応するオブジェクトの項目名(「商談」の「商談名」とか)にしておくと、マッピング時に「Auto-Match Fields to Columns」ボタンを押すと自動でマッピングをしてくれる。便利。

結果は常に2ファイルが出力される

もし処理が全部成功したとしても、結果ファイルは成功/失敗どちらも出力される。 全部成功の場合、失敗ファイルはヘッダーのみの1行のみとなる。

結果ファイルはいざというときに助けになるかも

もし、一括データ更新に失敗した場合、失敗結果ファイルには失敗理由がちゃんとかかれている。それを元に問題のあった箇所を正して再度やりなおせばいい。 また、データ新規作成に成功したものの、実はデータが間違っていて一括でなおしたい/削除したいなどの出来事が発生してしまった場合。このときは、成功結果ファイルにはSalesforceIDが出力されているので、それを元に改めて変更/削除のcsvファイルを作ることができる。結果ファイルの出力場所を忘れないようにしよう。(多分ウィザードが覚えていてくれると思うけど)

結局いいたかったこと

便利なものはどんどん全員使えるようになればよい!

観葉植物への水のあげ方

オフィス移転にともなって観葉植物をたくさんいただいた。 やはり植物なので水をあげないとと考えて、毎日コップ1~2杯の水を土にかけていた。 が、次第に植物たちは、しおしおしてきて元気が無くなっていった。 これはやばい。初心に返って原因をGoogleさんにお尋ねしたところあっさり理由がわかった。

www.apego.jp

そもそも水やりをする理由は次の2点。

  1. 土全体に行き渡らせるため。

  2. 土中にたまったガスを押し出すため。

自分は人間の水分補給くらいの気持ちでコップでえいえいと水をあげていたが、それだとまず土の中の空気の入れ替えがまったく完了できていない。植物たちがしおしおするのも当然といえた。 それが分かってから、水やり道具は紙コップから2Lペットボトルに切り替え、各鉢にたっぷり水をあげて様子をみることにした。

教訓として自分のよく知らないことについては、とりあえず最初にググったほうがいいなと思った。

ところで、ちなみに自分の預かっている鉢は、1回目の水やり以降1週間ほど経ったのだが土がカラカラに乾いたという感じがなくて最近やや不安である。 日当たりがよくないのはあるかもしれない......。 植物は難しいなぁ。

amazon musicはいいぞ(プライム会員)

無音よりも好きな音楽を聞いているほうがはかどる気がする派に属している。そして最近はよくamazon musicにお世話になっている。プライム会員なので一部の曲を聴き放題で利用できる。

自分としては好きなゲームのサントラがたくさんあるの嬉しい。ゲーム音楽は捗る。

 

ペルソナ5』オリジナル・サウンドトラック / アトラスサウンドチーム
https://music.amazon.co.jp/albums/B06ZYHQCS4

人類に栄光あれ『ニーア オートマタ』 / Rozen & Reven
https://music.amazon.co.jp/albums/B0755XCQ58

Undertale Soundtrack / Toby Fox
https://music.amazon.co.jp/albums/B01GGSLWRY

勇者のくせになまいきだ。1&2 ジャイアント・リサイタル / Sony Computer Entertainment Inc.
https://music.amazon.co.jp/albums/B00ICLXQ3W

ダンガンロンパ オリジナルサウンドトラック / 高田雅史
https://music.amazon.co.jp/albums/B00JTHMMI8


あとラスマス・フェイバーのアニソンのジャズアレンジも全部ある。すごい、嬉しい。

プラチナ・ジャズ ~アニメ・スタンダード Vol.1~ / ラスマス・フェイバー・プレゼンツ・プラチナ・ジャズ
https://music.amazon.co.jp/albums/B00BUAGWUG

 

いいぞ amazon music