0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Developers Summit2025のレポ、ではなく実践してみようと思ったことをまとめてみた

Posted at

Developers Summit2025に参加しました

2025/2/13-14に目黒雅叙園で行われたDevelopers Summit2025に参加しました。
初めての参加だったのですが、学びになるセッションが多く、とても楽しいイベントでした。
何より、開発者主役のカンファレンスというのはそれだけで気分が良かったです笑

レポートを書いてもいいのだけど

多分レポートはCodeZineでのオフィシャルなものや、弊社の他のメンバーが書いてくれると思うので、私の方では自分のチームが抱えている現状の課題に対して学んだことを突き合わせてこんなことしてみたい、こんなことを実践していきたいということを書いていこうと思います。

コードレビュー観点を事前に決める

コードレビューについて現状、チームが抱えている課題は

  • コードレビューの質にバラつきがある
  • コードレビューの量が多すぎる
  • コメントをしたことへの対処はされても、本質的な部分での改善がされない

というようなことです。

特に場当たり的に対処がされて、本質的に何が良くないのか、どうすれば良くなるのかということを理解しないまま対応をしていると思われることが多々あり、同じようなコメントを繰り返ししていることが多々あります。
それによって、いつまでも手戻りする量が改善されず、結果的にコードレビューの量も多くなり、時間を圧迫しているというのが現状です。

これに関して、下記の改善をしていこうと思っています

  • 実装を始める前にコードレビューの観点をチームで決めて同意を取る
  • 開発者はプルリクを作成する前にコードレビューの観点を元にセルフチェックをする
  • レビュワーはコードレビューの観点を元にレビューをする

スクリーンショット 2025-02-14 23.42.05.png

レビュー観点を事前に決めておけば、実装をする時にもそれを気にしながら実装をしていけるし、セルフチェックを入れることでレビューの量も減らすことができると思います。
また、レビュー観点は実装前なので具体的なものというより、本質的な部分での観点になると思うので、それによって何が良くないのか、といったことへの理解も進むのではないかと思っています。

PRFAQの作成

新機能を開発するに時、いつもぶつかる問題としてゴール設定に認識がプロジェクトメンバー内でばらつきがあることや、潜在的なリスク分析が甘いということがあります。
そこで、PRFAQを最初に作成し、プロジェクト内でのゴール設定や、潜在的なリスク分析を行うことで、新機能開発のスムーズ化を目指します。

また、テストの段階においてもPRFAQで定義した内容に実装されたものがマッチしているかをテストすることで、非エンジニアにもわかりやす形で品質が担保できていることを確認してもらえるのではないかと思っています。

仕様駆動テスト

テストファーストについてはここ半年くらいで少しずつ実践していたのですが、基本的には

テストコードを書く → 実装する → テストを実行する → テストが失敗する → テストを通るように実装を修正する → テスト成功 → さらにテストを追加する ・・・

といういわゆるTDDのような形で実践していました。

今回参加したセッションでもTDDを採用している話もあったのですが、先に完全にテストコードを書き切ってから実装する、という話もあり、その手法を一度取り入れてみようかなと思いました。
というのも、その手法だと下記のメリットがあると感じたためです。

  • 完全なテストコードを事前に書くためには完全にふるまいを定義しておく必要があるので、テストコードがそのままふるまいの説明にもなる
  • 実装前にテストコードだけの時点でレビューを行うことは、ふるまいのレビューにもなる
  • 先に書いたレビュー観点を事前に決めておくことと合わせることで、内部品質・外部品質ともに認識を合わせてから実装に取り掛かれるので、よりよいコードになるはず

実際、コードレビューのタイミングで「これ思ってたふるまいと違うな」みたいなことも多いので、それを防ぐことができるのではないかと思います。

もちろんあまりにも完全さにこだわりすぎるのも良くないと思うので、その辺りは実践しながら調整していければと思っています。

トラシューアニマルなのかもしれない

これについては実践というより、よくぞ言葉にしてくれた、という感じです。
自分はトラブルに限らず、CS経由でお客様からの質問にも積極的に対応をしていることでスキルアップや視界の広がりにも繋がっていると思うので今後も継続していきたいと思います。

まとめ

他にもチームビルディングでも実践したり、社内に広めたいと思ったこともあったのですが、それはまた別の機会に。

最後に参加した感想を少しだけ。

最初のセッションで聞いた「DevX」という言葉がとても印象に残っていて、その精神が登壇された方々からすごく感じられたことがとても深く刺さりました。
お客様に提供する価値を向上させていくことはとても大切なことではあるけれど、開発者自身の開発体験がより良いものにしていくことがとても大切で、引いてはそれがお客様に提供する価値に繋がるとも思いました。

これはなにもエンジニアに限らず、営業も、デザイナーも、コンサルも同じだよなあと。
みんな得物は違えど、UXのプロフェッショナルなのだから、それを少しでも自分たちのDevXに使うだけでもきっと今より楽しく、健康的に仕事ができるはず、と強く思いました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?