ITエンジニアが仕事に対して思うこと

ITエンジニアとして働く中で感じたことを、現場の温度感そのままに言語化するブログです。設計・実装・運用のリアル、学び続ける負荷、品質とスピードのせめぎ合い、コミュニケーションの難しさなど、きれいごとだけでは語れない「仕事の実態」を整理します。誰かを責めるのではなく、なぜそうなるのかを構造で捉え、明日から少し楽に、少し強く働ける視点を提供します。新人から中堅、マネジメントまで参考に。

情報処理安全確保支援士令和6年秋期問23 ‐ 恋するテスト駆動開発~パグだらけの私を救って! サクラ先輩のTDD特別講義~ 【動画解説付き】

    [https://www.youtube.com/watch?v=6CQK9YIFkKQ:embed:cite]

バグだらけのコードに悩む後輩を救うため、サクラ先輩がテスト駆動開発を特別講義します。情報処理試験の過去問を題材に、エクストリームプログラミングの基礎や、テストファーストの重要性、レッド、グリーン、リファクターのサイクルなどを分かりやすく解説しています。AI時代のテスト駆動開発のあり方まで学べる、実務にも試験対策にも役立つ動画です。きれいなコードで素敵な定時退社を目指しましょう。 本動画で学習すべき重要なキーワードとその内容について説明します。まず、エクストリームプログラミングは、1990年代後半に提唱されたアジャイル開発の先駆けとなる手法です。プログラマーは人間であるという核心思想を持ち、叩き台となるプログラムを早期に開発し、短いサイクルで頻繁にテストとリリースを繰り返すことを目的としています。これにより、顧客の要求への対応力を高め、リスクを軽減する効果があります。次に、テスト駆動開発はエクストリームプログラミングのプラクティスの一つであり、求める機能を明確化するために、実装よりも前にテストを書く手法です。バグを見つけるためのテストというよりも、仕様を固めるための設計の手法であるという点が重要です。プログラムを書く前にテストケースを作成することで、ゴールが明確になり、無駄なコードを書かずに済みます。また、テストが盾となることで、コードを変更してもテストが通れば壊れていないと保証される心理的安全性をもたらし、テストコードそのものが最新の生きた仕様書として機能します。このように、実装よりも前にテストを書くことをテストファーストと呼びます。テスト駆動開発は、レッド、グリーン、リファクターという3つのステップのサイクルで進められます。最初のステップであるレッドでは、失敗するテストを書き、何を作りたいかを定義します。次のステップであるグリーンでは、そのテストをパスするための最低限の実装を行います。ここではコードが汚くてもまずは動かすことを優先します。そして最後のステップであるリファクターでは、機能を維持したままコードを洗練させ、きれいにします。一方で、コードを書いた後にテストを書こうとするテストラストには罠があります。コードが複雑すぎてテストが書けなくなったり、仕様ではなく自分が書いたコードが通るような甘いテストを書いてしまうバイアスがかかったりする問題があります。また、テストの網羅率を示すカバレッジに関する注意点として、カバレッジ100パーセントを目的とすることの危険性も挙げられます。全行が実行されてもロジックが間違っていたら意味がなく、中身のないテストが増えるだけです。形式的な数字よりも、変化への対応力とリスク軽減を優先し、安心できるかどうかが重要です。さらに、AIが普及するこれからの時代では、自然言語で仕様を伝えてAIにテストコードを生成させ、人間が意図を確認するという新しい手法が求められます。AIはハルシネーションと呼ばれる嘘をつく可能性があるため、AIを監督する人間が先にテストで制約をかけることの重要性は、むしろ増していると言えます。