今回は開発をするうえで品質を高く保つにあたり基礎や柱の部分ともいえる「yepで行っている内部品質向上のポイント」について紹介します。
ポイントとしては以下の４つとなります。

• コーディングガイドラインに沿ってコーディングする
• 静的解析ツールを利用して警告出ている箇所を修正する
• リファクタリングする
• チームメンバーにレビューしてもらう

コーディングガイドラインに沿ってコーディングする

コーディングガイドラインやルールに沿ってコーディングします。
ガイドラインやルールが競合する場合は以下の優先度で適当します。

1. プロジェクト内のルール
2. 社内のガイドライン
3. フレームワークのガイドライン／ルール
4. グローバルスタンダードなガイドライン／ルール（PHPならPSR12準拠など）

一般的なガイドラインやルールは、プロジェクトによっては不適切なケースもあります。
そのため、プロジェクト内で必要に応じてルールの追加や削除を行います。

静的解析ツールを利用して警告出ている箇所を修正する

yepではphpでの開発においてはPHP_CodeSniffer(phpcs)とPHP Mess Ditector（以下phpmd）を利用しています。

推奨環境としてVSCodeにphpcsとphpmdを利用するためのプラグインを導入し各静的解析ツールの機能を利用します。
それぞれルールセットは社内向けのものを用意しており、場合によってはチーム内でルールセットを変更して利用します。

phpcs/phpmd導入前の古いプロジェクトの保守等では、追加変更箇所のみ対応するなどプロジェクトごとに個別ルールを決めて対応しています。

参考（外部サイト）

PHP_CodeSniffer
https://github.com/squizlabs/PHP_CodeSniffer

PHP Mess Ditector
https://phpmd.org/

リファクタリングする

yepではリファクタリングを積極的にしていく事が求められています。

新規開発中も保守開発中も他の機能が追加／修正されていきます。
そうした過程で設計実装当初と状況が変わってしまい現状にそぐわない設計実装になっていることも良くある話です。
現状にそぐわない状態のまま開発を続けていくと、多くの場合はソースコードが複雑になり、保守が大変になっていきます。
こうしてソフトウェアが劣化して行ってしまうことを防ぐためにリファクタリングが必要になってきます。

もちろん、リファクタリングにあたり実装済みの機能が壊れないことが前提です。
大きな範囲のリファクタリングになる場合は、チームのリーダーと相談し開発工数や納期も踏まえてリファクタリングする／しないの判断を行います。
納期やコストの問題もあるため、理想を切り捨てる判断も必要な時もありますが、実現可能な範囲で最高の状態を保って行きたいと考えています。

チームメンバーにレビューしてもらう

yepでは実装したソースコードについて第三者（主にチームメンバ）にレビューしてもらうことを推奨しています。

プログラムの実装作業を行うとどうしても視野が狭くなりがちです。
他の人の目で確認することで視野が狭くなって見逃してしまっていた問題を発見できるようにします。
できるだけ一人で開発ぜすソースコードはチームのものであると意識するためにも、チームメンバーがレビューし個人の責任ではなくチームとして責任を負う様にします。

レビューの観点としては「仕様通りの動作するか」という事も重要ですが私がレビューする場合は、以下の観点も踏あわせて見る／考えるようにしています。

設計：保守しやすさを重視する

• 自分が保守運用するとしたときに楽できそうかどうか
• 不具合が出たときに原因調査しやすいかどうか、出力するログは足りているか
• 不具合修正や機能追加時に影響範囲がすぐに明確に出来そうかどうか

実装：理解しやすさ（シンプルさ）を重視する

• 書くのは１回、読むのはｎ回、実装しやすさではなく読みやすさ／理解しやすさが重要

さいごに

今回はyepで行っている内部品質向上のポイントについて紹介しました。
内部品質の向上は外部品質の向上や保守運用していくにあたり土台とも言える重要な要素です。

2023年5月時点では今回記載した内容となります。
今後もエンジニア一同研鑽をし個人・会社ともに日々成長していきます。

The post yepで行っている内部品質向上のポイントのご紹介 first appeared on 株式会社yep.

なんだか最近、社内が賑やかっぽい…

デザイン部門の*conです。

最近、yepでは本格的に『スクラム』の導入を始めたのですが、

始めてから、会議室の使用頻度と、オフィスの飛び交う会話がすごく増えた気がします！
なんなら雰囲気の良い活気さえ感じられ…ちょっと楽しそう…
ついつい、となりのチームが何やってるのか気になります。

スクラムどんな感じなのか聞いてみよう！

スクラム自体は多少見知っていたものの、
ファシリテーターとして実際に導入したメンバーがどんなことを感じているのか気になったので、
今回は社内に向けて『スクラムしてみてどうだった？』というアンケートを実施しました!

スクラムに興味はあるけど、
「実際に案件に取り入れると、どんな感じなんだろう？」「何にどう効果があるだろう？」
という疑問や不安をお持ちの方、是非、スクラムがyepにもたらした生の声をご覧ください。

【今回アンケートに答えてくれたメンバーの情報】
スクラムを実施している期間
1~2週間/1ヶ月/2ヶ月/それ以外

スクラムの取り入れ方
スプリントを定期的に回している/スクラムの方法を一部取り入れている

導入前や導入方法を聞いて、どんなイメージを持ちましたか？

・慣れるまで大変そう
・覚えないといけないことが多く、めんどくさそうなイメージ
・意外と普段から意識していたことなので違和感なく、逆に明文化されていて浸透させやすいと感じた
・チーム運営に課題を感じていたので、藁にもすがる思いで絶対に取り入れようと思った
・業務と並行してできるのか不安があった
・余計な工数が発生してしまって、開発のペースが落ちるのではないかと感じた
・説明を聞いてもあまり理解できず、難しそうなイメージを持った
・チーム内のタスクが見える化すること、チームの開発速度が見えることが面白そう（楽しそう）に思えた

実際導入してみて、導入前の印象は変わりましたか？

変わった : 50%
変わらなかった : 34%
その他 : 16%

どんな変化を感じましたか？

メンバー

・コミュニケーションが増えた
・全体的な進捗を気にするようになった
・開発速度を意識するようになった
・残タスクが可視化されることによって、スケジュール感がつかみやすくなった
・優先度が低く、詳細(対応内容やいつやるか等)が決まっていないまま放置されているタスクが減った
・作業の進み具合や、巻き取るべき作業が分かりやすくなった

リーダー

・個々の役割が明確になり、自走する意識ということが身についているように見えた
・各メンバーの作業タスクが見える化できたことで、チーム内でのコミュニケーションが活発になった
・チーム内の課題を見つけやすくなった
・課題に対しての対策案をメンバーが提案するようになった

スクラムをしてみて良かったと思うエピソードがあれば教えてください

・どこでつまっているかを説明しやすくなった
・タスクが可視化されているので業務に取り掛かりやすい
・コミュニケーションが活発になったことで、ソースコードの相互レビューを行う中で良い点・悪い点を指摘しあえる空気になった
・1日どれだけ作業を進めれば良いかの目安になり、スケジュールが立てやすくなった
・短いスパンでの進捗や期限が明確に分かるので、モチベーションが保ちやすくなった
・発言しやすい雰囲気になったことで、なにか問題が発生してもすぐに対応ができるようになった

スクラム続けたいですか？

続けたい または 条件付きで続けたい : 100%！！！

いかがでしたでしょうか？
メンバー同士のコミニュケーションが活発になり、
管理者に進捗報告が自然に上がってくることで課題を見つけやすくなり、
解決に向けチームの一人一人が自走できる。

これが社内を元気にしていた理由だったんですね！納得！

スクラム気になっていたけど、なかなかきっかけが掴めなかった方へ参考となれば幸いです！

スクラムチームを組んでお仕事してみたい
進捗のコミュニケーションがシステム化されている現場で働きたい
という方は、ぜひyepで一緒にお仕事してみませんか？
 

yepでは一緒に働く仲間を募集しています

Webエンジニア
Webデザイナー

The post yepがスクラム始めたらこうなった！ first appeared on 株式会社yep.