今期に入ってメンバーが私1人から新人(2年目)とパートナーさんが追加されて3名体制になったので、情報格差をなくすための活動に勤しんでいる。
以前にいたメンバーはそれなりに最初からRailsに詳しかったりしていたので、そこまで情報を整理しなくても勝手に学んでくれていたが、それも今思ってみるとある種の属人性と、私と年代が近く、同じ場所で働いているからお互いにサクッと聞ける、という環境メリットがあったからだなと思う。
しかし現代は令和となり、新型コロナの影響でリモートワークを余儀なくされ、メンバーの年齢は干支一周かそれ以上くらい年の離れているので、サクッと聞きづらいところもあろうかと思う。ましてや私は今や髭面坊主なのだ。
まぁ開発に取り掛かる上での情報はある程度は整備していたし、docker-composeでサクッと開発自体は開始できるようになっているし、参加しているうちにわかってくるかもなぁ〜と思って放置していた部分もあって、👨🦲「どちらかというと技術力の底上げを頑張らないといかんだろう」と当初は思っていた。しかし、これやっぱり順序が違うかな？と思うようになってきた。
プロジェクトに対する情報格差を減らしたい
プロジェクトの概要とか、機能説明についてはプロジェクトに参加してもらう時点で一通りしているのだが、やはりコードを理解するには仕様の理解やライブラリの知識が必要となる。作る時点では、gemを導入で色々と検討したものがgitのログにあるし、DB設計もそれなりに行ってannotateでドキュメントを残したつもり…となっているが、やはり途中から参加したメンバーにとっては情報がいろんなところに散らばっていてわかりにくいだろうし、そもそもgitのログから探そう、という発想にもなりにくいだろう。
そこで、情報格差を減らす方策を行うことにした。
DBのカラムにコメントを追加した
これは最近取り組んでいたことでブログにもまとめてある。まぁ具体的にどういうことをしたかはそちらを見てもらえばいい。
RailsはMVCアーキテクチャのフレームワークなので、コメントを追加してannotateで出力するだけでもわりかしModelに関してのドキュメントは充実するのではないか？と思う。特にカラム名だけ見てもぱっと見で意味がわからないやつとか、enum使っていて数値の表す意味がわからないものとか。
リファクタリングデーを設定した
これは2回ほど行ったのだが、よい取組になったと思っている。最終的にはメンバー全員にプロジェクトの全体を把握してもらいたいわけなので、よく使われている機能から優先的に、実際に動かしてもらい仕様を把握してもらいつつ、コードを読んでもらってリファクタリングデー当日までにチケットを作ってもらっておいた。そして、当日はその中から取り掛かれそうなものに取り組んでもらう。あくまでもリファクタリングのため、仕様が変わるような修正は受け付けないけれど、アイデアはチケットとして残して検討後に対応することにしている。
1つの機能について、メンバー全員が同時に取り組むため、確認もしやすいし質問もしやすい。状況によってはペアプロに移行することもできる。いつもより、コミュニケーションが活発になったかなと思う。
実際のところ、大きなリファクタリングをするのは難しかったのだが、細かい使い勝手や、キャッシュできる箇所の選定や処理の共通化程度は行うことができた。
これは今後も定期的に行っていこうと考えている。
意識してチケットの粒度を下げた
これは1on1をしたときにアドバイスを貰ったこと。もともとは個々の裁量に任せたいという気持ちが強かったのだが、そもそもまだ個々で判断して動けるレベルに到達していない場合は、こちら側で粒度をコントロールして、より小さく、より具体的な情報を与えて導いていく。そうすることで、情報格差は減り、何をしていいかわからないということは減るのでメンバーは動きやすくなる…のだが、チケット管理の手間がかなり増えるので私の負担が増えることになる。が、今後成長してくれば、この投資コストに見合うようになる筈！と思って当面頑張って粒度を小さめにしていく。
Gemfileにコメントを付けた
ライブラリの概要を知らないと、同じような機能を持つgemを知らず知らずに追加してしまうことがあったり…。また、今後削除していきたいと考えていたgemを新規開発に使われてしまったりすることもあり得る。
これはやってみて思ったことだが、自分の中でも何のために入れたかうろ覚えになっていたgemがいくつかあったので、自分の中でも整理することができてよかった。調べる過程で、もうメンテナンスが放棄されているgemも見つかった…💀あとバージョンを固定したままになっているものがあったりとか。なるべくバージョン固定は外していきたいのだが、テストが落ちたりして固定したまま放置していたものなどがあった。リファクタリングでgemを削除していくときにもヒントになるので、やってよかった。
どんな感じで書いたか、一部を抜粋する。
source 'https://rubygems.org' ruby '2.6.6' gem 'rails', '6.0.3.5' gem 'pg', '~> 1.2.3' # ActiveRecordでPostGISを扱うために追加 gem 'activerecord-postgis-adapter' # 簡潔な記述で綺麗なフォームを生成する gem 'simple_form', '~> 4.1.0' # テンプレートエンジンslimをrailsで使うためのライブラリ gem 'slim-rails', '>= 3.0.1' # 半角全角変換などに特化したgem gem 'moji' # Excelファイルを生成するためのgem。読込はできない。 gem 'caxlsx' gem 'caxlsx_rails' # 親子関係を管理するためのgem gem 'ancestry' # 検索を簡単に実装するためのgem gem 'ransack' # 論理削除実装用gem gem 'kakurenbo-puti' # ...省略
まとめ
まずは情報格差を減らし、プロジェクトへ参加しやすい道を作ってから。暗黙知を形式知に変えていけば、学習曲線もよくなるだろう。そうなれば、自ずと技術力はついてくるようになる、はず…。そう考えて、今後も情報格差を減らしていくよう頑張る。
