いっしょにコーディング規約を作るといいことがある

はじめに

これは　Power Apps Advent Calender 2024　2日目の記事です。

私のこと

京都の製造業で社内エンジニアとして働いています。前職は「Google大好き
」な会社でGoogle App Engineで社内システムを構築していましたが、現職はMicrosoftで環境が整えられていたことから、Power Apps・Power Automateで日々開発をしています。
会社全体の情シスではなく「事業部のIT担当」なので人員は少なく構築・保守は基本一人体制。

状況の変化

Power Apps を触りはじめた4年前に比べると、社内の色んなところでPowerAppsで構築する人が増えた。もちろん自部門にも「構築したい」人が現れる。
テンプレートを使ってハードル低くサクッと構築できること、自由度・拡張性が高いことはPower Appsの良いところだけれど、機能拡張やその先の保守を考えると、お作法というものがある。

・デフォルトのままの名称「TextInput1、TextInput2」
・変数名「test1、test2、test3」
・その「Form1」どこの画面のもの？

相手にエンジニア経験がないので「保守性が悪いから命名法整えようか」「次回からこの規約の通りに命名してね！」では説明が不十分。できれば規約のもとになる考え方も共有したかったので
「いっしょにコーディング規約を作りましょう！」の会を設定しました。

これまでは完全一人体制。Microsoftのホワイトペーパーをもとに自分ルール運用で十分だったので、ちゃんとしたペーパーにはしてませんでした。（めんどくさかっ・・・以下略）

規約づくり

こんな感じですすめました。
メンバーは、これから開発を行う2名と私の3名。
1日1時間の打ち合わせを合計3回。

＜ゴール＞
・Microsoft のホワイトペーパーをベースに、自社用のものを作る
・システム規模が小さくまたメンバーが不慣れなので「命名法」だけ
・質問歓迎！ぐちゃぐちゃの命名で困ることの感覚を共有する

たとえばホワイトペーパーには規約をまとめる目的として「簡潔さ・読みやすさ・サポート性・デプロイと管理の容易さ・パフォーマンス・アクセシビリティ」の6項目が挙げられています。
もちろんどれも大切ですが、私たちが日常的に意識できる・約束できるものに限定したかったので「簡潔さ・読みやすさ・サポート性」の3項目にしぼりました。

「規約づくりの会」と称しながらノウハウを伝える会でもあったので、
・メニューバーはどの画面もこういう構成だよ
・どのアプリも共通の変数作って表示／非表示を切り替えているよ
・この辺共通化しておけば他のアプリからコピペして転用しやすいよ
などなど、いろんなことが伝えられて本懐が遂げられた会でした。

「規約に書く」が目的なので
伝える側は「きちんと言葉に表そう」
受け取る側は「きちんと理解しよう」
こんな意識が自然と芽生えていたようで、すごく充実した会になったのが本当に良かった。

普段は割と「んー、この辺は何でもいいですよ」「適当で」と端折っていた自分を反省しました。
参加者の方が「それ、本当は何でもよくないんですよね？」と聞き返してくれたおかげです。

おわりに

規約づくりは面倒なもの、暗黙知に任せたいとこれまで思っていましたが、規約づくりそのものが暗黙知の共有の会となってとても有意義でした。
命名ルール無法地帯のアプリ（他者作も自分作も）は、あとからヘルプが来たときに大変なので、今対処できてよかった。未来への投資にもなっているはず。

余談ですが規約として明文化したことで、自身の過去アプリの「規約違反」が明るみに出て、今は恥ずかしい思いをしています　笑
「自分ルール」だけでは自分を罰せないので、明文化と共有は本当に大事ですね。