【就活】STAR〜part 1〜

やかんです。

今回も就活回です。いやー、就活って思ってたよりも大変なんですね。。すみません、今まで誤った認識をしていたかもしれません。世の中の全就活生に拍手喝采ですよ本当に。

因むと、スタンディングオベーションの「おべーしょん」の部分はovationです。拍手って意味らしいですが、初めて知りました。

STARというものがあるらしい。

こちらもまた初めて知ったことですが、世の中にはSTARというものがあるらしいです。「何かを相手に説明するときのメソッド」みたいなイメージですかね。

それぞれ頭文字を表していて、

• S…Situation
  • まず状況を説明しろと。
• T…Task
  • 状況から考えて、タスクとして何が必要だったの？みたいな。
• A…Action
  • 状況とタスクを踏まえた上で、自分何したん？っていう。
• R…Result
  • で、結果どうだったん？っていう。

はい。以上がSTARメソッドの概要になります。

そして今回は、このSTARメソッドにのっとり、自分の経験を整理し直してみようっていうそういう試みになってます。

では、順次振り返る。

時系列で振り返っていきますか。

プログラミングを勉強したい（大学1年春）

• S…状況としては、「プログラミング勉強してえ！」ってところですかね。
• T…タスクっていう概念あるのかなあ。ないよね。まあ、勉強しろ！ってところですかね。
• A…自分で勉強してもよかったんですが、プログラミング系のサークル入ってそこで実務やりながら学んだ記憶。
• R…学習の初手でブーストがかかった感じで大変よかった。

これはそもそもSTARに当てはめて説明するようなことでもない気がするけど。あと、Resultの部分が主観的評価なのは今ひとつなのかな？

もっとプログラミングしたい（大学1年夏）

• S…プログラミングにハマったわいはもっとプログラミングしたいと思った。
• T…略。
• A…実際に働けばいいんじゃね？ってことでインターン応募して2社採用もらった。
• R…勉強しつつ実務に参加させてもらいつつでいい経験になりました。

これもまあ同じようなツッコミかな。。てか、主観的評価にとどまらない結果ってあるんかね？

初めて（いい意味で）丸投げ系の業務に取り組んだ（大学1年終盤）

今も働いているスタートアップにjoinしました。そこでの出来事です。

• S…新入りの立場で、チームが抱えているタスクの消化を依頼された。まあ、依頼してもらったって感じなのかな。
• T…シンプルに目の前のタスクをこなそうっていう。多分、コーディング規約に慣れるとか、そういう側面もあった。チームに慣れるとか。
• A…まずリモート論外で出社したよね。で、チームに入って初期は「自分の色を出さないようにする」っていうのも大事だなと感じたんだ。チームはすでに文化を持っているから、まずはそれを受け入れてそれに染まってみるっていうのが大事だと思って、色々気になることはあったけど一旦、積極的な意味で「言われたことをやる」ということに専念したんだ。
• R…チームには馴染み始めたんじゃないのかな？あと普通にタスクを完了できた。そんで、自分の現状の能力値を正確に相手に示すっていうことも、第一歩としてできてたんじゃね？

結構良いまとまり方をしたのでは？

まあでもこれもまた「Resultが弱いですね」とか言われるんかな？いやだって、当時必死に業務やってたからResultの部分とか注視してられんわ！

これは失敗談だけど、バグらせた（大学2年春）

これは大学1年だったか大学2年だったか覚えてないんだけど、まあその辺の出来事。会社のサービスを一部壊してしまいました。

• S…業務開始から間もない頃、一部リファクタをお願いされた。当時はまだ自社サービスについて理解も浅かったから、どこが「特に重要か」とかわからなかったよね。目の前にコードがあるだけだったわ。
• T…タスクとしては、まあリファクタだよね。確か、コードが不用意に複雑になったり行数稼いだりしてたから、その簡素化がタスクだったと記憶している。
• A…一生懸命、「コードを」よくしようとした。で、コード自体は綺麗になったと思っている。gitのPRで行数減ってたし。確か。あんま覚えてないけど。ただ、本当に「コード」しか見ていなかったし（つまり動作確認はしていなかった）、最終チェックみたいなのやってなかったよな。。
• R…まあ、バグりました。すっごい些細なミスだったんだけど、それが原因でサービスにバグを生んでしまいました。

はい。いやー、今となっては懐かしいですが、かなり自分の中では印象深い出来事だよな。

あと、めちゃめちゃ恥ずかしいんだけど当時のブログ残ってました。こちら↓

https://yakan.blog/mistake1

で、後日談的にResultの部分についてもう少し。

この失敗については、結構落ち込んだ記憶があります。その結果、バグとかの異常事態を恐れるあまりすっごい縮こまって業務してた気がする。全然楽しくなかった期間が続いた。あと、今となっては「何かあっても治せる」という自信みたいなものが多少ついているけど、当時はマジで何もわからんかったしな。

というわけで、これは結論から言うと、自分で状況を打破することはできませんでした。

自分で状況を打破することはできませんでしたが、チームのエンジニアリーダーに助けてもらったことで復帰しました。具体的には、「コードのレビュー体制とかにも原因はあるだろうし、コードの品質はチームで担保するもんやで」的なことを言っていただいた記憶。

で、これを経てからはやっぱりチームの先輩エンジニアへの方々へのリスペクトは一段と大きくなりましたし、「信頼」というものを実感し始めたと思ってます。そこからは、楽しく気負わず、それでいて責任を持って業務にあたることができていた気がします。

なんかちょっと美化が入ってる気がしなくもないけど、まあ、次に行きましょう。

書くに値するかわからんがサークルのHP作ったよね（大学2年夏）

• S…友達がいるサークルから、「HP作ってよ」ってお願いされた。自分で何かを作る経験に乏しかったから、結構嬉しくて張り切っていた記憶がある。
• T…タスクを自分で切ることがタスクだったのはひょっとしてこの時は初めて？
• A…まあ、一生懸命作りました。デザインからやったな確か。一応「クライアント」的な人がいたわけだから（サークルの人ね）、その人と色々スリ合わせることをかなり心かけた記憶があるんだけど、上手くいってたんかな？
• R…まあ、HPが完成しました。

これが仕事だった場合は、それこそ自分の働きについてクライアントポジションの人から意見とか聞くべきだったんだろうなあ。当時の自分の働きはけっこう反省要素が多いな。

はいー、反省会です。箇条書きで反省するという悪態ぶりですがご容赦ください。

• クライアント側の人のリテラシーのなさに正直驚愕した。ここで、ちょっとめちゃめちゃ最悪なんだけど、若干舐め始めた節あるよね自分。やばいな、これは。2度とやらん。反省だ。
• 上記のことを反省するなら、進捗の共有とかは相手の人にもわかるように行うべき。これは、「共有を重んじるために、積極的に共有しない事柄があってもいい」ってことなんじゃないかなと今は思っている。

あー、なんか、反省してて思い出したわ。これ、自分の仕事が本当拙かったから、後々自分が苦労したんだよね。こういう形で思い知ることになるのか。。

まあ、言ってみれば自分で仕事もらって、自分でタスク切って、クライアントポジの人と擦り合わせて、自分で実装して、自分でリリースするっていう「まるッと」系の出来事はこれが初めてだったもんなあ。。失敗ばかりだったなあと実感。

まあ、失敗が故に生じた自分の身の上への苦労はちゃんと逃げずに向き合えたんじゃないかな。しんどかったけど。これで逃げてたらまじでどうしようもなかったかもだけど、まあ、及第点あげてもいいのかな？

うん、めちゃめちゃ書くに値する話だったわ。こういうのがあるから、就活も無駄じゃないよねと思ったりします。

初めて自分でプロジェクトを持ったのってこの時だっけ？（大学2年夏）

サークルのHP作成はあくまでプライベートな話だったけど、会社でプロジェクト任されたのは多分これが初めて。まあ、「プロジェクト」っていうと大袈裟な気もするが。

• S…SaaSに付随するとある機能のフロントエンド（あとそれに伴うバックエンド）の開発を任された。先輩エンジニアが結構要件定義はまとめてくださっていたので、「何をするか」は明確だったような。あ、あと、デザイナーの方とのコミュニケーションは僕がやってたっけな。すごい良い方だった記憶。
• T…タスクは、要件定義に則りつつ、適宜自分で気づいたことをやるっていう感じかな。あと、もちろん「暗黙のタスク」として、綺麗にPRまとめるとか、安全に開発しようねっていうタスクはもちろんありました。
• A…まず普通に実装。で、履歴等丁寧に残しつつ、PRにする。あと、typescript導入したのってこの辺だよね？確か。
• R…これがさー、、まあ、うまいことまとまりはしたんだけど、「はい！完璧にできました！」とはいかなかったんだよねえ。。当時の自分には結構難易度高かったのかなあ。。

なかなか「自分の取り組みめっちゃええやん！」とはならないんですよねえ。

これは結構ボリューミーな出来事なので、甲斐甲斐しく「よかった点」「反省すべき点」の2項目で列挙してみますか。

まず、よかった点。

• コミットの残し方とかブランチ戦略とか、自分主体で積極的に考えることができた。そして、失敗もありつつだったけどこの点は「いいね！」と言ってもらった気がする。
• PRも丁寧にまとめるようにした。エンジニアチームのために、という側面もあるが、PRを丁寧にまとめることで自分の作業もまとまるから、これはよかった。
• 前にバグを作った時の反省から、動作確認系はしつこくやったんじゃないかなあ。
• Typescriptを導入したのは我ながら「よくやったやん！」と思う。まあ、反省すべき点もあるんだけど。まあでも、開発の文脈で「長期的視点」を持ち合わせていた説が濃厚。ええやん。
• DB設計にも取り組んだのは、プラス評価。外部キーとか中間テーブルとか初めてだったけど、臆せず取り組んだのは、よく頑張ったと思う。

反省すべき点（改善点）

• 技術的に当時はできなかったんだけど、テストコードは書いておけばよかったね。客観的な指標にはなり得るから。絶対ではないけど。
• Typescript導入は、プラスの評価もできるけど、不要にスコープを広げてしまった側面もある。別タスクとして切り分けることも検討していればもっとよかったかも。
• これが一番の反省点だけど、最後までやり切ることはできなかった。9割でダウンした。
• ダウンする際、「何が済んでいるか」「何ができていないか」とかをまとめて引き継げていたらまだよかったんだけどなあ。ギブアップして、そのままフェードアウトした気がする。。情けなすぎるな。

反省点の3、4点目について、詳しく振り返っておきましょう。

こちらの業務について、当時の僕は完遂することができませんでした。9割くらいのところでダウンしました。

うーん、当時の最善は尽くしたと思うんだけどね、、シンプルに実力不足でした。やり残りしたこと、追加でやる必要が出てきたことについては先輩エンジニアが巻き取ってくれました。

先輩エンジニアの方々には本当に感謝が尽きないです。いつもありがとうございます。

で、実力不足で開発を完遂できないということは、それ自体そこまで問題ではないと思います。背伸びして届かないところについては、先輩等に任せた上で、実力を養ってから挑戦したらいいと思います。分業ってやつかな？もちろん、無責任とは違うっすよ。

ただ当時の僕の場合は、「完遂できない」と分かった後の自分の行動に問題があったなと。せめて、「ここまではできました」「ここから先はできません」という情報はきちんと伝えた上で、残りの業務をお願いするべきでした。当時はそれができずに、「すみません、あとよろしくお願いします」だけ伝えてフェードアウトしてしまった記憶。

まあ、しっかり反省して同じ轍を踏まぬようにって感じですかね。

なんか、思っていたよりも長くなってしまっているので、一旦この雑記は一区切りとします。

最後までお読みいただき、ありがとうございます。