免許更新の講習で学んだこと

自動車運転免許の更新のために、府中運転免許試験場に来ていた。

更新料の支払い・視力検査・写真撮影などの手続きを経て、講習を受ける教室に着席した。

教室のホワイトボードには「50(昨対比 -4)」と書いてある。

講習の講師と思しき女性が、ホワイトボードの前に立ち、講習の流れや教材について説明を始める。

そして、ホワイトボードに書かれた数字についても説明を始めた。

「この数字は、2021年の東京都における交通事故で亡くなられた方の人数です」

そうなのか、1ヶ月に約10人の方が亡くなっているのか、悲しいな...

などと考えていると、講師の女性は話を続けた*1


私はいつもこの数字をホワイトボードに書いて講習をしています。

1ヶ月ほど前でしょうか。いつものように講習を終えると、ある女性が私の元に質問に来てくださいました。

「このホワイトボードの数字は、事実ですか?」

私は「はい」とお答えしました。

するとその女性はこうおっしゃいました。

「私の夫は昨年交通事故に遭い、約1年を経て、今年亡くなりました。夫は、この人数に含まれていますか...?」

私は「いいえ」とお答えしました。

ここに書かれてる数字は、事故発生から24時間以内に亡くなられた方の人数です。ですので、含まれておりません。

そうお伝えすると、その女性は

「この話を、ぜひ講習を受けに来たみなさまに伝えて欲しいです。」

とおっしゃいました。

私はこれまで、"交通事故で亡くなられた方の人数です" とお伝えすれば、"24時間以内に亡くなられた方の人数" であることが伝わると思っていました。

みなさんご存知のことだと考えていたのです。

でも、そうではないんだと気づきました。

ここに書いた「50人」よりも多くの方が、交通事故をきっかけに亡くなられている、ということをみなさんにぜひ知っていただきたいです。


....

教室が静まりかえっているのを感じた。

なんともいえない気持ちになった。

50人という数字を表面的にしか見ていなかったな、、と気分が落ちた。

この話をしてもらえて、とても良かった。

正直なところ、講師の方に対して「毎回同じような講習をやって、退屈だろうなぁ」などと考えていた自分がいて、とても恥ずかしくなった。

講師の方が日々の中でこのような気づきを得て、より良い講習にしてくださっているのだと分かり、尊敬した。

学び

講習を受けて、もちろん道路交通のルールについてたくさん学んだのだけれど、一番の学びは「その数字の前提を知っているか否かで数字の伝わり方が変わる」ということだった。

それはそう、という話なんだけれど、大事なのは聞き手にちゃんとその前提を伝えることであって、「聞き手側がその前提を受け取れるように工夫する」のは話し手側の責務だよなぁと思ったのだった。*2

*1:記憶を頼りに書いているので細かい表現は正確ではありません

*2:話し手側が相手に「聞いてほしい」と思って話している場合の責務。聞いてほしいと思っていないケースは対象外。

働く仲間からみたエンジニアについて発表するメモ

現在所属しているGMOペパボの2021年新卒研修にて、「自分以外の職種について理解する」という主旨の講義を担当することになったのでその時に話すことを考える。

エンジニア以外の職種の新卒パートナーがエンジニアのことを理解するきっかけとなる講義にできるといいな。

人事チームが設定してくれた話題は次の4点。

  1. 自己紹介
  2. 職種概要
  3. 具体的な仕事
  4. 新卒パートナーへのメッセージ

ざっくり発表20分、質疑応答10分という感じとのこと。

新卒パートナーのお名前と職種を把握したうえで「この職種のOOさんはエンジニア職のこの部分のことを知りたいはず〜」など仮説を考えながら資料を作れるといいね。

「自己紹介」で話すこと

ここはライトに。アイスブレイク的な。

人となりやこれまでのキャリアがわかるとよさそう、とのこと。

ラテちゃんを飼っている話と、今まで経験してきたお仕事や趣味でやっていることを話そう。

「職種概要」で話すこと

ペパボにおけるエンジニアのミッションなど。

これは全社的なミッションはペパボテックカンパニービジョン*1を参考に書けそう。

インターネットを通じて可能性をつなげる、ひろげる

をテクノロジーで実現する、という話。そのための時間軸と空間軸でのタッチポイントの広がりに対応していく的な...

エンジニア組織の構成や人数とかもここで紹介しよう。

ペパボのエンジニア職は

  • アプリケーションをつくる・支える人
    • Webアプリケーション(バックエンド/フロントエンド)、モバイルアプリケーション、etc...
  • アプリケーションの基盤をつくる・支える人
    • データ基盤エンジニア、SRE、etc...
  • 社内の基盤をつくる・支える人
    • コーポレートエンジニア、etc...

などなどの分類ができそう。他にもいろんな分類の仕方がありそうだな。様々にまたがっている人もいるだろうから明確な分類はしにくい面もあるな。

それぞれの分類のエンジニアと業務上のどのタイミングで接するシーンがありそうか、とかを話すとイメージしやすいかも。 具体例に基づいて話すと自分的にも話しやすいし。

「具体的な仕事」で話すこと

自分はさっきの分類でいうところの「アプリケーションをつくる・支える人」にあたるので、その一例としておしゃべりすることになりそう。

自分のいまの立場とミッションを踏まえておしゃべりする必要がありそうだなぁ。

まず、一日中ずっとコードを書く、という日は多くない。

他職種の人からたエンジニア職って「ずっとカタカタプログラムを書いている」イメージなんじゃないかなぁという気がするんだけど、どうだろう?

というのも、自分が学生時代に抱いていたイメージはそうだったから。

でも実際のところ、

  • コードを読んでいる時間
  • アプリケーションの動作を確認している時間
  • 仕様やあるべき状態を考えている時間
  • 設計や実装方法を考えている時間
  • 言語やライブラリの公式ドキュメントを読んでいる時間

などがとても多い。

ゼロからアプリケーションを作るのではなく、既存のアプリケーションに機能を上乗せしたり仕様を変更したりするのが主なお仕事なので、いかにしてやりたいことを既存のアプリケーションを壊さずに実現するか、という話になる。そうなるとコードを書くだけっていうお仕事はほぼないのよね。
コードが読めるソフトウェア開発者 - As a Futurist...のようなお話もある)

その他でいうと、CREという立場で毎日CSチームとのMTGに参加してユーザ視点やお困りごとの共有と相談を受けている。

業務委託パートナーにお仕事をお願いするために仕様を検討してタスク分解したり、プルリクエストのレビューをしたり。

エンジニアリングリードという立場で、チームメンバーがより高いパフォーマンスを発揮するためにはどうしたらいいか、も常に考えている。

ここまでで自分がどのような日々を過ごしているかをまとめることができそう。 (とはいえ自分の一日を一般的なものとして紹介するのは今回の主旨に沿っているのか?という懸念もあるなぁ、ちょっと検討する)

他職種の方との関わりはどんなものがあるか

  • ディレクターさん
    • 仕様を検討する
    • タスクの進捗状況を確認し合う
  • デザイナーさん
    • 画面における表現(文言,動き)を検討する
    • 実現方法を検討する
    • プルリクのバトンタッチ
  • CSさん
    • ユーザの利用状況や運用上の要望をヒアリングする
    • 質問や相談を受ける
    • 新機能や仕様変更について共有する
  • 人事さん
    • 採用の方針や選考についてお喋りする
  • 法務さん
    • 「この機能は法律的にどうか?」の相談をする
  • 経理さん
    • 「この機能は会計的にどうか?」の相談をする
    • 月初の経理処理に関連する質問を受ける

このあたりかな?

コミュニケーション面だと「解決策よりも課題を教えてほしい(解決策は一緒に考えよう)」とか「『仕様ですか?』という問い」の話とかをするといいかなぁ。

「新卒パートナーへのメッセージ」で話すこと

なんだろなぁ

「周りの人を頼ってね」と「頼った結果知ったことや学んだことを周りのみんなに伝えてね」ってことかなぁ。

なんでこのブログを書いたか

だいたい話すことがまとまってきた気がするのでメモはこの辺で。

なんでこのブログを書いたのかというと、ひとつは「資料作れよ〜」と自身を追い込むためなのだけど、もうひとつは発表資料に記載されないであろう思考プロセス的なものを誰でも見れる場所に残しておきたかったから、というのがある。何かの役に立つんじゃないかなぁと思ったのだった。書き終えてみると本当にただのメモなので、誰かの役に立つとは到底思えないのだけど、まあよし。

*1:antipopさん&kotarokさんによる最高文書。入社したら読めます。

突然連絡をくれた学生さんとペアプロしてお悩みを解決した話

「突然失礼します!プログラミング初学者のXXXという者です。hatenaブログのAction textの記事を見て来ました。僕もあの記事の質問者さんと同じで...」

Twitterのダイレクトメッセージが来た。

自分自身ではすっかり忘れていたのだけど、どうやら約1年前(2020-01-26)に ruby-jp slack で ActionText の質問に答えた というブログを書いていたらしい。

完全に書いた記憶を失っていて、ダイレクトメッセージをみたときに「誰か別の人と勘違いされているか、あるいはスパム的な何かかな」と疑ってしまった。申し訳なさ。

で、このブログに書いてあることと似たようなことをやろうとしたのだけどうまくいかないのでアドバイスがほしい、とのことだった。

行動力がすごいなぁ。
ブログを読んでその著者に連絡するの、自分はやったことないなぁ。

テキストベースでアドバイスとコードレビュー

ダイレクトメッセージは、やりたいことの説明とエラー画面のスクリーンショットが送られてきたのだけど、うーんまあこれだけではなんとも言えんな〜という感じで。

「具体的にどのようなコードを書いているのか分かればアドバイス出来るかと思いますので、GitHub等の手段でコードを見せて頂ければと思います〜」
GitHub上でプルリクエストの形にしておいてもらえると、コメントしやすくて助かります!(できなければ大丈夫です)」

とお伝えしてみた。

翌朝になるとプルリクエストのリンクが送られてきた。(ちょっと安心した。プルリクの作り方分からん、となった場合にコードを見ながらのテキストコミュニケーションはけっこう大変だよなぁと思っていたので)

コードを読んでみると、なるほどこれじゃ動かなそう、という実装になっていて、どれがどのクラスのオブジェクトなのかとかをまだ理解できてなさそう、という感想を持った。

プルリクには「こんな感じで想定した動きになるんじゃないか?」というコメントとともにコード例を書いてみたのだけど、それでもまだ動かんという話だった(コード例がミスってた)ので、じゃあ画面共有しながらやりましょうか、という話をして同期的に課題解決に取り組むことになった。

ペアプロ

実際に取り組んだ様子。

許可をとった上で録画することにした。

動画として残しておけば、学生さんも後で見直すことができるし、自分も伝え方や内容にミスがあったらあとから訂正できるので良いかなと思った。

ペアプロ中に自分が参考にしたドキュメントはScrapboxにリンクをまとめて共有した。プログラミングを学習中のときって、2次情報(個人のブログ等)に頼りがちになると思うのだけど、お仕事では基本的に1次情報(公式リファレンス)を見るわけで、その辺の感覚も伝えることが出来ると良いなぁと。

最終的に課題を解決することができてよかった。

まとめ

1年前に書いたブログがきっかけとなってお悩みの解決にたどり着くことができて、良い体験だった。

自分のブログが知らない誰かに読まれていて、誰かの役に立っているのかもしれないと思うと、胸アツであった。

しかも今回、自分自身では完全に忘れていた記事だったのもすごいなぁ。

書いているときはそんなに思いを込めて書いたわけじゃなかった(なんとなく月に1個くらいは書いとくか〜という気持ちのやつだった)のだけど、いまになって効いてきたというか。

自分にとってそれほど価値が高くないと思っていたものが誰かにとって価値のあるものである可能性があるんだなってことを実感できた。

書いておいてよかったなぁ。

オープンセミナー岡山2020で発表しました

2021年2月13日(土)に開催されたオープンセミナー2020@岡山に参加し、「SUZURIを支える"モノづくり"の心」というテーマで発表しました。

発表動画はこちら

youtu.be

発表資料はこちら

オープンセミナー岡山2020のテーマは「【エンジニアリング x ○○】(えんじにありんぐ かける なんか)」でそのテーマに込められた想いは以下のようなものでした。

色々な人の【エンジニアリング x ○○】を見聞きすることで、みなさんが持っている漠然とした不安が少しでも和らぐこと、そしてみなさんもそれぞれの "なんか" を見つけ出してもらえたら、 それが巡り巡って、最終的には世の中をとても良いものにしてくれるのではないか。

https://okayama.open-seminar.org/theme.html

自分にも「漠然とした不安」があったなぁという自覚があって、その不安がここ数年でどのように変わっていったのかを考えてみると、そこにはSUZURIの存在が欠かせなかったなぁと。

そんなことを考えながら作ったのが上の発表動画と発表資料です。

ご覧いただけたら嬉しいです。

Date.today > Date.yesterday は必ずしも真ではなかった

Ruby on Railsの話です。

まとめ

もうすこし詳しく

Date.today に関してはまとめに書いた以上の説明は特になし。

Date.yesterday に関して少しだけ。

    # Returns a new Date representing the date 1 day ago (i.e. yesterday's date).
    def yesterday
      ::Date.current.yesterday
    end

https://github.com/rails/rails/blob/5f3ff60084ab5d5921ca3499814e4697f8350ee7/activesupport/lib/active_support/core_ext/date/calculations.rb#L37-L40

Date.current に対してyesterdayを呼んでる。Date.currentはこう。

    # Returns Time.zone.today when <tt>Time.zone</tt> or <tt>config.time_zone</tt> are set, otherwise just returns Date.today.
    def current
      ::Time.zone ? ::Time.zone.today : ::Date.today
    end

https://github.com/rails/rails/blob/5f3ff60084ab5d5921ca3499814e4697f8350ee7/activesupport/lib/active_support/core_ext/date/calculations.rb#L47-L50

アプリケーションでタイムゾーンが設定されている場合は Time.zone.today を返す。

気づいたきっかけ

お仕事。

%m/%d のようなフォーマットで渡されるStringをDateに変換し、その日付が今日より前だった場合に特定の処理を実施する、というロジックがあった。

date_string = '01/29' # 外部から渡される(CSVファイルとか...

if date_string.to_date < Date.today
  # do something
end

対象のシステムはUTCで動いているので、この処理をJSTの1月30日00:00~08:59に実行すると Date.today は「1月29日」になる。 そのため date_string.to_date < Date.todayfalse になる。

これは想定した挙動ではなかった。

気づいたのはたまたま朝9時前にテストコードを実行した日があり、CIがfailしていたからだった。

テストコードでは date_stringDate.yesterday.strftime('%m/%d') で生成していた。
アプリケーションのタイムゾーンの設定はJSTになっているため、このテストをJSTの1月30日00:00~08:59に実行すると、タイムゾーンが考慮されてDate.yesterdayは1月29日になる。

気づけてラッキーだった〜。

で、こういう修正をした。

- if date_string.to_date < Date.today
+ if date_string.to_date < Time.zone.today
  # do something
end

アプリケーションのタイムゾーンを考慮して「今日」を判定できるようになったのでおっけ。

ひとこと

Date.today > Date.yesterday が真とは言い切れないの、時空が歪んでいる感じがしてすごい。

おしまい。

犬好きのためのSUZURI 2020

SUZURI Advent Calendar 2020 - Adventar の6日目。

5日目の記事はこちら↓

scrapbox.io

2020年はリモートワークになって人生においてもとても大きな変化だったなぁ。 リモートワークの整備はみんなでやってきたけど、とりわけshimojuさんが率先して進めてくれてとても助かった。本当に大感謝。

リモートワークに加えて、個人的な「2020年の大きな変化」は、9月からゴールデンレトリバーを飼い始めたこと。

めっちゃかわいい。

f:id:tanaken0515:20201205163548j:plain

この記事では犬好きのためのSUZURI情報を書いていく〜。

犬を飼っている人にオススメのアイテムベスト3

直近の数ヶ月間を犬と過ごしてみて「オススメしたい!」と感じたSUZURIのアイテムたち。

第3位: ブランケット

https://suzuri.heteml.net/suzuri/blanket2-6.jpg

忍者スリスリくん ( surisurikun ) の「 新アイテム【ブランケット】の詳細情報公開!!! 」というジャーナル ∞ SUZURI(スズリ)

12月に入って一気に寒くなった。冬、本気出してきた。寒いと感じているのは人間だけでなく犬も同じ。犬が寝るときにブランケットが1枚あると安心。

好きなデザインのブランケットに包まれている犬の寝顔、最高〜〜〜

第2位: ウエストポーチ

https://d233sqxsrf11cu.cloudfront.net/img/1.9bc97e0.jpg

軽くて大容量。SUZURIのウエストポーチ ∞ SUZURI(スズリ)

犬のお散歩は地味に荷物が多い。犬用の携帯ドリンク容器、ウンチをした時に使うエチケット袋、子犬の場合は訓練用(ごほうび)のオヤツ、などなど。お散歩中にウンチをしたら、エチケット袋で回収して持ち帰る必要もある。

そういった荷物を運ぶ際にウエストポーチが便利。荷物を持つ手が空くのでしっかりとリードを持ってお散歩を楽しむことができる🐕

荷物の手が空くという点ではサコッシュもオススメだけど、ウンチ入りのエチケット袋を運ぶ際にはかなり豊潤な香りがするので、個人的にはファスナー付きのウエストポーチの方が適しているかなと。

第1位: アノラック

https://suzuri.heteml.net/suzuri/journal/2019SS/02.JPG

忍者スリスリくん ( surisurikun ) の「 [NEW]アノラックについて。(SUZURI X) 」というジャーナル ∞ SUZURI(スズリ)

これめちゃくちゃ良い!

まずは大きなポケット。これがあるので散歩用品の一部をここに入れることができて便利。

つぎに撥水効果。お散歩中に休憩でお水を飲ませる時、アクシデントで水がこぼれて服にかかっちゃうのはありがち。そんな時に水を弾く!濡れない!

つづいて防風(?)。風が強い日にお散歩をすることもある。このアノラック、風を通さない力が結構すごい。冬場でも、温かいパーカーやスウェットを着てその上にアノラックを着ればバッチリ◎

さいごに防 "噛み癖"。うちのワンコ、噛み癖がすごいのだよなぁ。様々な衣類が被害にあっているのだけど、このアノラックは生地がとてもしっかりしていてまだ穴が空いていない。すごい。噛まれても大丈夫!(噛まないように訓練中)

個人的なお気に入り犬ショップベスト3

犬関連アイテムを販売しているお気に入りのショップたち。 

第3位: OOKIIINUさん

suzuri.jp

大型犬にまつわる魅力的なアイテムを販売しているショップ。

小型犬も好きだけど、やっぱり大型犬のもふもふ感が好き。身体は大きくてどっしりしていても心はヤンチャだったりする、そのギャップもかわいい。やっぱり大型犬だよな〜。

で、このショップで気になっているアイテムはこのグラス。かわいくて、かつ、ちょっと勉強になるテクニックが書いてあって素敵だな〜。

f:id:tanaken0515:20201205160019p:plain:w480

OOKIIINU TECHNICS / OOKIIINUのグラス通販 ∞ SUZURI(スズリ)

第2位: もんとみ( •ө• )さん

suzuri.jp

犬のあるあるなワンシーンのアイテムを販売しているショップ。

このショップといえばこれかな〜!この状態の柴犬ときどき見かけるわ〜、というやつ。首元がぶにゅっとなっていて、シッポはくるんと丸まっていて、かわいい。

f:id:tanaken0515:20201205153930p:plain:w480

散歩から帰りたくない柴犬 / もんとみ( •ө• ) ( shigemochi_kun )のTシャツ通販 ∞ SUZURI(スズリ)

第1位: efrinmanさん

suzuri.jp

主にゴールデンレトリバーのエフちゃんコメちゃんをモチーフにしたアイテムを販売しているショップ。

ゴールデンレトリバー好きにはたまらないアイテムがたくさんある。

思い出のアイテムは、以前のスマホの時に使っていたこのスマホケース。一生懸命クツを運んでいる様子が愛らしい。うちのワンコもクツを運んでくれないかな〜 🐕

f:id:tanaken0515:20201205162518p:plain:w480

師匠と弟子(ネイビー) / efrinman ( rinman )の手帳型スマホケース通販 ∞ SUZURI(スズリ)

まとめ

この記事では犬好きのためのSUZURI情報を書いた。

SUZURIの犬アイテムをもっとみたい方はこちらからどうぞ(犬が飛びます) https://suzuri.jp/search?q=犬

ではまた。

犬の散歩を始めたら道端のゴミが気になるようになった

飼っている愛犬(ラテちゃん)の予防接種を終えて、2020-10-13から毎日お散歩をしている。

f:id:tanaken0515:20201129194018j:plain

いまは1回30〜40分のお散歩を1日2回、朝と夕方にやっている。 心身のリフレッシュになっていてとても良い。なによりラテちゃんがかわいい。

ラテちゃんは好奇心旺盛で、お散歩中に出くわすすべてのものに興味があり、何でもかんでも咥えて食べようとしてしまう。

落ち葉や生えている雑草、花壇のお花、プラスチックの破片やタバコなど、本当になんでも食べようとする。

食べさせたくないので、食べようとしたらリードを引いて止めるか、咥えてしまったらなんとかしてクチから取り出す。

視点が変わるとモノの見え方が変わる

ラテちゃんとのお散歩を始める前までは何も感じなかったのに、お散歩を始めてから道端のゴミがすごく気になるようになった。

特にタバコの吸い殻は絶対に食べさせたくなくて、そういう気持ちで道を眺めると想像以上に落ちていることに気づく。

タバコのポイ捨て、ダメ、ゼッタイ。

これまではタバコの吸い殻が道端に落ちているのを見つけたときに、「よくないな〜」と思うに留まって、これがどんな実害に結びつくかまでは考えていなかった。

いまは、犬や小さな子どもが食べたら死んじゃうかもしれないじゃん!という実害にしっかりと結びついている。

視点の切り替えを意識する

視点の切り替えについて、たまたま関連がありそうな記事を2つ読んだ。*1

両方ともとても面白い記事で、物事への向き合い方や立場を強制的に切り替えることで思考の広がりが生まれている様子が伺える。

面白いな〜と感じると同時に、「自分は物事への偏った向き合い方や偏った立場での思考や言動をしていないだろうか...?」と怖くなった。

ある物事について考えたり会話したりする際に、

  • 自身がその物事に対してどのような向き合い方をしているか
  • どの立場で思考しているか

を意識しようと思った。

意識というか、この2つを明示した状態で考えたり会話したりすることしよう。

これをやると、より良い思考や会話になっていくと思う。

*1:きっかけはキマグレエフエムのエピソード17で、デイリーポータルZの與座ひかるさんの記事が紹介されていたこと。與座さんの記事をいくつか読んでいった中にこの2つがあった。キマグレエフエム、いつも聴いています。