チーム開発で大切なこと

ノーツは一般にビジネスで使用するアプリケーションです。そこでアプリケーションを開発される方はほとんどの場合 ”仕事” としてプログラミングされていると思います。

では、”仕事” でアプリケーションを開発する場合、どのようなことに気を付けるべきでしょうか？

ポイントは、趣味の開発とは違って、複数人で担当することがあるという点だと思います。たとえ現在一人で開発していたとしても、将来担当替えなどで誰かに引き継ぐかもしれません。この点を考慮に入れると、アプリ開発が一人で完結することは稀なはずです。

他のメンバーと効率よく作業できる ”チーム開発” が、”仕事” での開発に重要と考えており、その結果、生産性や開発物の品質の向上につながると考えています。

私が重視しているのは次の３点です。

• わかりやすいこと
• 効率が良いこと
• メンテナンス性が高いこと

それぞれの項目について掘り下げてみましょう。

わかりやすいこと

簡単に言うと「プログラムが読みやすい」ということです。

スペースやタブを活用して整然と記述します。As や = などの位置がそろっていると気持ちいですよね。処理が複数のブロックに分かれる場合には、その間に改行を入れ間隔をあけるのも効果的です。

このように、プログラムのレイアウトを整え、見た目に美しいプログラムにするだけで、ずいぶんわかりやすくなります。汚い字で書かれた手書きメモは、読む前から気分がそがれるのと同じですね。

また、変数や関数名を適切に命名し、見ただけで用途がわかるようにします。必要に応じてコメントを記述すると、さらにわかりやすくなります。

チームの他のメンバーでもわかりやすいかを意識してコーディングするといいですね。これは技術ではなく ”思いやり” になりますね...

効率が良いこと

処理時間が短い、データの更新が少ない、メモリの使用量が少ない、プログラムが短いなど、”効率” にはさまざまな指標があります。ただ、こういった指標を追求したプログラムは得てして複雑になったり、読みにくくなります。例えば、変数を使いまわしたり、複雑なアルゴリズム利用したり、コメントを省略したりなどです。

ノーツのようなビジネスアプリケーションの場合は、これらの指標を追求するより、前項のわかりやすさを優先すべきかと思います。まずは仕様通りのプログラムをわかりやすく記述し、どうしてもレスポンスが悪いなど不都合がある部分だけをチューニングすればいいでしょう。

後任者がわかりやすいことがビジネス上の ”効率が良い” といえますよね。将来、すっかり忘れた自分自身が得するかもしれませんしね(笑)

メンテナンス性が高いこと

これは将来の仕様変更などプログラムの修正がしやすいということになります。

古い言い方ですが、ノーツは EUC（End User Computing）のツールなので、アプリケーション開発といっても、プログラマではない方が担当することが多々あります。そのため、アプリを動かすことだけに注力し、メンテナンス性まで意識できていない場合が多いといえます。ただ、最近の流れの早いビジネス環境に対応するためにはメンテナンスしやすい状態にしておくことが大切だと思います。

どうすればいいの？

これらを具体的に実現するためには、ソフトウェア工学という学問や、構造化プログラミング、オブジェクト指向などの技法や考え方を駆使する必要があります。私はその筋のプロではありませんので、そんなことは解説できません。

真似事かもしれませんが、私が実践していることは次のような項目です。参考までにご紹介します。主に LotusScript を意識していますが、＠関数でも応用できることはあるかと思います。

• コーディングスタイル（レイアウトのルール）を決定
• コメントを適切に記述する
• 命名規則を決定する
• 変数を宣言する（暗黙の変数宣言を禁止する）
• パブリック変数を（極力）使用しない
• 無用なスコープは与えない
• 共通の処理は関数化する
• 関数のインターフェースを明確化する
• 汎用的な関数はライブラリ化する
• 一般的な処理は部品化する（＠関数やダイアログボックス）

こういったことをルール化することを、コーディング規約やコーディングルール、標準化などと言います。ルールは制定するだけではだめで、実践することが大切です。チーム全員で実践することで、分担作業がしやすくなり、生産性が上がります。また、他人のプログラムが読みにくいという問題も改善できます。

ライブラリ化を進めると、ライブラリ開発とアプリ開発を分担したり、アプリ開発者はアプリの機能に集中できるという効果もあります。ノーツでは書かない場合も多いのですが、仕様書のドキュメント量を減らすこともできます。将来、担当替えがあったときは引継ぎ工数が削減できるはずです。

これらすべてを初めから完成させるのは大変です。ルールを作ることだけでなく、ルールを守ることにも手間（コスト）が発生します。実現することより、必要性をチームで認識する方が重要です。できることから順にはじめ、効果を感じられたら範囲を広げるなど、段階的に進めるぐらいで十分だと思います。

まとめ

転職などもあり、これまでに複数のチームで開発をしてきました。お客様の要望や上司の指示によりそれぞれの環境で、チームの生産性向上に取り組んできました。その経験を事例としてご紹介しました。

多岐にわたるため、今回は概要の説明だけとなりました。これだけでは、『だから？？』となるかと思います。今後、より具体的に事例を紹介する機会を作る予定です。