こんにちは。先日かかったことのないものに罹患して老いを感じるとともに健康管理について意識を改める年齢になっていることを感じています大田です。
エンジニアという職種は日々生産性に向き合っている職種と思いますが、開発グループの紹介を兼ねてそれぞれについて改めてブログにしたためてみたいと思います。
まずはスキルについてですが、開発グループでは下記の言語、ライブラリを採用してます。これらを扱えることが必須のスキルにはなります。
現時点で採用している言語、ライブラリたちざっくり
フロントエンド：Remix、Next、Maintine、Tailwind、URQL、TypeORM、Prisma
バックエンド： SpringBoot(Java)、DGS、FastAPI、Django
インフラ：AWS、Terraform、Ansible
データベース：PostgreSQL、Redis
その他：GraphQL
セマンティックバージョニング
言語、ライブラリ、ソフトウェアのバージョン管理に番号を割り振る決めごとがあります。
左からメジャーバージョン.マイナーバージョン.パッチバージョンのパートで構成され、
・メジャーバージョンは、後方互換性のないAPIを変更した場合
・マイナーバージョンは、後方互換性を保ちつつAPIを変更・追加した場合
・パッチバージョンは、APIに影響を及ぼさないバグを修正した場合
噛み砕いてざっくりお伝えすると、
・メジャーバージョンは、めちゃくちゃ変更あるとき
・マイナーバージョンは、機能足したり、ちょっと変更したとき
・パッチバージョンは、とりあえずバグ対応したとき
みたいな感じです。
言語やライブラリ毎にこれらの番号で最新版が管理されています。最新版を使うことはパフォーマンスやセキュリティなどが向上されているのであえて古いバージョンを使うことはよほどの理由がない限りありません。
上記で上げた言語、ライブラリは常にバージョンアップしてきますから、これらに追従する必要があります。
では、これらの言語やライブラリのスキルが身につけば生産性があがるのでしょうか？ブログへのアウトプットを踏まえて整理してみたいと思います。
他にも個人として持っておいたほうがいいスキルを上げてみます。採用しているライブラリ以外の事がたくさん含まれるはずです。
個人のスキル
採用している言語、ライブラリの知識は前提として、別で必要であるのことでいえば、
タイピングスキル（ショートカット含む）、ターミナル（黒い画面）の操作、仮想環境の操作（バージョン切り替え）、git操作、VSCodeやエディタの操作
HTMLの基本的な知識、CSSの知識等、SEOの知識、DNSの知識...色々あります。
Figmaなどワイヤーフレームを作る事ができることも、必須ではないけどあると良いスキルになります。
データベースの知識はアプリケーションを作る上でもアプローチが異なってくるのでここも個人のスキルに依存してきます。
AIの活用
最近のAIの利用について少し振り返りたいと思います。
ChatGPT
活用の機会が減りました。理由は、先に上げたセマンティックバージョンに対してGPTの回答が古い事があるからです。
ドキュメントやライブラリのコードを直接読んだほうが早いことが多々あります。
Github Copilot
タイピング量が減りました。文章で説明するのは少し難しいのですが、コメントやメソッド名でやりたいことを記述すると補完してエディタ上でサジェストされます。あとはタブを押すと展開され、タイピングしないで済みます。とてもわかりやすい効率化です。
生産性につながる？考え方などの紹介
1人で全ての開発工程を行うとすれば、個人のスキル=開発生産性と言えるかもしれませんが、チームで組織的に開発を行う場合は≠です。
先人達のたくさんの考え方がありますので簡単に紹介したいと思います。
設定より規約 CoC（Convention over Configuration）
設定より規約は、開発者の決めることをなくし、ルールによってソフトウェアを動作させる手法です。ざっくりいうと。
Ruby on RailsというRubyでできたフレームワークで話題になりました。
https://ja.wikipedia.org/wiki/%E8%A8%AD%E5%AE%9A%E3%82%88%E3%82%8A%E8%A6%8F%E7%B4%84
（この考えを踏襲したCakePHPなどもフレームワークも生まれたりしてまして、私も過去多数のアプケーションをCakePHPで作ってきました）
DRY原則（Don’t Repeat Yourself）
「同じことを繰り返さない」という考え方で、あらゆる情報について、様々な個所に複数記述するのではなく、1か所に記述します。
それにより、変更が生じた際に何か所もコードを修正することがなくなります。
例えば税率を計算する箇所が複数あったとして、税率が変更になった場合、複数に分散していると変更漏れが出てくるのは想像しやすいことかと思います。
https://ja.wikipedia.org/wiki/Don't_repeat_yourself
YAGNI原則（You Ain't Gonna Need It 原則）
ヤグニ原則は、システム開発の原則の一つであり、「必要なもの以外を実装するな」という考え方で、無駄なコードを書かないようにすることで開発コストを削減し、システムをよりシンプルに保つことが目的で、本当に必要になったタイミングで実装することを推奨する考え方です。「今後必要になる」という想定のもと進められた実装は意外と使わないことが多いという考え方に従うことで、余計なコードを書かずシステムの保守性や可読性が向上を目的とします。
https://ja.wikipedia.org/wiki/YAGNI
ベストプラクティス
言語、ライブラリの使い方で、これが最善と思われる手法のことです。
例えばディレクトリ構成はこの方法がよい、など、このように使うと良いという手法のことを指します。
AIに質問するときに「○○のベストプラクティスを教えて」って聞くと有益な回答が得られるかもしれない魔法のフレーズです。
コーディング規約
ライブラリ自体に規約が設けられていることもあったり、組織内で独自に規約を設けることがあります。
その目的はルールを統一することで、可読性を向上させたり、品質や効率も向上させることにあります。
たくさんの人が使っているオープソースにパッチを送るときはコーディング規約を守って修正リクエストを出す必要があります。
社内ではこの規約の整理には手が回ってませんが、プロジェクトに関与する開発者が増えると決めないおかないと行けないルールになります。
https://en.wikipedia.org/wiki/Coding_conventions
三点見積り
3つの視点で見積もりを出して計算する手法です。
・楽観的見積り（Optimistic Estimate, O）: 最も順調に進んだ場合の最短時間や最小コストを見積もります。すべてが順調に進む理想的なシナリオ。
・悲観的見積り（Pessimistic Estimate, P）: 最悪の場合にかかる最長時間や最大コストを見積もります。問題が発生し、すべてがうまくいかないシナリオを想定。
・現実的見積り（Most Likely Estimate, M）: 最も現実的な条件下で、平均的にかかるであろう時間やコストを見積もります。通常の進行状況を想定したシナリオ。
三点見積りの計算式は、「（楽観的見積り + 現実的見積り × 4 + 悲観的見積り）÷ 6」という方法で求めます。
社内でも三点見積りを参考に工数を出すこともあります。
プランニングポーカー
アジャイル開発で用いられる見積もり手法の一つで、各メンバーに特定の数値が書かれたカードが配布されます。
数値は通常、フィボナッチ数列が用いられたりします。全員が、このカードを元におよその時間を見積もります。そして議論して合意していきます。
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%9C%E3%83%8A%E3%83%83%E3%83%81%E6%95%B0
https://en.wikipedia.org/wiki/Planning_poker
開発における見積りは、そのとおりに進むほうが難しい側面がありますがこれらの手法を使って精度を高めていくということはできます。
継続的デリバリー
ソフトウェアの構築、テスト、リリースをより迅速かつ頻繁に行うことを目的してます。
端的に言うと、自動テストを回して、ソースコードが本番として利用可能になったタイミングで自動でアプリケーションを入れ替えて、人の手を介することなくできる限り機械的にリリース作業を実行して、効率化と品質を最速で回していこう。というものです。
単体テスト、ユニットテスト、自動テスト
ざっくりいうと、プログラミングで書いたコードに対してプログラミングで検査する。
というものですが、キャプチャで軽く説明しますと、
動作する処理に対して、期待値通りになっているかを検証します。期待値通りであれば成功となり、期待値と異なれば失敗となります。
テスト用のコードを書くのでその分時間がかかってしまいますが、ある変更が他にも影響していた、などを検知できるため、品質の担保と合わせて、結果として生産性の向上にもつながります。
（意図した日時に送信されていることをチェックしているコード）
余談ですが、弊社ではChatworkを自動でリマインダーしてくれるボットを自社で開発してます。
上記のキャプチャはそのテストの例です。
このボットが気になる、使いたいかもという方、いらっしゃいましたらご相談ください。
チームで考えると
例えば、3人チームに、
Aさん＝ベテラン
Bさん＝ベテラン
Cさん＝神レベル
というチームがあり、Cさんだけスキルが突出してたとしましょう。
そのCさんがブリリアントジャークだとしたら、という例えた言葉があります。Netflixがその方針を公開したことで広く知れ渡ったそうです。
https://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.html
自分だけがスキルを高めて個人の生産性を高めたとして、チームとして生産性があがるかどうかは別の話。というのは想像しやすいと思います。
ここはあの人しか出来ない、これはあの人がつくったからあの人しか触れないなどよくある組織課題と思います。
大事なのは、
- 個人でできることや知識を増やす
- チームに還元していく
の両方を日々やっていくことと思います。
結局のところ
開発の生産性という観点で言えば、現時点で言えば、チーム内にストレスがない状態は生産性が高いと考えています。
何かしらバグによる手戻り、調査、があればストレスがかかってくるでしょうし、その間予定していたタスクが後ろにずれるとそれはそれでストレスの原因になります。
また、特定の人にだけタスクが偏ると当然その人にストレスがかかってしまいます。
開発Gとしては、現時点での生産性をさらに高めるというよりも、上記観点での生産性の高い状態を維持していくために、やることをやっていくことが今のフェーズです。
（フルスタック70%という指標を設けてますが、現時点では計測してません）
将来メンバーが増えると一時的に生産性は落ちるかもしれませんが、事前に準備できることは準備して、新メンバー以外の生産性は落とさずに、新メンバーの生産性だけを上げていくアプローチを考えてます。（規約だったり、ドキュメントだったり、スキルレベルの定義だったり、座学で高めれるところは整理するなど）
終わりに
いくつか開発特有の考え方を紹介しましたが、別の職種でも活用できる考え方なのではと思います。
例えばGoogleWorkspaceのスライドをテンプレートとして作って使いまわそうとかはDRY原則に通づるものを感じたりします。
参考になれば幸いです。
おわり。
