０. 目次

皆さんこんにちは。久しぶりの投稿です。
今回は初めて開発系のプロジェクトを経験しました。アプリやソフトウェアを作るほどのがっつりとした開発プロジェクトではなくサーバで定期的に実行されるbatやスクリプトの開発プロジェクトでしたが、それでもインフラ系のプロジェクトとは異なり、かなり苦労したので、その中で経験し感じたことを備忘録として残しておきます。
ただ具体的な言語がどうとかフレームワークとかの話というよりは、こんなことが大事だったなみたいな話です。
チーム体制については、4,5人のチームでほとんど開発経験のある方はおらず、インフラを主に扱っている方々でした。（誰もコードなんて書けん、、みたいな状況です。）

簡単にプロジェクト内の工程でどんなことを経験したか説明します。
後悔した点やこんなことすれば良かった点については後ほど説明します。
■担当した工程

■詳細設計
私がまず担当した工程は、詳細設計でした。基本設計と機能設計はほぼ終わっていました。
作業としては、お客様の要件を満たすために設計された機能を実装するためのプロセスや処理をドキュメントに書き起こす作業です。
インフラ系のプロジェクトの詳細設計書は、サーバやソフトウェアのパラメータ記載することが、多いイメージですが、開発系の詳細設計書は少し異なります。フロー図などを用いて、開始処理から処理処理までのプロセスの流れを詳細に記載する必要があります。
フロー図については、以下のような図を指します。

幸いにも機能自体が複雑ではなかったこともあり、フロー図の作成することはできました。
このフロー図の作成でプログラムの構造を整理することができ、ロジックや考え方が少し身に付きました。
プログラムにおいては、処理Aが起きた後に処理Bが発生しなければいけないとか、この処理がループ処理に含まれてはいけないとか処理全体の整合性が保たれなければバグとなってしまうのです。
フロー図の作成は、システムの全体を理解するために構成図を作ったりすることと同じように感じました。

■コーディング
詳細設計が完了したら設計書を元にコーディングしていきます。全然コマンドを知らないため、何を使えば良いの調べるのにかなり苦労しました笑、この処理はどのコマンドを使えば良いのだろうと一生懸命考えてました。
ただ一から調べて実装するには作業時間の兼ね合いもありますし、限界があったため、生成AIを活用していました。
この機能を実装したいのでコマンドの使用例を教えてほしいと質問すれば大体は教えてくれますし、実際にプログラミングしてスクリプトとして、例を出してくれたりします。他にも既にコーディングされたものでどんな処理を行っているのか不明な箇所があった場合には、その部分を尋ねると説明してくれたりもします。
生成AIはかなり重宝しました。

↓Microsoft edgeで使用できる「Copilot」を用いた例

■単体試験、結合試験
単体試験と結合試験では、試験仕様書の作成と試験実施しました。試験仕様書の項目としては、テスト対象、観点、条件、手順、確認結果等があります。バグの洗い出しとその改修が目的になるため、漏れがないように詳細に記載する必要があります。仕様書は網羅的に試験観点を洗い出さなければいけないため、時間がかかりました。大まかに正常な場合（動作が正しく行われる場合）と異常な場合（意図しない動作の場合）の2パターンがあり、それぞれの試験でも細かい条件で試験結果が変わり、検討しなければいけない事が多いため、マトリクス図を活用しました。さらには試験条件によっては、現実的に起こりえないものなどがあったりするので、必要のない試験の洗い出しもしなければいけません。
試験では、実際に作ったものを仕様書の条件に沿って実行して、動作結果を記録していきます。エビデンスをどうするかという点について、かなり苦労しましたが、次のコラムで説明したいと思います。

全体を振り返ってみて、大事だと感じたポイントを紹介します。

■生成AIの活用について

生成AIは、これまでの仕事ではあまり活用する場面が少なく使ってこなかったのですが、知識が全くない状態から調査しなければいけない問題が多かったこともあり、かなり活用しました。よほど専門的な分野でなければ、初歩的な調査にはかなり有用です。

「こんなコマンド教えてください」「こんな処理を作るためには、どうしたら良いですか？」みたいなかなりざっくりとした質問でも教えてくれます。しかし教えてくれるものはあくまで例なので、しっかりと動作確認が必要です。私が質問したときは、求めていた処理を実現するコマンドであることは間違いないのですが、性能面性や保守性を考えられていない場合が多々ありました。調査のサポートツールのように使用することが望ましいと感じました。あと一歩間違えると情報漏洩になりかねないので、お客様の情報が入らないように注意が必要です。

■分かりやすい日本語で文章を書く

当たり前といえば当たり前なのですが、ドキュメント類は誰が見てもわかるような文章で書くことが本当に大事だと感じました。

特に詳細設計書は、設計内容の確認のために執筆した以外の人も頻繁に見ます。処理に関する説明文などが分かりにくい場合、設計時と実装時で認識がズレます。さらに不明点に関する質問のやり取りなど必要のないコミュニケーションまで発生して、お互いの時間を浪費する可能性もあります。最悪の場合には、あとから認識のズレに気が付き大幅な修正が必要になったりします。そうならないためにも、時間をかけて誰が見てもわかるように推敲するべきです。インフラ系の詳細設計書と異なる開発現場の詳細設計書の性質からどんな現場でも分かりやすい文章を書くことの重要性を再認識しました。

■必要のない手戻りを防ぐ。

開発では、テスト工程でバグを発見して詳細設計まで戻ることが多々ありました。これは実際に経験して分かりましたが、ぶっちゃけて言えばしょうがないものです。動かして確認するしかないです。そのためのテストでもありますからね。

こういった手戻りは確実に起きるものとして考えた方が良いです。

しかし防げる手戻りはたくさんあります。ただ開発現場での経験というよりは、プロジェクトの進め方の部分が大きいかもしれませんが笑

今回一番多かった手戻りは、ドキュメントの追加作成、ドキュメントの体裁修正、単体試験の再試験です。

まずドキュメントについてですが、どの工程でも開始前に必要な成果物を洗い出し、チームの共通認識として持っておくべきです。そのため大小様々なプロジェクトがありますが、小さいプロジェクトでもWBS等を用いた管理は必要と感じました。後から必要な成果物が出てくるとそれだけで着手中の作業や工数に影響が出ます。（実際に頻繁に出ていて苦労しました。。笑）

次に体裁修正については、ドキュメント毎に書き方が異なる部分があったため、成果物として提出時に修正しなければ箇所が多くあったということがありました。基本的にはテンプレートに沿って書くものですが、文章の書き方などにもルールがあった方が良いです。文字の大きさや罫線の引き方など分かりやすいものは簡単な決めた方でよいと思いますが、経験豊富な方が多ければよいですが、いくつか例文みたいなものを作って、書き方を統一したほうがプロジェクト全体として進めやすいのではないかと思います。

最後に再試験についてですが、結局は上二つと同じことです。事前検討は大事ですよという話です。

試験を行う前に、試験を行った結果なにが得られたのかを示すエビデンスはどうするか、試験前と試験後で何が変わったかどうやって証明するかを事前の検討が全くできてませんでした。取り決めせずに進めてしまったので、後から足りないものがどんどん出てきます。恥ずかしい話ですが、その都度始めから再試験をしていました笑。エビデンスが不足していれば、再試験になるのは当然です。試験数も膨大ですし、試験毎に画面のキャプチャやログなどを取得するのでとても時間がかかりました。

一回の試験で終わるように先に何回も検討してから進めましょう。

今回初めての開発現場を経験してみて感じたことをざっと書いてみました。最後らへんはより良いプロジェクトの進め方みたいな話になってしまいましたが笑。インフラであれ開発であれ、もちろんプロジェクトの進め方は同じなのですが、細かい部分は全然違っていて、分野違うとこんなにも大変なのかと感じました。ただ新しいことが多く新鮮味があったり、学びを得ることも多く良い経験ができたのかなと思います。間違いなく知見も広がったと感じてます。やっぱり新しいことに挑戦することは大事ですね。また開発関係のプロジェクトに機会があれば、この経験を生かしてまた挑戦したいです。