案件情報の必須または歓迎スキルで「基本設計・詳細設計の経験」と記載されているのを見て「自分は基準を満たしているのだろうか」と考えたことはありませんか？
本記事では、システム開発の中核を担う「基本設計」と「詳細設計」の違いやそれぞれの役割、具体的な業務内容、そして実際にどのような経験が評価されるのかを解説します。エンジニアとしての自身のキャリアを見直し、転職活動や案件獲得に向けて有利に働く知識を得ることで、次のステップへ踏み出すための一助となれば幸いです。
エージェントサービス「エンジニアファクトリー」では、ITフリーランスエンジニアの案件・求人の紹介を行っています。掲載中の案件は7,000件以上。紹介する案件の平均年商は810万円（※2023年4月 首都圏近郊のITエンジニア対象）となっており、スキルや言語によって高条件の案件と出会うことができます。
氏名やメールアドレス・使用できる言語を入力するだけで、簡単60秒ですぐにサポートを開始できます。案件にお困りのITフリーランスの方やより高条件の案件と巡り合いたいと考えている方は、ぜひご登録ください。
基本設計と詳細設計の違い
基本設計は、要件定義で特定されたシステム全体の要件や仕様をどのように具体的なシステム設計で実現するかを大まかに固める段階です。ユーザーとのやり取りを通じて、「どのような機能を実装するか」「システムをどう構成するか」「画面やインターフェイスはどんなイメージか」を決めていきます。
具体的には画面レイアウトの大枠、システムの構成、データやテーブルの基本的な構造といった、上流部分の設計を担当します。このフェーズでは、顧客やステークホルダーとの調整が中心になるため、コミュニケーション力や要件の抽出能力が求められます。
基本設計は要件定義に基づきシステム全体をどのように作るかの「大枠」を決める工程であり、基本設計を明確にしないと後々のトラブルの原因になる可能性もあるため特に重要視されます。
詳細設計は、基本設計で決まった仕様を、実際のプログラム実装に落とし込むまで詳細化する段階です。基本設計で描いた全体像を、クラス設計、テーブルのスキーマ定義、関数やメソッドのロジックなど、コードレベルで実装できる粒度に細分化していきます。
APIやデータのやり取りがどのように行われるか、エラー処理はどうするか、ログの出力はどのように設計するかなど、開発者が迷わず実装できる具体的な仕様を定義することと異なる開発者でも同様の結果を生み出せるようにすることが目的です。
詳細設計は、基本設計に基づき具体的な実装仕様へと落とし込み、開発や運用をスムーズに進めるための要となり、運用段階でのトラブルシューティングなどにおいても欠かせません。
基本設計・詳細設計の流れとタイミング
一般的なウォーターフォール型開発プロセスを例にとると、システム開発は大まかに以下の段階に分かれます。
- 要件定義
- 基本設計（外部設計）
- 詳細設計（内部設計）
- 実装（プログラミング）
- テスト
- 運用・保守
以降では上記の開発プロセスを例に基本設計と詳細設計の流れとポイントについて解説します。
基本設計はいつ行うのか？
基本設計は要件定義で収集・整理した機能要件や非機能要件をもとに、「システム全体の機能構成」や「画面レイアウト」「操作フロー」「データの大まかな構造（テーブル設計やインターフェース）」など、大枠を設計する段階となります。
つまり、要件定義は「何を作るか」の方向性を定める工程であり、基本設計ではそれを「どのように作るか」の大枠へと具体化します。ここで認識のズレを残したまま詳細設計・実装に進むと、大幅な手戻りが発生するリスクが高まるため、要件定義で明確になった事項をしっかり踏まえたうえで基本設計を行うことが大切です。
この段階では、システム全体の見通しを持ちながら、要件との整合性を保った設計に仕上げることが重要です。要件が設計に正しく反映されていなければ、詳細設計や実装の段階で手戻りが発生し、コストや納期に大きく影響を及ぼす可能性があります。また、基本設計は後工程すべての土台となるため、視野を広く持ち、全体を俯瞰した設計が求められます。
さらに、ステークホルダーとの認識のずれが残ったまま進めてしまうと、後のトラブルにつながるため、定期的なレビューを通じて早期に確認・修正を重ねていくことも欠かせません。
詳細設計はいつ行うのか？
詳細設計は、上記の開発プロセスの中で基本設計で決定されたシステム全体の仕様や構成を具体的な実装レベルに落とし込むフェーズとして位置づけられます。具体的には基本設計で固めた大枠を、クラス設計やAPI仕様、DBスキーマ、エラー処理などのレベルまで細分化し、開発者が実装に着手できる詳細な仕様に落とし込みます。
基本設計とは異なり、ユーザーの目に触れない範囲が対象となるため、開発チーム内でレビューを行い、あわせて非機能要件（性能・セキュリティなど）の考慮やドキュメント化をすることで、後の実装・テストフェーズを円滑にし、手戻りを最小限に抑えることができます。
基本設計・詳細設計におけるよくある課題と対策
設計における課題を下記の３点にフォーカスして紹介します。
- 設計の本質が理解されていない
- 設計ルールや基準が曖昧になっている
- 設計の標準化が進んでいない
設計の本質が理解されていない
開発プロセスにおける設計では、要件定義に基づきステークホルダーのニーズや課題を解決するソフトウェアの大枠や詳細を決めます。その重要な工程である基本設計と詳細設計の目的・違いを正しく理解しないと、後工程で以下のようなトラブルが生じる可能性があります。
設計が正しく理解されていないと発生しやすいトラブル一覧
| トラブルの種類 | 具体的な内容 | 原因となる設計上の問題 |
|---|---|---|
| 要件の見落とし・機能の抜け漏れ | 想定外の機能や仕様が後から発覚し、手戻りや追加作業が発生する | 基本設計で要件定義が正確に反映されていない／確認が不十分 |
| パフォーマンス・セキュリティの不備 | 負荷テストやセキュリティ検証の段階で問題が露見し、大幅な修正が必要になる | 非機能要件（性能・拡張性・セキュリティなど）の考慮が不足 |
| 開発メンバー間の認識ズレ | 「この仕様で良かったのか？」「どこまで対応すればいいのか？」と現場で迷いが生じる | 設計書の曖昧さやレビュー不足により、仕様の共通理解が不十分 |
正しく設計を行うためには、要件の優先度と範囲を正確に把握し、システム全体の構成や機能連携を俯瞰して考える基本設計と、実装可能なレベルまで仕様を詰める詳細設計を丁寧に行うことが欠かせません。
設計ルールや基準が曖昧になっている
設計書のルールや基準が統一されていない場合、新しいメンバーや他部署のエンジニアが参画したときに「どの資料が正なのか」「必要な情報がどこにあるのか」が分からず、スムーズな引き継ぎが難しくなったり、レビュー担当者がプロジェクトの度に違うルールを把握し直さなければならず、レビューの効率が下がったりすることがあります。
設計書に関する統一したルールを作成するには、組織全体で合意した設計方針を定め、定期的なレビューや振り返りでルールをブラッシュアップしていくような仕組みを整える事が重要です。
設計の標準化が進んでいない
前述したように設計書のルールの作成、つまり標準化が進まないと、個々のエンジニアが独自の設計方法を持ち込み、メンバーが変わるごとに設計書の品質も大きく変化することが考えられます。また、過去プロジェクトで成功した設計手法やテンプレートを組織全体で共有できず、ベストプラクティスが活かされないまま別プロジェクトでも同じ課題が発生する可能性があります。
標準化を進めるためには、組織共有の設計ガイドラインを必要最小限で始めるのが良いでしょう。理由としては、ルールが多すぎると運用が形骸化しやすいので、まずは最も重要な部分（例えば命名規則やドキュメントの最低記載項目など）から標準化を進めると導入しやすくなります。また、設計のレビューを定期的に実施することやドキュメントの運用を行うことで継続的にルールを改善する仕組みを作っていくことが重要です。
基本設計・詳細設計では何を決めるのか？具体例で解説
システム開発における設計フェーズは、要件定義で明らかにされた内容をもとに、システムとしてどう実現するかを具体化していく重要なステップです。とくに、開発の初期段階に行う「基本設計」と、その内容を実装レベルに落とし込む「詳細設計」は、開発全体の品質・効率・安定性を左右する基盤となります。
ここでは、基本設計・詳細設計それぞれで何を決めるべきかを整理するとともに、業務系システムや組み込み系システムなど用途別の具体例や、ドキュメントの種類と記載内容についても詳しく解説します。
基本設計で決めること（機能要件・非機能要件）
基本設計では、要件定義に基づき画面構成や機能の概要、データ構造などの機能要件に加え、性能・セキュリティ・可用性などの非機能要件を具体化し、システム全体の骨格を固めることが不可欠です。
理由としては、設計の初期段階で要件を明確にしておかないと、後工程での大幅な修正や再設計が必要となり、工数やコストを圧迫するリスクが高まるほか、品質面でも不安定要素の増加が懸念されるからです。
たとえば、主要な画面レイアウトやAPI仕様を定義する際に、同時にアクセス集中対策や障害復旧手順を検討しておくと、設計の品質を高められます。また、高負荷が想定される場合にはキャッシュや負荷分散などの方針を早期に決めることで、大きな性能問題を未然に防ぐことが可能になります。
詳細設計で決めること
詳細設計はクラス構造やデータ構造、インタフェース、エラー処理を具体化し、実際にプログラミングを行うエンジニアが実装を円滑に進めるために行います。業務系は画面やDB定義重視、組み込みではハードウェア連携とリアルタイム制御を重点設計します。
業務系システムの詳細設計（データベース設計・API設計・画面設計）の場合
業務系システムの詳細設計では、データベース、API、画面の各要素を整合性と拡張性を考慮しつつ具体化し、性能と可用性を高めることが重要です。
| 要素 | 方法 |
|---|---|
| データベース設計 | テーブル構造を最適化してインデックスやパーティショニングを適切に定義し、将来的なデータ量の増加や検索速度を見据えた設計を行います。 |
| API設計 | 認証方式やパラメータの受け渡し、例外処理を明確化し、連携先とのインターフェースを定義します。 |
| 画面設計 | UI/UXや入力項目のバリデーションに加え、画面遷移やユーザビリティを事前に検証しておくことで、実装後の修正を最小限に抑えられます。 |
組み込み制御の詳細設計（ハードウェア制御・リアルタイム処理・通信プロトコル）の場合
組み込み制御の詳細設計では、ハードウェアとの連携やリアルタイム性を考慮して、システムの構造や動作仕様を具体的に定義します。PCやサーバーを中心とした業務系システムとは異なり、限られたリソースや厳しい応答時間要件に合わせて設計を最適化する必要があります。以下、組み込み制御の詳細設計で決定される主な要素です。
【組み込みシステムにおける詳細設計の主要要素】
| ハードウェアレジスタやデバイスドライバとのインターフェース | 実際のハードウェア制御に必要となるレジスタの設定や、デバイスドライバが提供するAPIなどを明確化します。 |
| リアルタイム処理の要件定義 | 応答時間（例えば数ミリ秒以内に処理を完了する必要があるなど）や同時に発生する割り込みを想定し、どのように優先度付けやタスク切り替えを行うかを検討します。 |
| 通信プロトコル | データの構造ややり取りのルール、異常時の対処方法を具体的に定義します。実際に送受信するデータをどのような形式（バイナリ／テキスト、JSON／XMLなど）で定義するかや文字コードやエンコーディング方式の選定（UTF-8、Shift-JISなど）などを定義します。 |
リアルタイム処理では、決められた時間内にタスクを完了させるスケジューリングや優先度設計がカギとなり、ハードウェア制御では、デバイスドライバやレジスタの操作、割り込み処理を適切に扱うことが大切です。
基本設計と詳細設計のドキュメント例
システム開発の設計工程では、目的やフェーズに応じてさまざまな設計ドキュメントが作成されます。ここでは、基本設計と詳細設計それぞれの代表的なドキュメントの種類・目的・記載内容を整理しました。
「どのドキュメントで何を伝えるべきか」「どの設計で何を決めるのか」を把握することで、設計の質やプロジェクトの成功率を高めることができます。
| 詳細設計の種類 | 目的 | 記載内容 |
|---|---|---|
| クラス図 | システム内のクラス同士の関係や構造を視覚化し、プログラム実装時の見取り図として活用します。 | – クラス名、属性（メンバ変数）、メソッド（関数）- クラス間の関連（関連、集約、継承など）- 依存関係や可視性（public, privateなど）の整理- 大規模システムの場合はパッケージ分割の概要も併記 |
| アクティビティ図 | ユーザー操作からシステム処理の流れを俯瞰し、処理の手順や分岐を示すことで、業務フローの理解と共有を深めます。 | – 処理や操作の開始・終了、分岐や並行処理の表現- アクション（処理ステップ）の順序や遷移条件- 例外系・エラー時の分岐表現- （ユーザー操作から）システム完了までを俯瞰する全体フロー |
| シーケンス図 | アクティビティ図よりも各システム内部の処理をさらに細かく時系列に沿って示し、オブジェクト（クラス）間のやり取りを時間軸で可視化します。 | – 参加するオブジェクトやアクターの列（Lifeline）- メソッド呼び出し、返却値、イベントの送受信などのシーケンス（時系列）- メッセージや引数、戻り値の表現- 分岐やループなどの制御フロー（alt, loopなど） |
| モジュール構成図 | システムを構成する処理単位をモジュール単位で示し、各モジュールの役割や相互依存関係を明確化します。 | – モジュール同士の関係・依存関係- 各モジュールの担当機能（入出力、処理内容など）- 利用するライブラリや外部サービスとの接続関係- （必要に応じ）モジュール内のクラスやファイル単位の階層構造- システム全体でのモジュール配置図（サブシステム、パッケージ分割など） |
これらのドキュメントをどう活かすか？
開発規模やシステムの性質によって、必要となる設計書の種類や粒度は異なりますが、全体像を把握する・仕様の誤解を防ぐ・実装をスムーズに進めるといった観点で、各設計書の目的を明確にしておくことが重要です。
また、レビューや引き継ぎの際にも、どのドキュメントを見れば何がわかるかが整理されていると、チーム内外の情報共有が円滑になります。
基本設計・詳細設計の経験が求められる理由とは？
設計経験は、エンジニアとしての成長において一つの節目とされることが少なくありません。とくに基本設計や詳細設計といった上流工程に関わるスキルは、実装スキルを超えてシステム全体を見通す力やコミュニケーション力、課題解決力といった総合的な能力が問われる場面でもあります。
ここでは、エンジニアのキャリアにおける設計経験の位置づけや、なぜ設計スキルが高く評価されるのかを解説し、あわせて未経験からどう設計経験を積み上げていくかについても紹介します。
エンジニアのキャリアパスと設計経験の関係
基本設計や詳細設計の経験は、エンジニアが上流工程を担うための重要なスキルセットとして高く評価されます。
理由としては要件定義や顧客折衝を踏まえてシステム全体の構造を理解し、複数のチームやモジュールを調整しながら設計を進める必要があるため、高度なコミュニケーション力と技術力が求められるからです。
新規プロジェクトで要件を整理し、基本設計書や詳細設計書を作成した経験を持つエンジニアは、プロジェクトを俯瞰する視点と問題解決能力を備えているとみなされ、リーダー職やアーキテクトなどへのキャリアアップにつながりやすいと考えられます。
設計経験があると評価されやすい場面
転職や昇進の際には、基本設計・詳細設計の経験を積んだエンジニアが高く評価されやすいです。
設計工程では要件の整理や仕様の落とし込みなど、プロジェクト全体を俯瞰しながら問題を解決する力が求められるため、これらの経験を持つ人材は即戦力として重宝されます。
実際に私が転職活動した際にも、小規模システムではありましたが、設計〜実装・テストまでを一貫して成し遂げた経験は高く評価されました。
未経験から設計経験を積むには？
設計未経験のエンジニアが基本設計や詳細設計の経験を積むには、OJTや自主学習を組み合わせて実際のプロジェクトに参加し、先輩やチームメンバーからノウハウを吸収するのが最も効果的です。
理由としては要件定義や設計工程は実務で得られる知見が大きく、仕様書の読み解きや設計レビューなどを通じた実体験が、独学では得られないスキル習得につながるからです。
まずは小規模な機能の詳細設計を任せてもらい、設計書を先輩エンジニアと相互レビューしたり、自身で設計パターンを学習しつつ徐々に大きなモジュールの基本設計に挑戦する、というステップアップが有効であると考えられます。
基本設計・詳細設計のスキルを身につける方法
基本設計や詳細設計のスキルは、システム開発の品質や生産性を左右する重要な要素であり、上流工程を担うエンジニアにとって避けては通れないスキルセットです。しかし、実装と異なり具体的なアウトプットや学習機会が見えにくいため、「どうやってスキルを伸ばせばいいかわからない」と悩むエンジニアも少なくありません。
このセクションでは、基本設計・詳細設計それぞれのスキルを高めるための学習法や実践的なアプローチ、加えてスキルアップに役立つ資格・学習リソースをご紹介します。現場で通用する設計力を身につけたい方は、ぜひ参考にしてみてください。
基本設計スキルを向上させる学習法
基本設計のスキルを向上させるには、理論と実践を組み合わせた学習方法が効果的です。基本設計はユーザー要件の正確な理解やシステム全体の俯瞰、さらに設計書の作成など多岐にわたり、自己学習だけでは身につかない実務上の経験が重要と考えられるからです。
UMLや設計パターンを体系的に学びながら、小規模なプロジェクトや模擬案件で設計書を作成し、先輩のレビューを通じてフィードバックを得ることで、基本設計のスキル向上が期待できます。
詳細設計スキルを磨くための実践的アプローチ
詳細設計のスキルを身につけるには、実務経験を通じて設計書を作成し、その内容についてフィードバックを受ける機会を増やすことが重要です。書籍や講座で学べる知識は基本的な考え方にとどまりがちで、実際のプロジェクトで求められる設計判断力や品質への配慮は、実践を通じてこそ習得できます。
具体的には、次のようなアプローチが有効です。
小規模な機能開発から始める
たとえば、画面1つ分の機能やAPIエンドポイント1つを対象に詳細設計書を作成し、命名規則やメソッド設計、エラーハンドリングなどについて先輩エンジニアからレビューを受けます。
コードレビューに積極的に関わる
他のメンバーが書いた設計書やコードをレビューする側に回ることで、自分の視点では気づけなかった設計上の工夫や落とし穴に気づくことができます。
設計意図を言語化する習慣をつける
「なぜこの処理にしたのか」「この構造にした理由は何か」を自分の言葉で説明することで、設計判断に一貫性が生まれ、レビュー時のやり取りも質が上がります。
このように、まずは実際に手を動かし、他者とのレビューを通じて視野を広げながら経験値を積み上げていくことが、詳細設計のスキルを着実に伸ばすための近道です。
設計スキルを伸ばせるおすすめの資格・学習リソース
設計スキルを伸ばすには、資格試験や専門書、オンライン講座といった学習リソースを活用した体系的な知識の習得が考えられます。資格や書籍は設計の基本概念を体系化して整理しており、オンライン講座などでは最新技術や事例を踏まえた学習ができるため、効率よく知識を深められるからです。
以下で具体的な資格や学習リソースについて紹介します。
| 資格・書籍・オンライン講座など | 説明 |
|---|---|
| システムアーキテクト試験 | 情報処理推進機構（IPA）が主催する国家資格で、システムのアーキテクチャ設計、技術選定、要件定義など広範な知識と実践力が問われるためIT業界での認知度が高く、高度な設計能力を証明できる資格です。 |
| 応用情報技術者試験 | システムアーキテクト試験の前段階として位置づけられ、システム設計や運用の経験がある中級者向けの資格です。 |
| はじめよう！システム設計 | システム設計をやったことがない初心者向けの書籍で、システム設計で出てくる知識や関連の知識や用語など細かく解説されています。 |
| 現場で役立つシステム設計の原則 | システム設計の中でも特にクラス設計やモデルに特化した本で、詳細設計・実装する方におすすめです。 |
| 【入門】システム要件定義と基本設計（実践ワークで理解する上流工程の進め方） | これから上流工程に取り組んでいきたいと考えているエンジニアにおすすめです。要件定義、基本設計で実施すべき内容や留意点が整理されており、上流工程に最低限必要なことを学ぶことができます。 |
| 【超実践】ビジネス要件分析・基本設計・詳細設計をやり抜く実践ワーク講座 | ビジネス価値の高いプロダクトを設計・開発したいエンジニアにおすすめです。要件定義〜詳細設計で作成する成果物を一通りハンズオンで作成することができます。 |
| OSSプロジェクトへの参加 | 興味のあるOSSプロジェクトにコントリビュートし、実践的な経験を積むことができます。 |
基本設計・詳細設計に関するよくある疑問
設計工程の重要性は理解していても、実際の現場で「どこまでやれば十分なのか」「この判断は設計なのか実装なのか」と迷う場面は少なくありません。特にアジャイル開発のように変化が前提となる現場では、設計の進め方そのものに戸惑う人も多いのではないでしょうか。
このセクションでは、基本設計・詳細設計にまつわる代表的な疑問や不安に対し、実務に根ざした視点でわかりやすく解説します。現場で判断に迷ったときのヒントとして、ぜひ参考にしてみてください。
アジャイル開発での基本設計・詳細設計の進め方
アジャイル開発では、基本設計・詳細設計をスプリントごとに小さく区切って進め、必要に応じて設計内容を継続的に見直すアプローチが有効です。
短いサイクルで要件が変化しやすいアジャイル環境下では、大規模な設計書を一度に作るのではなく、動くソフトウェアとフィードバックを優先しながら柔軟に修正できる体制を整える必要があるからです。
最初にシステム全体の大まかな基本設計を作成し、スプリントごとに詳細設計を細分化しつつ実装し、レビューとリファクタリングを通じて設計内容を常に最新化します。これにより、要件変更や仕様追加にも迅速に対応でき、設計の無駄が最小化されます。
設計と実装の境界線はどこ？
基本設計と詳細設計は「何を作るか」「どう作るか」を明確にする工程であり、その内容が具体的に落とし込まれ、開発者が迷わずコードを書ける段階までが設計、それ以降のコード記述やテストは実装にあたります。
設計では仕様の全体像や機能要件、データ構造を抽象化しながら整理し、開発チームの共通認識を形成するのが目的であり、実装はその仕様をもとに具体的なコードを作成・検証する作業になるからです。
UML図でクラスやメソッドの引数・戻り値、例外処理を設計書に定義し終えたら設計の範囲は一旦完結し、それを参考にプログラマが実際のコードを書き、動作検証を行う部分が実装になります。
ただしアジャイル開発の場合は設計と実装が反復的に行われるため、明確な境界線を引きにくいという側面があります。
どれくらいの規模のプロジェクトから設計が必要か？
「設計が必要かどうか」はプロジェクトの規模そのものよりも、以下のような要素の複雑さによって判断すべきです。
- 要件の不確実性や変更リスクがあるか
- 複数人での開発・引き継ぎが発生するか
- 外部システムとの連携やAPIの整合性が求められるか
- 保守・運用を見据えた設計が必要か
たとえば、開発者が1人で完結でき、要件も固定されたシンプルなツールであれば、設計書を省略しても問題ないことが多いです。しかし、たとえ数人規模のチームであっても、画面数が多い／データ構造が複雑／外部連携があるといった場合には、少なくとも簡易的な基本設計やインターフェース仕様は必要になります。
一方で、中〜大規模プロジェクト（例：10人以上／期間3か月以上／複数モジュール・チームが関与）では、基本設計・詳細設計を省略すると、後工程で手戻りが多発し、品質や納期に大きく影響を及ぼします。
設計スキルを伸ばすために実務以外でできることは？
実務経験が少なくても、オンラインコミュニティやオープンソースプロジェクトでの活動などを通じて、理論と実践を両立した学習を続けることで設計スキルを伸ばせます。
設計は抽象的な仕様化から具体的な実装への落とし込みまで一貫した思考力が問われるため、実務以外でも同様のフローを試行できる環境を活用することで理解が深まるからです。
個人プロジェクトを立ち上げ、UML図やワイヤーフレームを用いて設計を可視化し、GitHubやQiita、Zennなどで公開してレビューをもらうのも良いと思います。これにより、設計段階からのフィードバックを得て継続的に改善でき、実務へ応用可能な設計力が養われると考えられます。
まとめ
システム開発における基本設計と詳細設計は、プロジェクトの成功とエンジニアのキャリア成長において非常に重要な要素であると考えられます。基本設計はシステム全体の骨格を定義し、要件を整理して大枠を固めるフェーズであり、転職や昇進の際には「上流工程に携わってきた経験」として評価されやすいポイントになります。
一方、詳細設計は、その大枠を具体的な実装レベルの仕様に落とし込む工程で、コードレビューやプロジェクト経験を通じて実践的なスキルを磨くことができます。こうした基本設計・詳細設計の経験の積み重ねを通じて、市場価値の高いエンジニアとして活躍の幅が広がっていくでしょう。
ライター：R.Kotomo
プロフィール：見習い中のデータエンジニアとして、PythonやSQL、クラウドを日々の業務で扱っています。ITエンジニアが執筆した技術記事から多くを学び、自身の経験も誰かの役に立てたいと考えライターを始めました。データ人材やデータ業界に関する情報を、初心者にもわかりやすくお伝えすることを目指しています。実務に基づいた具体的な内容や、現場で役立つノウハウを共有することで、読者のみなさまに気づきを与えられたらと思います。
