はじめに
こんにちは、LANSCOPE セキュリティーオーディターチームの長井です。
今回は、「新しい開発プロジェクトを始める際に注意しておきたいポイント」について、チーム内で話し合った結果をご紹介したいと思います。
セキュリティーオーディターチームは、今年の新入社員から開発歴25年の私まで幅広いバックグラウンドを持つメンバーが所属しています。中途入社者も複数います。
これまでの開発経験を振り返ると、最初から気を付けておけばよかったと思うことがたびたびあります。
開発歴が長いほど、そういったことがなくなるかと思いきや、実際にはそうはいかず、次のプロジェクトでの改善を誓いながら過去の負債と戦う毎日です。
そんな私たちが、次のプロジェクトを始めるとしたらどのように取り組むべきかを話し合ってみました。
開発者の姿勢や開発プロセス、ドキュメント、開発言語、コーディング規約、仕様、設計、実装、テストまで、幅広いトピックが集まりましたが、その中からいくつかのポイントを抜粋してご紹介します。
気を付けておきたいこと
よく言われている原則を意識しておく
よく言われている原則とは SOLID原則 *1 / DRY原則 *2 / KISS原則 *3 / YAGNI原則 *4 といったものになります。
特にYAGNI原則については、多くの意見が寄せられました。
YAGNI原則は「機能は実際に必要となるまでは追加しないのがよい」とされる原則です。
恥ずかしながら、私は近年までその重要性に気付けませんでした。
「そんなこともあろうかと用意しておきました(ドヤッ)」みたいなのがいいと思っていたんですね。
しかしYAGNI原則の中で語られているように、予測して作っていたものはほとんど使われません。
開発工数を無駄に使わないためにも、必要な機能だけを効率的に作ることが重要です。
受けた要望のままに作らない
お客様や他部門の方から様々な要望をいただくことがあります。
それらの要望は大変ありがたいですが、すぐに実装するのではなく、より良い解決策がないか検討することが重要です。
要望を受けた問題を、現状の製品で最適な方法で解決するために、まずは問題を理解し、適切な対応策を検討してから実現していくことが望ましいです。
コミュニケーションを大切にする
コミュニケーションは非常に重要です。
受信だけでなく、発信も大切です。
アウトプットすることで、自分自身の考えを整理し、他の人と相談することで問題を解決できることがあります。
製品の方向性が変わっても、作ったものを捨てることがあっても前向きに
この項目も多くの同意見が寄せられました。
皆さん、何らかの形で苦い経験をしているようです。
私も作っていた製品が最終的にリリースされなかったことがありますが、その経験は自分のコーディングスキル向上に役立ちました。
気持ちを切り替えて前向きに取り組みましょう。
ユビキタス言語表を作成する
上のコミュニケーションと関連していますが、同じモノを同じ言葉で話す・書くことが大事です。
言葉を統一することで、認識の齟齬が減り、理解が早くなります。
文字列のルールは最初に決めておく
文字列のエンコーディング、正規化、トリミング、絵文字の取り扱い、文字数の数え方といったものをあらかじめ決めておくといったことです。
利用する開発言語やデータベースの仕様を考慮して決定しましょう。
考慮が漏れていると、不具合につながることがあります。
特に近年は、Unicodeの絵文字の扱いが厄介です。
Formatter、Linterは最初に導入する
FormatterやLinterは、開発初期に導入することが望ましいです。
セキュリティオーディターチームでは途中からの導入だったため大変でした。
まだ導入が完了していないものもあります。
独自のルールを時間をかけて吟味してから導入するよりも、標準ルールを早急に導入し、問題がある部分だけカスタムルールを追加していく方が導入しやすいでしょう。
後から導入すると、既存のコードの修正が大変なことになります。
データフォーマットはISO規格ベースにする
標準的なフォーマットを採用すると、既存ライブラリーが使えるメリットがあります。
独自フォーマットは仕様が人の頭の中にしかなくて情報伝達漏れが起きたり、特殊なパターンに対する考慮が不足していて後に困ったりします。
おわりに
以上が、新しい開発プロジェクトを始める際に注意しておきたいポイントです。
違うご意見を持たれたものもあるかもしれませんが、私たちのチーム内でも意見が分かれるものがありました。
その根底にあるのは、開発初期のスピード感を重視する意見と、長期開発を見据えた継続性を重視する意見の対立でした。
陸上競技に例えると、短距離走と長距離走の違いになるでしょうか。
しかし、開発では短距離走で始めて長距離走り抜くことが求められます。
どちらの意見が正しい・間違っているというわけではなく、プロジェクトのタイミングによって重視すべきポイントが変わるということだと思います。
この話し合いによって、チームメンバーのバックボーンが共有でき、より結束が高まりました。
みなさんのチームでも同様の話し合いを行ってみてはいかがでしょうか。
ここまでお読みいただき、誠にありがとうございます。
本内容がお役に立てれば幸いです。
