ローコードに設計書は必要か

今年からローコードを始めています。

システムインテグレーターの仕事が激変しています。その１つが、ローコード、ノーコード。ローコードツールを使えば、簡単に業務で利用できる画面が開発でき、データを蓄積できます。しかしながら、大きなデメリットがあるんです。

ローコードとは

ローコードのデメリット

ローコードのデメリット簡単に画面が開発できてしまうが故に、設計書が残らない。なぜ、このようなコードが書かれているのかわからない。そういう状況に陥りやすいということです。超便利なExcelのマクロを作ってくれた人が突然やめてしまい、そのマクロが修正できなくなってしまった、という事例、よくあるのではないでしょうか。ローコードは、人依存のコード問題はどうしても残ってしまうのです。

ソースにコメント

短時間でアプリが作成できる、そのメリットの裏に、ソースにコメントが掛からず、そのソースが何をやっているのかわからない状況に陥ります。例えば次のコードをみて、パッと何をやっているか想像つきますか？

例）インベーダーゲームのソースの一部

If (
   PlayerShotFired = true,
   // Check if player shot hits active Alien One
   If(
       (PlayerShot.Y >= AlienOne.Y && PlayerShot.Y <= AlienOne.Y + 130) && (PlayerShot.X >= AlienOne.X && PlayerShot.X <= AlienOne.X + 100) && AlienOneTransparency < 1,
       Set(
           PlayerScore,
           PlayerScore + 250
       );

コメントを１行だけ記載しています。//Check if player shot hits active Alien One ：プレイヤーが撃った弾が動いているエイリアンに命中したかをチェック

実際の画面での動きコメントを書いていますが、その下のソースには、プレーヤーとエイリアンの X座標、Y座標を比較しています。
この例では、プレーヤーの位置とエイリアンの位置が一致したら（高さ＋１３０pxの範囲で)、プレイヤーの得点を 250点追加しています。

コメントと、実際のロジックが異なっている典型的な例だと思います。ローコードで開発されたプログラムを引き継いだ人が果たしてこのコメント行をみただけで、何をしているか、判別つけられるでしょうか？

答えはNo　だと思います。

ローコード開発にも設計書が必要？

だれかに引き継ぐことを考えたら、ローコード開発にも、設計書が必要になってきます。設計書を作成するタイミングはとても難しいです。なぜなら、ローコードで開発したものは簡単に修正ができ、リリースまでできてしまいます。従来のソースコードのDiff(旧ソースコードと新ソースコードを比較する作業）が簡単にできないことも問題になるかもしれません。

ローコード製品には設計書を自動で作成してくれることを望みます。そうしないと、せっかく画面開発は素早くできるのに、設計書に転記するような無駄な作業で、時間を余計についやすことになります。

PowerAppsとは

PowerApps開発の設計書

これからPowerAppsを使って、社内業務システムを開発する方は、どのように進めますか？進め方は、アジャイルで、そう上司が言ってくるかもしれません。ではそのメンテナンス本当にできますか？メンテナンスフェーズのことを意識した開発は、これまでのシステム開発同様、ローコード開発でも必要です。メンテナンスを意識して、コメントをできるだけわかりやすく書くべきです。（もし、設計書を作らないで進めるならば）

しかしながら、コメントを書くのは人間です。特に、開発者にとってコメントを書くことはあまり得意ではありません。その得意でない作業をすることで、ローコードのソースの中身が余計に複雑にならないかが気になるところです。もし、これからローコード開発を実践する方は、「わかりやすいコメントの書き方」を意識して開発を進めるべきです。この意識こそ、ローコード開発にとって、一番重要な部分です。

わかりやすいコメント

わかりやすいコメントは、どうすれば書くことができるか。端的で、誰もが同じ認識ができる内容である必要があります。上記のコードの例であれば、

動作：プレイヤーのショットが動いているエイリアンにヒットした場合は、２５０点をプレイヤーの得点に加算。

制御：プレイヤーの位置を(X1,Y1)、エイリアンの位置を(X2,Y2)とし、X1=X2 かつY1=Y2　となった時を　エイリアンにヒットしたと判定する　ただし、Ｙはエイリアンの身長　130pxの幅を想定しなければならい。

ここまで、コメント欄に書かないとわからないですね。やはり、ソースにコメントを書くだけでは、設計書の代用は難しそうです。

ローコードにも設計書が必要！

 現時点での答えは、ローコード開発でも従来どおり設計書は書くべき　だと判断します。

必要な設計書の内容については、プロジェクトを進めていく中で、必要、不要の判断をしていかないければ、ローコード開発の短期間開発、工数短縮開発のメリットを生かせないです。せっかくのローコード開発を選択したのであれば、そのメリットを活かせる開発スタイルを探るべきです。

決して、従来のウォーターホール型開発で作成してきた、ドキュメントが必要だとは言っていません。ローコード開発で必要なドキュメント、それはシステムの仕様を十分に理解できるものでなければなりません。それが、設計書なのか、はたまた動画でプログラム内容を録画したものなのか、開発方式をレクチャーしたYoutubeなのか、はプロジェクトで決めるべきです。そして、後世のメンバーでも簡単にメンテナンスができなければ、ローコードを使う意味はないことも理解しておかなければなりません。

次回から、ローコード設計における設計書の役割について、解説していきたいと思います。次回をお楽しみに。