はじめに
今度、開発初任者が開発する際に考えていることをレクチャーすることになったので、一度ここにまとめてみたいと思います。自己流な考え方のため、参考程度に見ていただけると幸いです。1人でRAGシステムの開発を行った考え方を残したいと思います。
参考になる方
・開発初任者の方
・ローコードツールを用いた開発をしている方
・１人開発に興味がある方
開発の8つの流れ
ユーザーに提供することを想定し、使いやすくシンプルになるように開発することを意識しています。
①やりたいことを考える
②やりたいことの本質を考える
③ユーザーが使っている改修後の姿をイメージする
④改修が可能な仕様を想定する
⑤LLMで改修の手法を聞いてみる
⑥LLMから聞いたパッケージ処理や関数などをネットで調べてみる
⑦改修を行い、エラーが発生した場合やLLM、ネットから修正を行う
大枠としてはこれを繰り返します。
それぞれのステップを言語化して考えてみましょう。
まずはやりたいことを明確にする
仕様を考えるというレベルの前にまずはこれから開発しようとしているものを絵に書いてみましょう。
これは、人によって様々で私の場合は、ノートに書きだします。
Canvaなどイラストを作成するツールなどで代用するのもいいと思います。
つまり、最初にやることはテキスト化する前にイラスト化することです。
そこにテキストを付け加えることはいいですが、基本的にイラストを用いてイメージ化することで自分のやりたいことを頭から形にすることが大事です。
この時点でイラストにうまく落とし込めなければ、自分でやりたいことを改めて整理・精査して形を再度イメージしてみてください。
ここが出来てから次に移ると、開発の精度が異なってきます。
やりたいことの本質を考える
個人的に一番大切だと感じている項目です。
イラスト化して、視覚的にやりたいことを確認出来たら、それをもとにやりたいことを深堀します。
本質ってなに？
と、疑問が生まれるかもしれませんが、具体的には以下のような課題があったとします。
課題：システムでエクセルにまとめたデータを取り込んでシステム内の情報をもとに集計したファイルを出力したい。
あなたなら、どのようなシステムを作りますか？
出力するファイルのレイアウトはおいとくとしても、そのまま実装すると、
①エクセルを取り込む機能
②内容を表示する機能
③集計する機能
④ファイルを出力する機能
ざっくりとこんなところでしょうか。
これで実装すると、確定でのちほどもめます。
なんでや、言われた通りに作ったやんけ！！
と思われるかもしれませんが、ここが本質を考えるという点の重要な部分です。
そもそも、この課題、何をして欲しいのか、それを本当に理解できていますか？
この問いに、うえの課題をそのまま口にすると、頭を叩きます。（パコーン）
違います。
課題があるということは、それを行う業務もしくは作業という大きな枠があって今回やろうとしていることはその一部に過ぎないのです。
つまり、本当にやらないといけないことは、その大きな枠の中で困っている一部を改善することなんです。
では、大きな枠でみたときに課題をそのまま対応する場合と違ってくることはなんでしょう。
その1つが前提です。
例えば、課題のエクセルからデータを取り込む、という部分。
【そもそも、どうしてエクセルなの？？】
この部分に着目してみましょう。
大きな枠でみたときに、その前段となる作業が見えてきます。
実は、そのデータについては【大昔からエクセルにまとめて渡してくるから、必然的にエクセルで対応していた】そんな回答が来たときに、Googleスプレッドシートにまとめることはできませんか？と質問してみると、【運用変えればできますよ。】と返答がきたとすると、やるべきことが変わってきます。
①エクセルを取り込む機能→Googleスプレッドシートを連携し表示
②内容を表示する機能→いらない
③集計する機能
④ファイルを出力する機能→Googleスプレッドシートを更新する
こんな感じに変わったりします。
このブログなどが表示に関しては参考になるかもしれません。
https://zenn.dev/carenet/articles/abac74ca0fb460
とまあ、このような感じで、広い視点で見ると課題が変わるなんてよくあります。
なんなら、お客さん視点で考えたときにもっと簡単に実装できる方法があるなら、その方法を検討することも大切です。
やりたいことの本質がどこにあるのかを考えて、
①低コストで済む方法を考える（短時間）
②正しい課題をとらえる
③場合によっては今やっていることを変更することを提案する
このような対応が大切です。
ユーザーが使っている改修後の姿をイメージする
ここは、②の本質の話と被り、同時にやる部分でもあります。
実際にユーザーが使用している姿を想像する、です。
なぜかといえば、違和感なく改修後のシステムを使えているか、ここが大切です。
折角改修しても、使いづらい、二度手間になっている、などの使いづらい内容になっていたら、折角準備したシステムも使われないものとなることがあります。
そうならない為には、そうしたユーザーのストレスを軽減させることを踏まえたシステムである必要があります。
例えば、大量データを扱うシステムでどれだけ優れたシステムを作ったとしても、入力が手入力しか想定されていない場合、誰も得しないシステムが出来上がってしまいます。
こういったことを防ぐ意味で今回の対応が必要となります。
改修が可能な仕様を想定する
ここまでの過程では、こうしたらいいなとか、こうしたら使われるだろうなと、使われるシステムをイメージして考えてきたと思います。
でも、ここで改めて立ち返っていただきたいのが、そもそも、生み出せないシステムはただの妄想です(; ･`д･´)
出来る範囲で実装できるものを構想します。
各機能をどうやって実装するか、それをそれぞれまとめましょう。
LLMで改修の手法を聞いてみる/LLMから聞いたパッケージ処理や関数などをネットで調べてみる
やりたいこと、改修の仕様まで固まったら実装の仕方を調べましょう。
わたしが主に行っているやり方です。
①LLMで改修の手法を聞いてみる
②LLMから聞いたパッケージ処理や関数などをネットで調べてみる
LLMにやり方を聞くというのは、懐疑的な意見もあるかもしれませんが、もちろん手放しで信用してはいけません。
LLMはあくまで質問に対して、意味を理解して回答しているのではなくもっとも可能性の高い言葉を拾って繋げているだけといわれています。最近のLLMがどの程度まで、発展しているかは不明ですが、現状は存在しない関数や動かないプログラムを平然と回答してくるので正しい回答をしようと考えて返答しているわけではないことが分かります。
その為、返答をもらったらまずやることは、返答からパッケージ処理や関数など使用されている処理が実際に存在し、利用が可能なのかをインターネットで確認します。
その結果、実際に利用できるものであればそれを活用して実装してみましょう。
動作を検証し、想定通りに動いたらOK！
改修を行い、エラーが発生した場合やLLM、ネットから修正を行う
動かない場合は、その際、出力されたエラーをLLMに聞いて解消させます。
どこで、どんな理由で問題が発生しているか。
どうすれば改善できるか。
代替案がないか。
この辺りをきちんと、確認しましょう。
エラーログの確認は、かなり役に立ちます。
ちなみにここまでの過程で記載していませんでしたが、LLMを用いた開発を行う場合そのままコピペすることはいいですが、必ず後ほど修正できるように理解したうえで利用しましょう。
LLMから聞いたことは、自分の知識として得ることで開発者として自分のレベルをあげてくれます。
話はそれましたがこれを繰り返していけば、プログラムレベルで構築が可能です！
まとめ
以上、システム開発における考え方・やり方について、わたしが行っていることを言語化してみました。あくまでわたし個人のやり方なので、開発者の数だけあるのかなと思っています。
開発の醍醐味は言われたことを実行するだけではなく、自分も考えたシステムを作り上げることだと考えています。
その場合も基礎となる考え方は同じです。
やりたいことの本質を見失わずに楽しく開発してください
少しでも参考になっていただけると幸いです。