働くということ
― エンジニアに伝えたい仕事の本質 ―
この書籍は、新人から中堅エンジニアに向けて書いています。
技術スキルだけでなく、仕事について総合的にまとめたものです。社員教育の一環で、伝えたいことの一部をつらつらと書き起こしてみました。
日々のタスクに追われる中で、ふと立ち止まって「自分の仕事の意味」を考えるきっかけになれば幸いです。
目次
- 第1章 仕事の起源
- 第2章 商売とは何か
- 第3章 仕事の定義
- 第4章 仕事はどこから来るのか
- 第5章 仕事の肝は「人への興味」
- 第6章 コミュニケーション ― 仕事を動かすインフラ
- 第7章 成長とは何か
- 第8章 学びの技術 ― 勉強・真似・失敗・好奇心
- 第9章 体調管理も仕事のうち
- 第10章 メタ認知 ― 自分を知ることが最大値を引き出す
- 終章 まとめ
第1章 仕事の起源
人類にとっての「仕事」の始まり
人類の長い歴史において、「仕事」の原点は 狩猟 でした。
獲物を仕留められなければ、その日の食事がなくなります。
群れに食料を持ち帰れなければ、家族が飢えます。
失敗すれば、自分が獲物になることもありました。
つまり、仕事とはかつて 生き抜くための行為 でした。
現代との違い
現代社会においては、制度や法律、セーフティネットが整備され、仕事に失敗しても命を失うことはほとんどありません。
しかしこの「安全」は、同時に仕事に対する 切迫感や本気度を薄める 側面も持っています。
「なんとなくこなす」「とりあえず形にする」という姿勢が生まれやすいのは、生存がかかっていないからこそです。
では、今の私たちはどうあるべきか
生存の危機がないからこそ、自分自身で仕事に向き合う理由を持つことが必要 になります。
「自分がこの仕事をやり切らなければ、誰かが困る。だから本気で向き合う。」
そう思えるかどうかが、仕事のクオリティを根本から変えます。
現代における「本気で働く」とは、体力や時間を消耗することではなく、「この仕事に真剣に向き合う」という意志を・覚悟を持ち続けること です。
真摯さ ― 仕事に向き合う姿勢
経営学者のピーター・ドラッカーは、著書『現代の経営』の中で、働く人にとって最も重要な資質として 「真摯さ(integrity)」 を挙げました。
ドラッカーは、スキルや知識は後から身につけられるが、真摯さだけは持って生まれるか、自ら育てるしかないと語っています。
真摯さとは、難しい概念ではありません。
- 手を抜かない
- ごまかさない
- 相手に対して誠実である
- 自分の仕事に責任を持つ
派手な成果を出すことでも、器用に立ち回ることでもなく、「当たり前のことを、当たり前にやり続ける」 という姿勢そのものです。
そしてこの真摯さは、一朝一夕には身につきません。日々の小さな判断の積み重ねによって、少しずつ形になっていくものです。
給料はなぜ差があるのか
世の中を見渡すと、給料には大きな差があります。この差はどこから生まれるのでしょうか。
分かりやすい例として、アルバイトを考えてみます。
コンビニやファストフードのアルバイトは、時給1,000円前後のことが多いです。決して楽な仕事ではありません。立ち仕事で、クレーム対応もあり、覚えることもたくさんあります。
ではなぜ、専門職やマネジメント職と比べて時給が低めに設定されているのでしょうか。
理由はシンプルで、「代わりがきく」 からです。
- マニュアルが整備されていて、誰でも短期間で習得できる
- 判断に大きな責任が伴わない(重要な意思決定は店長・本部が行う)
- 失敗しても影響範囲が限定的
これは「アルバイトの仕事に価値がない」という意味では決してありません。世の中にその仕事をできる人が多ければ、一人あたりの報酬は下がる という、ただの市場の原則です。
報酬を決める3つの要素
裏を返せば、給料が高くなる仕事には共通の要素があります。
| 要素 | 意味 |
|---|---|
| 専門性 | その人にしかできない領域があるか |
| 責任の重さ | 判断を誤ったときの影響範囲はどれほどか |
| 代替可能性の低さ | 他の人で簡単に置き換えられるか |
医者、弁護士、熟練エンジニア、経営者 ― 報酬が高い職業はすべて、この3つのどれか、あるいは全部を高い水準で満たしています。
- 医者は、判断を誤れば人の命に関わる(責任)
- 弁護士は、法律という専門領域を持つ(専門性)
- 熟練エンジニアは、他の人では解決できない技術課題を解決する(代替不可能性)
報酬とは、「働いた時間の対価」ではなく、「専門性と責任と代替不可能性の対価」 なのです。
報酬を上げたいなら、背負うものを増やす
「もっと給料が欲しい」と思うのは自然なことです。では、どうすればそれが実現するのか。
答えはシンプルです。アルバイトの対極 ― 代わりがきかない人になっていくこと です。
- 誰もが避けるタスクに、あえて手を挙げる
- 自分の担当範囲を少しずつ広げる
- 判断が必要な場面で、逃げずに決める
- 苦手な領域から逃げず、できる範囲を広げる
これらの積み重ねが、専門性と責任を育てます。そしてその土台にあるのが、先ほどの 真摯さ です。
真摯さがない人には、責任は預けてもらえません。真摯さがない人には、専門性も深まりません。
真摯に働く → 代わりがきかない人になる → 報酬が上がる
このシンプルな循環が、仕事人としての歩みそのものです。
― 働くことは辛いだけではない
ここまで「生き抜く」「真摯さ」「責任」「報酬」と、少し硬い話が続きました。
でも、仕事には確かに楽しさがあります。
昨日できなかったことが今日できるようになる。
誰かに「ありがとう」と言われる。
任される範囲が少しずつ広がっていく。
「あなたに頼みたい」と言ってもらえる。
見える景色が、少しずつ変わっていく。
この 「成長を味わえる感覚」 は、働くことでしか得られない報酬のひとつです。お金だけではない、もうひとつの報酬。
重たく考えすぎる必要はありません。真摯に、丁寧に、目の前のことに向き合っていれば、そうした瞬間は自然と訪れます。それを受け取れる人は、きっと仕事を好きになれます。
― あなたはあなたという物語の主人公
少し視点を変えてみます。
あなたが毎日過ごしているこの人生は、一本の長い物語 です。そしてその物語の主人公は、他の誰でもない あなた自身 です。
どんな物語でも、主人公には共通点があります。
- 最初は未熟で、何もできない
- 困難に出会い、悩み、もがく
- 仲間と出会い、助けられたり、助けたりする
- 少しずつ成長し、できることが増えていく
- 気づけば、昔の自分には見えなかった景色に立っている
これは、あなたのキャリアそのものではないでしょうか。
主人公であるという自覚
自分を物語の主人公だと思えると、不思議なことが起こります。
- 辛い出来事が「試練の章」に変わる ― 乗り越えた先に次の展開があると信じられる
- 失敗が「伏線」になる ― あとで効いてくる経験として受け取れる
- 出会う人が「登場人物」になる ― それぞれに意味があると思えるようになる
- 日々の小さな選択が「物語を動かす決断」になる ― どんな一歩にも意味が生まれる
脇役として生きるか、主人公として生きるか。
この違いは、同じ1日の重みをまったく別のものに変えます。
あなたの物語を、誰も書いてくれない
ここで大切なことが一つあります。
あなたの物語を書けるのは、あなただけです。
上司が書いてくれるわけでも、会社が書いてくれるわけでも、時代が書いてくれるわけでもありません。どんな選択をするか、どんな挑戦をするか、どう立ち上がるか ― そのペンを握っているのは、常にあなた自身です。
しんどい日もあります。うまくいかない日もあります。
でも、それも含めて、あなたの物語の一部です。
あなたが今日踏み出した小さな一歩は、
1年後、3年後、10年後の自分が振り返ったとき、
「あの時の自分、よくやったな」 と誇れる一行になります。
今日という1ページを、どんな気持ちで書き込みますか。
その選択が、明日の主人公の姿を決めます。
第2章 商売とは何か
商売の本質は「価値の交換」
商売の原点は、相手が持っていないものを提供し、自分が持っていないものを受け取る という交換にあります。
物々交換の時代から現代に至るまで、この本質は変わっていません。
【価値交換の構造】
あなた(提供者) 相手(受け手)
┌─────────────┐ ┌─────────────┐
│ スキル・知識 │ ──────▶ │ 課題・悩み │
│ 時間・労力 │ │ やりたいこと │
└─────────────┘ └─────────────┘
▲ │
│ 対価(報酬) │
└──────────────────────────┘
商売は「信頼の積み重ね」でもある
価値交換は「一回で終わり」ではありません。
継続的な商売が成立するためには、相手との信頼関係 が必要です。
- 約束を守る
- 期待を超える成果を出す
- 問題が起きたとき誠実に対応する
これらが積み重なって初めて、長期的なビジネス関係 が生まれます。
「商売とは、相手の課題を解決し、その対価を得ながら、信頼を積み重ねて関係を継続させること」
単発の取引で終わるのは「売る」こと。
継続する関係を築くのが「商売」です。
エンジニアとしての商売
私たちエンジニアにとっての「商売」は何でしょうか。
- クライアントの業務課題をシステムで解決する
- 社内の生産性向上に貢献する
- チームメンバーの疑問や詰まりを解消する
誰かの「困った」を解決すること 、それがエンジニアとしての価値交換であり、商売の実体です。
第3章 仕事の定義
「仕事」を定義する
「仕事」という言葉は日常的に使われますが、改めて定義すると何でしょうか。
仕事とは、「誰かの役に立つことで、社会との関係を結ぶ行為」である。
ポイントは3つです。
| 要素 | 内容 |
|---|---|
| 誰かの役に立つ | 自分だけが満足するのは「趣味」。仕事は必ず受け手がいる |
| 社会との関係を結ぶ | 報酬・評価・信頼という形で社会とつながる |
| 行為である | 考えているだけでなく、アウトプットがある |
「作業」と「仕事」の違い
よく混同されますが、作業と仕事は異なります 。
- 作業:言われたことをこなすこと
- 仕事:目的を理解し、価値を生み出すこと
たとえば、「この画面のボタンを赤くしてください」という依頼があったとします。
- 作業思考:ボタンを赤くする
- 仕事思考:なぜ赤くするのか?ユーザーに何を伝えたいのか?本当に赤が適切か?を考えた上で実装する
仕事は、「なぜ」を問い続けること から始まります。
一挙一動が、評価につながっている
仕事を「誰かとの関係の中で価値を生む行為」と定義したとき、見えてくる重要な事実があります。
自分のすべての行動が、評価の材料になっている。
評価とは、人事考課や昇給面談のときだけ発生するものではありません。
- 朝の挨拶の仕方
- 質問への返答の速さと丁寧さ
- 締め切りに対する姿勢
- ミスをしたときの対応
- 誰も見ていないときの仕事の丁寧さ
- 会議中の聴き方・発言の仕方
これらすべてが、周囲の人の記憶に蓄積されていきます。
そして その積み重ねが「あの人はどういう人か」という評価になる のです。
人間は、相手のことを無意識に観察しています。
「あの人は頼めばちゃんとやってくれる」「あの人は細かいところまで気にしてくれる」という印象は、特定の一場面ではなく、無数の小さな行動の総体 から形成されます。
逆も然りです。「あの人はちょっと……」という印象も、大きな失敗からではなく、日常の何気ない行動の積み重ねから生まれることがほとんどです。
評価を「試験」として身構える必要はありません。
ただ、「自分は今も誰かと関係を結んでいる」という意識を持つこと 。
それだけで、日々の行動の質は変わります。
第4章 仕事はどこから来るのか ― ビジネスの構造
自分のタスクが、なぜ存在するのか。
この章では、その問いに答えます。
受託開発という仕事
SIer(システムインテグレーター)は、顧客から依頼を受けてシステムを開発・納品する ビジネスモデルをとっています。
| モデル | 説明 | 例 |
|---|---|---|
| 受託開発 | 顧客の要件に基づいてシステムを作る | 「A社の業務管理システムを構築する」 |
| 自社プロダクト開発 | 自分たちでサービスを作って売る | SaaSサービスなど |
| 派遣(労働者派遣) | 派遣契約により、顧客先で顧客の指揮命令を受けて作業する | 派遣社員として常駐 |
| SES(準委任) | 準委任契約に基づき、顧客先で作業する。指揮命令権はSES会社側にあり、顧客が直接指示を出すと偽装請負となる | 技術者常駐型の受託作業 |
受託開発の最大の特徴は、「顧客がいなければ仕事が存在しない」 という点です。
これが、営業活動の重要性につながります。
顧客はなぜシステムを依頼するのか
顧客企業も、常に何らかの課題を抱えています。
- 業務が非効率で人件費がかかっている
- 競合他社がデジタル化を進めていて遅れをとっている
- 法改正への対応が必要
- 既存システムが老朽化している
これらの課題を解決する手段として、外部のIT会社にシステム開発を依頼 します。
営業は何をしているのか
営業の仕事は「モノを売る」ではなく、「顧客の課題を理解して、解決策を提案する」 ことです。
顧客との関係構築
↓
課題のヒアリング(何に困っているか)
↓
解決策の提案(どういうシステムで解決できるか)
↓
見積もり・提案書の作成
↓
受注・契約
営業は、技術者と顧客の「通訳者」でもあります。
顧客の言葉(業務用語)を技術要件に変換し、技術者の言葉(システム仕様)を顧客が理解できる言葉に変換します。
案件の流れ ― 受注から納品まで
[営業] [PM/リーダー] [エンジニア]
| | |
受注・契約 ──→ 要件定義・設計 ──→ 実装・テスト
| | |
顧客折衝 スケジュール管理 タスク実行
予算管理 品質管理 課題報告
追加交渉 メンバー調整
契約の種類と責任範囲
受託開発には主に2種類の契約形態があります。
| 契約形態 | 内容 | リスク |
|---|---|---|
| 請負契約 | 成果物(システム)を納品する義務がある | 仕様変更・バグ対応は基本的に受注側の責任 |
| 準委任契約 | 作業時間・工数を提供する | 成果物の保証はないが変更に柔軟 |
この契約形態によって、変更があったときの対応コストが誰に発生するか が変わります。
これが、「仕様変更は慎重に扱う」理由です。
見積もりとは何か
案件が始まる前に、「この作業にどれくらいの費用がかかるか」を提示します。
工数(人日・人月)× 単価 = 費用
例:
設計:5人日
実装:20人日
テスト:10人日
──────────────────────────
合計:35人日 × 単価 = 見積金額
エンジニアが「タスクに何時間かかったか」を記録するのは、次の見積もり精度を上げるため でもあります。
会社が存続するための条件
会社が継続して存在するためには、次の循環が必要です。
売上(受注)
↓
利益(売上 − コスト)
↓
給与・設備・採用への投資
↓
組織の維持・成長
↓
次の案件をこなす力
↓
(繰り返し)
コストの大半は 人件費 です。エンジニアの給与は、案件の売上から支払われます。
稼働率という概念
SIerでは「稼働率」が重要な指標です。
稼働率 = 実際に案件に使った時間 ÷ 総労働時間
例:月160時間のうち140時間を案件に使った → 稼働率87.5%
稼働率が低い(案件がない時間が多い)と、会社の収益が下がります。
これが、営業が常に次の案件を探し続けている理由です。
役割分担の全体像
| 役割 | 主な責任 |
|---|---|
| 経営・役員 | 会社の方向性、資金調達、重要な顧客関係 |
| 営業 | 案件獲得、顧客折衝、契約管理 |
| PM(プロジェクトマネージャー) | スケジュール・品質・コスト・リスク管理 |
| テックリード | 技術方針の決定、アーキテクチャ設計 |
| 中堅エンジニア | 設計・実装・後輩指導 |
| 新人エンジニア | 実装・テスト・ドキュメント作成 |
どの役割も欠けると案件が回りません。
「タスクをこなすだけ」に見えても、それが案件の品質と納期を支えています。
新人・中堅から見えていないこと
新人の視野
新人の視野は、自分のタスクの周辺に集中しています。これは自然なことです。
【新人の視野】
自分のタスク ─── 直近の締め切り
【実際に動いているもの】
・営業が顧客と追加要件を交渉している
・PMが予算超過のリスクを経営に報告している
・別のエンジニアが依存する機能の完成を待っている
・顧客側の内部承認が遅れてスケジュールが圧迫されている
・次の案件の提案書を同時進行で作っている
中堅の視野
中堅になると案件内の動きは見えてきますが、まだ見えにくいものがあります。
- 営業と顧客の間で何が交渉されているか
- 会社全体の利益率・財務状況
- 経営が次にどの市場・技術領域に投資しようとしているか
- 顧客企業の内部政治(誰が決裁者か、どの部署が主導しているか)
なぜ「見えない」のか
情報は意図的に絞られている場合もあります。
- 機密保持(顧客との契約上、共有できない情報がある)
- 役割の明確化(知らなくてよい情報を渡すと混乱を招く)
- 伝達コスト(全員に全情報を共有するのは非効率)
「見えない=自分には関係ない」ではありません。
見えていないところで、あなたの仕事に影響する判断が毎日行われています。
顧客企業もビジネスの中にいる
私たちのシステムを発注する顧客企業も、それぞれの市場で戦っています。
【例:小売業のA社がシステム発注するケース】
消費者がA社で買い物する
↓
A社の売上が立つ
↓
A社は競争力強化のために在庫管理システムを刷新したい
↓
私たちに発注
↓
エンジニアがシステムを構築
↓
A社の業務効率が上がり、消費者への価格・サービスが改善される
あなたのコードは、最終的に 消費者の体験 につながっています。
IT投資と経済の関係
企業がITに投資するのは、景気や経営環境と連動しています。
| 経済状況 | 企業の動き | IT投資への影響 |
|---|---|---|
| 好況 | 積極投資・拡張 | 新規開発案件が増える |
| 不況 | コスト削減 | 既存システムの保守・効率化案件が増える |
| 法改正・規制変更 | 対応必須 | 特定システムの改修需要が発生 |
| 技術トレンド変化 | 競合対応 | クラウド移行・AI導入などの需要 |
お金の流れで見る社会
[政府・日本銀行]
金融政策・財政政策
↓
[金融機関]
企業への融資
↓
[事業会社(顧客)]
IT投資・設備投資
↓
[私たち]
受注・開発・納品
↓
[エンジニア]
給与として受け取る
↓
[消費・納税]
社会へ還流
給与は「もらうもの」ではなく、社会の経済循環の中で自分が生み出した価値の対価 です。
第5章 仕事の肝は「人への興味」
技術より先に必要なもの
エンジニアという職業は、技術力が重視されます。しかし、仕事の現場で圧倒的な差を生み出すのは、「人への興味」 です。
クライアントが何に困っているか。
チームメンバーが今どんな状態か。
ユーザーが何を求めているか。
これを知ろうとする姿勢が、仕事の質を根本から変えます。
「人への興味」が生み出すもの
人への興味
│
├── 相手の状況を理解しようとする
│ └── 的外れな提案が減る
│
├── 相手の言葉の裏を読もうとする
│ └── 本当の課題を発見できる
│
└── 相手の立場に立って考える
└── 信頼される提案ができる
「興味がない」は致命的
逆に、人への興味がないとどうなるか。
- 要件を聞いても「なぜそうしたいのか」を考えない
- 作ったものが「使われない」システムになる
- コミュニケーションが事務的になり、信頼が生まれない
技術はツールです。ツールを活かすのは、相手を理解しようとする姿勢 です。
前章で見たように、私たちの仕事は必ず「顧客」から始まります。その顧客は生身の人間であり、不安を抱え、期待を持ち、社内政治の中でプロジェクトを推進しています。その人への興味なしに、良いシステムは作れません。
そして、人への興味を行動として形にしたものが、次章で語る「コミュニケーション」です。
第6章 コミュニケーション ― 仕事を動かすインフラ
コミュニケーションの本質
多くの人が「コミュニケーション=自分の考えを伝えること」と捉えています。
しかし本質は、「相手と理解を共有すること」 です。
伝えた ≠ 伝わった
この差を意識しているかどうかが、仕事の成否に直結します。
コミュニケーションは「仲良くするための手段」ではありません。
仕事を正しく、速く、ミスなく進めるための最も基本的なインフラです。
なぜコミュニケーションが重要なのか
仕事は、一人では完結しません。要件はクライアントから来て、設計はチームで議論し、成果物は誰かに使われます。すべてのプロセスに「他者」が介在します。
社内における重要性
| 目的 | コミュニケーションがもたらすもの |
|---|---|
| 認識合わせ | 要件・仕様のズレを防ぎ、手戻りをなくす |
| 問題の早期発見 | ブロッカーや遅延を早めに共有することで被害を最小化する |
| チーム連携 | 属人化を防ぎ、誰が抜けても回る体制をつくる |
| 意思決定の質 | 多角的な情報をもとに、より良い判断ができる |
| 信頼関係 | 問題を隠さず報告できる心理的安全性が生まれる |
社外における重要性
社外(顧客・取引先)とのコミュニケーションにおいて、最も重要なのは 「信用」と「信頼」 です。
- 社内のミスはリカバリーできることが多い
- しかし社外では、一度失った信用は簡単には取り戻せない
顧客はサービスや技術だけを買っているのではありません。
「この会社・この人に任せて大丈夫か」という信頼を買っています。
コミュニケーションを取らないとどうなるか
社内への影響
- 認識ズレによる手戻り・やり直しが多発する
- 問題の発見が遅れ、被害が拡大する
- 属人化が進み、特定メンバーが離脱するとブラックボックス化する
- 「知らなかった」が頻発し、チームに不公平感・不満が蓄積する
- 心理的安全性が下がり、問題を隠す文化が生まれる
社外への影響
顧客視点で考えると、コミュニケーション不足は以下を引き起こします。
- 進捗が見えず、不安になる
- 確認したいのに連絡が取れず、不信感が生まれる
- 期待していたものと違うものが届き、落胆・クレームになる
- 問題が起きても知らされず、顧客側の計画まで狂う
- 次第に「この会社には頼めない」という判断につながる
顧客にとってのコミュニケーション不足は、「不安」と「不信」に直結します。
そしてそれは、失注・解約・悪評という形で会社全体に返ってきます。
個人の成長への影響
コミュニケーションを取らない人は、成長の機会を自ら閉じています。
- フィードバックが得られないため、自分の課題に気づけない
- 他者の知識・経験が入ってこないため、視野が広がらない
- 失敗を一人で抱えるため、同じミスを繰り返す
- 自分の考えを言語化する機会がないため、思考が深まらない
人の成長の多くは「自分だけでは気づけないことを、他者との関わりで気づく」プロセスです。
コミュニケーションを避けることは、そのプロセスを遮断すること です。
コミュニケーション不足が生む具体的な損失
損失の類型
| 種類 | 内容 |
|---|---|
| 失注 | 提案・見積もり段階での信頼低下により、受注できない |
| 解約・取引停止 | 既存顧客が離脱し、継続売上がゼロになる |
| クレーム対応コスト | 謝罪・再対応・追加工数が発生し、利益を圧迫する |
| 紹介機会の損失 | 不満を持った顧客は紹介をしないどころか、悪評を広める |
具体的な金額イメージ
- 失注1件:提案規模にもよるが、数十万〜数百万円規模の売上機会を失う
- 既存顧客の解約:新規顧客の獲得コストは、既存顧客の維持コストの 5〜10倍以上 かかると言われている。つまり解約1件は、新規獲得数件分のコストを無駄にすることと同義
- クレーム対応:担当者が1週間対応に追われた場合、人件費だけで数万〜十数万円。さらに役員対応・訪問謝罪が加わると、それ以上になる
- 口コミ・評判による損失:不満を持った顧客1人は、平均9〜15人にその経験を話すとされている。SNS等での拡散が加わると影響範囲は数百〜数千人規模になりうる
新規顧客の獲得コスト
新規顧客の獲得は、時間・人・費用のすべてを大量に消費するプロセス です。
初回接触・ヒアリング
↓(1〜2ヶ月)
課題整理・提案書作成
↓(2〜4週間)
提案・プレゼン(複数回になることも)
↓(1〜2ヶ月)
予算承認・社内調整(顧客側)
↓(1〜3ヶ月)
契約・受注
初回接触から受注まで、早くて3ヶ月・長ければ1年以上かかることも珍しくない。
| 活動 | 発生するコスト |
|---|---|
| 営業・SEの商談工数 | 月数回×複数名×数ヶ月 = 数十〜百万円規模の人件費 |
| 提案書・見積書の作成 | SE1人が数日〜1週間拘束されることも |
| 競合との比較・再提案 | 1案件で提案書を複数回作り直すケースも多い |
| 受注できなかった場合 | 上記すべてがゼロ回収になる |
これだけのコストをかけても 受注できる確率は決して高くない。
IT・SIer領域における新規商談の受注率は、一般的に 20〜40%程度 とされています。つまり、5件アプローチして受注できるのは1〜2件 という前提で動く必要があります。
これだけのコストと時間をかけて獲得した顧客を、コミュニケーション不足で失うことの損失は計り知れません。
「ちゃんと確認すればよかった」「早めに報告すればよかった」という後悔は、
会社にとっては取り返しのつかない損失として残ります。
時間という視点
レスポンス・対応速度
返信や報告が遅いことは、相手の時間を奪っている ということです。
- 相手は返信を待っている間、次のアクションに進めない
- 1人の遅延が、チーム全体の遅延に連鎖する
- 顧客への返信が遅いことは、「軽く見られている」という印象を与える
返信・報告は速さそのものが価値です。
完璧な答えが出るまで待つより、「確認中です、○日までに回答します」の一言が、信頼を守ります。
キャリアの時間軸
あなたに与えられている時間は有限です。
新人・若手のうちは「まだ時間がある」と感じがちですが、成長できる環境・タイミングには期限があります。
- フィードバックをもらいやすい立場にいられる期間は限られている
- 失敗が許容される経験年数も限られている
- 周囲が「教えたい」と思ってくれるフェーズも永続しない
コミュニケーションを避け続けた1年と、積極的に関わり続けた1年では、3〜5年後のスキル・信頼の差は歴然です。
今日動かなかった時間は、二度と戻りません。
どうすれば良いか
基本姿勢
- 分からなければすぐ聞く。一人で詰まる時間の上限は30分を目安にする
- 確認してから進める。「たぶんこうだろう」で動かない
- 問題はすぐ報告する。悪い情報ほど早く共有することが、被害を最小化する
- 返信は速く。内容が固まっていなくても「確認します」の一言を送る
社内での具体的な行動
| シーン | やること |
|---|---|
| 作業開始時 | タスクの目的・完了条件を確認してから着手する |
| 詰まったとき | 30分以上悩んだらすぐ相談する |
| 進捗報告 | 「完了したら報告」ではなく、途中経過を定期的に共有する |
| ミスが発生したとき | 隠さず、すぐに報告する。対処法も一緒に伝える |
| MTG・レビュー | 「特にありません」で終わらせない。疑問・気づきを一つ以上出す |
社外での具体的な行動
| シーン | やること |
|---|---|
| 問い合わせへの返信 | 当日中に返信する。回答が遅れる場合は期日を伝える |
| 進捗共有 | 依頼されなくても、定期的に状況を報告する |
| 問題発生時 | 顧客に隠さない。早期に状況と対応策を伝える |
| 要件の確認 | 「たぶんこういう意味だろう」で進めず、必ず確認する |
| 納期・スケジュール | 守れないと分かった時点で、すぐに連絡・相談する |
裏を返せば ― コミュニケーションは最大のチャンス
ここまで「失敗するとどうなるか」という角度で話してきました。読んでいて重かったかもしれません。
しかし、裏を返せばこういうことです。
コミュニケーションを大切にする人は、それだけで周囲から信頼されやすい。
同僚の中で、返信が早い人・相談しやすい人・状況をちゃんと共有してくれる人を思い浮かべてみてください。きっと「一緒に仕事がしたい人」として、自然に名前が挙がるはずです。
コミュニケーションは才能ではありません。苦手でもいいから、少しずつ挑戦している姿勢 は必ず誰かが見ています。そしてそれは、あなた自身も気づかないうちに、次の仕事・次の機会・次の人間関係につながっていきます。
「苦手だからやらない」ではなく、「苦手だけど一言だけ送ってみる」。
その一歩が、1年後・3年後の自分を大きく変えます。
第7章 成長とは何か
「成長」の正体
「成長したい」という言葉はよく聞きます。
では、成長とは具体的に何が変わることでしょうか。
成長とは、自分の世界の中に「他人」が増えることである。
「自分の世界」とは
人は誰でも、自分だけの「世界の地図」を持っています。
その地図には、自分が経験したこと・知っていること・理解できることだけが描かれています。
成長する前の地図は、自分のことだけで埋まっています。
【成長前の世界】 【成長後の世界】
┌──────────┐ ┌──────────────────┐
│ │ │ Bさんの視点 │
│ 自分 │ │ ┌────┐ │
│ │ │ │ 自分│ Aさんの │
└──────────┘ │ └────┘ 感じ方 │
│ Cさんの │
│ 考え方 │
└──────────────────┘
他人が増えるとはどういうことか
これは「友人が増える」という意味ではありません。
「他者の視点・感情・思考回路が、自分の内側に蓄積されていく」ということです。
- Aさんがなぜあの発言をしたのかが、自然に想像できる
- このシステムを使うユーザーの戸惑いが、体感として分かる
- クライアントが本当に恐れていることが、言葉の裏から読める
これが「自分の世界に他人が増えた」状態です。
この状態に至るためには、人と深く関わり、観察し、対話する経験 が必要です。
だからこそ、コミュニケーションは成長の根幹なのです。
ダニングクルーガー効果 ― 知ることの罠と恵み
ダニングクルーガー効果とは
1999年、心理学者のデイヴィッド・ダニングとジャスティン・クルーガーが発表した研究に基づく概念です。
能力の低い人ほど自分の能力を過大評価し、能力の高い人ほど自分の能力を過小評価する傾向がある。
各フェーズの解説(後年広まった図解として)
| フェーズ | 状態 | 陥りやすいこと |
|---|---|---|
| 愚者の峰 | 少し知って「分かった気」になる | 「自分はできる」と過信し、人の話を聞かなくなる |
| 絶望の谷 | もっと知ると「分からないことの多さ」に気づく | 自信を失い、諦めてしまう人も出る |
| 啓蒙の坂 | 謙虚に学び続ける | 他者から学ぶ姿勢が身についてくる |
| 安定の台地 | 本物の理解と自信が共存する | 次の世代を育てることができる |
エンジニアとしての実例
「愚者の峰」にいるエンジニアの特徴:
- フレームワークを一つ覚えて「もう大体分かった」と言う
- レビューで指摘されると「自分のやり方の方が正しい」と思う
- 設計の話になると黙る(表面の実装しか見えていないため)
「絶望の谷」を越えるために必要なこと:
- 「分からない」を恥と思わないこと
- 谷は成長の証であり、通過儀礼であること
- 谷の存在を先に知っておくこと(それがこの文章の目的のひとつです)
鉄は鉄によって研がれ、人は人によって研がれる
「鉄は鉄によってとがれ、人はその友によってとがれる。」(箴言27:17)
鉄製の刃物は、柔らかいものでは研げません。
同じ硬さを持つ鉄でなければ、刃を磨くことはできません。
人間も同じです。
真剣に向き合ってくれる他者がいて初めて、自分は磨かれます。
「摩擦」の大切さ
快適な環境だけにいると、人は成長しません。
- 自分と異なる意見に触れる
- 間違いを指摘される
- 自分より優れた人の仕事を間近で見る
これらの「摩擦」こそが、成長の砥石です。
職場での実践
| 状況 | 成長の機会 |
|---|---|
| コードレビューで厳しい指摘を受ける | 自分の盲点を知る |
| 経験豊富な人とペアプログラミングをする | 思考プロセスの違いに気づく |
| 顧客からクレームが来る | 視点の違いと改善点を学ぶ |
| チーム内で意見が対立する | 自分の論理の欠陥を発見する |
大切なのは、これらを「嫌な出来事」として避けるのではなく、「研がれる機会」として受け取る姿勢 です。
成長のロードマップ
新人(1〜2年目)
└─ タスクを正確に、期限内にこなす
└─ 「なぜこの機能が必要か」を考え始める
中堅(3〜5年目)
└─ 案件全体の構造を理解する
└─ 顧客の業務課題と技術の橋渡しができる
└─ 後輩のタスクの文脈を説明できる
シニア以降
└─ 顧客と対等に課題を議論できる
└─ 提案・見積もりに参加できる
└─ 自分の専門性で受注に貢献できる
第8章 学びの技術 ― 勉強・真似・失敗・好奇心
「勉強」の定義を問い直す
学校教育の影響もあり、多くの人が「勉強=机に向かって教科書を読む・問題を解く」というイメージを持っています。
しかしこれは、勉強の一形態に過ぎません。
勉強とは、「自分の世界を広げるあらゆる営み」である。
なぜ「机に向かうこと=勉強」になってしまったのか
学校では、評価のために特定の形式の学習が求められました。
しかし社会に出た後の成長は、多くが「経験からの学び」 です。
経験から学ぶためには:
- 経験に意味を見出そうとする姿勢
- 経験を振り返る習慣(内省)
- 経験を言語化して他者と共有する力
この3つが揃って初めて、経験が「勉強」になります。
勉強の範囲
一般的に「勉強」と思われているもの
├── 資格取得のための学習
├── 技術書を読む
└── 研修・セミナーに参加する
実は「勉強」であるもの
├── 先輩の仕事の進め方を観察する
├── クライアントとの会話から業界知識を得る
├── 失敗の原因を自分で考察する
├── 他チームの設計レビューを聞く
├── 違う職種の人と話して視点を借りる
└── 日常の「なぜ?」を追いかける
学習の最も基本的な形 ― 真似をする
勉強の方法論はたくさんありますが、その中で 最も基本的かつ本質的なもの が「真似をする」ことです。
人間の学習は、模倣から始まる。
これは子供の頃を思い出せば自明です。言語も、歩き方も、箸の持ち方も、誰かの真似から入りました。教科書を読んで言葉を覚えた人はいません。
仕事においても、同じことが言えます。
真似をする → できるようになる → 理解が深まる → 自分なりに改良できる
(模倣) (習得) (理解) (昇華)
多くの人はこの順番を逆に考えてしまいます。「理解してから真似る」のではなく、「真似ながら理解していく」 のが学習の本来の姿です。
真似ることは、恥ずかしいことではない
「真似する=オリジナリティがない」「パクリだ」と感じる人がいます。
しかしこれは誤解です。
世界一流のアーティストも、スポーツ選手も、エンジニアも、最初は誰かの真似から始めています。
「守破離」 という言葉があります。
| 段階 | 内容 |
|---|---|
| 守 | 師の型を忠実に守り、真似る。基本を徹底的に模倣する |
| 破 | 型を理解した上で、自分なりに改良・応用する |
| 離 | 型を超え、自分独自のスタイルを確立する |
「離」に至るためには、まず「守」が必要です。型を知らない人が「離」を目指すのは、土台のない建物を建てようとするのと同じです。
仕事における「真似る」の実践
- コードを書くとき:優れたコードをそのまま写して動かしてみる
- 文章を書くとき:上手な人の構成・文体を意識してなぞってみる
- 会議の進め方:ファシリテーションが上手な人の動きをそのまま試してみる
- 提案資料:説得力のある資料の構成をそのままテンプレートにする
「自分で考える」前に、まず「良いものを真似る」 。
これだけで、学習のスピードは大きく変わります。
質より量を優先する ― まず動いてみる
勉強を始める際に「完璧に理解してから進もう」と考える人がいます。
しかしこれは、学習を遅らせる最大の罠のひとつです。
最初は質より量。手っ取り早く試す回数を増やすことが、最速の成長につながる。
理由は単純です。完璧な理解は大量の失敗経験の後にしか生まれません。「分からないまま触れる」ことで初めて「何が分からないか」が分かり、量をこなすことでパターンが見えてきます。
エンジニアとして言えば、ドキュメントを完全に読んでから実装しようとするより、まず動かしてみて、壊してみて、直す という繰り返しの方がはるかに早く身につきます。
完成度60%のアウトプットを10回出した人は、完成度100%を目指して1回も出せなかった人より、圧倒的に多くのことを学んでいます。
失敗を恐れない ― 失敗こそが勉強の本体
なぜ失敗を恐れるのか
多くの人が失敗を避けようとします。その根には、幼少期の経験 があることが少なくありません。
学校では、間違えると笑われたり、恥ずかしい思いをすることがあります。授業中に手を挙げて間違えた瞬間、クラスに笑いが起きた。そういった経験が積み重なると、脳は「間違えること=危険」と学習してしまいます。
しかし社会における「失敗」は、学校における「間違い」とは根本的に違います。
失敗は恥ではない
失敗は、「まだ正解を知らなかった」という事実の記録に過ぎない。
失敗した人を笑う文化は、その組織・チームの成長を止めます。笑われる恐怖があると、誰も挑戦しなくなるからです。
本当に恥ずかしいのは、失敗することではありません。失敗しないほうが恥である 、という考え方を持ってください。
なぜか。失敗しない人は挑戦していない人であり、挑戦していない人は成長していない人であり、成長していない人はチームに貢献できない人だからです。
| 状態 | 本当の意味 |
|---|---|
| 失敗した | 新しいことに挑戦した証拠 |
| 間違えた | 自分の限界を一歩超えようとした証拠 |
| 失敗しなかった | 安全圏の中だけで動いていた可能性がある |
| 一度も間違えなかった | 知っていることしかやっていない可能性がある |
失敗の正しい扱い方
失敗を恥と思わないことと、失敗から学ばないことは別です。
- 失敗を記録する:何が、なぜ、うまくいかなかったのかを書き出す
- 失敗を共有する:チームで共有することで、同じ失敗を繰り返さない
- 失敗を次に活かす:次の挑戦の設計に組み込む
失敗は 次の成功へのインプット です。それを「恥」として封印した瞬間、せっかくの学習機会が消えてしまいます。
失敗の蓄積は、最強の武器になる
「うまくいかないパターンをどれだけ知っているか」が、圧倒的な強みになる。
経験の浅いエンジニアと、熟練エンジニアの最大の差のひとつはここにあります。
熟練者は「正解」を多く知っているのではありません。「これをやるとどう失敗するか」を体で知っている のです。
- このアーキテクチャは運用フェーズでこう壊れる
- このコミュニケーションの取り方をするとプロジェクトがこう崩れる
- この見積もり方をすると必ずここで詰まる
これらはすべて、失敗した人間にしか持てない知識 です。失敗を避け続けた人は、このライブラリを持てません。
失敗の数は、引き出しの数です。引き出しが多い人ほど、いざというときに強い。
「知りたくてたまらない」状態をつくる
学習の最大の障害は「義務感」
「勉強しなければならない」という気持ちで取り組む学習は、長続きしません。
なぜなら、脳は義務感による強制から逃げようとするからです。
理想の状態は、「知りたくてたまらない」 という内発的動機です。
どうやって作るか
① 「なぜ?」を止めない
│
▼
表面の答えではなく、その奥にある理由を追う
│
▼
② 「分からない」に気づく
│
▼
知っているつもりが、実は知らなかったと認識する
(ダニングクルーガーの谷に自ら入る)
│
▼
③ 「これが分かったら何が変わるか」を想像する
│
▼
学んだ先にある「使える場面」を具体的にイメージする
│
▼
④ 小さな発見を積み重ねる
│
▼
「分かった!」という体験が、次の「知りたい」を生む
仕事における実践方法
「なぜ?」ノートをつける :日々の仕事で「なんとなく」やっていることをリストアップし、「なぜそうするのか?」を書き出す。答えを知ったとき、その達成感が学びへの欲求を育てます。
「知らないふりをしない」 :知ったかぶりは、「知りたくてたまらない」状態の天敵です。分からないことを正直に言える環境を、チームで作ることも重要です。
「人を観察する」 :仕事ができる人・コミュニケーションが上手な人を観察すると、「なぜあの人はあんなふうに動けるのか?」という好奇心が生まれます。その好奇心が、自発的な学習につながります。
学ぶ人は、何歳になっても若い
学び続ける人には、ある共通点があります。目に好奇心が宿っていること です。
新しい技術、新しい人、新しい視点に触れるたびに「へぇ!」「なるほど!」「そういうことか!」と思える感覚。この感覚があるうちは、何歳になっても前に進めます。
学びの面白さは、分からなかったことが分かる瞬間の 小さな快感 にあります。
- 昨日まで意味不明だったコードが、今日読んだら理解できた
- ずっと苦手だった会話が、少しだけ上手くいった
- 先輩の振る舞いの意味が、ある日ふっと腑に落ちた
この小さな「分かった!」の積み重ねが、仕事を楽しいものに変えていきます。
勉強は義務ではありません。未知の世界を旅する楽しみ です。
そして旅の面白さは、行き先が分からないほど、強く感じられるものです。
第9章 体調管理も仕事のうち
「体調管理は自己責任」で終わらせない
「体調管理も仕事のうち」という言葉は、精神論として語られることがあります。
しかしこれは精神論ではなく、パフォーマンス・信頼・コストという3つの観点から見た、極めて合理的な話 です。
生産性とパフォーマンス
体調と仕事の質は、直接連動しています。
睡眠不足や体調不良の状態では、思考力・判断力・集中力のすべてが低下します。
研究によれば、17時間起き続けた状態で、血中アルコール濃度0.05%相当の認知機能低下 が起きると示されています(Williamson & Feyer, 2000)。これは日本の酒気帯び運転の基準(血中アルコール濃度0.03%)を 大きく上回る水準 です。つまり「昨日夜遅くまで働いて寝不足」という状態は、酒気帯び運転と同等かそれ以上に判断力を蝕んでいる可能性があります。
エンジニアの仕事は特に、集中力と論理的思考力に依存しています。
- バグの発見に通常の2倍の時間がかかる
- 設計上の欠陥を見落とす
- コミュニケーションでの誤解が増える
体調が万全の状態で4時間集中した成果は、体調不良で8時間粘った成果を上回ることがあります。
量より質、そのための土台が体調です。
信用・信頼への影響
体調管理は、個人の問題にとどまりません。チームへの影響があります。
突然の欠勤・パフォーマンス低下がチームに与えるコスト:
- 担当タスクの引き継ぎコスト
- 予定していたレビューや打ち合わせの遅延
- 納期や品質への影響
- 周囲の「あの人は安定して頼れるか?」という評価の低下
仕事における信頼は、「言ったことをやる」「期待通りのパフォーマンスを出し続ける」 の積み重ねで生まれます。体調不良による不安定さは、この積み重ねを崩す要因になります。
逆に言えば、体調を安定させることは、信頼を積み上げる行為 です。
パフォーマンスとコストで考える
ビジネスの視点から見ると、人件費はコストです。
あなたが1日働くことで発生するコストに対して、どれだけのアウトプットが出せているか。
パフォーマンス(成果)
─────────────────── = コストパフォーマンス
コスト(人件費・時間)
体調不良で生産性が50%に落ちているとき、コストパフォーマンスは半減します。
しかし固定費(給与・席・設備)は変わりません。
これは個人の問題ではなく、チームと会社の損失 です。
体調管理を「仕事」として設計する
体調管理を「なんとなく気をつける」ではなく、意図的に設計する ことが重要です。
| 領域 | 最低限やること |
|---|---|
| 睡眠 | 7時間以上を確保する。質より量より、まず量 |
| 食事 | 抜かない。特に朝食は脳のエネルギー源 |
| 運動 | 週2〜3回、30分程度。集中力と気分に直結する |
| 休息 | 有給・連休を罪悪感なく使う。回復も仕事の一部 |
| 予防 | 体調の「予兆」に早く気づき、無理をしない |
「休むことは怠けではない。パフォーマンスへの投資である。」
体調を崩してから回復に1週間かけるより、崩す前に1日休んで予防する方が、チームへの影響も、コストも圧倒的に小さく済みます。
休み方が印象をつくる
「休むことは大切」ですが、重要な補足があります。
休むこと自体は問題ではない。問題になるのは、休み方だ。
| 印象が良くなる休み方 | 印象が悪くなる休み方 |
|---|---|
| 前日・数日前に申告する | 当日の朝、直前に連絡する |
| 自分の担当タスクの状況を共有してから休む | 何も引き継がず、チームが困る状態で休む |
| 体調不良のサインを早めに伝える | 無理をして限界まで働き、突然倒れる |
| 休んだ後に「ご迷惑をおかけしました」と一言添える | 何もなかったように戻ってくる |
| 計画的に有給を取る | 繁忙期の直前・直中に急に休む |
休みへの 事前の配慮と、チームへの意識 があるかどうかが、印象の分かれ目です。
体調不良で休むことは誰にでもあります。突発的な事情で急に休むこともあります。
それ自体を責める文化は健全ではありません。
しかし、「自分が休むことでチームにどんな影響が出るか」を考えた上での行動 かどうかは、周囲にはっきりと伝わります。
休み方もまた、「一挙一動が評価につながる」行動のひとつです。
「この人はいざというときもチームを意識できる人だ」 という信頼は、こうした場面で積み重なります。
第10章 メタ認知 ― 自分を知ることが最大値を引き出す
メタ認知とは何か
メタ認知 とは、「自分が考えていることを、もう一人の自分が上から観察する」能力です。
「今の自分は焦っているな」「この判断は感情的になっているかもしれない」「自分はこういう場面で判断が鈍くなる傾向がある」――こうした 自己観察の精度 がメタ認知の深さです。
最大のパフォーマンスを出せるかどうかは、メタ認知がどれだけ深いかで決まる。
なぜメタ認知がパフォーマンスに直結するのか
自分のことを正確に把握していない人は、自分の能力を誤った場面に投入します。
- 得意なはずの作業で、なぜか毎回詰まる(弱みへの無自覚)
- 強みを活かせる場面で、自信なく手を引く(強みへの無自覚)
- 疲労・ストレスの状態に気づかず、判断の質が落ちたまま進む
メタ認知が深い人は、自分の「今の状態」と「性質」の両方を把握したうえで動けます。
これが、同じ時間・同じ環境でもアウトプットの質が変わる 最大の理由です。
メタ認知はメンタルの強さにもつながる
メタ認知が浅い人は、ネガティブな出来事に 飲み込まれます 。
「自分はダメだ」「なぜいつもうまくいかない」という感情が来たとき、それを 事実として受け取ってしまう からです。
メタ認知が深い人は、同じ感情が来ても 一歩引いて観察できます 。
メタ認知が浅い場合
ネガティブな出来事
│
▼
「自分はダメだ」という感情
│
▼
その感情=事実として受け取る
│
▼
落ち込み・思考停止・回避行動
メタ認知が深い場合
ネガティブな出来事
│
▼
「自分はダメだ」という感情
│
▼
「今自分はそう感じているんだな」と観察する
│
▼
感情の原因を分析 → 次の行動を選択できる
メンタルの強さとは、感情が来ないことではなく、感情に飲み込まれないこと です。
そしてそのためには、メタ認知の深さが不可欠です。
自分の強み・弱みを言語化する
メタ認知を実践する第一歩は、自分の強みと弱みを具体的な言葉で言えること です。
「自分はコミュニケーションが得意です」では不十分です。
「どんな場面で、何が得意で、なぜそれが強みになるのか」まで言えることが重要です。
| レベル | 例 |
|---|---|
| 浅い | 「コミュニケーションが得意です」 |
| 中程度 | 「人の話を聞いて、要点を整理するのが得意です」 |
| 深い | 「感情的になっている相手の話から本質的な課題を引き出すのが得意です。ただし、意思決定を急かされる場面では判断が雑になる傾向があります」 |
強みだけでなく、弱みも同じ深さで言えること が重要です。弱みを言えない人は、弱みをコントロールできません。
どんな性格にも良い面と悪い面がある
「自分はせっかちだ」「自分は慎重すぎる」「自分は感情的になりやすい」――
これらはしばしば欠点として語られます。
しかし、どんな性格も、文脈によって強みにも弱みにもなります 。
| 性格の傾向 | 弱みとして出る場面 | 強みとして出る場面 |
|---|---|---|
| せっかち | 品質の確認を飛ばす | スピードが求められる場面で即断できる |
| 慎重 | 決断が遅れ、機会を逃す | リスクの高い判断で失敗を防ぐ |
| 感情的になりやすい | 冷静な判断が鈍る | 熱量でチームを動かせる |
| 完璧主義 | 期限を守れない | 品質にこだわりが求められる場面で真価を発揮 |
| 飽きっぽい | 継続的な作業が苦手 | 新しい技術・領域への適応が早い |
大切なのは、自分の性格を「良い・悪い」で判断するのではなく、
「この性格はどんな場面で力を発揮し、どんな場面でリスクになるか」を把握すること です。
業務への活かし方を「パッと言える」ようになる
最終的な目標は、自己分析を抽象的な「自己理解」で終わらせるのではなく、業務の具体的な場面に紐づけること です。
「自分は〇〇という傾向がある。だからこの仕事では意識的に△△するようにしている。また□□な場面では自分の強みが活きるので、そこに積極的に関わっている。」
この一文が すぐに、自分の言葉で言えること 。
それがメタ認知の実践的な到達点です。
チームの中で自分をどう活かすか、どこを補完してもらうかが明確になると、
個人のパフォーマンスもチームの成果も、両方が上がります 。
終章 まとめ
| テーマ | 本質 |
|---|---|
| 仕事の起源 | かつては生き抜くための行為。今は自分で向き合う理由を持つことが必要 |
| 商売 | 価値交換 × 信頼の積み重ね |
| 仕事の定義 | 誰かの役に立ち、社会と関係を結ぶ行為 |
| ビジネスの構造 | 顧客の課題から仕事が生まれ、経済の循環に組み込まれている |
| 人への興味 | 技術より先に必要な、仕事の肝 |
| コミュニケーション | 伝えることではなく、理解を共有すること。仕事のインフラ |
| 成長 | 自分の世界に他人が増えること |
| 学びの技術 | 真似から始め、量をこなし、失敗を武器にする |
| 体調管理 | 生産性・信頼・コストすべてに直結する、仕事の土台 |
| メタ認知 | 自分を深く知ることが、最大値とメンタルの強さを生む |
最後に
あなたが今日実装した機能は、
顧客の業務を支え、
その顧客の顧客(エンドユーザー)の生活に届き、
経済の循環の一部になっています。タスクをこなすことは、社会に参加することです。
働くことは、技術を身につけることだけではありません。
人と関わり、摩擦を受け入れ、自分の世界を広げ続けること。
その積み重ねが、エンジニアとしてだけでなく、一人の人間としての成長 につながります。
この文章が、あなたの「なぜ働くのか」を問い直すきっかけになれば幸いです。
参考:よく出てくる用語集
| 用語 | 意味 |
|---|---|
| 受注 | 顧客から仕事を取ること |
| 工数 | 作業に必要な人×時間(人日、人月で表す) |
| 稼働率 | 案件に使った時間の割合 |
| 請負 | 成果物を納品する義務がある契約 |
| 準委任 | 作業を提供する契約(成果物保証なし) |
| PM | プロジェクトマネージャー。QCD(品質・コスト・納期)を管理する |
| QCD | Quality(品質)・Cost(コスト)・Delivery(納期)の略 |
| SIer | システムインテグレーター。受託でシステムを構築する会社 |
