AIの使い方を学ぶより先に、ソフトウェア工学を理解しないといけないんじゃないかと思います。 AIにテストコードを書かせた場合を例に説明します。AIはテストコードを高速で書いてくれますが、テスト理論を理解していないと、バグを見逃すテストコードを書かせてしまうことがあります。 テストの話(例として) 先に、今回の話の土台になるテスト理論を簡単に説明しておきます。わかりやすい例として、テストの技法で有名な以下の2つを挙げたいと思います。 ブラックボックステスト は、コードの中身を見ずに、仕様（入力→出力）だけを基準にテストする方法です。「この入力を与えたら、仕様どおりの結果が返るか」を確認します。境界値分析や同値分割といった技法はこちら側です。 ホワイトボックステスト は、コードの内部構造（分岐、ループ、処理経路）を見てテストする方法です。「このif文はtrue側もfalse側も通したか」を確認します。どれだけ通せたかはカバレッジという数値で測れます。 ここで大事なのは、ホワイトボックスといっても「コードを基準にしていいのはテストの経路の選択だけ」という点です。 結果が正しいかどうかの判定（期待値）は、必ず仕様から立てる 必要があります。コードを見て「コードがこう動くから、これが正解」としてしまうと、バグごとテストが追認してしまうからです。 どこをテストするか（経路） → コードから決めてよい 結果が正しいか（期待値） → 仕様から決める この分離が今回の話の核心です。 理論を知らないと、AIをうまく使えないときがある AIはテストコードをものすごい速さで書いてくれます。ただ、指示の出し方を間違えると「全部パスしているのにバグを見逃すテスト」を量産します。しかも数字の上では完璧に見えるので、見逃したことに気づけません。 実際にやってみたので、失敗例と成功例を並べます。 題材のコード 料金計算の関数です。仕様はこうだとします。 10,000円以上は10%オフ。会員はさらに5%オフ。 def charge ( amount : int , is_member : bool ) - > float : """料金計算""" if amount < 0 : # 仕様書に記載のない分岐（実装者が独自に追加） return 0 fee = float ( amount ) if amount > 10000 : # ★バグ: 仕様は「以上(>=)」なのに > にしている fee = amount * 0.9 if is_member : fee = fee * 0.95 return fee わざとバグを仕込んであります。仕様は「10,000円以上」なのに、実装は   > （超）になっている。つまり10,000円ちょうどのとき、割引されるべきなのにされません。境界値のバグとしてはかなりありがちなやつです。 おまけに、仕様書には書かれていない負数チェックの分岐も入れてあります。実装者が気を利かせて勝手に足した、という想定です。 失敗例：テスト理論を知らずに指示を出すと 極端な例なのですが、まず、理論を意識せずにこう頼んだとします。 このコードのテストを書いて。カバレッジ100%にして。 AIはコードを読んで、こういうテストを書いてきます。 from charge import charge def test_normal ( ) : # コードを読んで期待値を計算: 15000 > 10000 → *0.9 → 13500 assert charge ( 15000 , False ) == 13500.0 def test_member ( ) : # 15000*0.9*0.95 = 12825 assert charge ( 15000 , True ) == 12825.0 def test_boundary_10000 ( ) : # コード上 10000 は「> 10000」に該当しない → 割引なし、と読める assert charge ( 10000 , False ) == 10000.0 # ← バグを"正解"として追認 def test_negative ( ) : # コードにそういう分岐があるので、それを期待値に assert charge ( - 100 , False ) == 0 問題は   test_boundary_10000   です。AIはコードから期待値を逆算するので、「10000は   > 10000   に該当しない。だから割引なしが正しい」と解釈します。 バグの動きを”正解”としてテストに固めてしまっている わけです。 実行結果がこれです。 4 passed branch coverage 100% 全テストパス、分岐カバレッジ100%。数字だけ見れば完璧です。でも境界値バグの検出はゼロ。指標がすべて緑なので、この見逃しに気づく手段がありません。個人的には、テストが落ちるより、この「完璧に見える」状態のほうがよっぽど怖いと思っています。 成功例：テスト理論を分かった上で指示を出すと 今度は、さっきの「経路はコードから、期待値は仕様から」という分離をプロンプトに落とし込みます。 以下の手順でテストコードを作成してください。 【カバレッジ設計：ソースを参照】 - ソースの全分岐(true/false)・例外パスを洗い出し、 各経路を通すための入力条件を列挙する（分岐網羅100%目標） 【期待値設計：仕様書のみ参照】 - 各ケースの期待値は必ず仕様書から導出する - ソースコードの出力を期待値に流用することは禁止 - 境界値分析を適用し、境界(10,000円)の直前・ちょうど・直後を必ず試す - 仕様書に記載がなく期待値を判断できないケースは、 期待値を書かず「要確認」として質問リストに出す 【出力】 - 各テストに「どの分岐を通すか(ソース由来)」 「期待値の根拠(仕様書のどこか)」をコメントで明記 仕様書は以下となります。 10,000円以上は10%オフ。会員はさらに5%オフ。 このプロンプトでAIが書くテストはこうなります。 from charge import charge # 仕様書: 「10,000円以上は10%オフ。会員はさらに5%オフ。」 def test_under_boundary ( ) : # 仕様: 9,999円は割引なし assert charge ( 9999 , False ) == 9999.0 def test_boundary_exactly_10000 ( ) : # 仕様: 10,000円「以上」なので 10000 は10%オフ → 9000 assert charge ( 10000 , False ) == 9000.0 # ← 期待値は仕様から def test_over_boundary ( ) : assert charge ( 10001 , False ) == 10001 * 0.9 def test_member_discount ( ) : assert charge ( 20000 , True ) == 20000 * 0.9 * 0.95 def test_member_under_10000 ( ) : assert charge ( 5000 , True ) == 5000 * 0.95 # 【要確認】ソースに amount < 0 の分岐があるが、仕様書に負数の扱いの記載なし。 # 期待値をでっち上げず、仕様確認事項として報告: # Q. 負の金額は入力され得るか？ その場合の仕様は？（現実装は0を返す） 実行結果です。 FAILED test_boundary_exactly_10000 - assert 10000.0 == 9000.0 1 failed, 4 passed branch coverage 87% 境界値10,000円ちょうどのテストが落ちました。 バグ検出成功です。 面白いのはカバレッジのほうで、今度は87%と満点ではありません。未達なのは負数チェックの分岐です。ここでプロンプトの「仕様書にないケースは要確認として出せ」が効いていて、AIは負数分岐の期待値をでっち上げず、「負の金額の仕様は？」という質問として返してきました。カバレッジの未達が、そのまま 仕様書の記載漏れの発見 につながっています。 並べるとこうなります。 素朴なプロンプト 理論に基づくプロンプト テスト結果 4 passed（全緑） 1 failed（バグ検出） カバレッジ 100% 87%（未達＝仕様漏れの兆候） 境界値バグ 追認して見逃す 検出 仕様にない分岐 期待値をでっち上げ 要確認として報告 失敗例のほうが数字は良くて、成功例のほうが数字は悪い。でも健全なのは後者です。この逆転が、今回一番伝えたかったことです。 AIの使い方より、ソフトウェア工学 ここからが本題というか、この体験を通して思ったことです。 さっきの2つのプロンプトの差は、AIの使い方のテクニックではありません。「経路はコードから、期待値は仕様から」も、「境界のちょうどの値を試す」も、全部昔からあるテスト理論です。ホワイトボックス、ブラックボックス、境界値分析。それを知っているかどうかだけの差でした。 境界値分析を知らなければ、「10,000円ちょうどを試して」という発想自体がプロンプトに出てきません。AIは指示された観点しか網羅してくれないので、観点を出せない人がいくらプロンプトの書き方を工夫しても、この差は埋まりません。 AIの使い方講座とか、AIでのスライドの作り方みたいな情報は確かに有用で、それを学ぶことで業務の効率は驚くほど上がります。しかし、ソフトウェア開発者に大事なのはやはりソフトウェア開発の基本的な理論だと思います。「このコードのテストで何を検証すべきか」は、聞く側に理論がないと、そもそも正しい質問になりません。 考えてみれば当たり前で、AIに指示を出すのも人間に指示を出すのも同じなんですよね。後輩に「このコードのテスト書いといて」とだけ言って渡したら、やっぱり同じ失敗をするかもしれない。きちんと伝えないと毎回きちんとやってくれるとは限らないのは、AIも人間も同じです。そして、きちんと伝えるためには、指示する側が中身を分かっていないといけない。 AIはテストコードを書く速度を劇的に上げてくれました。だからこそ、「何を検証すべきか」を決める側の理論、つまりソフトウェア工学の価値は、下がるどころかむしろ上がっていると感じています。AIの時代に何を学ぶべきかと聞かれたら、私はソフトウェア工学だと答えます。やはり、いつの時代でも大事のは基本だと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIの使い方を学ぶ前に、まずソフトウェア工学を first appeared on SIOS Tech Lab .

～試験合格のための勉強方法～ 2026年6月26日　株式会社NTTデータ 第三公共事業本部 小沼真実 この記事は、2026年6月までに Amazon Web Services（AWS） の認定資格を現在廃止済みの MLS-C01 を含む計 13 個を取得（全冠）したため、その経験をもとに、自分に効果があった勉強方法や利用した勉強コンテンツ、問題解答時のコツなどについて、解説しています。 クラウド関連の資格取得のために勉強中の方や、これから始めようとしている方など、自分に合った勉強方法を見つけるのに参考にしてもらえたらと思い、今回学習メモとして、AWS を中心に整理しました。 この記事

ニフティに新卒入社したエンジニアは、3か月間の新入社員研修と技術研修を経て、7月からOJT期間に入ります。8か月の間に3つの部署をジョブローテーションし、業務知識やチームでのプロジェクトの進め方、エンジニアとしての技術を身につけたうえで、4月からの本配属に備えるという流れです（2025年度時点）。 実際にプロジェクトの一員として働くニフティのOJTは、単に仕事を覚えるだけでなく、自分自身の適正を知り、会社員やエンジニアとしての歩み方を見定めていく期間でもあります。今回は2025年度に新卒入社し、OJT期間を終えようとしている新人たちにインタビュー。春からの本配属を待つ4名に、この一年を振り返ってもらいました。 自己紹介 Nさん 2025年4⽉に新卒入社。現在の担当業務は、ISMS（情報セキュリティマネジメントシステム）の推進、インシデント対応、社内セキュリティ対策の企画・運用。趣味はチェス、旅行。 Yさん 2025年4⽉に新卒入社。現在の担当業務は、社内システムの運用・保守・刷新。趣味は鉄道旅。 Sさん 2025年4⽉に新卒入社。現在の担当業務は、オプションサービスの開発、運用。趣味は映像・音楽・映画やアニメ鑑賞・散歩。 Tさん 2025年4⽉に新卒入社。現在の担当業務は、@niftyトップページ・ニフくじの開発・保守。趣味は料理・アニメ鑑賞・ボルダリング。 3つの部署を経験し、興味とスキルの幅が広がった ※本文中の部署名は2025年度時点 みなさんは2025年4月にニフティに入社し、7月から現在までの約半年間、ジョブローテーションで3つの部署を経験しました。この期間に、どのような学びや気づきがあったのか教えてください。 Tさん 1年目に複数の部署を回れたことは、各部署の役割や部署同士のつながりなど、会社全体の動きを知るという意味で良かったと思います。また、エンジニアといってもコードを書く以外に考えることも多かったり、開発現場のリアルな動きを知れたのも大きいですね。 Sさん 私は「課金システムチーム」「セキュリティSREチーム」「インフラシステムチーム」を経験しました。どのチームでもたくさんの学びがありましたが、たとえば課金システムチームでは、チーム開発の基礎やプロジェクト立ち上げにまつわる知識、システム同士の連携、ドメインについてなど、今後の業務に活かせそうな経験ばかりでしたね。 Yさん  私は情報系の大学出身ではないこともあって、そもそも技術面での学びが大きかったです。また、ジョブローテで回った3つの部署はいずれも社内向けのシステムを手掛けていたのですが、同じ社内向けでもチームによって考え方や仕事の進め方、コミュニケーションを取る相手がまるで違うことが分かったのは良かったですね。 たとえば、1期目に配属されたプラットフォームチームでは、人事部門や経理部門との連携が中心でした。2期目のデータの収集基盤チームでは、システム系の部門や、データを活用したい企画側との連携が増えるなど、チームによって関わる人が変わる。頭を切り替えて臨まないといけないし、求められる知見やスキルも異なることを痛感しました。 Nさん 私も、Yさんと同じく専門的に学んできたわけではありませんが、3期とも開発がメインのチームに配属されました。最初は不安でいっぱいでしたね。ただ、開発の知識はもちろん必要ですが、それ以上に分からないことがあれば素直に教えを請い、理解した上で伝える力が大事なのだと気づきました。それさえできれば、後から開発のスキルはついてくるのかなと。 特に印象深かったのは2期目ですね。カスタマーサポートの社員の方が利用しているシステムの運用・開発をするチームに配属され、コールセンター業務をしているオペレーターさんの声を聞く機会がありました。実際にシステムを使う人が感じている不便など、リアルな要望を聞いた上で改善策を考え、設計に落とし込むプロセスは学びだらけでした。 オンライン学習や社外イベントへの参加推奨。スキルアップ制度も充実 現場での実践経験に加え、スキルアップのための社内制度なども利用されましたか？ Nさん Udemyのオンライン学習はかなり利用しています。資格取得の講座や、気になった技術に関する動画も気軽に見られるので、ビジネスマンとしてもエンジニアとしてもスキルの幅が広がっていく感覚はありますね。 Yさん  私もUdemyのほか、個人の学習や自由研究のような開発に使えるAWSのサンドボックス環境の制度を積極的に活用しています。月額100ドルまでと上限はありますが、ハンズオンのためにAWS環境で簡易サービスを作ってみたり、色んな検証を行うのに役立てています。 Sさん  同じくAWSのサンドボックス環境は重宝しています。私の場合は、生成AI系のアプリケーションを作成できるBedrockをよく使っているのですが、他にもAWSの新しいサービスや機能をすぐに試せるのが嬉しいですね。あとは、社内のナレッジ共有ツールとして使われているNotionに「みんなのレポート」というページがあって、そこで他チームのナレッジや情報を閲覧できるので、勉強になります。 Tさん ニフティ全社的にAWSの資格取得を推奨する動きがあり、私もUdemyを活用して2つの資格を取りました。他には、社外イベントやワークショップに参加しやすい仕組みがあるのもありがたいです。会社が促してくれるので気兼ねなく行けますし、交通費も支給されます。OJTの期間中も、AWS系のイベントに新人全員が参加していました。 Sさん イベントに関しては参加した人が「みんなのレポート」に内容やそこで得られた知見をシェアしてくれるので、自分が行けなかったイベントからも学びが得られます。また、Slack内にイベント情報を共有するチャンネルもあって、フロントエンド、バックエンド、AI系など、自分が興味のあるジャンルのイベントをチェックしている人も多いです。イベントに参加しやすい雰囲気や、参加を促す仕組みがあるのがいいですね。 制度や仕組み以外の部分で、自身の成長につながったと感じられる体験などがあれば教えてください。 Nさん  ジョブローテで回った各部署で、色んな方と議論ができたのは良かったです。対面だけでなく、社内のSlack上でのやりとりもオープンで。ふと感じた疑問を投稿すると同じ部署の先輩、別チームの人、マネージャーや幹部クラスの方々もコメントしてくれて、どんどん議論が展開されていく。質問したことを教えてもらうだけでなく、議論をすることでより深いところまで思考できる感覚がありますね。 あとは、基本的に先輩たちが優しくて、何でも質問できるのがありがたいです。先輩自身も分からない時は、一緒に調べてくれたりもして。新人や若い社員への丁寧な接し方みたいなものは、ニフティのなかで受け継がれてきた文化の一つなのかなと思います。 Tさん  Nさんが言ってくれたように、誰かの発言に対してちゃんとリアクションする人が多いのはニフティの特徴の一つだと感じます。それも仕事だからやっているというよりは、いい意味でディスカッションを楽しんでいる印象です。たとえば、Slack上で自分専用のチャンネルを作って業務や活動について発信する文化があるのですが、そこで「今こんなことをやっているんだけど、何かいい方法ありますか？」と投稿すると、誰かしらが反応してくれる。悩みや困ったことがあっても、一人で抱え込むことなく前進できるので、成長を早めてくれる環境だと感じますね。 技術に対する感度の高さに驚き。ニフティに対するイメージに変化は？ 実際に1年間働いてみて、入社前のイメージから変化したことがあれば教えてください。 Nさん 入社前はWEBサービスとネットワークがメインの企業という印象でしたが、実際は想像以上に多角的なサービスやプロダクトを展開していました。お客様向けのサービスだけでなく、社員が使うサーバーやネットワークの構築も社内でやっていて。技術を活用して刷新や補修をしていく範囲の広さに驚きましたし、それだけ活躍の幅があるのかなと思いました。 あとは、新しい技術に対する感度も高いですね。毎週、休みが明ける度にSlackのチャンネルに社員それぞれがインプットしてきた技術にまつわる情報が投稿されて、追いきれないほどです。最近はAI関連の話題が熱くて、詳しい人が社内勉強会を開いたりと、新しい技術をどんどんキャッチアップして自分のものにしていこうという雰囲気があります。 Yさん いい意味でイメージ通りだったのは、会社の雰囲気や風通しの良さです。学生時代にインターンで来ていた時から先輩たちがフレンドリーに接してくれて、それがニフティを選んだ理由でもあるのですが、入社後もそこは変わらなかったですね。 ニフティのサービスに関しては、私もNさんと同じく「昔からあるサービス」の運用が中心なのかなと思っていましたが、ISP事業のような軸となるサービスがありつつも、幅広く事業をやっているんだなと。守りと攻め、両方をバランスよく展開している印象ですね。 Sさん 社内で使うツールやプラットフォームも、良いものがあればどんどん採用していく柔軟性があると思います。たとえば先日は、Notionのカスタムエージェントという機能がリリースされた当日に社内でワークショップを実施していて、あまりのスピード感に驚きました。 コーディングに関しても全社的にAIを活用して、工数の削減に取り組んでいるのは意外でしたし、いい意味でギャップを感じましたね。 Tさん 私は入社前からNIFTY engineeringのブログ記事を読んでいて、技術に関する感度が高い会社という認識を持っていましたが、実際に入ってみたら想像以上でした。NさんやSさんが言うように、開発現場でも最新のもの、良いものをどんどん試して使っていこうという意識が浸透していると思います。 たとえば、コーディングアシスタントはもともとGitHub Copilotを使っていましたが、Claude Code が出てきてエンジニアの間でも評判がいいということで、とあるチームがすぐに検証を始め、半年も経たずに全社的に使える状態になっていました。新しいツールに対する制約は特にないので、どこかのチームがとりあえず試してみて、良ければ自然と広がっていくような感じですね。 会社全体が新しい技術に対してオープンな姿勢だから、情報をどんどんキャッチアップしてシェアしようという意欲が生まれやすいのかもしれませんね。 Tさん そうですね。情報もそうですし、自分の考えも共有しやすいですね。Slack上などに何気なく投げた疑問に対して別角度から色んな意見が出てきて、それらを組み合わせることで自分の考えをブラッシュアップできる。そこはニフティのオープンな社風や雰囲気があってこそなのかなと思います。 後編に続きます！ 今回はニフティの2025年度 新卒社員のインタビュー（前編）の様子をお届けしました。後編は近日中に公開します。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報