まえがき
みなさんいかがお過ごしでしょうか？
この記事を書いているのが3月中旬なので、一年の1/4が終わろうとしています。ついこの前年を越した記憶があるんですがね。
ただ、まだまだ寒い季節なので体調に気をつけながら頑張りましょう。
更新課題の続きのお話
先月の続きになります。と言っても先月は対応作業を進めていく...ってのとアプリケーションの不具合のお話でしたので、今回はその先のお話をしていきます。
サイトに表示する物件を管理する
物件王側の対応として対応サイトの仕様が変わりました。
具体的な仕様の内容は難しいので超簡単に説明すると、「サイトで取り扱うデータ」についての変更点があり、その変更点に対して適切な対応をするという内容です。
要するに皆さんが見ることのできる不動産の情報に変更点があった...みたいな感じで捉えてもらったらいいんじゃないかなと。
対応した作業内容は割愛しますが、今まで自分が触れてこなかった分野にまたまた挑戦することになりました。何せ、取り扱うデータを変えるわけですからね。
そのため、調べて試してと試行錯誤はしていたのですが、一向にうまくいきませんでした。
そこで、先輩と一緒に考えて対応していくことになりました。
発見
先輩と一緒に対応していく中で、この課題についてのある発見がありました。
それは”今回に限りなく、元々のコーディングに問題があった”ということです。
以前もお話ししたと思いますが、僕たちが作業する不動産サイトにはベースとなるもの「プロト」があります。
今回の課題の大元も「プロト更新」と言っているように、そのベースのアップデートをしようという内容です。
そのベース自体に問題があったというわけです。
これは更新作業のミスとかではなく、更新できている状態（現在の最新版）のプロトでも問題が残っているということですね。
この発見を経て、今回の課題では先輩サポートのもと無事解決に至りました。
ですが、それに加えて新たな課題を制作することになりました。
この課題は今回の不動産サイトのものではなく、次のプロト更新課題...つまり、対象となる全サイト＆次のプロトサイトに反映する課題です。
なんだか棚からぼたもち的な展開でしたが、いい感じに進展できたのは良かったと思います。
そしてこの件で更なる進展として、上記の課題を自分が作成することになりました。
このお話は次の月になるのでまた次回。ということで、以上でプロト更新のお話は終わりです。
対応作業自体はまだ残っているのでもしネタがあれば書きますが、多分これで終わりかと。
長い期間の対応でした。
コードレビューのお話
業務の中に「コードレビュー」と言うものがあります。
これは「他者が記述したコードを第三者視点で確認して間違いや非効率性がないかをチェックする」ことです。
コーディングには正解っていう正解はありません。何かやりたいことがあったとしても何通りもやり方があります。
その中で、「ベスト」ではなく「ベター」を探すことが大事です。「最も良い」ではなく「より良い」ですね。
そこで、その質を高めるために「コードレビュー」を行っています。
自分はまだ初心者同然のコーダーですが参加させてもらっています。
自分の知識を深めたりするのも目的ですが、初心者ならではの観点で質問ができると良いよねっていう趣旨があります。
今までも何度か行っていたんですが、今月良いレビューができたことがあったのでそのお話を。
違いの必要性
今回は外部のリンクのURLに関するものでした。
細かい内容は説明も難しいので割愛しますが、コードレビュー時に「元々のURLではないものを記述している」と、担当コーダーの方がお話されていました。
ですが、「なんで変えたのか」という理由の部分が明確ではなかったのです。
個人的に記述の意味がわからなかったこともあり曖昧な質問ではありましたが「何が違ってその記述に変更したんですか？」とお聞きしたところ、明確で良い理由や経緯がなかったのです。
自分も作業をしていて、そういう時があるから共感できたのかもしれませんが、「なぜ？」に気づくことができました。
コードレビューでは僕だけでは勿論なく、先輩の方と一緒に行っています。が、今回の件は先輩も違和感は持っていたものの、見過ごすところだったらしいので結果的に良いレビューになりました。
毎日行っている終礼でもそのお話が出てきて、「良いね！」って言っていただけたのは良かったし、レビューもいい業務内容だと感じました。
少し気にしていたこと
毎回レビューの時に気にしていたこととして「僕が指摘していいものか」という気持ちがありました。
僕が一番新入りということはそれ以外の人はみんな先輩なわけで、コードの理解とか技量については僕よりも上です。
僕の根っからのネガティブ思考も相まって、「僕なんかがあれこれ言うのはちょっと失礼になっちゃうのかな？」なんていう気持ちになっていました。
業務として考えたときに、そう言った考えは良くないですよね。
先輩も人間ですから間違えるときはあります。だから謎の上下関係を持ち込めばその間違いを抱えたまま商品をお客様に届けることになってしまいます。
そうなりゃダメですよね。 ...って頭では分かっているんですが感情というものは面倒で、自分の理解とは反してくる時も多いです。
そんなお話を先輩にしたところ、「そんなふうに思わなくていいよ」とおっしゃった後にある一言をいただきました。
「レビューするときは間違い探し感覚でやるといいよ」
自分の解釈ですが、言い換えると、「レビューとして指摘する」という考え方だと変な感情が入り混じるが、「間違いを探す作業」としてしまえば、ただ間違いを探し出しただけになるよねってことだと思います。
こうやって、業務でも考え方や捉え方の変換が大切だなと思います。
自分もそう言うふうに考えることが多かったのですが、仕事の業務となると頭が硬くなっていたので考え改めることができました。
上記のようにいろんな捉え方で業務をすれば、モチベーションとか人とのコミュニケーションとかも意外とすんなり乗り越えることができるのかもしれませんね。
ポジティブコアワークのお話
社内でポジティブコアワークというものに取り組みました。
趣旨をざっくり説明すると、
【自分のポジティブな軸を発見し、自分の強みにして業務をワクワクした気持ちで取り組もう！業務を活性化させよう！】
みたいな感じです。
内容としては、今までの自分の経験を振り返って、そこから自分の強みみたいなものを抽出することと、今までの経験の中でワクワクした体験を書き出してそこからいろんな観点で自己分析をするという内容。
最終的には、チームメンバーで質問しあってお互いの理解や自己理解に努めるという内容でした。
僕は普段自己分析を絶やさず行っています。というとなんかすごそうですが、案外そんなすごいことではないです。
お風呂とか掃除とかしているときとか、日常の一瞬一瞬で「今の自分はどうだろう」と調子や素直な思いを頭に浮かべてみたり、本来の自分のしたいことや目標を考え続けるだけです。
これには正解も不正解もありません。今回のワークもそうですが。
ただこうやって自己理解に努めるのはそんなに難しくない上に大切だなと思います。
自分の現状などを理解することで、自分の今向いているベクトルを再確認することができるんですよね。
さらに、自己分析した結果、自分が今やらないといけないこととか逆に頑張らなくてもいいことも見えてきたりするので、それによって自分の行動が変化していきます。
あとはアイデンティティの形成にも繋がるのではないかな？きっとそうです。
精神医学的な観点でもこういう自分のことを考えることは大切なんじゃないかなと思います。が、自分のようにメンタル貧弱人間だと最終的に傷つくこともあるんですよね。
そうなると本末転倒じゃんって思うかもしれません。
ただ、自分がやり続ける理由としては今の自分に「即席の自信」をつけることができると思っています。
ブレることのない強い意志や自信よりかは弱いですが、「これからは分かんないけど、一旦今は大丈夫だ」って思えるんですよね。だから自己分析とかそう言った類は常日頃からやるようにしています。
今回のワークもそれを紐付けながら考えました。なので、コーダーとしてのエピソードというよりはクリエイターとしてのエピソード中心でした。
ですがチームのみなさんにとって新鮮なエピソードになったかなと思います。
他の方のお話なので内容は伏せますが、自分も気になったことをいくつか質問して「そういう考え方もあるんだな」って発見することができたのは良かったです。
質疑応答のお話
みなさんも日々学校や仕事など色々な場面でミーティングや話し合いの場があると思います。
そこでは必ずと言っていいほど「質疑応答」の時間があるのではないでしょうか？
「何か質問はないですか？」と聞かれて中々発言できないまま終わってしまいがちな時間ですよね。
自分も色々な業務に関するミーティングに出席するのですが、中々質問できないことが多いです。
よく「何でもいいから言ってね〜」とか「遠慮はしなくていいよ〜」と言ってくださるので理解しているんですが、そもそも「なんでも」すら出てこないんですよね。多分みなさんも経験が多いんじゃないかなと思います。
実際後々考えてみたりすると「あ、これ聞きたい」って出てくるんですがその時はなぜか出てきませんよね。
「何か質問出て来いっ！」って毎回思ってはいるんですがね〜。出てくる気配すらない時もあります。
そんな私ですが、先日のとあるミーティングで二つほど学びを得ました。
話題やテーマの周りからいく
例えばPHPについてのミーティングの時。
質問を考える時は「PHPの...何かないかな？困ってたこと...」って考えてました。
ですが、先日のミーティングでその周辺から突いている質問がありました。
例えば「本買う時に何を基準に考えていますか」とか、「課題を受けた時どんな考え方で捉えていますか？」とかです。
「PHPで、ここをこうしてこうしたときにこれが分からなくて〜」と、具体例を持っていればいいんですが、それだと中々難しい。なら、とりあえず「なんか困ったことあったな」から始まるのならば「解決するには学びが必要」と変換し、「学びが必要なら学ぶものが必要」、「本とかいいんじゃないか」から「どうやって選んでどうやって読むのがいいんだろう」につながります。
そうすると、自ずと質問が湧いて降ってきます。
ストレートにいくのもありですが、回り道をして自分の知りたいことの断片を聞くっていうやり方です。
分からない時分からないって言う
何かを教えてもらった時に「分からなすぎて質問も浮かばないからどうすればいいんだ」ってなってました。
そう言う時は「何が分からないか分からなかったです。」って言いましょう。
なんだかバカらしく聞こえるかもしれませんが、これが大事。
やりたいこととかそう言う大目標的なのは理解してるけど、何でそれがここに繋がっていくのか？が分からなくて...というか今何が分かっていないかすら分からん。
そうなることって特にエンジニアの世界だと多いんじゃないかなって思います。
コードとか難しいですし、多少読めるようになってきたもののぱっと見呪文ですからね。
なので相手に「結局わからなかったです！」って言ってあげる方が逆に親切かと思いました。意思疎通ができますからね。
こう言うのは日々の会話でも大切だな〜と学びを得ました。
あとがき
ということで以上が今月号でした。
業務の進展もあり、また考え方とかのお話もあっていろんな経験談をお話できたんじゃないでしょうか？
記事を書くときに前回の号の文章を読み直してから書いているんですが、回を重ねるごとに成長している感じがしますね。
失敗談の中に気づきがあるので、自分自身も学びを得られるなと思います。
また来月も色々お話しできればいいな。それではまた。