これから学習したいことの整理

新しい会社に入ってもう半年が経つ。webエンジニアとして働いている中でもっと勉強しないとなーと思うことがたくさんある。 それらを整理するため文章を書く。だらだらと書きながら整理する。

技術力

技術力を高めましょうというフィードバックを上長からもらっているし、普段の開発をしているときにも同じく思う。技術力を高めなければならない、と。で、技術力を高めるにはどうしたらいいのか、技術力とはいったいなんなんだろう、という疑問が浮かぶ。

いまはRubyを使ってRailsのフレームワークで開発をしているので、その言語とフレームワークに精通することなのか。確かに言語とフレームワークに詳しくなれば、これやりたいからこういうメソッド使おう、と思うことができる。けれど、開発をしていて思うことはそれ以前の能力が足りてない気がする。

まず、チケットに書かれた要件を達成するには何を知ればいいのか、という判断が遅いときがある。チケットに書かれているのは追加開発・改修する機能の一部だ。なので、機能としてどのような場合にどのような期待がされているかを把握しないとならない。この把握能力を向上させたい。「技術力がある」と漠然とした印象を受けるエンジニアは、早く・正確に把握しているように思える。で、把握能力を向上させるには何を知ればいいのか。コードリーディング力はまずひとつ挙げられる。コードだけではなく、どのようなテーブルのどのカラムにどのようなデータを格納しているのか、を把握している。それをコードリーディングというのかもしれない。自分の認識が狭かったのかもしれない。技術力のひとつの要素は早く的確なコードリーディングといえる。これを向上させたい。でもどうやって？テーブルとカラムの情報はいまでも把握できているはずだ。何が足りないんだろうか。

それはきっとコードとサービスとしての提供する機能の結びつきかもしれない。こういうコードが書いてある、その場合、エンドユーザーがこういう動きをした場合、こういうデータができる、ということを簡潔に説明できるほど把握できていない。いまの自分は、ユーザーがこういう動きをしたらDBはどうなっているの？と聞かれたときにさっと答えることができない。デバッガで止めないと答えられる自信がない。んーこのあたりな気がする。コードと現実の振る舞いの結びつきを把握する力が足りない。過去にも同じようなことを記事にした覚えがある。

で、そのコードと現実の振る舞いの結びつきの把握が弱いため、適切に会話できないことがある。仕様決めの会議で自信を持って発言はできないし、本質的な意見が言えていない。さらに技術力のある方の会話を理解することができないでいる。これがすごくマジでとても悲しいので改善したい。会話できるまで理解することが大事だ。部分的な理解で終わっている。理解を急がないことはひとつの対策としていえる。んーもっと行動に落とし込みたい。

技術力のある人と自分との差分を感じることはメソッドの細かさや処理の汎用性や既存処理に不要に影響を与えない書き方などメソッドの単位や作り方も挙げられる。コードが美しいとすら感じることがある。このへんはPRレビューしているので、学ぶことができているし、自分でも少しはできるようになってきたつもりだ。

ここまで書いて、やっぱりコードリーディング力がもっとも向上させたいと思った。コードリーディング力を分解できないか。処理はざっくりDBの読み込みと書き込みなので、そのI/Oを把握する。プログラミング言語に限らない能力だと思う。どんな学習方法があるのだろうか。実地あるのみか。

あとは、DB設計について。設計能力が足りない。そして現行のDB設計だと、この仕様は実現できない、というような判断ができない。だからビジネスサイドとの会話でこれってできる？と聞かれたときに意見が言えない。何を把握していれば答えられるようになるのか。テーブル構成とカラムが頭に入っているとして、新規テーブルが必要なのか、新規カラムでいいのか、であればどのテーブルに追加するのか、などの判断基準を持てていない。DB設計周りを再度学習したい。判断基準がないと漠然とした不安しか持てず、とても悲しい。悲しい気持ちにはなりたくない。

説明能力

技術的な話を言葉にして会話する能力がまだまだ足りていない。エンジニア同士で会話するときでも感じる。コードレベルで懸念していることを要件の文脈で語れてないな、と思うことがある。このファイルのここのメソッドが、、、という会話になることが多い。喋っていて抽象度が低いなーと感じるときがある。コードレベルと要件レベルの往来を自由にできるようになりたい。この課題自体の言語化があまりできていない感があるけれど、まあ仕方ない。

改善能力

改善活動が弱い。何が本質的な原因で再発防止にはどんな仕組みがあればいいのかを考える力が思った以上になかった。いくつか改善策を挙げることはできるけれど、表面的で効果が見込めないと上長から指摘をもらうこともある。真因と効果的な対策を考えることは難しい。このあたりは失敗に対する再発防止という営みについての知見をIT関わらず集めることが必要そう。発生対策と流出対策が必須という下記のスライドはとても参考になっている。

https://www.slideshare.net/yamaz2/wayofnotroublepptx

チームビルディング

スクラムチームのアウトプットの責任を負う役割を任されている。よりよいチーム運営をしたい。そのための知識が全く足りていない。まずスクラムに対する知識がぼんやりしている。これは現在進行系で勉強しているのでOKだ。また、開発組織の文脈のなかでのスクラムチームという視点も持ちたい。そのためにはもちろん現行開発組織を知ることと、開発組織がどういう構造であることが望ましいのかを知ることが必要だ。エンジニアリングの組織論についての興味も出ている。そういう本も読んでいきたい。開発組織の課題は何か、その解決のためにスクラムチームとして関心を持つのかどうか、どう解決していくのかどうかを考えられるようになりたい。

まとめ

技術力、説明能力、改善能力、チームビルディングの観点で学習を進める。どれからやろーかなー。

（了）