最近は夢の中でもコードが出てくるようになりました。プロダクトチームの大木翔太です。
前回クリスマスに公開した「非エンジニアの僕が、Rubyを習得するまでの道のり（その１）」と同様、バレンタインデーである本日も、コードとにらめっこしております。
プロダクト開発をより良く進めていくために、以前から興味があったプログラミング言語を習得したいと思い、PR Table社で採用している「Ruby」の習得がはじまりました。
僕自身、PR Table社に2年前（2017年12月）に入社し、セールス→カスタマーサクセス→カスタマーサポートと移ってきました。
そんな非エンジニアの僕が、これまで見えていなかった視点についてお届けしたいと思います。
＜目次＞
- Ruby学習で行っていること
- 学習により見えるようになった視点
- 今後の学習の方向性
Ruby学習で行っていること
手を動かしながら学ぶのが一番であると、以前の記事でも書きましたが、現在はPR Tableの開発環境を自分のPC上で構築していただき、どのような仕組みで動いているのかを学んでいます。
プランナー業務としての新機能・改修系のタスクについても、実際の開発環境を手元で動かしながら原因調査を行っています。
やはり、手を動かしながら、対応していくことで知識の習得が促されるのを日々強く感じます。
学習により見えるようになった視点
開発タスクへの対応をエンジニア視点で見えるように
僕は、12月からプロダクトチームに異動となり、プランナーとして働いています。
当初は、新機能・改修タスクへの対応は、「現状の整理」、「変更後に想定している挙動」をエンジニアに共有することがメインでした。
たとえば、不具合対応の場合はこのようなイメージ。
① 発生している箇所の状況確認
② 不具合を再現できる条件の精査
③ 正しい挙動と整理
⇒ エンジニアに情報共有
しかし、表面上でわかる状況だけの判断だったため、共有後にエンジニアとすり合わせる時間が発生し、対応時間を無駄にしてしまっていました。
現状では、対応がこのように変化しました。
① 発生している箇所の状況確認
② コードベースで、発生している箇所の特定
③ 不具合を再現できる条件の精査
④ 不具合の解決方法を思案
⑤ 正しい挙動の整理
⇒ エンジニアに情報共有
上記のように、コードベースでの会話や解決策の仮説をもって共有できるようになったため、初動を早くすることができました。
今後の学習の方向性
現在、プロダクトチームではエンジニア採用を積極的に行っている状況です。また、先日のリニューアルに続き、新機能の準備を進めております。
また、個人的な関心事としてプロダクト開発のエンジニアリング部分を行っていきたいため、学習の幅を広げております。
こちらの記事を参考にすると学習の今後のSTEPでいうと、全STEP24のうち、僕はまだSTEP6のようです。（道のりは果てしない......）
次回予告
徐々にプログラミングとはなんぞや、というのが理解できてきたのですが、PR Tableがより良いプロダクトになるために、自らができることを増やしたくなってきました。
そこで、細かな改修対応にはじまり、さらにコーディング業務に挑戦していく予定です。次回のノウハウでは、その過程をご紹介できればと思います。
