エンジニアが恥をかかないための【重要キーワード5選】

2020年9月9日

個人事業、フリーランスをやる中で、あらゆる企業の方々と打ち合わせをしていると知らない言葉が飛び交うことがしばしばあります。

実際に打ち合わせをして初めて相手の技量がわかることも多いですよね。

そのような時は、正直に「わかりません」と質問してしまった方が長期的に見て良い信頼関係を構築していけるように感じます。

（わからないことは、わからないとキッパリ言える人に好印象を感る人は私の周りでも多くいます。逆に隠してわかったフリをして、後々理解していなかったとバレた方が信頼回復に時間を要してしまいます。）

とは言っても、初見の大事な打ち合わせでなめられたくない、相手に不安を感じさせたくないという気持ちは必ずあります。

特に私が最近Web会議で恥をかいた「このワードくらいは知っておけば良かった」と後悔したキーワードを５つ抜粋してみました。

実は僕も、私も、という方はぜひ概要的な理解にはなりますが、ご活用いただければと思います。

（※私の主観を交えての概要理解です）

DevOpsモデル

DevOps では、従来型のソフトウェア開発と、インフラストラクチャ管理プロセスを使用するよりも速いペースで製品の進歩と向上を達成し、企業がアプリケーションやサービスを高速で配信できるように、文化的な基本方針、プラクティス、ツールが組み合わされています。この高速化により、企業は顧客により良いサービスを提供し、市場競争力を高めることができます。

https://aws.amazon.com/jp/devops/what-is-devops/

DevOpsとは「サイロ化」されていた開発チーム、運用チームの障壁取り除き、開発者の生産性と、運用の信頼性を最適化することをいいます。

開発（Development）と運用（Operations）を組み合わせた言葉です。

※ サイロ化：部署間が情報共有せずに独自に業務を遂行すること

その利点としては、

• スピードの向上
• ビルド→デプロイ→リリースの自動化
• 信頼性
• 拡張性
• 共同作業の向上
• セキュリティ

などがあります。

要はあらゆる障壁をなくし、自動化、部品化、疎結合をして、合理的に「開発、リリース、運用、改善のサイクルを爆速化」することと理解しておく。

UML

Unified Modeling Languageの略語。

日本語では「統一モデリング言語」と呼ばれています。

複雑なシステムも図を用いてグラフィカルに表現し、記述方法を統一することで設計書の可読性を上げ、議論しやすく円滑なコミュニケーションを促進します。

「PHP」「Ruby」「Java」というようなプログラム言語にコーディング規約というものがあるように、ドキュメントのコーディング規約版といった理解になります。

ルール化しておくことで、メンバー間の共通理解も早く、早期問題発見にもつながります。

中でも

• クラス図
• コンポーネント図
• 配置図
• シーケンス図

あたりは良く使われますし、自分が設計する際にも矢印や図の意味などを知っているだけでドキュメントの精度はぐっと上がります。

ConvDev

Conversational Development（会話型開発）

DevOpsを実践するための手段として、開発グループのメンバー同士のコミュニケーションを重視してアプリケーション開発をおこなう開発スタイルのことです。

具体的にはGithubやGitLabといったツールでの対話型のレビュー機能であったり、Googleのスプレッドシートなどでリアルタイムにレビューや添削などをコミュニケーションをとりながらおこなっていくようなイメージです。

以前はプログラマー、システムエンジニアというとPCの前に張り付いて孤独にコーディングしているというイメージでしたが、最近では「よく喋って、よく議論してる」というイメージにシフトしてますね。

論理的に話せて、自分が作る製品を誰よりも熱く語れる。

今のエンジニアは営業的側面も持ち合わせているため素晴らしい人材ですよね。

シーケンス図

UMLのドキュメントの１つとして出てましたが、「プログラムの処理の流れや概要」を設計する際によく使われるグローバル・スタンダードの設計手法になります。

具体的にはクラスやオブジェクト間のやり取りを「時間軸」に沿って「図」で表します。

構成要素は大きく下記の４つに分かれています。

• ライフライン
• 実行仕様
• 停止
• メッセージ

ルール化されているため、誰がみても共通の理解を得ることができます。

より詳細、実際の書き方は以下のページがわかりやすいです。

https://aws.amazon.com/jp/devops/what-is-devops/

Atomic Design（アトミック・デザイン）

パーツ・コンポーネント単位で定義していくUIデザイン手法です。

１：原子（ATOMS）

例）検索ボタン、決定ボタン

２：分子（MOLECULES）

例）検索テキストボックス + 検索ボタン

３：生体（ORGANISMS）

例）ヘッダーロゴ + ヘッダーメニュー + （検索テキストボックス + 検索ボタン）

４：テンプレート（TEMPLATES）

３の要素 + ヘッダー画像 + サイドメニュー + 見出し

５：ページ（PAGES）

４の要素にそれぞれ実際のパーツ、フォントや画像をセッティング

の順にデザイン作業を合意して、進めていきます。

運用イメージとしては、出来上がりのページ（PAGES）から仕様の追加時に、ボタンという原子（ATOMS）が必要になるため、デザイナーに作ってもらう、といったような進め方が可能です。

メリットを考えると、コンポーネント化し再利用しやすい単位に分解しておく際や、デザイナーとの作業分担を明確にする際に活用できそうです。

まとめ

どのキーワードも概要しかおさえていませんが、いずれも一度は深く読み込んで理解しておくことをおすすめします。

ですが、概要や特徴をおさえておくことで急な打ち合わせの際にも話を遮ることなくエンジニアとして当然理解している程で会議を進めることができるようになります。

キーワードが意味する概念、実際の手法をしっかり理解し、生産性の向上につなげていきたいですね。

それでは、また。