プロジェクト化とプロジェクトマネジメントは人生に活かせそう

日々人生をやっていると「自分、なにも前に進んでいないな...」と感じることがある。

お仕事は楽しくやっていて充実しているし成長も感じているのだけど、お仕事ではやらないような自分の興味分野や趣味でやってみたいことはあって、そっちがなかなか進まないよなぁという話。

モヤモヤ〜としながらも毎晩YouTubeをみたり漫画を読んだりしてだらだら過ごしてお風呂に入って寝る、という日々を繰り返していて大変よくない。*1

プロジェクト化、人生にも活かせそう

先日たまたま、関わっているお仕事現場の方(@library_fitさん)が「プロジェクトマネジメントの基礎講座」を開催してくれて、その内容が人生にも活かせそう、と感じたのでこの記事を書き始めた。

講座のスライドはこちら

この記事ではスライドを抜粋しながら、思ったことを書いていく。

「プロジェクト」とは?

f:id:tanaken0515:20200716093035p:plain プロジェクトには「目的」と「明確な始まりと終わり」がある、とのこと。

人生において「なんとなく興味がある!」とか「やりたい!」とかを割りと気軽に発言するのだけど、実際にそれを学んだり実行したり、その活動を継続するためには「目的」があった方がよさそうだなぁと思った。

まあ毎回「目的を決めなきゃ〜〜〜」と考えすぎてしまうとしんどくなってしまうとは思うけれど。目的を決めずにふわふわと何かをやることで得られる何かがあることもすごく分かるし。

ただ、ふわふわせずにしっかりと着実に前進させたい、というケースでは「目的」を決めるのは結構大事そう、と思った。

そして「明確な始まりと終わり」。これが決まっていないと、それはプロジェクトではない、という話。

  • いつになったら始まりで、いつになったら終わりなのか
  • なにをやったら始まりで、なにをやったら終わりなのか
  • どういう状態になったら始まりで、どういう状態になったら終わりなのか

この辺、人生の中であんまり考えていない or 考えていても結構ゆるい、かもなぁと。

「プロジェクト化する」とは?

f:id:tanaken0515:20200716095144p:plain

やろうとしていることに「目的」を決めて「期限」をつけること。 ふんわりとではなく、意識的に明確にこれをやることで、その物事への向き合い方が大きく変わりそう、と思った。

f:id:tanaken0515:20200716092153p:plain 人生の何かを前進させたい場合も、プロジェクト化するとよさそう。

プロジェクトの種類

プロジェクトはメンバー構成と納品の有無で大きく四つに分類される

f:id:tanaken0515:20200717071033p:plain

この分類なるほどな〜、と思った。

人生において自分個人の何かをやりたい場合は「メンバー構成 = 自分ひとり、納品 = なし」なので、左下っぽい。

自分と同じ目的を持った仲間を集めて何かやる場合は、左上かな。(メンバーがフレキシブルかどうかは状況によりそうだから左下にもなりそう)

「プロジェクトマネジメント」とは

f:id:tanaken0515:20200717072817p:plain

つまりは、プロジェクトの目的と期限を満たすためのなんらかの活動を指すらしい。

なるほど、プロジェクトマネジメントは「目的を満たし、かつ、期限を守る」ための活動なのか。

逆に(?)、特に意識せずとも「目的を満たし、かつ、期限を守る」ことができるプロジェクトであれば、プロジェクトマネジメントは必要ない、ということになるな。

それってどんなプロジェクトだろう。満たすべき目的の水準がめっちゃ低いとか?期限が極端にゆるくて、ゆっくりやっていれば終わるプロジェクトとか?

お仕事において、そういうプロジェクトってあんまりなさそうだなぁ。だからお仕事ではプロジェクトマネジメントが必要だし、プロジェクトマネージャーという職種(職位?)が存在しているのだろうな。

プロジェクトマネジメントがなくとも、プロジェクトは前に進む。しかし、スピードがあげられない。

f:id:tanaken0515:20200717084703p:plain f:id:tanaken0515:20200717084700p:plain

なるほど、プロジェクトマネジメントは「プロジェクトの迷いを減らすための活動」と捉えることができるのか。

人生に「プロジェクトマネジメント」は必要か?

これまでの自分の人生経験でいうと、多くはそもそもプロジェクト化されていない(=目的と期限が決まっていない)ケースがだった気がする。

挙げるとすれば、大学受験はプロジェクト化されていたかもなぁ。目的=志望大学の合格*2、期限=OO年3月、みたいな。
この「目的を満たし、かつ、期限を守る」ための活動ってなんだろう?と考えてみると、学校授業を受ける、とか、大学受験塾に通う、とか、それらの宿題を定期的にやる、とか、模擬試験を受ける、とか、そういうことかな。様々な不安や迷いが常にあったけど、いろんな人に相談しながらその不安や迷いを小さくしようと心がけていた気がする。特に、当時通っていた塾の塾長さんにはよく相談していて、いま思えば、塾長さんは「大学受験プロジェクト」のプロジェクトマネジメントをしてくれていたのかもしれないなぁと思った。

これからの人生はどうだろう。

人生には限りがあるし、その中でも健康に過ごせる期間は限られていると思う。その前提で、たくさんのやりたいことをやっていくためには、プロジェクトマネジメントが必要そうだなぁと思った。

まとめ

この記事を書きながら思ったことをまとめると

  • やりたいことが進まないなぁと思ったら、プロジェクト化してみる(=目的と期日を定めてみる)と確認するとよさそう
  • プロジェクト化したら、プロジェクトマネジメント(=プロジェクトの迷いを減らすための活動)をするとよさそう
  • 人生には限りがあるので、プロジェクトマネジメントは必要そう

この3つかな。

忙しさにかまけて人生を蔑ろにしてしまいがちなので、まずはプロジェクト化してみるところから、やってみようかなと思う。

*1:週40時間のフルタイムで働きつつ週10~15時間で別のお仕事もやっているので「単純に忙しくない?」という気持ちもあるんだけど、それにしても日々無駄に溶かしている時間も多くて「もっと良い感じにできそう」という課題感がある

*2:「大学に入るのは手段であって目的ではないぞ!!」みたいなことを言う人がいそう

思い出した順

最近のこととか思っていることとか。思い出した順。

もっと音楽はあっていいんじゃないか

家にずっといる。音楽あったほうが生活が彩ると思う。

作業BGMとかもそうだけど、なんか折に触れて音楽が流れたらいいなって。

電気つけたら、窓を開けたら、トイレから出たら、冷蔵庫を覗いたら、コーヒーを飲んだら

目覚ましの音も好きな音楽が流れるようにしたらよさそう

まあ最近は目覚まし使ってないのだけれど

SpotifyAPIとかを使ったらなんか良い感じにできるのかな https://developer.spotify.com/

ミステリと言う勿れ

漫画

flowers.shogakukan.co.jp

奥さんが急に買って来た、何かのアプリで数話読んだらしい

主人公の視点や物事の考え方が面白い、素敵な作品

奥さんは最近ずっと毎日「あつまれどうぶつの森」をやっていたのだけど、今週月曜から今日(木曜)までは一度もやっていない

何か思うところがあって控えているようす

あつもりを控えている反動で、漫画を買ってきたっぽい

ジャンププラスで「ヒカルの碁」も読み始めている。ヒカルの碁は自分も好きなマンガなので共通の話題が増えるのは嬉しい。

Qiita

3つ書いた

こういうのを書いてみるといかに自分が今まで適当にやっていたのかが分かって便利

まあこの記事たちも適当なところはいっぱいあるのだけど

適当にやっているのだ、ということを認識することが大事だったりすると思う

スプラ2実は引退したけど実は復帰してる

先月30歳になったので、記念にスプラをやったのだけど

見事に13連敗もして、「30にもなって何やってんだ俺は...」と完全に思ってしまったので実は引退した。

だけど奥さんがあつもりをやってるなどで、

あ、これまでニンテンドーアカウント?のファミリープランに入っていなくて、

自分と奥さんは別々でニンテンドーアカウントの支払いをしていたのだけれど、

奥さんがあつもりをやりまくっている関係で、ファミリープランにしたほうが良くない?となり、

ファミリープランだと8アカウントまで同じ金額で通信が使えるので

サブ垢つくって色々遊べるじゃ〜んという考えに至ってしまい、

結局サブ垢でスプラ2に復帰してしまった。

サブ垢ではチャージャーをマスターするぞ〜、と楽しくやっている。

実力的には、ガチマッチを始めてC-からB-飛び級できてめちゃ喜んでいる程度です

からしいことだけやってる感覚

最近のお仕事では、お金周りのことやユーザとの関係性を良い感じにエンジニアリングして行こうぜ的なこと主にやっている。

必要であることだと感じているし、割りと自分が得意とするお仕事をさせてもらっているので幸せに感じている。

一方で、なんというか「お金をちゃんと管理するのは大事」だし「最高のサービスにするためにユーザに寄り添っていくのは大事」なのだけど、

正しいことすぎる、というか、正義?みたいな物を盾?にしているような感覚もある。

この命題は真だよね、みたいな、自明だよね、みたいな、何かそういうものを淡々とやっているというか。

ほぼほぼ誰の目から見ても、第三者からみても「やったほうがいいこと」をやっているとき、

自分の価値観で自分の意志でやっているのか、単に第三者からみて自明に「やったほうがいいこと」だからやっているのか、

わからなくなるなぁ、と感じる瞬間もある。

「やったほうがいい」という結論が概ね確からしい、というものごとだけをやっているような感覚になることがある。

周りに否定されながらも自分の信じる道を行く!みたいなことをしてみたいと感じているのかも、と思ったりもする。

他にも

書こうと思っていたことがあった気がするのだけどこの辺りにしておく。

メモを書き留めているTrelloがあるのでそこからまたぽつぽつと記事を書いていこう。

読んだ: エンジニアはどのようにして技術を学べば良いのか

@genkiroid さんのブログ記事「エンジニアはどのようにして技術を学べば良いのか | /etc/motg」を読んだ。

とても参考になる記事で、忘れたくないなぁと思った。

ので、マインドマップを作った(記事に書かれていたことの実践にもなるので二鳥)。

はじめに

f:id:tanaken0515:20200512095849j:plain

この節があることで読みやすかったなぁと思う。参考にしたい。

何を学べば良いのか分からない

f:id:tanaken0515:20200512095931j:plain

目的(提供したい価値)が分かれば手段(学ぶべきこと)は自ずと見えてくる、という仮定のもと、価値とはなんなのか、学ぶ際の注意点、の話をしていた。

個人的には提供したい価値が分かっていても学ぶべきことが分からないケースはあったなぁと思うので、若干自分の考えとのギャップがあるなと感じた。

その時は周囲の人が「tanakenくんがやりたいことを実現するにはこれを学んだら良いのでは?」という話をしてくれて「あ、それだわ」となって解決した。

ただもしかしたら、提供したい価値を分かったつもりになっていた(解像度が低かった)ために手段が見えなかっただけかも、という気もするので、提供したい価値を確認してみる、というアプローチはとても良さそう。

技術書を読んでもすぐ忘れる

f:id:tanaken0515:20200512095942j:plain

マインドマップを実践してみた。「文章ではなく単語で記述」という原則をバッチリ無視したマインドマップが出来上がってしまったので、記事で紹介されているこの本を読んでみようと思った。

マインドマップ読書術 (トニー・ブザン天才養成講座) (トニー・ブザンのマインドマップ) | トニー・ブザン, 近田 美季子, 近田 美季子 |本 | 通販 | Amazon

学習する時間がない

f:id:tanaken0515:20200512095955j:plain

すきま時間を復習の時間に充てるやつ、やってみようかなと思った。

昔はテストや受験の勉強の時に、トイレの壁にノートを貼ったりしてたのを思い出した。あれもすきま時間の活用だったのだなぁ。

Rails の to_json には便利なオプションを渡せるよ

3行まとめ

Rails でDBのデータを取得して json 形式に変換したい、というシーンにおいて

  • to_jsonActiveSupport::ToJsonWithActiveSupportEncoder のメソッド
  • to_json には as_json (ActiveModel::Serializers::JSON) のオプションが渡せる
  • as_json のオプションはとても便利

単に json 形式に変換したい

Rails でのアプリケーション開発において、取得してきたデータを json 形式に変換したいシーンはままあると思う。 そういう時は to_json が便利。

例えば name に tanaken を含むユーザを取得して json 形式に変換したい時はこんな感じ。

> users = User.where('users.name like "%tanaken%"')
=> [#<User:0x00007faead5daf08
  id: 1,
  name: "tanaken0515",
  email: "tanaken0515@example.com",
  created_at: Wed, 05 Feb 2020 21:25:55 JST +09:00,
  updated_at: Wed, 05 Feb 2020 21:28:07 JST +09:00>]
> users.to_json
=> "[{\"id\":1,\"name\":\"tanaken0515\",\"email\":\"tanaken0515@example.com\",\"created_at\":\"2020-02-05T21:25:55.000+09:00\",\"updated_at\":\"2020-02-05T21:28:07.000+09:00\"}]"

便利。

モデルの特定のカラムだけ欲しい

でもこれだと User モデルのカラムを全部出しちゃって不便なことがある。例えば「この json をフロントに渡したいんだけど email は個人情報だから渡したくない。id と name だけあれば良い。」みたいな時。

実際のお仕事(主に土日にやってるほう)で似たようなシーンがあったのだけど、先日まで to_json を雰囲気で使っていた( json 形式に変換してくれるだけでしょ?と思っていた)自分は、「 select で絞ってから to_json すっか〜」というアプローチをとった。

> users = User.select(:id, :name).where('users.name like "%tanaken%"')
=> [#<User:0x00007faead64f5b0 id: 1, name: "tanaken0515">]
> users.to_json
=> "[{\"id\":1,\"name\":\"tanaken0515\"}]"

そしたらレッビューで「それ to_jsononly: オプションを指定したらできますよ〜」というコメントをいただいた。

> users = User.where('users.name like "%tanaken%"')
=> [#<User:0x00007faead5daf08
  id: 1,
  name: "tanaken0515",
  email: "tanaken0515@example.com",
  created_at: Wed, 05 Feb 2020 21:25:55 JST +09:00,
  updated_at: Wed, 05 Feb 2020 21:28:07 JST +09:00>]
> users.to_json(only: [:id, :name])
=> "[{\"id\":1,\"name\":\"tanaken0515\"}]"

なるほど便利。ありがたレビュー、大感謝太郎。

to_json ってなんなのよ

で、この to_json ってなんなのよ、というお話。調べますわよ。

まずは rails console で定義元を探してみる。 source_location が便利。

> users.method(:to_json).source_location
=> ["/path/to/project/root/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/core_ext/object/json.rb", 36]

https://github.com/rails/rails/blob/9256ae8a389fd40f9e4f152737de0fb2c6059daf/activesupport/lib/active_support/core_ext/object/json.rb#L36 ここ。

to_jsonActiveSupport::ToJsonWithActiveSupportEncoder モジュールのメソッドだったのだなぁ。(# :nodoc: となっているのでドキュメントはない)

実は rails console でメソッドの中身をみることもできて便利(これは最近知った).

> users.method(:to_json).source.display
    def to_json(options = nil)
      if options.is_a?(::JSON::State)
        # Called from JSON.{generate,dump}, forward it to JSON gem's to_json
        super(options)
      else
        # to_json is being invoked directly, use ActiveSupport's encoder
        ActiveSupport::JSON.encode(self, options)
      end
    end
=> nil

さっきの例で渡しているオプション only: [:id, :name] はただの Hash なので↑の else の方に入って、ActiveSupport::JSON.encode(self, options) が動くわけですな。


さて、続いて ActiveSupport::JSON.encode(self, options) について調べる。何も考えずに以下を打つ。

> ActiveSupport::JSON.method(:encode).source_location
=> ["/path/to/project/root/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/json/encoding.rb", 21]
> ActiveSupport::JSON.method(:encode).source.display
    def self.encode(value, options = nil)
      Encoding.json_encoder.new(options).encode(value)
    end
=> nil

Encoding.json_encoder がなんらかのクラスで、そのインスタンスを new して encode メソッドを呼んでる。

https://github.com/rails/rails/blob/144df5b104d042792f3fa73576d3ca9fac74fa67/activesupport/lib/active_support/json/encoding.rb#L21 この辺読むと、Encoding はすぐ下にモジュールとして定義されていて、このモジュール内の一番下に json_encoder が書いてある。

ざっくりこんな感じ

module Encoding #:nodoc:
  class JSONGemEncoder #:nodoc:
    # 略
  end
  # 略
  
  class << self
    # 略
    attr_accessor :json_encoder
    # 略
  end
  
  self.json_encoder = JSONGemEncoder
  # 略
end

となってる。

つまり Encoding.json_encoder.new(options).encode(value)
Encoding::JSONGemEncoder.new(options).encode(value) のこと。

JSONGemEncoder クラスの中身、 encode メソッドを見てみる。

GitHubで直接コード読めば良いんだけどあえて rails console でやるならこう。

> ActiveSupport::JSON::Encoding::JSONGemEncoder.new(only: [:id, :name]).method(:encode).source.display
        def encode(value)
          stringify jsonify value.as_json(options.dup)
        end
=> nil

valueas_json(options.dup) して jsonify したものを stringify するよ、ということですね、直感的ですね。

value ってなんだっけ?というと ActiveSupport::JSON.encode(self, options)self で、これは詰まり users.to_jsonusers ですわ。

なので詰まるところ

> users.to_json(only: [:id, :name])
=> "[{\"id\":1,\"name\":\"tanaken0515\"}]"
> ActiveSupport::JSON::Encoding::JSONGemEncoder.new(only: [:id, :name]).encode(users)
=> "[{\"id\":1,\"name\":\"tanaken0515\"}]"

ってこと。

to_json がなんなのかわかってすっきり。

指定できるオプションは、どこを見ればわかるのよ

to_json の正体がわかったところで、オプションをみていこう。

valueas_json(options.dup) しているので、 as_json で使えるオプションをそのまま使えるっちゅうことですな。

value.as_json は実質 users.as_json なので、rails console でみてみると

> users.method(:as_json).source_location
=> ["/path/to/project/root/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.2.2/lib/active_record/relation/delegation.rb", 85]
> users.method(:as_json).source.display
    delegate :to_xml, :encode_with, :length, :each, :join,
             :[], :&, :|, :+, :-, :sample, :reverse, :rotate, :compact, :in_groups, :in_groups_of,
             :to_sentence, :to_formatted_s, :as_json,
             :shuffle, :split, :slice, :index, :rindex, to: :records
=> nil

ほ〜ん、なるほど、 recordsdelegate されているのね。

recordsActiveRecord::Relation#records かな。こいつの返り値は Array なので、結局のところ Array#as_json を追えば良さそう。

> users.class
=> User::ActiveRecord_Relation
> users.records.class # 一応返り値のクラスを確かめてみた
=> Array
> users.records.method(:as_json).source_location
=> ["/path/to/project/root/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/core_ext/object/json.rb", 152]
> users.records.method(:as_json).source.display
  def as_json(options = nil) #:nodoc:
    map { |v| options ? v.as_json(options.dup) : v.as_json }
  end
=> nil

これは Array の各要素に対して as_json をしているだけですな。

今回の場合 users の各要素は User モデルのインスタンスなので

> users.first.method(:as_json).source_location
=> ["/path/to/project/root/vendor/bundle/ruby/2.6.0/gems/activemodel-6.0.2.2/lib/active_model/serializers/json.rb", 89]
> users.first.method(:as_json).source.display
      def as_json(options = nil)
        root = if options && options.key?(:root)
          options[:root]
        else
          include_root_in_json
        end

        hash = serializable_hash(options).as_json
        if root
          root = model_name.element if root == true
          { root => hash }
        else
          hash
        end
      end
=> nil

なるほど、ActiveModel::Serializers::JSON モジュールのメソッドだったのだなぁ! そしてこれは # nodoc ではなく、しっかりとドキュメントが書かれているのである!

api.rubyonrails.org

ここに書かれているオプションは使い放題!便便便利!

オプション紹介

ドキュメントのサンプルコードをそのまま貼って眺める

まずはオプション指定なしパターン

user = User.find(1)
user.as_json
# => { "id" => 1, "name" => "Konata Izumi", "age" => 16,
#      "created_at" => "2006-08-01T17:27:13.000Z", "awesome" => true}

次に :only , :except 。良いすね。でも個人的には多分 :except は使わないかな〜。ブラックリスト方式よりもホワイトリスト方式の方が安心できるから。センシティブな情報が入ったカラムを後から追加した時に、ブラックリストに指定し忘れるとまずいからね〜。

user.as_json(only: [:id, :name])
# => { "id" => 1, "name" => "Konata Izumi" }

user.as_json(except: [:id, :created_at, :age])
# => { "name" => "Konata Izumi", "awesome" => true }

続いて :methods これ便利すな〜。

user.as_json(methods: :permalink)
# => { "id" => 1, "name" => "Konata Izumi", "age" => 16,
#      "created_at" => "2006-08-01T17:27:13.000Z", "awesome" => true,
#      "permalink" => "1-konata-izumi" }

最後に :include 、associationを引いてこれるのも便利だなぁ。

user.as_json(include: :posts)
# => { "id" => 1, "name" => "Konata Izumi", "age" => 16,
#      "created_at" => "2006-08-01T17:27:13.000Z", "awesome" => true,
#      "posts" => [ { "id" => 1, "author_id" => 1, "title" => "Welcome to the weblog" },
#                   { "id" => 2, "author_id" => 1, "title" => "So I was thinking" } ] }

3行まとめ(再)

Rails でDBのデータを取得して json 形式に変換したい、というシーンにおいて

  • to_jsonActiveSupport::ToJsonWithActiveSupportEncoder のメソッド
  • to_json には as_json (ActiveModel::Serializers::JSON) のオプションが渡せる
  • as_json のオプションはとても便利

最初に想定した分量の5倍くらいの長さになってしまった。でも勉強になったから、よしっ!

アイコンを描いてもらった

@hamayucco さんにアイコンを描いてもらった。

写真 イラスト
photo illustration

写真のわんこは、僕の奥さんの実家で飼っていたゴールデンレトリバーで、名前は「winter」。ウィンちゃんって呼んでた。

数年前に亡くなってしまったのだけど、すごく人懐っこい子で、この笑顔の写真が大好きなのでイラストにしてもらった。

自分のためだけにイラストを描いてもらう、という体験はこれまでになくて、すごく嬉しかった。

この bosyu を出したら数名の方に応募していただいて、イラストのテイストが好きだったので今回は @hamayucco さんにお願いすることにした。

僕と奥さんの要望に丁寧に対応いただいて、お気に入りのイラストに仕上がったので大満足。

@hamayucco さんは↓で「似顔絵を描いて欲しい人」を募集しているようなので興味のある方は是非。

CREとはなんなのかを考えている

以前から Customer Reliability Engineering (CRE : 顧客信頼性エンジニアリング)に興味があったのだけれどあまり掴めていなくて、最近改めて色々な文章を読んでみた。

自分なりに CRE の輪郭がわかってきたような気がするので記録しておく。

結論

CREとは

顧客の不安をゼロに限りなく近づけるために、課題を把握・計測し、技術的なアプローチでその課題の解決に役立つものを実現していくこと

である。

と、自分は解釈した。

読んだもの

考えたこと、思ったこと

今、この時代において、真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。

Google Cloud Platform Japan 公式ブログ: Google の新しい専門職 : CRE が必要な理由

なるほどこれだな、と思った。

自分は前職でも現職でも、CSチームの方達と協力して業務効率を上げたりお問い合わせに対する技術的な対応をやったり、そういうタスクに普段から取り組んでいて、別に得意というわけではないけど、相対的に他のエンジニアメンバーよりもそういうタスクを率先してやる傾向があるよなぁ、という自覚があった。

でもなぜそういう傾向があるのか、うまく言語化できていなかった。

なんとなく、大事なことだから?とか、困ってそうじゃん?とか、そんな感じだった。

これを読んで、明確に『自分が携わっているサービスにおいて、ユーザが抱えている不安をなくしたい』という思いがあるんだなと認識した。

そして、それをミッションとする職種が存在している、それが CRE である、ということを理解した。

不安は 1 を信頼性で割った数値に等しい

Google Cloud Platform Japan 公式ブログ: Google の新しい専門職 : CRE が必要な理由

これはつまり、「信頼性を高めることで、不安をゼロに限りなく近づけることができる」ということ。信頼性を高めるためにはどうした良いか?という視点で考えると物事の見え方が変わってきそう。

お客様に寄り添い、お客様が今置かれている状況を少しでも良いものにしていくために私たちにできることをおこなっていく、ということが、我々MackerelチームのCREのミッションになります。

セールスエンジニア 改め Customer Reliability Engineer (CRE) になりました - Hatena Developer Blog

CREはその名の通りお客様の信頼、つまり、不安を抱えるお客様に寄り添うことに主眼を置いています。

CREチームを設立しました! | レポート | XFLAG(エックスフラッグ) キャリア採用サイト ケタハズレな冒険を。

CREのミッションは一言で表せば「お客様の抱える不安を払拭すること」です。

CREという組織を作りました|Repro CS Blog|note

「お客様 対 CRE」ではなく、「お客様が抱える不安 対 わたしたち(お客様 and CRE)」という構図なのだなと思った。寄り添うというのはそういうことだな。

その他、総じて書かれていることは、ミッションを達成するために「技術的なアプローチをすること」「データ・ドリブンで行なうこと」。 課題の把握、定量化、施策の実施、効果測定、などが共通するキーワードだなと感じた。

おわりに

これまで CRE に対して曖昧な理解のままその単語の表面だけを眺めていたけれど、自分なりの解釈と定義をしてみることで腹落ちした。

「自分のやりたかったこと、これなのでは?」感がすごくある。

まだまだ脳内が整理できていないけど、自分の中にひとつの筋道というか、軸のようなものが生まれた手応えがあるので、常にこれを意識しながら過ごしていきたい。

2020年は CRE をやっていく。

API Client の rubygem を作ってみた

これを作った。

GitHub - tanaken0515/cotoha-ruby: COTOHA API client for Ruby

中身について詳しくはここに書いた。

[自然言語処理 初心者向け] COTOHA API を Ruby で使いたくて gem を作りました - Qiita

この記事では作るに至ったきっかけや作りながらのお気持ちなどを記録しておく。

作るまでの話

去年、自分 gem についてよくわかっていないな〜と思って勉強し始めた。

勉強といっても、公式ドキュメントに書いてある通りに実際に作ってみる、というだけの話だけど。

一人でやっても鳥が少ないので、みんなで学びたいな〜と思って2019年9月から社内勉強会(全8回)を開催した。

読んだドキュメントはこの辺。

いくつかの gem のコードリーディングもした。

この勉強会を経て、同僚の harashoo さんが https://github.com/harashoo/fujitatsu (詳しくは はじめての自作Gem - シンプルなGemを作成して公開する - Qiita 参照) を作ったり、

自分自身も https://github.com/tanaken0515/suri_lang (詳しくは 忍者スリスリくんの影武者を作っている - tanaken’s blog 参照) を作るなど、アウトプットにつながったので良い感じだった。

gem 作るの簡単だし楽しいな〜、という気持ちになっていて、なんとなく「次は API Client の gem を作りたいな〜」と思っていた。

作るきっかけの話

直近半年くらいは自然言語処理に興味があって scrapbox に調べたことをまとめたり、方言をテーマにして鹿児島Ruby会議01で発表したりした(発表の中身はほぼディープラーニングの基礎、みたいな内容になってしまったのだけど)。

そんな中 Qiita で↓の記事を読んでCOTOHA APIの存在を知り、この API の Client gem を作ることにした。

「メントスと囲碁の思い出」をCOTOHAさんに要約してもらった結果。COTOHA最速チュートリアル付き - Qiita

脱線するけれど、この記事を書いた youwht さんは自然言語処理関連の楽しい記事をたくさん書いてくださっている。

個人的に特に好きなのは

で、記事の構成がうまくて文書が面白いのに加えて、試行錯誤して物事を進めていく様子がすごく勉強になった。

記事を読んだ時の感想を残していたので貼っておく。

作ってるときの話

そんなこんなで COTOHA API の Client gem を作ることにしたのだけど、API Client を作ったことがなかったのでまずは参考になりそうなものを探した。

真っ先に思い浮かんだのは RubyKaigi 2019 で発表されていた @sue445 さんのこの資料。

この資料と、この資料で紹介されていた https://github.com/asonas/chatwork-ruby , https://github.com/sue445/pixela のコードを読み、「キーワード引数を使う」「独自のエラークラスでwrapする」などを取り入れた。この発表に関しては同僚の @tsummichan さんが RubyKaigi2019 Vol.2 - ペパボテックブログ に分かりやすくまとめてくれている。

実装の全体的な方針は同僚の @shimoju_ さんが作った https://github.com/shimoju/metabase-ruby を参考にした。読みやすくてありがたかった。

作ったあとの話

実装したあと Qiitaの記事 を書いたら、↑で紹介した youwht さんからコメントを頂いて嬉しかった(自分の記事内に youwht さんの記事のリンクを貼ったから通知がいったのかも?)。

COTOHA API の Slack コミュニティでこの gem を紹介したら「この界隈Pythonが多くてRubyの記事は個人的にとても嬉しい」「これからRubyで使ってみようかと思っていたので助かります」といったコメントをもらえて嬉しかった。

作ってよかった。

この gem の todo は直近2つある。

1つ目は未対応のエンドポイントに対応すること。「固有名詞(企業名)補正」「音声認識」「音声合成」のエンドポイントがあるんだけど、有料の for Enterprise プランに申し込まないと利用できないので、現時点(cotoha v0.2.0)では対象外としている。動作確認できないけど実装だけしようかなぁ、というところ。for Enterprise プラン、月額13万なんだよなぁ、、、。最初の3ヶ月無料とのことだけど、契約期間の縛りは無いのかな?などの調査を含めて todo だな。

2つ目はコードコメントの整備。なんも書いていないので質素な感じになってる。 https://www.rubydoc.info/gems/cotoha

適宜やっていきたい。


せっかくだからこの gem を使ってなんかやりたいな。アイデア待ち〜。

おしまい。