行動評価の感想

はじめに

勤務先で今期から新しい行動評価制度が始まり、初めての自己評価を入力しました。グレードごとに7つの項目があり、自分の行動がどのグレードの水準にあたるかを1〜5で付ける仕組みです。

私は一人体制のSRE / platformエンジニアで、部下はいません。この立場で入力してみて感じたことを、個人的な感想として残しておきます。

技術者にも合っていると感じたところ

下位〜中位のグレードの定義は、職種を問わず通用する内容で、違和感なく自分の仕事を当てはめられました。特に次のような行動は、SREの仕事そのものだと感じました。

• 属人化していた作業を、手順・ルール・仕組みに変えて、担当が変わっても回るようにする
• 改善を型にして、数字と再現手順とセットで公開する

IaC化、手順書づくり、仕様駆動開発、コストや障害の記録など、普段やっていることがそのまま根拠になりました。

マネージャー寄りだと感じたところ

一方で、上位グレードになるほど「メンバーに方針を伝えて動かす」「メンバーのギャップを言語化して業務を任せる」「部門の予算や人の配分を決める」といった、部下やチームを持つことが前提の定義が増えていきます。

一人体制の技術者だと、ほかの項目で高い水準に届いていても、人材育成の項目だけが構造的に低くなってしまいます。実際、私の自己評価もそうなりました。

評価軸にない観点

逆に、技術者を評価するうえで大事だと思う次のような観点は、項目として直接は出てきませんでした。

• 技術判断の質（アーキテクチャ選定、トレードオフの説明）
• 信頼性の成果（障害件数、復旧時間、SLO）
• セキュリティやコストのリスク低減
• 技術負債の返済や、EOL対応などの将来への備え

これらはコメント欄に間接的に書き込むしかありませんでした。

専門職の道という考え方

多くの技術組織では、マネージャーとは別に専門職の道（Staff / Principal Engineerなど）が用意されています。そこでは影響力を「部下の数」ではなく、「技術方針で組織を動かす」「仕組みやプラットフォームで他チームの生産性を上げる」「設計レビューや発信で周囲の技術水準を上げる」といった形で測るのが一般的です。

勤務先の制度でも、上位グレードは役職が前提ではないと説明されていて、考え方としては専門職も想定されているようです。ただ、定義の文面がまだそれに追いついていない印象を受けました。

入力してみて気づいたこと

最初は普段の作業記録（ドキュメントやタスク管理）だけで評価しようとしたのですが、それだと「自分が何をしたか」の根拠しか集まりませんでした。上位グレードで問われるのは「他者や他部署に何が起きたか」なので、チャットのやり取りや会議の議事録まで見直して、ようやく根拠が揃いました。

日頃から次のような記録を残しておくと、評価のときに楽になると思います。

• 作ったツールや手順書を、誰が何回使い、何時間・いくら減ったか
• 他のメンバーや他部署からの反応、採用されたという報告
• 作った型を他チームに渡した日、相手、その後の状況

おわりに

評価制度は、作る側も運用しながら育てていくものだと思います。一人体制の専門職としてどう評価されるべきかは、上長と話しながら、自分なりの読み替えを探していくつもりです。同じように「評価項目が自分の仕事と合わない」と感じている技術者の方の参考になれば嬉しいです。

「あったら良い」で作り始めたデータ基盤を、本番に出す前に止めた

SRE／インフラエンジニアとして働いていると、「インフラ側でこれを用意してほしい」という依頼がよく来ます。今回、ある依頼で取り込み基盤を作り、開発環境で検証するところまで進めたあとで、その要件が実は利用者の要望ではなかったと分かりました。

本番に出す前に止められたのは幸いでした。ただ、もっと早く気付けたはずだという反省もあります。自分への戒めを込めて、経緯と学びを残しておきます。

依頼の内容

サービスの会員基盤として、外部のロイヤリティ系 SaaS を使っています。その SaaS 側でも KPI ダッシュボードの提供が予定されていましたが、アプリのリリースには間に合いません。そこで「それまでの間、会員登録数やクーポンの利用率を AWS 上で見られるようにしたい」という依頼を受けました。

半年ほどの「つなぎ」で、SaaS 側のダッシュボードが出たら捨てる前提です。そのため、軽く・安く・捨てやすい構成を目指しました。

EventBridge Scheduler（早朝に毎時起動）
   → Lambda（SaaS のエクスポート API から日次ファイルを取得）
   → S3（生データ。個人情報の列は取り込む前に除去）
   → Glue Data Catalog（パーティション射影）
   → Athena（最新状態を出すビュー）
   → （ダッシュボードは次の段階で構築）

技術的には面白い点がいくつかありました。

• エクスポートは差分出力だった：前日から変わったレコードしか出てきません。そのため、キーごとに最新の行を採る *_latest ビューを必須にしました。
• SaaS 側のファイルは一定期間で消える：初回の全件取得もできないので、取りこぼした日は二度と復元できません。欠損日の検知とバックフィルを最初から組み込みました。
• 会員データに個人情報が含まれていた：Lambda で許可した列だけに絞り、氏名や連絡先を AWS 上に持ち込まない設計にしました。

ここまでを IaC で開発環境に反映し、数日動かして問題がないことを確認しました。

発覚

ダッシュボードの指標を決めるため、要件の細部を確認する打ち合わせを開きました。「この指標は何の判断に使いますか」「誰がどのくらいの頻度で見ますか」と質問したところ、利用者側から出た要望ではなく、部内で「あったら良い」と判断して追加された項目だったと分かりました。

利用者側も戸惑っていて、必要かどうかを持ち帰って検討してもらうことになりました。

「データを見せて決めてもらおう」という案について

その場で、「取り込んだデータの一覧を出して、どんなダッシュボードが必要か利用者に決めてもらおう」という案が出ました。

作ったものを活かしたい気持ちはよく分かります。それでも、私は反対しました。

• 業務上の課題がないところに、作る側からツールを提案する形になる：「何が見たいですか」と聞けば何かしら答えは返ってきます。でも、課題から生まれたものでなければ使われません。
• 利用者に余計な負担がかかる：必要かどうかを検討してもらっている最中に、画面の要件まで考えてもらうことになります。
• 会員データを外に出すことになる：目的が決まらないまま、データを外部に見せるべきではありません。

ただ、データを見せること自体が悪いわけではありません。課題はあるのに、何を見ればよいか言葉にできない場合は、取れるデータを示すことが判断の助けになります。問題は順番です。

課題 → 指標 → データ → 画面

この順番を逆にして、データから課題を探しにいかないようにしています。

止め方

作業は「保留」にして、次のことを記録に残しました。

1. 設計書の冒頭に現状を書く：「保留（利用者の要否確認待ち）」というステータスと、開発環境は構築済みで本番は未展開であることを書きました。
2. issue に経緯と、回答後の対応を書く：必要なら本番に展開し、不要なら開発環境のリソースを削除してクローズする、と両方の道筋を示しました。
3. 判断の期限を明記する：ここが一番大事でした。データの仕様上、会員登録が始まってから必要と分かっても、それより前のデータは取れません。そこで「いつまでに回答が必要か」を、技術的な理由と一緒に書きました。

保留は、期限がないと忘れられてしまいます。技術的な制約から決まる判断期限を伝えるのはインフラ側の役目だと考えています。

学び

1. 依頼を受けたら、まず「要望元」を確認する

「誰の、どの業務課題から出た要望か」を最初に確認します。今回は設計までは確認せずに進めてしまい、詳細を詰める段階になってようやく気付きました。今後は依頼を受ける時点で、次の4点を揃えてもらうようにします。

• 要望元（利用者か、社内か）
• 目的（何の判断や報告に使うのか）
• 期限
• 優先度

2. 詳細を質問するのは失礼ではない

「何に使いますか」と聞くのは、相手を疑うことではありません。今回も、質問したからこそ本番構築の前に止められました。

3. 作ったものに引っ張られない

開発環境まで作ってしまうと、「せっかくだから使いたい」という気持ちが生まれます。作った分は「検証の成果」として記録に残せば十分です。使い道を無理に探す必要はありません。

4. 捨てやすく作っておいてよかった

最初から「半年で捨てる」前提で、サーバーレス構成と IaC 管理にしていたので、止めるのも消すのも簡単です。要件が揺らぎそうな案件ほど、撤退しやすい設計の価値が高いと実感しました。

おわりに

まだ利用者の回答は出ていません。結論がどちらになっても、「誰のために作るのか」を確認するという基本を、改めて意識するきっかけになりました。

依頼を「作る」ことで応えるのがエンジニアの仕事ですが、ときには「本当に必要か」を問い返すのも同じくらい大事な仕事だと思います。

外部向けサービスをどう守るか

この記事は「正解」を示すものではなく、SREとして日々インフラに関わる中で感じた個人的な考えです。セキュリティを体系的に学びたい方は、専門の書籍や公式ドキュメントもあわせて参照してください。

最近、ソフトウェアの脆弱性をきっかけにしたセキュリティ事案が続いています。ニュースを見ながら「外部に公開しているサービスは、結局どう守ればいいのか」を改めて考えたので、2つの視点でまとめてみました。

初めての踊り子

前準備など

以前から「6歳になったら踊り子に乗りたい」と言っていたが、ここ最近はその話をしなくなっていた。おそらく、自分の中でブームが終わったのかな？と思っていたところだった。

ところが、なぜか最近になってまた言い始め、いきなり週末に行きたいと言い出した。

ちょうど日曜日に予定がなかったので、行ってみることにした。

踊り子は主に伊豆方面へ向かう電車だが、子どもと二人で伊豆に行く予定はないし、行ったとしても特にやることがない。

そこで発想を変えて、上り電車に乗って都会で遊んでくることにした。横浜なら何かしらやることがある。

私も踊り子に乗るのは初めてだったし、きっと子どもは運転席を見たがるだろうと思ったので、JRのえきねっとで座席を選んで予約した。

海側ではなく陸側の席だったが、ちょうど一番前の席が空いていた。しかも、隣の席も空いていたので、窓側を予約した。

当日の移動

子どもは朝からテンション高めで、早起き。何度も「お昼ごはんの頃に乗れるよ」と伝えたが、いまいち理解していない様子だった。

結局、乗車時間の2時間ほど前に小田原駅に到着。いつもの図書館と子育てサロンのコースに行った。

予想どおり、あまり時間をつぶせなかったので、結局、先に昼ごはんを食べることにした。

一応、妻におにぎりを作ってもらっていたが、それだけでは足りないと思うので、先に少し食べても問題ないはず。

いつも行っているハンバーガー屋で軽めの昼ごはんとアイスを食べたら、ちょうどいい時間になった。飲まずに持っていたコーラを持ち、駅に戻った。

列車は意外と混んでいた。予約したときには空いていた隣の席にも、おばさんが座っていて、すでに晩酌を始めていた。

仕方なく、子どもを膝の上に座らせた。

乗車時間はそれほど長くないので、移動中も子どもは喜んでいた。途中で運転席も見に行った。もちろん、抱っこで。

横浜

まずはNゲージ体験のため、ポポンデッタ横浜西口店（https://www.popondetta.com/yokohama/）へ移動した。

移転前は商業施設の中にあったのでアクセスが便利だったが、今回はだいぶ遠くなったように感じた。

それでも、子どもはテンション高めで、文句も言わずに歩いてくれた。

体験時間は20分。車両は一番安いものを選び、料金は800円だった。

鉄道クラブにあったコントローラーとは少し違っていたが、問題なく操縦できた。

最初は20分では足りないのではないかと心配していたが、意外にも15分ほどで満足したのか、自分から切り上げた。

もちろん、店内にはいろいろな電車関連の商品があるので、何か買いたいらしい。

意外とNゲージの車両もばら売りされていて、動力車は2,800円程度だった。どうやら欲しいらしい。

とはいえ、線路などもそろえる必要があるし、いきなり購入するのも大変なので、いったんママと相談することにした。

一応、何か買うつもりで来ていたので、お土産として電車の靴下を購入した。

おそらくまた来ることになりそうなので、会員証も作った。

次の場所へ移動しようとしたところ、問題発生。

トイレに行きたいらしいが、店員さんに聞いたところ、店内にはトイレがないとのこと。

来た道を戻り、コンビニでトイレを借りた。こういうことも何年ぶりだろう。

その後は、京急ミュージアムへ移動した。

本来は横浜駅まで戻って地下鉄を利用するつもりだったが、距離的に微妙だったので、歩いて行くことにした。

意外にも、子どもは文句を言わずに歩いてくれた。やっぱり楽しかったのかな。

京急ミュージアムは、週末ということもあってか、まあまあ混んでいた。

 

今まで何度も来ているし、シミュレーターも予約なしでは体験できないので、うちの子にとっては、もうあまりやることがないようだった。

結局、割と早めに切り上げて帰ることにした。

 

帰り道

帰ろうとしたところ、子どもから「相鉄線に乗って帰りたい」と意外な提案があった。

確かに相鉄線でも帰れるが、乗り換えが必要だし、東海道線よりも時間がかかる。

そのことを説明したが、それでもいいらしい。

私も相鉄線には乗ったことがなかったので、少し気になっていたところだった。

 

改札に入りながら時間を確認すると、ちょうど海老名行きの急行に間に合いそうだった。

電車に乗ると、子どもはさっそく運転席を探し始めた。

何とか一番端の車両まで行ったが、そこからは車掌さんの席が見えた。また反対方向へ移動し、ようやく運転席が見えたところで電車が出発した。

車内が空いていてよかった。

初めて乗る電車だし、運転席が見えるように抱っこしてあげたが、さすがに私も体力の限界だった。

幸い、座席が空いていたので、座って休みながら抱っこすることにした。

どうやら子どもも疲れてきたようで、「ママに秦野まで迎えに来てほしい」と言い出した。

最初はバスに乗って帰るつもりだったが、私も疲れていたので、妻に迎えに来てもらうことにした。

今回のお出かけで、子どもはみなとみらい線の電車が大変気に入ったらしい。

踊り子に乗ることが目的だったはずなのに、最後には別の電車がお気に入りになったようだ。

大雄山線イベント

 

概要

10月は鉄道関連のイベントが多いので、色々と調べていたところ、昨年に続いて今年も大雄山駅で体験型イベントが開催されるらしいことが分かった。

終点まで行くことになるので、少し遠くはあるが、普段はあまり乗らない大雄山線に乗れるし、ちょっとしたお出かけにも良さそう。

子供も運転士体験ができるので、数日前から楽しみにしていた。

3連休の最終日で、連日のお出かけによる疲れも残っていたが、最後まで頑張る覚悟で出かけることにした。

当日

初めて参加するイベントだったので、どれくらい混雑するのか心配だった。

おそらく昼食後に行った方が空いている気もしたが、調べてみると大雄山駅周辺には子供と一緒に食事ができそうな場所が少なそうだった。そのため、どうしても小田原で昼食を取ってから向かうプランになる。

結局、頑張って早めに出発することにした。

小田原から大雄山線に乗り換えたところ、何人かの子供が目に入った。みんな手元にチケットのようなものを持っていて、「小田原駅で何か配っていたのかな？」と少し焦った。

ただ、事前の告知には特に案内がなかったので、とりあえずそのまま向かうことにした。

電車の運転席は子供にとってとても見やすい位置にあり、乗っている間、ずっと前方を眺めていた。

大雄山駅に着くと、降りる人の流れに乗って、そのまま洗車体験の電車に乗り込んだ。ちょうど始まる頃だったので、タイミングが良かったかもしれない。

洗車体験が終わり、次にどこへ行こうか考えていると、子供が「お土産を買いたい」と言い始めた。

これまでの経験から、並んでいるときなども、手元に好きなものがあれば飽きずに過ごしてくれるので、お土産を買うのも良いかもしれない。

お土産売り場には行列ができていて、なかなか商品を選べなかったが、予想どおり、ロマンスカーミュージアムでもよく買っている列車のバームクーヘンを選んでいた。

 

 

その後は敷地内で色々な体験を楽しみ、最後に運転士体験をしてから、帰りの電車に乗った。

帰りの電車には、行きの電車で仲良くなった子供とそのお母さんが偶然乗っていた。帰りは一緒に遊びながら、楽しく電車で過ごすことができた。

小田原に戻ってもまだ時間があったので、久しぶりに新幹線を見に行った。

ウルトラマンイベント

■発端

町からお祭りのチラシが届いていた。

今までとは少し違って、今回はウルトラマンのイベントを開催するらしい。

子どもに聞いてみたところ、意外にも行く気があるようだった。

確かに、大磯高校のコスプレイベントも好きそうだったので、その流れでこういったイベントにも興味が出てきたのかもしれない。

イベントは午前と午後の2回開催されるが、午前中はいつもの習い事があるため、午後の部に参加することにした。

■イベント会場へ

習い事から帰ってきて、取り急ぎ昼食を済ませてから会場へ向かった。

前の回が終わるのを待っていたが、なかなか整理券を配る気配がない。よく見ると、別の部屋で配布していた。

少し列はできていたものの、整理券をもらうのには特に問題なかった。むしろ、思っていたより参加者が少ない印象だった。みんな午前中の部に参加していたのかもしれない。

時間になったので、子どもを連れて会場へ向かった。

ちょうどイベントを見終えて帰宅する幼稚園の友達にも遭遇した。何気に町中の子どもたちが集まっている感じがした。

■ウルトラマンショー

時間になり、会場に入った。

なぜか子どもは会場の一番後ろの席に座ろうとしていた。

せっかくなので、前の方がよく見えるだろうし、行ってみようと誘って前の席まで移動した。

ちょうど前の方に幼稚園の友達がいたので、通路を挟んでその向かい側に座ることにした。

最後まで集中して見られるか少し心配だったが、様子を見る限り、本人なりに楽しめたようだった。

■握手会

イベント終了後は握手会。

ただ、入口付近にウルトラマンが待機していて、退場しながら少し触れ合うという形式だった。

確かに、あまり長居すると後ろの人たちにも迷惑がかかりそうだったので、こちらも写真を連写して、手短に済ませた。

■お祭り

イベントが終わった後は、町の商業会（？）が開催しているお祭りの方へ。

巨大なピンボールに挑戦したところ、連続で当たりが出た。

その一方で、輪投げは相変わらず一つも入らず。何か練習した方がいいのかな……。

友達にも会えたし、全体的に楽しめたと思う。

来年も同じようなイベントを開催してもらえると嬉しい。

■最後に

あのウルトラマンの目はずっと光っているけど、中の人はちゃんと前が見えているのかな？

Stripe Tour Tokyo 2026

Stripe Tour Tokyo 2026に参加してきました。

きっかけはAWS Summitの「ついで」

始まりは、AWS Summitの終わりにふらっと立ち寄ったStripeのブースでした。

仕事で前から気になっていたことをいくつか聞いてみたのですが、返ってきたのは「担当者に聞かないと分からないですね」という答え。そして「Stripe Tour Tokyoに来ていただければ、担当者と直接話せますよ」と勧められました。

実は昨年も行こうとしていたのですが、時間が取れずに断念していました。今年こそは、と思って参加を決めました。

朝ごはんを目指して、電車を乗り間違える

早く行くと朝食がもらえる、という情報を事前に聞いていました。

ただ、自宅から会場までは距離があるので、早朝に着くのはなかなか大変です。それでも「時間ギリギリには間に合うかな」という電車で出発したところ……乗る電車を間違えました。

思いもよらないタイムロス。遠方から都心のイベントに行くたびに、乗り換えの難しさを感じます。

幸い、告知された時間を過ぎても、基調講演が始まるまで朝食は出し続けてくれていました。ありがたい。

• コーヒーとお茶
• トルティーヤ
• おにぎり
• フルーツ

トルティーヤとおにぎりが並んでいるのが、グローバル企業の日本開催らしくて面白かったです。

天井の高いホテルで、ほぼ通常業務

会場は天井の高い、いわゆる高級ホテル。こういう場所に来るのは久しぶりです。海外の会社のイベントなので、外国の方も多く、少し海外カンファレンスのような雰囲気がありました。

そして正直に書くと、セッションにはあまり参加せず、ほとんど普通に仕事をしていました。

平日開催なので仕事もMTGも普通に入っていますし、Wi-Fiは会場で提供されていて接続も安定していました。席にも余裕があり、作業場所には困りませんでした。

一方で、気になった点もあります。

• 電源がない：15時ごろにはノートPCのバッテリーが18%に。冷や汗ものでした
• BGMがうるさい：これが一番つらかった。もともと音には敏感なほうなので、長時間いると正直しんどかったです

次回はモバイルバッテリーと、できればノイズキャンセリングイヤホンを持っていこうと思います。

お昼はすき焼き弁当

昼食はお弁当が配られました。何種類かある中から、迷わずすき焼き弁当を選びました。イベントのお弁当としてはかなり満足度が高かったです。

エンジニアと直接話せる価値

今回の一番の目的は、エンジニアブースでした。

とりあえずサブスクリプション関連のブースに行ったところ、「それならこちらへ」とAPI（開発者）ブースに案内してもらえました。対応してくれたのは、海外出身らしいエンジニアの方と日本人エンジニアの方の2人。

APIのアップグレードや、Webhookを処理するときのレートリミットなど、ずっとモヤモヤしていたことを直接聞けました。「結局こちらで工夫するしかないのか」という答えもありましたが、公式の人から直接聞いて納得できることにはやはり価値があります。

あと、英語にはなりますが、StripeにはDiscordのコミュニティがあって、リアルタイムで質問できるそうです。これは知らなかった。

👉 https://discord.com/invite/stripe

会場から「チームの質問」を集めてみた

せっかく担当者がいるので、会場から社内のチャットで「Stripeに聞きたいことはありませんか？」と呼びかけてみました。

すると、以前Stripeを使ったプロジェクトのメンバーから、こんな悩みが返ってきました。

• 決済審査の状況をメールで問い合わせても、返事が来るまで数週間かかった
• 「投げ銭」のような、物を売り買いしないサービスは審査に通りにくいのでは？

最初は質問が抽象的だったので、「なぜその質問をしようと思ったのか（何に困ったのか）」を聞き直してから、サポート担当のブースへ持っていきました。具体的な背景が分かると、相手も答えやすくなるのを改めて実感しました。

担当の方から聞けた話をまとめると、こんな感じです。

審査について

• 投げ銭のようにリスクが高いと見なされるサービスは、社内審査に時間がかかりやすい
• ただ、数年前までは却下していたものも、最近は「できるだけ検討して通す」方針に変わってきている

問い合わせの返事が遅い件について

• Stripe社内のやり取りは基本的に英語なので、日本語の問い合わせは意思疎通に時間がかかることがある
• 窓口は複数の担当者で対応しているので、メールではなく、ダッシュボードのサポート画面から「サポートケース」を作って、その上でやり取りするのがおすすめ
• 状況をできるだけ詳しく書いておくと、審査もスムーズに進みやすい

「メールよりサポートケース」という話は、Stripeを使っている人にはかなり役立つ情報だと思います。

ちなみに、別件の相談でも担当の方と長く話し込んだので、すっかり顔見知りになりました。こういう関係ができるのも、オフラインイベントの良さですね。

お土産はもちろんタオル

帰り際にはお土産が配られていて、Tシャツかタオルを選べました。

もちろんタオルを選びました。Tシャツはもう家に十分あるので、実用性で選ぶとタオル一択です。

感想：「仕事環境が充実したカンファレンス」という価値

振り返ると、平日参加ということもあって、内容は「いつもの仕事を場所を変えてやった」に近い一日でした。

でも、それが逆に良かったと思います。

• 仕事を止めずに参加できる
• 合間にStripeの中の人と直接話せる
• その場でチームの質問を集めて、すぐに答えを持ち帰れる
• 気になるセッションだけ覗ける

「仕事環境が充実している」こと自体が、このイベントの大きな魅力だと感じました。人混みや長時間のイベントが苦手な自分でも、自分のペースで過ごせたのは大きいです。

来年もまた行きたいと思います。次は電車を間違えずに、朝食の時間に間に合うように。