ERは「Entity Relationship Diagram」の略称であり、**データベース設計における代表的な設計図を指します。**システムを設計する際の手法としては、他にもUMLなどの技法もあります。UMLは「統一モデリング言語」という意味で、システム開発を図式で表現、記述方法を統一することです。設計書のわかりやすさや情報共有の効率の向上に役立ちます。

ER図は「DOA」と呼ばれる「データ中心アプローチ」の技法を用い、作成したER図を物理データベース上に直接変換できることから、データベース設計における手法の事実上の標準となりつつあります。ER図の「E」はエンティティを示し、「R」はリレーションを示します。つまり、**ER図とは「実体（データなど）」と「関係」の組み合わせのことで、システムにおけるデータ間の処理する構造を指します。**

例えば、「顧客が本を注文する」という処理をER図で表現してみます。「顧客」「本」がエンティティ、「注文する」がリレーションに対応します。*大規模システムの場合でも、エンティティとリレーションの組み合わせを用いて、わかりやすくシステムを表現できる*ことがER図の特徴です。

システムエンジニア（SE）とは？仕事内容や年収、必要スキルを解説！

システムエンジニアがキャリアアップするのにおすすめの資格を解説！

ER図はシステム開発における要件定義や設計などの上流工程の中で、段階的に設計を行います。各工程で作成したER図の状態を「データモデル」といい、データモデル図には*「概念データモデル図」「論理データモデル図」「物理データモデル図」の3種類があります。*

ここからは、各データモデルについて簡潔に説明します。

**1.概念データモデル図**
概念データモデル図は、*要件定義工程の際に作成するデータモデル図*を指し示し、システム全体におけるエンティティ、リレーションを洗い出し、事象を大まかに表した図のことです。

**2.論理データモデル図**
論理データモデル図は、*基本設計工程の際に作成するデータモデル図*を指します。論理データモデル図を作成する際は、概念データモデル図に対してさまざまな詳細を加えて肉付けを行います。具体的には、*アトリビュート・主キー・外部キー・リレーション・カーディナリティ*といった要素を付け加えます。
論理データモデル図においては、データ型の定義のように物理データベース向けの設計は行わないため、特定のデータベースに依存しない状態のモデル図といえるでしょう。

**3.物理データモデル図**
物理データモデル図は、*詳細設計工程の際に作成するデータモデル図*を指します。ここでは、「*MySQL*」や「*Oracle Database*」など特定の物理データベース向けに論理データモデル図の変換を行います。例えば、物理データベースに適したデータ型を追加したり、ローマ数字に変換したりします。ER図の最終形態が物理データモデル図です。物理データモデル図が完成した後は、物理データベースを実際に作成することができるでしょう。

ER図を作成する際は、下記の5つの標準的な要素を用いることが多いです。

**1.エンティティ**
「エンティティ」とは、実体、つまりデータのまとまりのことを指します。エンティティの中には、アトリビュートという属性情報があります。アトリビュートについても後ほど解説します。

**2.リレーション**
「リレーション」は関係を意味し、エンティティ同士の関係を表現する線のことを指します。リレーションの詳細については、カーディナリティという記号を使って表現します。カーディナリティについても後ほど解説します。

**3.アトリビュート**
「アトリビュート」は属性を意味し、エンティティの中の属性情報のことを指します。アトリビュートでは、主キーや外部キーについても表現します。主キーとなる項目は、エンティティ上部に四角の囲いで記載し、外部キーとなる項目は、項目名の後ろに「（FK）」と記載します。その他の項目は、項目名のみ記述することが多いでしょう。

**4.カーディナリティ**
「カーディナリティ」は多重度を意味し、「*1対1*」「*1対多*」「*多対多*」など、リレーションの始点と終点を表現する記号のことを指します。さらに、「*0以上*」「*0または1*」なども表現することが可能です。

**5.エンティティの依存関係と非依存関係**
「*依存関係*」とは、結びつくデータが必ず存在する関係、つまりエンティティ間の親子の関係性を指します。親と子のどちらのデータが欠けたとしてもシステム的に成り立たないことを示しています。子となるエンティティの枠線を角丸で表現することが多いでしょう。
一方、「*非依存関係*」とは、エンティティ間で親子がない関係性のことを指します。この場合、結びつくデータが存在しなくてもシステム的に成り立つことができます。非依存関係の場合、親と子のどちらのエンティティも四角の枠線で表現することが多いでしょう。

## ER図を作成する2つのメリット

これまでに、ER図の詳細について紹介してきました。ここからは、ER図を作成する上で2つのメリットを紹介しましょう。

システム開発後は、正常に稼働するように監視を行いながら、よりよいシステムになるように改修を繰り返していきます。ER図は、システム開発後の保守・運用工程においても活用できるでしょう。システムが稼働しはじめた直後は、設計者がプロジェクト内にいることが多いため、設計書がなくても問題がない場合もあります。

しかし、設計者が別のプロジェクト案件に異動するなど、プロジェクト内に残り続けるということはほとんどありません。したがって、**ER図を設計書の中に記載しておくことで、設計者ではない方でもシステムの設計内容を正確に理解し、システムの仕様の変更などの改修を行う際にスムーズに対応することができます。**

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

### 手戻りのコストを防止することができる

データベースのテーブル数が多くなると、設計誤りや、プロジェクト関係者がシステムの仕様について理解できないことがあります。その場合、手戻りが必要なことも多く、余分なコストが発生してしまいます。特に大規模なシステムの場合は、**ER図でデータベース構造などを整理することで、システム全体の構成を俯瞰することができるため、手戻りを起こす可能性を減少させることもできるでしょう。**したがって、システム開発においてER図の作成は必要不可欠といえるでしょう。

ここからは、ER図の作成方法を紹介します。ER図に限らずシステム設計全般において言えることとして、大枠から徐々に詳細に落とし込む作業が重要です。

### ①システム開発の進め方を把握する

**ER図を記述する際は、システム開発の進め方が明確になっていることが前提です。**ユースケース図やアクティビティ図などを、インプット情報としてER図を設計します。特に、ER図を作成する際に、ユースケース図は重要な役割を果たすことが多いです。ユースケース図とは、ユーザーの視点に立ち、システムの利用例を表現する図解術のことを指します。

*ユースケース図の設計が終わってない段階でのER図の作成はおすすめできません。*まずは、システム開発の進め方の設計からはじめましょう。

システム開発の進め方について把握できたら、*ユースケース図やアクティビティ図などを基にエンティティを洗い出します。*システム開発の進め方の設計を正確に行っていれば容易にエンティティを洗い出すことができるでしょう。

### ③エンティティをマスタデータとトランザクションデータに分ける

エンティティの洗い出しが完了したら、**エンティティを「マスタデータ」と「トランザクションデータ」に分けましょう。**データはマスタデータとトランザクションデータに大きく分けられます。マスタデータとは固定的なデータ、トランザクションデータとは流動的なデータといわれることが多いです。次のアトリビュートを洗い出す前に、整理しておきましょう。

また、マスタデータとトランザクションデータを整理する過程の中で、エンティティが合体することも少なくありません。

### ④アトリビュートを洗い出す

次に、エンティティの中のアトリビュートを洗い出します。*アトリビュートの洗い出しは、画面設計書を基にすると効率的に行うことができます。*画面に出力される項目がアトリビュートとなる場合が多いでしょう。

アトリビュートまで洗い出すことができたら、リレーション・主キー・外部キーの設計を行いER図を作成します。また、*カーディナリティは業務内容によって変わることに注意しましょう。*これでようやくER図の完成です。ここからは、設計メンバーでレビューを重ねてブラッシュアップしていくことが重要です。

## ER図を効率よく作成してプロジェクトの成果を向上させよう！

この記事では、ER図の詳細、メリット、作成方法を紹介しました。ER図を作成することで、プロジェクト工程の手戻りを減らすことができるなどメリットが多くあります。

また、**実際にER図を作成する際に、無料で利用できるツールも存在します。**カーディナリティの変更なども、ツールを使えば簡単に変更が可能です。例えば、「*Cacoo*」というクラウド型の図形作成ツールがあります。業務効率を上げるために、ER図作成ツールを活用することもおすすめします。これらを踏まえて、ER図を効率よく作成してプロジェクトの成果を向上させましょう。

ER図（Entity Relationship Diagram）とは、データベース設計における代表的な設計図を指します。当記事では、このER図についてのそもそもどういったものなのか・基本ルール・メリット・ER図の作成方法をわかりやすく解説します。

ER図とはデータベース設計における代表的な設計図の1つである

ER図のデータモデル図には「概念データモデル図」「論理データモデル図」「物理データモデル図」の3種類ある

ER図を作成するメリットとして、「保守・運用工程で役に立つ」、「手戻りのコストを防止することができる」ことが挙げられる

ER図とは？詳細・メリット・作成方法についてわかりやすく解説！　

まずはコードレビューの*基本的なやり方を解説*します。どういう手順で行うべきか、1から説明します。初めてコードレビューを行う方は、まずはこちらをお読みください。

コードを読む前に、まず**「システムの仕様を把握すること」が重要**です。どのような機能をもつシステムなのか仕様を把握しないと、コードのどこを指摘したらいいのか分からず、仕様通りに書かれていない箇所の指摘もできません。

また、*コードレビューに慣れていない場合、仕様を頭に入れていないとコードが読み解けないことも多い*です。新人のコードレビューをする場合は、新人が関わっている箇所の仕様書を読み込み、何を作ろうとしているのか全体像を確認しましょう。

### コードを一通り読んで確認する

仕様書を一通り理解したら、コードを一通り読んでいきます。書き方が良くなかったり、非効率な処理をしていたりする部分などがあれば*メモ*しておきましょう。

また、**コードを自分の開発環境でも実行し、エラーが出ないかもチェックします。**開発環境が変われば、エラーが発生するケースも多いためです。こういった地道が作業が、コードレビューでは必要です。

メモした内容を基に、問題点を*口頭・Github・チャットツールなどで指摘*します。また問題点を指摘する上で、参考にした資料などがあれば提示・添付すると良いでしょう。新人が問題点に関する質問をしてきたら、きちんと答えられるようにしておくことも重要です。レビューをする際は**同じミスを繰り返さないよう、相手に分かりやすく伝えることを意識しましょう。**

## コードレビューで見るべきポイント

ここでは、コードレビューで見るべき具体的なポイントを紹介します。特に*コード量が多い場合、最初から最後まで熟読するのは大変*です。見るべきポイントを抑えて、そこを重点的に確認すれば、*コードレビューの時間を短縮*できるでしょう。1つ1つのポイントを詳しく解説していきます。

### 自社のコードルールに則っているか

まずは、**自社のコードルールにしっかり則って書かれているコードか**確認しましょう。インデントやコメントの書き方など、それぞれの会社でルールが設けられているはずです。

他の会社でエンジニア経験がある方の場合、*自社のコードの書き方ではなく、前職での書き方をそのまま使っているケースも多い*です。そういった場合は、自社のコードルールに則っていない旨を指摘しなければなりません。レビュー時はコードが自社のルール通りなのか、確認してください。

### コメントが分かりやすく書かれているか

コメントが分かりやすく書かれていないと、*仕様変更を行う際や他の人に担当部分を引き継ぐ場合に苦労します。*エンジニアによっては、コメントを全く書かない人や、逆にコメントが多すぎる人もいます。*ソースだけでなく、コメントが上手く挿入されているか確認する*のが良いでしょう。

### バグを生み出しやすい部分がないか

コードレビューを行う主な目的は、「バグを潰す」であることがほとんどです。プログラマーを数年続けていると、どの部分がバグを生み出しやすいか感覚が掴めていると思います。その感覚を頼りに、*バグが出そうな部分を重点的にチェック*しましょう。

たとえば、if文がネストされている部分や無限ループが使われている部分、変数名が分かりにくい部分などはバグが出やすいです。また、**なるべぐバグを生み出しにくいコードを書くように指示する**ことも大切です。

### 仕様変更の際に修正箇所が多くならないか

コードレビューの際は、**今後の仕様変更のことも考えて行いましょう。**仕様変更が発生すると予想される箇所のコードは、修正部分が少なくなるよう記述するのが重要です。たとえば、*同じような処理を関数にまとめる*などが該当します。後に修正箇所が多くなりそうな部分も、コメントしてあげることが大切です。

*例外処理が入っていない場合が割と多い*ため、そこも重点的に確認しましょう。ユーザーが想定外の動作を行った場合に、プログラムがエラー文を出さないかチェックします。例外処理が入っていない場合は、**例外処理を書く必要があることの旨と、書き方の例をコメント**しておきましょう。

## コードレビューを効率化させる方法

コードレビューは、*あまり時間をかけすぎるのも良くありません。*時間をかけすぎて自分の業務に影響が出てしまうことがあります。そこで、コードレビューを効率化させる方法を解説します。レビューすべきコード量が多い場合などは、これらを意識してみてください。

### レビューの目的を明確にする

**レビューの目的を明確にすることは重要**です。たとえば「バグをなくす」「効率的なコードの書き方を教育する」など、目的はそれぞれ異なります。レビューの目的が決まれば、その部分のみに絞って効率的にチェックできるでしょう。

### 自動コードレビューサービスを使う

「自動コードレビューサービス」というものもあります。コードを入力すると、**ツールがコードを自動解析してくれ、問題点をコメント**してくれます。たとえば、「Sider」は日本初の自動コードレビューサービスとして有名です。また、解析ルールをカスタマイズし、自社仕様にすることもできます。

もちろん、*こういったサービスに頼り切るのは良くありませんが、要所で活用することでレビュー時間を短縮できるでしょう。*「Sider」以外にも「Codacy」や「Hound」などいくつか種類はあるので、試しに使ってみてください。

レビューする箇所が多すぎる場合は、*役割分担を行うことも検討*しましょう。たとえば「コードが仕様書通りか確認する人」と「コードの書き方が規約に則っているか確認する人」に分けるなどです。

**役割分担することでピンポイントで確認でき、レビューの質も上がる**でしょう。役割分担に関しては、上司に相談してみるのが良いです。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

コードレビューする際の注意点も解説していきます。これらの注意点も意識しないと、新人との関係を悪くしたり、レビューの質低下に繋がったりします。*ある程度コードレビューを行ってきた人も、注意点を守れていないことが多い*です。どういった点に気をつけるべきか、1つ1つ解説していきます。

コードの悪いところを否定しても、*その人自身は否定してはいけません*。「なぜこんなこともできないのか」と、高圧的な態度を取るのも止めましょう。新人との関係を悪くしたり、相手がコードレビューを嫌いになることに繋がったりします。

悪い箇所を指摘する際は、**淡々と事実のみを話し、自分の感情を介入させないようにしてください。**また、絵文字などを使って柔らかい雰囲気を出すのもコツです。柔軟な対応を見せることで、レビュイーが新人でも萎縮することなく疑問点を質問してくれるようになるでしょう。あくまで「レビューするのは相手に対してではなく、コードであること」を意識するのが重要です。

### なぜこうすべきか根拠を話す

悪い部分を指摘する際はなぜこのような書き方をすべきか、*根拠を話すことも重要*です。たとえば「コード規約に書かれているから」という説明では、相手は納得できません。

コード規約に則るとどんなメリットがあるか、分かりやすく話すことが重要です。そうすることで初めて相手は納得し、改善もしやすくなります。

また、**レビューする際に参考にした本などがある場合は、それを見せるのも効果的**です。「なぜそうなのか」をきちんと説明することは、コードレビューをやる側の理解度アップにも繋がります。

コードレビューをする際は、*具体的な修正案も示してあげましょう*。その方が相手がどのように変更すべきか分かりやすくなります。また、**言葉ではなかなか伝わりにくい部分も理解させることが可能**です。もちろん、具体的な修正案を示すのは時間もかかるため、できる範囲で行いましょう。

悪い部分を指摘するだけでなく、*良い部分があれば褒めるようにしましょう。*コードレビューを行う上で大切なのは、**やる側とやってもらう側の信頼関係**です。悪い部分ばかり指摘するのは、信頼関係を築く上で好ましいことではありません。

また、良い部分を褒めることで、エンジニアとしての自信がつき、レビュイーの成長速度を早めることにも繋がります。良い部分や「なるほど」と思う部分も必ずあると思うので、コメントしてあげるようにしましょう。

書き手の意図が分からない部分は、*「なぜこういう書き方をしているのか」直接本人に質問*しましょう。質問することで、レビュアーの読解力が不足しているのか、コードの書き方に問題があるのかが分かります。

また、レビュイーの説明力や理解力をアップさせることにも繋がるでしょう。ただし、**問い詰めるような言い方はせず、穏やかな雰囲気を意識して対応することが重要**です。

## コードレビューはやる側もエンジニアとしての成長に繋がる

本記事では、コードレビューのやり方について解説しました。どういった手順でコードレビューを行うべきか、お分かり頂けたかと思います。

コードレビューはやってもらう側だけでなく、やる側もエンジニアとしての成長に繋がります。コードレビューを行うことで、読みやすいコードはどういった物なのか分かってくるため、*自分のコードを確認する上でも役立つ*でしょう。

ただし、時間をかけすぎると自分の業務に支障が出るため、**効率的にレビューを行うことも重要**です。コードレビューを頼まれた場合は、本記事で解説したことを意識して行ってみてください。

リモートで働くエンジニアの実態やメリット、デメリットについて紹介

本記事ではコードレビューのやり方を解説します。エンジニア2、3年目になると新人のコードをチェックする機会もあるでしょう。そこで、コードレビューで見るべきポイントや、効率的に行う方法を解説します。コードレビューをする予定のある方はぜひご覧ください。

コードレビューを行う際は見るべきポイントを抑える

コードレビューは時間をかけすぎるのも良くないため、効率的に行うことを意識する

コードレビューはやる側もエンジニアとしての成長に繋がる

コードレビューを初めて行う人必見！やり方を1から解説！

## オーバーエンジニアリングとは

オーバーエンジニアリングとは、気をきかせたつもりがありがた迷惑になるような過剰なエンジニアリングのことです。また、シンプルに組み立てることができず無用に複雑にしてしまうエンジニアリングを指すこともあります。

### オーバーエンジニアリングの2つの意味

日本語版のウィキペディアには「オーバーエンジニアリング」の項目はありませんが、英語版では次のように定義されています。

「オーバーエンジニアリングとは、製品を、その用途に必要な以上に頑丈にしたり、多くの機能を装備させること。あるいは、ある機能を装備するために不必要に複雑、非効率な設計することである」

つまり、**製品に過剰な性能を与えること**、あるいはある機能を持たすめの**設計(システム開発)で、最短コースではなく遠回りをしてしまうこと**がオーバーエンジニアリングです。

自転車のタイヤに時速100㎞に耐える性能は必要ないし、独身寮に置く電子レンジに「煮込み機能」や「パン焼き機能」は無用の長物です。

エンジニアリングの場合、同じ機能があるのなら、できるだけシンプルなロジックで書かれたコードが望まれます。

### 過ぎたるは及ばざるがごとし

日常の使用ではオーバーエンジニアリングと思われていた機能が災害時には役に立った、ということもあります。*セキュリティに関してはオーバーエンジニアリングが起きにくい*と言えるかもしれません。しかし、そんなケガの功名がいつも生じるわけではありません。

自転車のタイヤが時速100㎞で壊れなくても不都合はないし、独身寮の電子レンジに煮込み機能が付いていても別に邪魔にはなりません。大は小を兼ねるのです。それにもかかわらず、オーバーエンジニアリングが「過ぎたるは及ばざるがごとし」と言われるのはなぜでしょうか。

最も分かりやすい理由は、**オーバーしている分だけ時間とコストがかかっている**からです。それはユーザーにとっては「*高い価格*」につながるし、メーカーには「*競争力の低下*」をもたらします。

システム開発における**不必要に複雑なロジックは、オーバーエンジニアリングというより、エンジニアリングの失敗**です。見た目では問題なく機能しているようでも、それが*システムの脆弱性*になったり、*バージョンアップの際に手間やコストがかかる*原因になります。

趣味で行なうプログラミングにオーバーエンジニアリングという概念はないかもしれませんが、仕事・企業活動においては常に「過不足ないエンジニアリング」が求められます。

## オーバーエンジニアリングが生じる原因

エンジニア・クライアント・ユーザーそれぞれにデメリットが大きいオーバーエンジニアリングがしばしば生じるのは、**エンジニアリングも人間の行為で、ヒューマンな要因が深く関わっている**からです。

### ソフトウェアの開発に内在するスケーラビリティへの要求

スケーラビリティ（scalability）とは、例えばユーザーが1万人から100万に増えても適応できるような拡張性のことです。エンジニアはシステム開発をするときに、**スケーラビリティを過剰に追求する傾向**があります。

しかし、「将来はこんな機能が役に立つはずだ」とか「この機能ではここも拡張可能にしておいて方が良い」という発想は、オーバーエンジニアリングを生む大きな要因です。

とくに日本人は「おもてなしの精神」が豊かなので、*「不足」を心配するあまりに実装内容が過剰になりがちなメンタリティ*を持っています。

「今のところは、とりあえずこれで間に合う」がもっとも妥当なシステム開発と言えます。現在、自分あるいはプロジェクトが抱えていない問題を解決するコードを書く必要はないのです。

### 自己陶酔型のエンジニアリング

要件をコードに落とし込むときに、なにか**アイディアが浮かぶと、ついそれを実装したくなる誘惑**にかられませんか？

「オレもなかなかやるじゃないか」と思う瞬間があるのはプログラミングの醍醐味ではありますが、「なんてオレは賢いのだろう」という自己陶酔は抑制しないと、いたるところでオーバーエンジニアリングが生じます。

ドキュメンタリー映画を作るときに、効果音楽をドラマチックにしたり、有名俳優をフューチャーしたりするのは逆効果です。自己陶酔型のエンジニアリングでは、このような*フューチャリング(過剰な機能の追加)*が生じがちです。

システム開発中に「こんなこともできる」「あんなこともできる」というアイディアが浮かんだとしても、それは別のプロジェクトに活用すべきアイディアかもしれません。

### 成功体験がセカンドシステム症候群を誘発する

最初のシステム開発では「コンパクトに、シンプルに」という自制心が働いたとしても、それが**成功して「次のバージョンを」というときにやりすぎてしまうのがセカンドシステム症候群**です。

ファーストバージョンの成功は開発者に自信を与え、ステークホルダー(利害関係者)にセカンドバージョンへの期待を抱かせます。このような*勢いに乗ったムードの中でオーバーエンジニアリングを自制するのは、簡単ではありません*。

## オーバーエンジニアリングを避けるには

エンジニアリングという仕事にやりがいを感じている人、創造性がある仕事だと思っている人ほど、オーバーエンジニアリングに陥りがちです。それを避けるには、次のような注意が必要です。

### オーバーエンジニアリングへの誘引が自分の中もあることを自覚する

オーバーエンジニアリングが生じる原因にはヒューマンな要素が大きいので、エンジニアは「気をつけないと自分もやってしまう」という自覚を持つ必要があります。

とくに、**「できるエンジニア」だという自己肯定感は、自己陶酔型のエンジニアリングを誘引しやすい**ので、自制しなければいけません。

*成功体験でチームや会社のムードが盛り上がっているとき*も、セカンドバージョンの設計でオーバーエンジニアリングが生じやすいので、警戒が必要です。

### 要件の本質、解決すべき問題の本質を捉まえる

オーバーエンジニアリングを防ぐには、心構えだけでなく、要件の本質的な意味を理解することが必要です。言い換えるなら、**「なぜこの要件があるのか」をUI(ユーザー・インターフェース)、UX(ユーザー・エクスピアリエンス)の視点で深く捉える**必要があります。

また、 YAGNI（You ain't gonna need it）の原則では、実際に必要となるまでは余計な機能は追加しない方がよいとされます。要件の本質、必要性がユーザー目線で明確化されれば、複数の想定されるソリューションのどれを選ぶべきかは、ある程度絞られてくるはずです。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

### 要件の意味を包括的、長期的に理解する

個々の要件の意味を、プロジェクト(あるいは製品)の**全体像から理解すること、さらに、できるだけ長期的な観点から理解すること**がオーバーエンジニアリングを防ぐことにつながります。

これは個人の心構えや努力だけでは限度があるので、プロジェクト全体、企業全体の意思統一と見通しが必要です。

要件の理解、ソリューションの選択が、課題の全体像から離れるほどオーバーエンジニアリングが生じやすく、プロジェクトのあちこちでそれが生じるほど、*成果物は将来に向けて厄介な問題を抱え込む*ことになります。

## オーバーエンジニアリングかどうかの分かりやすい基準はない

ここまで述べてきたように、オーバーエンジニアリングがヒューマンな問題である以上、*あるソリューションがオーバーエンジニアリングかどうかの客観的で分かりやすい基準はありません*。

また、あるソリューションがオーバーエンジニアリングかどうかは、セカンドシステムをどの程度視野に入れておくかによっても、判断が異なってきます。

このように単純明快な対処策がないのがオーバーエンジニアリングなので、エンジニアに求められるのは、**要件の意味をUX視点で繰り返し問い直しながら、過不足ないエンジニアリングを心がける**ことです。

システム開発をしているエンジニアがついやってしまいがちなオーバーエンジニアリング。余計な時間がかかるだけでなく、後々システムにとって負の遺産になることもあります。本記事は、オーバーエンジニアリングとはなにか、オーバーエンジニアリングが生じる原因と、予防策について考えます。

オーバーエンジニアリングとは、成果物に本来求められていない機能を装備させることである

オーバーエンジニアリングが生じる原因には人間的な要素が大きい

オーバーエンジニアリングを防ぐには要件の本質をUXから理解する必要がある

オーバーエンジニアリングとはなにか？なぜ発生し、どうすれば防げるのかを徹底解説！

Git Bashとは、*Git for Windows*に同梱されている*Bashとターミナルエミュレーションを含むソフトウェア*です。BashはLinuxやUnixならびにmacOSで利用されています。Windowsで利用する際は「*Windows Subsystem for Linux*」を用いるか「*Git for Windows*」を導入することで**bashが利用可能**です。

Git Bashの*Git*とは、プログラム開発で用いる*バージョンコントロールシステム*を指します。Gitは*Linuxのソースコードのバージョンコントロールを行う目的*で開発されました。Gitは*大規模プロジェクト*で用いるために、*全履歴がネットワーク全体で利用できます*。

このため開発者が多数参加するプロジェクトの場合も、ソースコードの共有や一元管理が行えるため、**共同開発ツール**として数多く利用されています。
参考：[git About](https://git-scm.com/about)

Gitでは複数人でのプログラム開発時において、*ソースコードの共有や一元管理*ができます。Linuxカーネルの開発で使用しているため、*超大規模プロジェクト*にも対応します。

*Git for Windows*は**GitのWindows版パッケージ**です。Git for Windowsは、*Git SCM*という*GitのフルセットをWindows環境で利用すること*を目的としています。そのため、バージョン管理に必要な機能をGit Bash、Git GUIから利用可能にしています。
参考：[Git for Windows Tools&Features](https://gitforwindows.org/)

*Git for Windows*をインストールすると、*Git Bash・Git CMD(Deprecated)・Git GUI*のツールがインストールされます。各**ツールの用途**は以下の通りです。

・*Git Bash*
　Bash環境をWindowsでエミュレートします（簡単にいうとBashとして利用できます）。
　さらにLinuxで利用している標準Unixコマンドが利用できます。
・*Git CMD(Deprecated)*
　WindowsのコマンドプロンプトでGitのコマンドが利用できます。
・*Git GUI*
　Git BashがCUIなのに対して、GUIでGitを利用できます。
　他にもGUI型のGitが多数あるので好みに応じて利用します。

Git Bashは**Git for Windowsをインストールすることで利用可能**です。LinuxやmacOSではBashが同梱されているため、追加作業は不要です。もし、Windows以外でもGitを利用してバージョン管理したい場合はGitをインストールする必要があります。

Git Bashのインストールをするには、Git for Windowsの公式サイトで「*Download*」リンクをクリックし、ダウンロードします。2021年9月時点でv2.33.0のインストーラ ”Git-2.33.0.2-64-bit.exe”が登録されています。その他のリリースは以下のGitHubに格納されています。
参考：[Git for Windows Tools&Features](https://gitforwindows.org/)
参考：[Git for Windows All Releases](https://github.com/git-for-windows/git/releases/)

次に、ダウンロードした*インストーラを起動*します。以下にインストーラのセットアップ画面の手順を説明します。
（1）*ユーザアカウント制御*
　インストーラ起動時にユーザアカウント制御が表示されたら「はい」をクリックします。
（2）*GNU General Public Licenseの表示*
　「Next」をクリックします。
（3）*インストールフォルダの指定*
　通常はそのまま「Next」をクリックします。
（4）*Select Componentsの選択*
　Git Bashをエクスプローラーで利用するために、「Windows Explore integration」「Git Bash Here」のチェックを確認し、「Next」をクリックします。
（5）*スタートメニューフォルダへの表示設定*
　指定後「Next」をクリックします。
（6）*Gitで使うdefault editorの指定*
　VimまたはVisual Studio Codeを指定し、「Next」をクリックします。
　Visual Studio Codeを利用する場合は別途インストールが必要です。
（7）*リポジトリの設定*
　変更不要の場合はそのまま「Next」をクリックします。
（8）*コマンドラインPATHの設定*
　変更不要の場合はそのまま「Next」をクリックします。
（9）*HTTPS transportの設定*
　変更不要の場合はそのまま「Next」をクリックします。
（10）*行末処理（LF、CRLF）の設定*
　変更不要の場合はそのまま「Next」をクリックします。
（11）*Git Bashのターミナルエミュレータの設定*
　変更不要の場合はそのまま「Next」をクリックします。
（12）*git pullの動作設定*
　変更不要の場合はそのまま「Next」をクリックします。
（13）*追加オプションの動作設定*
　変更不要の場合はそのまま「Next」をクリックします。
（14）*疑似コンソール（実験オプション）の動作設定*
　変更不要の場合はそのまま「Install」をクリックし、インストールが開始します。
（15）*インストール終了画面*
　「Next」をクリックし完了します。

LinuxやmacOSでは、bashはそのまま利用できます。Gitを利用する場合は、*Gitのダウンロードサイト*からダウンロード・インストールします。*macOS*の場合は*Homebrew*または*Xcode*を使います。*Linux*の場合はディストリビューションに対応した*パッケージマネージャ*を使います。
参考：[Git Downloads](https://git-scm.com/downloads)

インストール時にスタートメニューに登録した場合、*スタートメニュー*の「*Git*」または「*最近追加されたもの*」からGit Bashをクリックすると、Git Bashが起動します。同様に、エクスプローラーの設定で「*Git Bash Here*」をチェックした場合は、エクスプローラーで右クリックするとそのフォルダで*Git Bashが起動*します。

その他、インストール時に指定したルートディレクトリに*bash.exe*があるため、コマンドプロンプトで直接起動することも可能です。デフォルトでは*”C:\Program Files\Git\bin\bash.exe”*となります。

### Git Bashのフォルダ・ディレクトリの移動方法

Git Bashのホームディレクトリは、**”~”**です。カレントディレクトリ以下のファイルの表示は*”ls”コマンド*を使います。フォルダ・ディレクトリの移動は*”cd”コマンド*を使います。

Git Bashのディレクトリの移動方法は、Git Bashプロンプトで以下のコマンドを入力することで指定できます。
*使用方法：*
　$ cd パス（パスは絶対パス、または相対パス）
*使用例：1つ上のディレクトリに相対パスで移動*
　$ cd ..
*使用例：特定のディレクトリに絶対パスで移動*
　$ cd "C:/Program Files/"

Git Bashを起動する前に、エクスプローラーでデフォルトディレクトリを指定することもできます。エクスプローラーで該当フォルダとして開きたい場所を開きます。そこで「*右クリック*」→「*Git Bash Here*」を選択してください。*Git Bashが指定したディレクトリで開きます*。

なお、*ドライブの変更*は以下のように指定します。
*使用方法：*
　$ cd /\[ドライブ名\]
*使用例：Cドライブに移動する*
　$ cd /c

Git Bashは*GitとWindows用Bash*が利用できるインストーラです。Bashの内部コマンドは*Bashの仕様*に従います。外部コマンドとしては*Linuxで用いる標準Unixコマンドが同梱*されるため、**LinuxやUnixと同等の操作が可能**です。ファイル表示は*”ls”コマンド*ですので、Git for Windowsでインストールされた*コマンド一覧*は*”ls /usr/bin”*で確認できます。

以下の代表的なコマンド一覧を説明します。
・*ls*
　ディレクトリのファイル一覧表示を行います（Windowsのdirに相当します）。
・*cd*
　ディレクトリの移動を行います（Windowsのcdに相当します）。
・*pwd*
　カレントディレクトリの表示を行います（Windowsのcdに相当します）。
・*mkdir*
　ディレクトリの作成を行います（Windowsのmd / mkdirに相当します）。
・*rmdir*
　ディレクトリの削除を行います（Windowsのrd / rmdirに相当します）。
・*mv*
　ファイル・ディレクトリを移動、名前変更を行います（Windowsのmove / renに相当します）。
・*cp*
　ファイルのコピーを行います（Windowsのcopyに相当します）。
・*touch*
　ファイルの作成を行います（Windowsのcopy nul / type nulに相当します）。
・*rm*
　ファイルの削除を行います（Windowsのdelに相当します）。

さらにコマンドを追加したい場合は、*ルートディレクトリ下のusr/bin*にモジュールをインストールすることでGit Bashから利用可能です。ルートディレクトリはデフォルトの場合、*”C:/Program Files/Git”*です。

Windowsのパッケージマネージャである*Chocolatey*等からGit for Windowsをインストールすると、*関連コマンドの追加*が簡単にできます。
参考：[Chocolatey](https://chocolatey.org/)

Git Bashの*ウィンドウの左上のアイコン*を右クリックすると、メニューが表示されます。Git Bashのカスタマイズはこの**メニューの「Options...」**から行います。ここからターミナルのテーマを設定したり、見栄えやフォントを指定したりすることができます。

このようなカスタマイズは標準設定の機能だけではなく、GitHubに*カスタマイズツール*が多数登録されています。追加してGitを利用する際には、*”git config”*で*リポジトリの構成設定や確認*を行いカスタマイズしていきます。

## Git Bashを使ってOSの違いを吸収しましょう

Git Bashを使うことで、Linuxで用いる標準Unixコマンドも合わせてWindowsで利用可能です。そのため、従来Linuxで稼働させた*シェルスクリプト*も*Windowsで動作*するため、より柔軟にシステムを構築することができます。カスタマイズを進めて、さらに最適なシステム構築を目指しましょう。

Git Bashとは、Git for Windowsに同梱されているBashです。BashはLinuxやmacOS等で利用されており、多くのシェルスクリプトで活用されています。ここでは、Git Bashのインストールからコマンド活用まで幅広く解説していきます。

Git Bashとは、Git for Windowsに同梱されているBashおよびソフトウェアを指します

Git for WindowsをインストールすることでGit Bashが利用可能です

Linuxで用いる標準Unixコマンドが合わせてインストールされるため、シェルスクリプトの活用が可能です

Git Bashとは？WindowsのLinuxツールを解説！

**Jupyter Notebooとは、オープンソースソフトウェアの統合開発環境（IDE）です。**統合開発環境とはソフトウェア開発に必要とされるエディタ・言語処理・デバッグ・実行に関するツールを*単一の操作環境から利用できるようにしたもの*です。

Jupyter Notebookでは*Python*を始めとする**40以上の言語**を用いた開発を、ウェブブラウザやウェブベースアプリケーションを用いて行うことができます。Jupyter Notebookは*データ分析機能*があるため、*ビッグデータのデータ分析・統合*にも用いることができます。*科学技術計算や機械学習*等を目的とする方には特におすすめです。

Python標準のpipコマンド、あるいはAnacondaのcondaコマンドを始めとするいくつかのインストール方法が提供されています。
参考：[Project Jupyter | Home](https://jupyter.org/)

Jupyter Notebookのメリットは、**豊富なライブラリを用いてデータ分析を行えること**です。オープンソースソフトウェアのため、*無償*で利用できます。また、Jupyter Notebookのドキュメントは*プログラムコード*に加えて、*数式や図式を入れること*ができるため**データ分析の統合開発環境**として人気があります。

データ分析の主要ライブラリである*NumPy・SciPy・Matplotlib・SymPy・pandas*を、*Python・IPython*で利用することを想定しています。

さらに、Jupyter Notebookは*実行結果がすぐに出力*され、1画面にまとめて表示されるため、*逐次確認が可能*なこともメリットの1つです。このことは対話型で授業を行う**教育現場**にも適しており、大学の授業にも取り入れられています。

### JupyterLabとJupyter Notebookの違い

JupyterLabとJupyter Notebookは、ともにProject Jupyterの*ユーザインターフェイス*として位置づけられています。JupyterLabはJupyter Notebookの**次世代ユーザインターフェイス**を提供するもので、Jupyter Notebookの機能をカバーします。

具体的な違いですが、従来のJupyter Notebookの画面は*ファイルブラウザとエディタ*のビューで構成されていました。対してJupyterLabは、*ファイルエクスプローラービューとメインビューの統合画面*で構成されています。そのためJupyterLabでは、主要な統合開発環境で用いられている**マルチドキュメント**が単一ウィンドウで表示できるため操作方法が改善されました。

これにより、JupyterLabでは直感的な編集作業ができるように機能強化が図られています。

Jupyter Notebookを使うには、*パッケージマネージャ*を用いて**Jupyter Notebookをインストール**します。インストール後はパッケージ管理システムのラウンチャーを使ったり、直接コマンド起動したりすることでJupyter Notebookを実行することができます。詳しくは以降で説明します。

### Jupyter Notebookのインストール方法

Jupyter Notebookのインストールは、通常パッケージ管理システムに付属している*パッケージマネージャ（コマンド）*を用います。代表的なパッケージマネージャは、*PyPIで用いるpip*と*Anacondaのconda*です。

これから導入を始める方は、*データサイエンスや機械学習用途*に用いるのが*Anaconda*、*汎用用途あるいは初心者の利用*は*PyPI*を利用することをおすすめします。pipとcondaはそれぞれ選択したリポジトリに合わせて使用します。以下はそれぞれのインストール方法です。

**・pipを用いたインストール方法**
以下のいずれかのコマンドでインストールを行います。
　$ python -m pip install jupyter
　$ pip install jupyter

**・condaを用いたインストール方法**
ここでは簡単なインストール方法として、Anaconda Navigatorを起動します。
　Anacondaの最初の起動時には「Environment」「Create」で環境を作成します。
　「Home」をクリックし、右画面にアプリケーションを表示します。
　Jupyter Notebookの「Install」をクリックするとインストールが開始し、「Launch」で実行可能となります。すでに「Launch」と表示されている場合は追加作業は不要です。

condaコマンドを用いる場合は”conda list”でインストールパッケージを確認し、”conda install -c anaconda jupyter”でインストールすることもできます。

Jupyter Notebookの起動と停止方法は、以下の方法で行います。通常*”http\://localhost:8888/”* がjupyterのローカルサーバーの*HTTP接続で使用*されます。

**・pipを用いた場合の起動と停止方法**
pipを用いた場合は、コマンドプロンプトやターミナルで”jupyter notebook”コマンドで起動します。これにより、ローカルでJupyterのウェブサーバーが起動するため入力画面はそのままにしておきます。

停止時はコマンドプロンプトやターミナルの起動画面を「Ctrl」キーと「c」キーを同時に押して、終了処理を行います。終了処理が完了すると、コマンドプロンプトやターミナルにプロンプトが表示されます。確認表示が出た際は”y”を入力します。

**・condaを用いた場合の起動と停止方法**
conda（Anaconda）を用いた場合は、Windowsの場合スタートメニューの「Anaconda3 (64-bit)」の下の「Jupyter Notebook」をクリックします。Anaconda NavigatorのアプリケーションからJupyter Notebookの「Launch」をクリックしても起動します。

終了する場合は、Jupyter Notebookのメイン画面右上の「Quit」をクリックしてください。その後”Server stopped”が表示されると終了です。または「File」「Close and Halt」をクリックすると、”Shutdown this notebook’s kernel, and close this window”が表示され、終了です。

終了処理を忘れた場合は、*”jupyter notebook stop”*コマンドで終了させることもできます。

### Jupyter Notebookのコード作成と実行方法

お役立ち記事