自分をReadyな状態に

今週のタイムライン

エネルギーを奪った出来事（悲しくなった・不幸になったなど）

• 頑張り続けることでお金はついてくる理論は本当に信じるべきか考えてしまった（日曜日）

エネルギーを与えた出来事（幸せになった・安心した）

• 朝喫茶で勉強をすること（ほぼ毎日）
• パン作り（日曜日）
• 仕事での目標を立てた（月曜日）
• Amazon Personalizeの勉強（火曜日）
• 銀行を一つにまとめるための行動（火曜日）
• 不動産屋巡り（火曜日）
• アルゴリズムの勉強を進めた（水曜日）
• 普通に褒められた（木曜日）
• 今まで一緒に作業していなかった人とペア作業ができた（金曜日）
• 大学の友人と会話（金曜日）

戸惑った出来事や疑問に思った出来事

• その場でわからないことを解決するべきか、ちょっと自分で考えてから改めて質問をするべきか（水曜日）

話したいこと

1. 仕事での目標を立てた
2. Amazon Personalizeの勉強

自分をReadyな状態に

3月から新たなクォーターがはじまるということで、5月までの目標をたてました。

私は目標を立ている時に「SMARTの法則」にしたがって考えています。SMARTの法則は具体性（Specific）、測定できるか（Measurable）、行動的か（Action-oriented）、関連性（Relevant）、期限（Time-bound）の5つの要素からなる目標設定の方法です。

（ちょっと内容は変えていますが）私が立てた目標の一つはこちらです。 S：チームメンバーがスクラムのプロセスやルールを理解し、スクラムの考えに基づいて行動するようになること M：どれくらい各イベントがチームに浸透したかで達成度を判断 A：自分がファシリテーターをする時に各スクラムイベントの目的を確認する、...（たくさんあるため省略） R：チーム全体の目標を達成するためにこの目標を達成することが重要だと考えている T：5月末まで

個人的に一番大切にしているのは行動的か（Action-oriented）です。目標達成のためには、何らかの変化が必要だと思います。その変化は自分の行動によって起こす必要があります。そこで具体的な行動を考えることによって自らの力で変化を起こすきっかけを作ることができると思っています。そのため、目標を達成するための行動を具体的に考えることが重要だと思っています。

今週は、目標達成のために何を自分がすべきかを考えることができ、自分をReadyな状態*1にすることができたと思っています。

レコメンドエンジンをさくっと作る

知り合いのお手伝いの中で、ユーザにおすすめのコンテンツを推薦する部分を実装する機会がありまして、その際にAmazon Personalizeを使ってみたので、学んだ知識をまとめてみます。

事前知識

Amazon Personalizeを使う際にはいろいろな言葉が出てきますので先にまとめておきます。

用語	内容
データセットグループ	データセット、ソリューション、キャンペーン、バッチジョブなどが含まれたもの。
インタラクション	どのユーザがどのアイテムに対してアクション（見る、購入するなど）をしたかという情報のデータセット。
ユーザ	ユーザに関するメタデータのデータセット。
アイテム	ユーザがアクションを起こすアイテムのメタデータのデータセット。
ソリューション	実際のレコメンデーションモデルを作るところ。
キャンペーン	リアルタイムで推薦するために使用するもの。（ちょっと料金が高い）
バッチジョブ	バッチで推薦するために使用するもの。

実際にやること

ここではAWSのコンソールの画面上での操作で説明します。

1. データセットグループの作成

コンソールにてAmazon Personalizeと検索して、Get startedのボタンを押すと、データセットグループを作成する画面に遷移する。遷移後は名前を指定するだけで作成完了。

2. 必要なデータをS3にアップロード

S3にバケットを作成して、必要なcsvデータをアップロードしておく。また、Amazon Personalizeからのアクセスを許可するため、アクセス許可タブのバケットポリシーに以下のように記述を追加。

{
    "Version": "2012-10-17",
    "Id": "PersonalizeS3BucketAccessPolicy",
    "Statement": [
        {
            "Sid": "PersonalizeS3BucketAccessPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "personalize.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::[指定したバケット名]",
                "arn:aws:s3:::[指定したバケット名]/*"
            ]
        }
    ]
}

3. データセット・データセットインポートジョブの作成

データセットにはインタラクション、ユーザ、アイテムの3種類があり、それぞれインポートできるボタンがある。インタラクションは必須だが、それ以外は任意のデータとなっています。

データセット作成の際にはスキーマ（どんなデータかの定義）を作成し、指定する必要があります。スキーマはその場で作成することもできますし、以前作成したスキーマを使用することもできます。Amazon PersonalizeではAvroスキーマという形式で書く必要があります。 以下がインタラクションのスキーマの例です。

{
    "type": "record",
    "name": "Interactions",
    "namespace": "com.amazonaws.personalize.schema",
    "fields": [
        {
            "name": "USER_ID",
            "type": "string"
        },
        {
            "name": "ITEM_ID",
            "type": "string"
        },
        {
            "name": "TIMESTAMP",
            "type": "long"
        }
    ],
    "version": "1.0"
}

スキーマの指定を行うと、データセットインポートジョブの作成画面に移ります。ここではどのデータを用いるかを指定します。 手順2で保存したデータのパスを指定してあげます。

s3://[バケット名]/hoge.csv

これでデータセットとデータセットインポートジョブの作成が完了します。 実際に作成するまでに少し時間がかかります。

ソリューションの作成と行きたいところだったが…

インタラクションの必要データ数が1000データ以上ということでデータセットの作成に失敗してしまいました。

ソリューションを作成するためにはデータセットには以下の条件が必要らしいです。

• インタラクションは1000データ以上
• ユーザは2回以上インタラクションに存在するユーザが25ユーザ以上

その他の細かい制約についてはこちらに記載されています。データ数をどうにかあつめて学習まで進めたい気持ちです。

他にもデータセットを作るまでの工程をPythonのboto3とdiscord.pyを使って自動化などもしたが、体力が尽きたので書くのは諦めました…

最後に

先週の日曜日は人生で初めてパン作りをしました。以下の写真は作ってもらった食パンですが、絶品でした。パン作りの機会に誘っていただいたことに感謝です！

食パン

*1:スクラムにおいて使う言葉で、実施する上でわからないことや妨げになるようなものがないこと。詳しくはこちらの記事が良さげです。

仲間について考える

今週のタイムライン

エネルギーを奪った出来事（悲しくなった・不幸になったなど）

• PCが重くなって作業のやる気が下がる（月曜日）
• ミーティングが重なり作業時間をなかなか確保できない（木曜日）
• 飲みすぎて二日酔い（土曜日）

エネルギーを与えた出来事（幸せになった・安心した）

• 3月の目標を立てた（日曜日）
• チームメンバーが夢を叶えるため次のステージへ（水曜日）
• 朝のカフェ作業（木曜日）
• 会社のキックオフでのみんなの様子がよさそうだった （金曜日）

戸惑った出来事や疑問に思った出来事

• どのようにフィードバックしあえるとよい効果がうまれるだろうか
• オンラインで緊張を和らげる方法って何があるだろうか

話したいこと

1. チームメンバーが夢を叶えるため次のステージへ
2. どのようにフィードバックしあえるとよい効果がうまれるだろうか

チームメンバーが夢を叶えるため次のステージへ

チームメンバーの1人が夢を叶えるために転職をするという話がありました。チームメンバーの中でも特に尊敬をしていた仲間だったので、夢を叶えるという嬉しさの反面、寂しさがこみ上げてきました。2人きりで話す機会を作れ、今までのことやこれからのこと、相手や私についての印象など様々なことが話せてとてもしあわせな気持ちになりました。

一方でチームとしては重要なメンバーの1人が抜けるということで緊急ミーティングが開かれました。昨年くらいからこのような時のためにトラックナンバー*1を増やすことを行ってきました。すぐに今月までにやらないといけないこと、誰が行動していくか、などが決定され、「なんかいいなぁ」と感じるミーティングでした。こんな風に、チームメンバーが新たなことに挑戦する時に笑顔で喜んで応援し会える状態を作り出すのって難しいけど大切だなぁ。

今週は十分に悲しんだり嘆いたりしたので、来週からは気持ちよく仲間を送り出せるように頑張るぞ！

フィードバックってどうすればいいの？

今週は12月に立てた目標に関して、チームや関わるメンバーとフィードバックし合う機会がありました。私の会社はフラットな組織や自律型組織を目指しているため、上司は部下にフィードバックを与えるというような形ではありません。私も経験年数が長い仲間に対してフィードバックもしますし、逆に自分より経験年数が短い仲間からもフィードバックをもらいます。

そんな中、何を伝えることやどう受け取ろうとすることが良いフィードバックとなるのかが悩ましいなぁと感じました。 適当に動画を調べてみてみました。

www.youtube.com

この動画ではフィードバックを受け取る側の意識が大切ということを行っていました。フィードバックは「間違っているところ」「改善できるところ」「気づかないところ」など自分を成長させるチャンスである。もらったフィードバックを論理的に理解し、次の計画に取り入れることが重要であると言っていました。更には受け取るのが上手になると人から好かれるようになるよとも言っていました。

受け取る側の気持ちはわかったが、フィードバックをする側についてどういうことをどういう風に伝えればよいかはわからんなぁ

最後に

サンマルクが7時から開いていることに気づいて朝カフェ作業をしてみました。高校生のときによく勉強で使っていたので懐かしみがあります。

朝のサンマルク

*1:トラックナンバー：ある日突然トラックに轢かれてもプロジェクトが停止しないメンバーの数

私の読書術

今週のタイムライン

エネルギーを奪った出来事（悲しくなった・不幸になったなど）

• 資料がうまくまとまらない

エネルギーを与えた出来事（幸せになった・安心した）

• 湘南蔦屋書店に行って次に読む本を買った
• Discord botの開発に関して社内LT会で発表した
• ハングリータイガーに初めて行った

戸惑った出来事や疑問に思った出来事

• 発言に反応してしまいそうになるときにその気持ちをどこに消化させるのか

話したいこと

1. 湘南蔦屋書店に行って次に読む本を買った
2. Discord botの開発に関して社内LT会で発表した

私の読書術

最近、「最高の体調」を読了しましたが、思ったより早く読めたし、良いと感じたのでそのやり方を共有しようかなぁと思います。

私はほぼ毎日21時から1時間で読書会を行っています。 具体的な進め方は、

• 最初の30分はちょうどよい区切れで交代しながら、声に出しながら読む
• 後半の30分は読んだところに関して感想を言い合う

だけです。メリットは、何も準備をしなくて良いことや他の人と感想を共有することで、自分が着目していなかった部分にも意識を向けることができることだと感じています。また、1回あたり30ページほど読めるというペースもわかってくるので、あとどれくらいで読み終わるのかとかも予測しやすいというもの良い点かもしれません。個人的に思うのが、声に出して読むのは高校生以来くらいでなんか新鮮でとても良いです（新人研修のときに声に出して読んだか笑）。

ぜひ皆さんもお試しを！

スクラムをDiscord botに手伝ってもらった

私のプロジェクトのチームはスクラム（スクラムマスターはいない…）で開発を行っています。そんな中、プロダクトバックログとスプリントバックログの情報の一致やベロシティの計測などの面で煩わしさを感じていました。具体的にはプロダクトバックログはGoogle Spreadsheet、実際の詳細が書いてあるアイテムやスプリントバックログはBacklog（nu-lab）と別々のサービスで管理されており、アイテムが完全に同期できていないという点です。そこで、discord.pyを使ってどうにかできないかなぁと思っていました。

実際にやったこととしては以下の3点です。

1. ベロシティの計算
2. ベロシティの可視化
3. プロダクトバックログ（Google Spreadsheet）の情報（ストーリーポイント）をアイテム（Backlog）に反映させる

実装してみて良かった点やうーんと感じた点は以下のスライドにまとめてあります。

開発していて面白いなぁと思いつつ、こういうタスク指向型のボットにはどんな機能があると便利なんだろうと対話システム勉強会に参加したときのことを思い出していました。

最後に

今週はなんだかもやもやする週だったなぁ感じています。 まぁそういうときもあるか！先週のハングリータイガー美味しかったなぁ（さわやかのほうが好みだけど）

初めてのハングリータイガー

様々な知識を得る機会

今週のタイムライン

エネルギーを奪った出来事（悲しくなった・不幸になったなど）

• 特になし！

エネルギーを与えた出来事（幸せになった・安心した）

• ドリームマネジメントのキャリアのセッションを実施（月曜日）
• Retrospective ANTIPATTERNS読書会（月曜日）
• 久々にジムに行った（月曜日）
• 最高の体調を完読（火曜日）
• 対話システム勉強会に参加（木曜日）
• 兄の誕生日（金曜日）

戸惑った出来事や疑問に思った出来事

• リモートワークにおいて全員が集まる機会を作るということ
• 議論の時間と発散のバランス

話したいこと

1. 対話システム勉強会に参加
2. ドリームマネジメントのキャリアのセッションを実施
3. 最高の体調を完読

今後は人間らしさのフィルターが重要となるのか

2月18日にオンラインで対話システム勉強会 雑談AIもここまで来た！ -最新の対話システムと未来-に参加してきました。 内容としては対話システムライブコンペティションというイベントについてとそのイベントで最優秀賞を受賞したチームの実装内容と「これからの対話システム」というタイトルでのパネルディスカッションでした。

そもそも対話システムにはタスク指向型と非タスク指向型があります。タスク指向型はよくある飲食店のレコメンドや機械翻訳などのようになんらかの目的がある対話システムのことを指します。一方で非タスク指向型はLINEなどで会話できるりんなのように雑談ができる対話システムのことを指します。今回の勉強会では後者の非タスク指向型の対話システムについて話していました。

ライブコンペティションオープントラックの最優秀賞のチームの実装内容は現在のstate-of-the-art（以下、SOTA）であるBlenderBotを日本語で学習させたものでした。 2017年に提案されたTransformerが機械学習界に大激震を与えましたが、対話システムの分野ではルールベールの手法もNNの手法と同等の性能を出していたそうです。ですが、2020年に提案されたGPT-3やT5によって対話システム界にもその波がきて、一気に雰囲気を変えたらしいです。BlenderBotはそのTransformerの考え方を用いたものらしく、それまでのSOTAであったMeenaを大きく上回る性能だったとか。 実際の対話内容を見ても本当に自然です。（こちらからコンペでの対話内容を確認できます。）

また、パネルディスカッションでは雑談AIの今後の開発について話していました。現在の対話システムの文章生成はある程度はできてあがっている気がするとのこと。これからの開発では生成された文の候補のうちどの分を選ぶのかという部分の開発がなされていくだろうと話していました。イメージとしては以下の図の赤枠の部分です。

イメージ図

確かに実際の会話においてもいろんな会話パターンが思いついた中でどれを話すか選択する部分にその人らしさや倫理観などが含まれて来そうだなぁという感覚があるのでしっくり来ました。 どんな情報で学習するかだけでない部分に重要な部分がありそうな気がしますが、どうなんだろうか…

キャリアについて考える

私は会社においてドリームマネジメントプログラムのファシリテーターをしており、月に1度夢を叶えることを支援するための活動をしています。 詳しいとこが知りたい方はザ・ドリーム・マネージャーを読んでみてください。

今回は「キャリア」についてということで自分がなりたい姿を思い描くようなワークを行いました。 私は資料などを準備する際に、実際に同じワークを行い、シミュレーションをしています。そこで、私もどんな働き方や生き方をしていきたいだろうかと改めて考える機会を得ることができました。 実際に行ったワークは以下のようなものです。

1. キャリア面での夢を1~3個決める
2. そのうち1つを選択し、達成したい期間を選ぶ（1年以内 or 1~5年 or 5年以降）
3. 選択した夢を他の期間に置き換えた場合に、どのような夢になるかを考える
4. パートナーを考えたり、SMARTの法則に基づき具体化する

手順2で私が設定したのは、5年以降に達成したい夢で物質・環境・時間に依存せずに働きたいとしました。

	内容
具体的	場所や時間が異なっていても協力でき、物質（お金など）に困らない状態で「システムで人々をしあわせにする」が実現できている
測定可能	（うまく考えられなかった）
行動的	さまざまな文化に触れる、コミュニケーションを大切にする、勉強への向上心をおこならない
妥当性	（うまく考えられなかった）
期限	35歳くらいまで
パートナー	今の会社の仲間、近くで関わりを持てている他の会社の方々

また、手順3では以下のような夢を考えました。

1〜5年で達成したい夢資産所得が少しでもある状態にする。 これは経済的に自由となるための第一歩となるような気がしたのでおきました。

	内容
具体的	今働いている会社の給与以外の収入ができること
測定可能	労働所得の5%くらいの資産所得がある状態
行動的	ブログを続ける、毎月株式投資をする
妥当性	ブログを続けることでいずれは事業所得となったりするかなぁ、株式投資によって配当などは入るなぁ
期限	1~5年で達成したい
パートナー	大学の友達（株式投資を積極的に行っている人がいる）、はてなブログなど

1年以内で達成したい夢はマインドフルネスな状態をいつでも起動できるようになる。 これは場所や環境に依存せず、いつでも集中できるようにするためにおきました。

	内容
具体的	50分作業＋10分休憩のサイクルで集中力が維持ができるようになる
測定可能	その日にやりたいことが達成できているかどうか
行動的	慣れるまではタイマーで測る、その日にやりたいことを3つを書き出す
妥当性	やりたいことが達成できているということはそのことに集中できているということ
期限	1年以内
パートナー	タイマーアプリ、夢リスト（やりたいことがたくさん書いてある）

5年後にこの夢が達成できるように行動するのみ！

文明病を治す鍵は自然に触れること

最高の体調を完読しました。

ざっと要約すると、

人類は狩猟採集民の時代の方が長いのにもかかわらず、現在の生活は全く異なった暮らし方をしているために不安やストレスなどの文明病と呼ばれる病気にかかってしまっている状況である。
進化論に基づいた行動をすることで文明病から脱却することができる。

と言ったことが書かれていました。これらのことを語る際に実際に行った実験などが書かれていたり、実践方法などが書かれていてとても納得の本でした。

特に面白かったのが、自然と触れ合うことがストレスや体調を整える最強の方法であるということです。 具体的には研究結果によってマッサージよりも癒し効果が高いという結果が得られているらしいです。さらには実際の自然ではなく偽物の自然（画面に映った自然の写真や自然の音だけ）でもその効果が得られるということです。さらには、公園などにいくことで大気中に含まれる細菌が腸内環境をよくしてくれるというのだからすごいなぁと思いました。今後は積極的に散歩しようという気になりました。

その他にも時間感覚や遊びについてなど様々な観点から狩猟採集社会の時代と現在を比較し、良い効果が得られるような研究について紹介されており面白い本でした！（書くのが面倒になりました笑）

最後に

今週はいろんなことが盛り沢山でたくさん考え、たくさん学んだ楽しい週となりました。 写真は水曜日のランチに食べたパリヤのお弁当です。

パリヤのお弁当

開発にワクワク

今週のタイムライン

エネルギーを奪った出来事（悲しくなった・不幸になったなど）

• 人との会話が少なかった（月曜日）
• 集中力がなかった（月曜日）
• 楽天モバイルのSIMとXiaomi mi9の相性が悪かった（水曜日）

エネルギーを与えた出来事（幸せになった・安心した）

• 久々にAPI実装の担当になった（月曜日）
• チームメンバーと話せる機会が多かった（火曜日）
• Discord botの作成を始めた（木曜日）
• 焼肉食べた（日曜日）

戸惑った出来事や疑問に思った出来事

• スクラムにおいてチームメンバーが増えそう（火曜日）

話したいこと

1.スクラムにおいてチームメンバーが増えそうなこと 2.久々にAPI実装の担当になった

開発を早くするためにスクラムでチームメンバーが増える

私はもう少しで3年目のエンジニアなのですが、スクラム(完全なものではない)で開発を進めていて、最低限のドキュメントしかない状況で、日々チームで認識を合わせながら開発しています。

開発力を強化するという目的で、1〜2人メンバーが増えることになりそうです。現在のチームは4人＋4人の8人体制です。現在の開発力を維持しつつ、数カ月先に開発力を上げるためにどうしたら良いだろう。体制としては様々なパターンがあります。

1. 5人＋5人: それぞれのチームに一人ずつ追加するパターン
2. 3人＋3人＋4人: それぞれのチームから一人ずつ出して、3チーム目を作るパターン
3. 4人＋4人＋2人パターン: チームはそのまま維持し、3チーム目を作るパターン

事前の話し合いでパターン2が一番良いのではないかと思いながらチームでの議論に向かいました。

一番人気がなかったのがパターン4でした。理由は日々の認識合わせによって培ってきた品質の認識やコードの書き方などを新しいチームに伝えづらく、技術的負債が増えてしまい、逆に開発スピードが落ちる可能性があったためです。

次にパターン1とパターン2を比較し始めました。

パターン1

• pros : 現在のチームを維持できる。計画する際の合計時間が増える。
• cons : チーム内での意思決定が遅くなりそう。

パターン2

• pros : チーム数が増える。小回りがききそう。
• cons : チーム全体での意思決定が遅くなりそう。

結果としてはパターン2が選ばれました。理由は チーム内での意思決定が遅くなりそう です。私達のチームではプルリクエストを承認する方法としてチーム内全員のOKが必要です。5人チームになった場合、承認をもらう人数が増えれば遅くなりますし、承認する人数を減らした場合には最初に誰がレビューをするのかで責任が変わってきそうな気がします。一方で3人チームとなった場合は承認の人数が減ることで承認スピードが上がることが期待できつつ、全員がレビューをするためチームの責任であることが維持しやすいのかなぁと思います。まずは決まって良かったです。次は誰が新たなチームに行くかの議論がありそうですね。

API実装に悩む

画像のアップロード機能の送信側の設計をしており、既存のコードを修正するのではなく、新たにパッケージを切って書いていくことになりました。画像はS3に保存し、画像の情報はデータベースに保存するような形です。3層アーキテクチャーに習って以下のように切っています。

root
|- application
|   |- HogeService
|- domain
|   |- Hoge
|- infrastructure 
    |- controller 
    |   |- HogeController 
    |- repository
        |- HogeRepository

最近テストの大切さを知り、プロダクションコードを書く前にテストを書きたいのですが進め方がわからない… ちょっと相談したところ、まずはインタフェースだけ決めちゃえばかけるかもいうことで以下の事を実施

• それぞれのクラスにインタフェースを切る
• それぞれのクラスに必要そうなフィールドを追加

これでなんとなく書けそう。かもというところまで行けました！早くテストを書いて、実装を進めたいところです！

最後に

スキーへ向かうバスの中でこの記事を書いています。一年以上ぶりのスキーなので楽しみすぎるぞ！

bus

ブログを始めることにしました

ブログを書く目的

1. 自分の成長を感じられるため
2. 学んだことを忘れないため

社会人3年目をもう少しで迎えますが、何も意識していないとあっという間に一週間が終わってしまいます。「今週何してたかな」「自分は成長しているのかな」とか考えるようになっちゃいました。そこで上記のような目的で「自分のために」ブログを書くことに決めました（続くか分からないけど。。。）

ブログを書く手順

1. 一週間あったことをタイムライン形式であった出来事をあげていく
2. 出来事に関してエネルギーを奪った出来事（悲しくなった・不幸になったなど）、エネルギーを与えた出来事（幸せになった・安心した）、戸惑った出来事や疑問に思った出来事に分ける
3. その中から1~3個出来事を選んでなぜそう思ったのかを書く
4. あれば今やっていることなども書く

私はただ思いを連ねるみたいなことをするのが苦手なので、自分なりに手順を作ってみました。手順を作ることで書き始めが楽になるかなぁなんて考えたりしています。

気をつけること

1. 「自分のため」だということを忘れない
2. 内容がまとまってなくても良い

とにかく重要なのは「続けること」なので、他の人がみて有益な情報を書かないと、読みやすいものを書かないとという気持ちはなしにしようという意気込みです。

最後に

ブログを書くことを続けることで、気持ち面でもそれ以外でも自分になんらかの変化をもたらしてくれるといいなぁと考えています。