読んで描いた「ソフトウェアの仕様、挙動、バグ、利用者の期待」

先日たまたま ソフトウェアの仕様、挙動、バグ、利用者の期待 - 29box を読んで、とても良いページだなと感じたので、自分なりに図を描いた。

描きながら思ったことたち:

「バグ」を「仕様」と「挙動」が一致していない状況のことである、と解釈をされていて、「同意〜」と思った。

利用者からの「バグですか?」という問いは「提供者さんの考える"仕様"と実際の"挙動"は一致していますか?」という問いと同じであると解釈できる。

この問いが提供者に与える価値はあんまり高くなりそう。なぜなら「仕様」も「挙動」も提供者が把握している(できる)情報だから。 (この問いを受けて新たな「挙動」が発覚するケースはあると思うので、その点においては価値があると思うけれど)

また、この問いは、利用者の情報を提供していないのだから、利用者の課題解決につながらない可能性が高そう。

提供者が知らない情報は「利用者がなにを期待しているか」なので、この情報が最も価値があるんだよなぁと思った。

なので利用者は「バグですか?」という問いよりも「OOになってほしいと思っています!」という問いを選ぶとよさそう。 提供者にとっての価値が高いし、利用者の課題解決にもつながる可能性がある。

一方で、提供者は「利用者がなにを期待しているか」を聞き出すように努めるとよさそう。

Next.jsで自分のサイトをつくった

つくった。

tanaken0515.com

つくりはじめるまで

今年の2月〜4月あたりに知り合いたちとモブプロで勉強するのにハマっていて、その題材としてReactとNext.jsのチュートリアルをやった。

Reactは2018年ごろにいっかいチュートリアルをやったのだけど、業務でもReactを使っているので改めてやってみることにしたのだった。

ja.reactjs.org

Next.jsはReactのフレームワークとして認識はしていて、「なんかめっちゃ便利らしい」ということだけ知っていたので面白がって取り組んだ。

nextjs.org

たしかに便利じゃん、ということがわかったので、これを使ってなにかつくろうかね〜ということで、自分のサイトをつくることにしたのであった。

つくるにあたって

まずはNext.jsのチュートリアルのコードをそのまま使う感じでつくり始めた。

Next.jsのチュートリアルはいくつかのレッスンに分かれていて、どのレッスンも途中から開始できるように「Download Starter Code」というセクションがある。 これが便利で、直前のレッスンをやっていなくても「直前のレッスンを終えた状態のコードがあるから、これを使いなよ?」と言ってくれるのだ。 (今後自分になにかのチュートリアルをつくる機会が訪れたら、この手法を取り入れたいなと思った)

で、今回は Assets, Metadata, and CSS | Learn Next.js のレッスンを終えた状態のコードからつくり始めることにした。

サイトのコンテンツを練るにあたって先輩方のサイトを参考にした。

サイトに経歴を載せたいな〜と思い、でもコンポーネントのデザインに時間を掛けたくないので、そういう便利なコンポーネントがありそうなUIライブラリを探した。

いくつか眺めてみると React Timeline component - Material-UI が一番しっくりきたのでMaterial-UIを使うことにした。

あとは、サイトを訪れたときに自分の最近の様子が伝わるといいなぁと思ったので、TOPICSという枠を設けてみた。 月に1~2件のTOPICが追加されるイメージ。 TOPICSや経歴の情報はYAMLで管理してる。

デプロイ先は Vercel を使っている。これもめちゃんこ便利。

ドメインムームードメイン | 欲しいドメインがすぐ見つかる。 で取得しました。ありがとうございます。

現職のGMOペパボでは「好きなドメイン無料」という福利厚生があるんですよね、ありがとうございます。

recruit.pepabo.com

ありがとうございます。

つくったあと

コンテンツをもっと充実させたいと思っていて

  • つくったもの
  • 書いたブログ(会社/個人)
  • 発表した資料
  • イベント参加の様子

あたりを追加する予定(未定)。

当初はブログの執筆もこのサイトに寄せてしまおうかなと(はてなブログを卒業しようかな)と思っていたのだけど、それ自体にそこまでのモチベーションはないのでどうしようかなというところ。はてなブログAPIを叩いて直近の記事数件のタイトルをサイトに表示(はてなブログへのリンク)って感じでも良いかもなぁ、など考えている。未定です。

親知らずを抜歯する

同僚が親知らずの抜歯エピソードをブログにしていました。

achamixx.club

人生の記録としてとても良いなと思ったので真似して書きます。

親知らずを抜こうと思ったきっかけ

虫歯の治療で歯科通院をしていて、親知らずの隣の歯を治療するにあたって「抜いちゃったほうがいいかもね〜、治療もやりやすくなりそうだし」とのことで抜くことにしました。

「うちの歯科クリニックではやっていなくて、近くの総合病院に紹介状を書くのでそこの歯科口腔外科で抜いてもらいましょう」となり、ああそうなんですね〜となりました。

過去に親知らずを抜歯したときは歯科クリニックでやった気がするので、そのあたりの運用とかルールとかはまちまちなのかな?

抜歯までにやったこと

初診の予約

歯科クリニックで紹介状をもらったのは3月末頃。

紹介先の病院に予約の電話をしたら「まずは初診になります〜」と言われ、いきなり抜歯ってわけじゃないんだなぁと思いました。

初診部分は歯科クリニックで実質終わっていて(レントゲンも撮っていたし)手術だけ紹介先の病院でやるもんだと思っていたので、このあたりの情報共有がもっとなめらかだと幸せになれそうだなぁと思いました。

「初診の予約を〜」とのことだったので「一番早くていつ予約できますか?」と聞くと「5月14日ですね〜」とのこと。

うお〜〜1ヶ月半も待つのか、、。まあそんだけ待つなら、仮に情報が共有されていても改めて診察する必要が出て来ちゃいそうですね。悪循環っぽい。

「じゃあその日でお願いします」といって予約しました。

初診・レントゲン撮影

レントゲンを撮影して抜く歯の確認をしました。レントゲンの写真撮っておけばよかったな〜と後悔しています。次なにかでレントゲン撮ったら絶対写真撮ります。

一部歯茎に覆われているので切る必要があるのと、歯を砕きながら抜いていく処置になるとのことでした。

「ほぼ確実に一週間は腫れるのでそのつもりでいるように」と言われたのと、手術の承諾書みたいなやつに「手術中に予定外の出来事が発生したら別の手術に変えるかも。そんときはやりながら意思確認するか術後にその旨を説明するからよろしくね」的なことが書いてあったので結構ビビっていました。手術承諾書の定型句なんだろうけど色々想像しちゃいますよね。

もともと自分は顎が外れやすくて、歯科治療中に顎が外れたことも何度かあったので、顎関連でなんかあったらやだな〜など考えていました。

(顎外れエピソードとしては、節分の日にあくびをしたら顎が外れて1時間以上そのまま戻らなくなってしまい、救急搬送されて口腔外科で顎を戻してもらった経験があります。帰宅して冷蔵庫にしまっておいた恵方巻をみて「絶対無理やろ、、、」と思った記憶があります。(小さく刻んで食べました))

手術の日取りを2週間後の5月28日と決めて、予約をして帰りました。

美味しいものを食べる

親知らずの抜歯後はご飯をまともに食べれなくなるだろうと予想していたので、抜歯までにとにかく好きなものを食べよう、という意気込みで過ごしました。

初診の翌日(5月15日)は自身の誕生日でもあったので鉄板焼きを食べに行きました。

f:id:tanaken0515:20210612095828p:plain

他にも、母からの誕生日ギフトでゲットしたすき焼きや、ふるさと納税の牛タン、回転寿司、行きつけのお店で油そばを食べました。

f:id:tanaken0515:20210612102335j:plain

抜歯ブームを観測する

同時期に抜歯する同僚たちがいて「この時期ってそういう時期なの?」と勘違いすらしました。

念のためtwitterで「親知らず」で検索して「みんな抜いている!」となりました(それはそう)

ついに当日!親知らずを抜く!

この日はお仕事を1日おやすみしました。 朝から自動車運転免許の更新も済ませたかったのでした。

免許の更新をスムーズに終えて、抜歯に行く直前にガストでランチをしました。

f:id:tanaken0515:20210612102529p:plain

すべての食事に「抜歯まえ最後のXX」と命名すると3倍くらい美味しく感じることがわかりました。

ガストのお手洗いで歯を磨きました。

いよいよ病院に到着し、受付を済ませ、大人買いした呪術廻戦を読みながら名前が呼ばれるのを待ちました。ドキドキしていたので内容がぜんぜん入ってこなかった。

名前が呼ばれ処置する席に座ると、まずは手術にあたって血圧を測定しました。術中も血圧測定器(腕に巻くやつ)をつけたままとのこと。「血圧が急変したら術式展開できるようにかな?」と思いました。

歯の周辺に麻酔を打たれるあたりから更に緊張感が高まってしまい、手や腕から冷や汗みたいなのが出ました。

3~5分くらい待って麻酔が効いてきたところで「じゃあ始めますね〜〜」と処置が始まりました。

ゴリッ、ゴリッ、ゴリッ。...。ゴリッ。

くらいで「あ、ラッキーですね〜、もう取れましたよ」と言われて「はへ!?」って声出ちゃいました。たぶん1分未満だと思います。

「これ縫わなくてよさそうだな。このままでいきましょう」とのことで、は〜そんなことあるんだ、と驚きました。

歯を砕きながら抜いていく処置になる予定でしたが、運良くきれいに抜けたとのことで、実際に抜けた歯を見せてもらいました。

持ち帰りますか?と言われたけれど、歯自体はきれいってわけではなかった(なので写真も取らなかった)し、正直持ち帰っても処分に困るなと思ったのでここで処分しちゃってくださいとお願いしました。

抜歯後、やっぱり痛いの?腫れるの?

運良くきれいに抜けたので、全く腫れませんでした!ラッキー!

抜歯当日は麻酔が効いていたのと、麻酔が切れそうなタイミングに備えて早めに痛み止めを服用したので、痛みを感じることもありませんでした。

翌日以降は痛み止めの服用をせずに過ごせました。

その後の流れ

1週間後に「抜歯後の経過観察」という名目でもう一度病院へ行きました。

先生が「はい、じゃあ糸抜きますね〜」と言うので「あ、自分縫ってないっす」「あ、そうでしたね。消毒だけしときますね」となるくらいには縫わないのが珍しいんだなと思いました。

とにかくラッキー!な抜歯でした。

余談ですが、偶然にも姉が同時期に親知らずを抜歯していて、姉の場合は一度抜歯を試みたところ局部麻酔ではうまく行かず、軽い全身麻酔をして一泊二日で入院をして抜歯することになったそうです。 こんなにも状況に違いがあるんですね。驚きでした。

これにて、自分は親知らずをすべて抜き終わったので、虫歯治療に専念できそうです! 先月から電動歯ブラシを導入したので、歯を大切にやっていきます!では!

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

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

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

教室のホワイトボードには「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の存在が欠かせなかったなぁと。

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

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