前置き

新卒～４年目くらいに向けたものです
ちなみにコードは一切出てきません

IT業界全体とWeb系では結構差がありますが、主にWeb・アプリ系を中心にお話します
IT業界でもほとんど通用しますが、一部読み替えが必要な部分があります
ご注意ください

結構なボリュームになりました
途中に中間地点を用意してるので
慌てずゆっくり読んでください

中間地点1
中間地点2

方針

難しいの苦手なんで簡単に書くつもりです
あと、ゲームに喩えて話します

対象

• プログラマー
• テスター
• システムエンジニア
• ディレクター
• デザイナー

メインはエンジニアです

この業界の新人教育

IT業界の中でも、特にWeb・アプリ系は非常に若い業界です
会社も若いので規模も小さく、新卒教育も充実していないパターンが少なくありません
代わりに先輩が教えてくれるかといえば、忙しかったり、先輩も分かってなかったりします

喩えるなら今の業界は
新人を適当にジャングルに投入して「がんばって生き残って！！　応援してる＞＜」みたいな状況です
漫画だと燃える展開ですが、漫画じゃないので消し炭になるだけです

私は情報系の出で、運良く新人研修も３ヶ月受けられましたが
それでも３年くらいはしっくり来ない日々が続きました

このゲーム、取説がない

しっくりこないのはルールが分からないからです
ゲームに喩えると、取扱説明書がない状態です
中古屋でゲーム買ったらたまにありますよね（おっさん脳？）

王道RPGなら、HPとかMP、攻撃力とか防御力なんかがあってラスボスを倒すのがゴールですよね
でもWeb系業界にはそういう分かり易いのがありません
（私ゲームやらないし〜、とかいう人は碁盤と碁石をいきなり渡されて「囲碁やろうぜ」と言われた状況に置き換えてください）

IT業界の場合、何を倒せばいいのか分かりづらいです
どのくらい分かりづらいかというとこのくらいです

分かり易い
↑
普通のゲーム
スポーツ
MMO RPG
将棋、囲碁、麻雀
IT業界の仕事　←　ここ
学校
恋
人生
宇宙
↓
分かりづらい

誰か説明書くれよ！　と思いましたがどこにも売ってなく
少しずつ調べながら自分で作るしかありませんでした

取説がないなら、wikiを見ればいいじゃない

無いです
なので自分で解説したいと思います

皆が同じように迷うのはアホくさいですよね

なんで分かりづらいのか

ちなみに、なんでこんなに分かりづらいのかといえば

• ゲームの単位がそこそこ大きく、個人では全体像を把握しづらい
• 一個のルールを調べるのに数ヶ月掛かる
• プレイヤー、組織によってやってるゲームが微妙に違ってる
• ゲームが入れ子構造になってる（ゲーム内ゲーム）
• 業界が若い（リリース直後のゲームみたいな）
• システムというものが外から見えない（ビルを建てるとかなら分かりやすいですよね）

などです
とは言っても、他の業界よりは分かりやすい方だと思います
他の業界だと40代で若手みたいな所ありますしね

本題

ここから

1.プロジェクトとは何か？

この業界に入ると色んなカタカナ用語が飛び出ますが
「プロジェクトは流石に分かるよね＾＾」という謎の空気があると思います

私はNHKで昔やってたプロジェクトXくらいしか分かりませんでした
音楽方面でも◯◯プロジェクトってありますよね
皆さんは何プロジェクトを知ってますか？
それ、関係ないので忘れてください

プロジェクト＝ボス

ネタバレするとこれが倒すべきボスです
大事ですよこれ
大事ですよ

でも皆あまり意識してない

皆さんの先輩方のほとんどは
「ジャングルに放り込まれて、右も左も分からない中どうにか生き残った猛者たち」です

そんな彼らにこのゲームのボスを聞いてみます

先輩「ああボスね、うざいよね。それよりこの武器を見てくれ。強そうだろう？
　　　こいつでな、あのボスを斬るんだよ。目にも留まらぬスピードでな！　楽しいぞ～」
後輩「あっ、なるほどですねー」

彼らは何かしら強い武器（スキル）を得られたので生き残れたみたいです
でも生き残れない人も居ます
武器強化も楽しいですけど、先にボスとルールくらいは知っておきたいですよね
（サバイバルを楽しみたい直感肌の人にはいらないかもしれませんが）

プロジェクトに対して多くの人が無頓着になるのも仕方なくて
そもそも普通の人は社会にでるまでプロジェクトというものにお目にかかることがあまりありません

全体像が把握できない、何やら怖いものです

奥が深すぎるプロジェクト

こういうときはグーグル先生に聞くのが一番ですよね
とプロジェクトでググると絶望します
全然分かりません
辞めたくなります

それもそのはずで、私が持ってるプロジェクト管理の参考書は800ページを超えます
そしてその一章一章が、実践とか練習するのに数ヶ月掛かるようなものばかりです
一応体系的に説明したものもWikipediaにありますが（これとかこれとか）
魔術書めいた何かです
深く知ろうとすると精神がやられます

少しでも理解する

それでもIT業界のほとんどはそういう業界です
そういうゲームだと割りきって、少しでもプロジェクトについて知っていきましょう

できるだけ簡単に説明します

プロジェクトじゃないもの→定常業務

プロジェクトを説明する際、先に定常業務というのを覚えなければなりません
多くの説明では「プロジェクトは定常業務じゃないんだよ」と、
定常業務観点で説明されるからです

定常業務ってなに？

なにやら難しそうですが、要はよくある普通の仕事です

例えばファミレスの店員は定常業務をします
それは毎日似たような仕事です

3年後には凄い店員になってるかもしれませんが、やることは基本的に同じです

郵便局も水道会社も本屋も保険屋も医者も同じです（厳密には違う人も居ますが）
役職が変わらないかぎりやることは大体同じで
維持することがまず重要です

簡単ですね

プロジェクトには目的と終わりがある

プロジェクトにはゴールがあります
例えば「お料理アプリをリリースする」はプロジェクトです
アプリエンジニアはそのお料理アプリを作るのが仕事ですが
3年後にはそれはもうリリースされていて、「お料理アプリをリリースするプロジェクト」はもうやっていません

というか3年後もリリース出来てないとヤバイですよね？
プロジェクトにはもちろん締め切りもあります（業界では「納期」と言っています。納品する期日です）

プロジェクトは企画と計画（スケジュール）が必要

別の例で「ピラミッドを作る」もプロジェクトです
これは随分長い時間がかかりそうですが、目的と終わりがあります
王様が「やだやだ！死ぬ前に完成したのが見たいんじゃもん！10年で作って！」とか言ったら期日も決まります

何百人も使い何年もかかる場合、適当に作るとヤバいというのは想像できるかと思います
（学校の生徒全員で一個の何かを作るのを想像してください）
きちんとした計画（スケジュール）が必要です
あと、どういう風に仕上げるかの企画設計も必要ですね
何段にするのかとか決めないと、途中であれ違うくね？となります

基本的にプロジェクトというのは複数人で何週間も何ヶ月も時間をかけて行うので
企画設計と計画が必要になります

小さいのはプロジェクトじゃないの？

これはちょっとややこしいです

期限がある、目的もある、時間もそこそこかかる、でも企画設計とか計画は要らないし一人か二人くらいでやる
例えば宿題やレポートなんかはそういうものですよね

境目はあまりハッキリしませんが、小さいのはタスクと呼んでしまいましょう
多くの場合、実際にプロジェクトと呼ぶのは一番大きな塊だけです

プロジェクトはボスだ！

こんがらがってきました

こう考えてもいいです
プロジェクトはタスクの大きいやつです
複数人で企画設計、計画をしないと終わらないヤバいタスクです

宿題をやっつけてしまおう！なんて言い方しますよね
あれのでかいやつがプロジェクトで、プロジェクトをやっつけてしまおう！がこの業界での仕事です

IT業界・Web系の仕事はプロジェクトを倒すゲーム

ここから、本格的にゲームに喩えていきます

ある日アプリを作るプロジェクトが依頼されました
1000万円の懸賞金が出ています

いろいろ頑張って攻撃します
テテテテーテーテーテッテレー♪（このファンファーレ新卒に通じなさそう）

プロジェクトを倒しました
1000万円ゲットしました
めでたしめでたし

これが請負ビジネスをしてる受託開発会社の場合です

自社サービスを運営する自社サービス会社の場合だとこうなります

ある日お金になる鉱脈を見つけました
そこを採掘するにはアプリプロジェクトを倒さなければなりません

いろいろ頑張って攻撃します
テテテテーテーテーテッテレー♪（FFわかりますかね？）

プロジェクトを倒しました
採掘の結果、550万円儲かりました
めでたしめでたし

倒す＝終わらせることです
倒したらめでたいので打ち上げとかします

（プロジェクトはボスじゃなくてクエストといったほうが良いんじゃないかと思った方、慌てないでください）

倒すとゴールドが手に入る、あと依頼者が居る

お金が発生しないプロジェクトも世の中にはありますが
プロジェクトをお仕事だとして考えた場合
上の例のように２つの要素が出てきます

プロジェクトは依頼される場合がある
プロジェクトを倒して、その結果お金をもらう
（鉱脈はちょっとむずかしいので後回し）

ゲームっぽくないですか？

チームで倒す

このゲーム、1人で倒せるボスは少ないです
普通はチームで倒します

攻撃役、回復役、補助役、盾役、魔法役　いろいろ必要です

結構シビアな戦い

色んな役割があって、全員が全力を出してようやく倒せるかどうかというボスです
1人でも欠けると厳しいですし、結構簡単に詰みます

攻撃力

先ほど言ったように、プロジェクトは期間が長いです
長期戦です
数週間～数年掛かります

つまりターン制じゃないので、攻撃力（つまりいくらプロジェクトが消化できるか）は時間あたりで考えなければなりません

攻撃力　→　1ヶ月あたりに与えられるダメージ
攻撃力　→　1日あたりに与えられるダメージ

こんな感じで考えます

1人月

この業界は人月という単位が使われます
これはつまり、1人で1ヶ月に与えられる攻撃力(いくらプロジェクトが消化できるか)です

何で「人」が付くのかといえば、チーム戦だからです
何人でやる場合も、同じ単位で表現したいから人月を使います

100人月＝10人×10ヶ月かもしれないし
100人月＝5人×20ヶ月かもしれません

似たような考えで、人日もあります

プロジェクトのヒットポイント

プロジェクト（ボス）のHPは人月で表現できます

プロジェクトHP：100人月　・・・　10人が10ヶ月間、攻撃し続けて倒せるプロジェクト
プロジェクトHP：30人月　・・・　5人が6ヶ月間、攻撃し続けて倒せるプロジェクト

ちなみに最近極東の某国で観測された神話級のボスは20万人月と噂されています
他にもそのくらいのボスが2015年を中心に観測されました

ただWeb系ではそこまで大きいのは見ません
100人月でもう数年に一度のヤバイボスだ！くらいです

依頼者から貰う報酬額は、プロジェクトのHPに比例する

例えば1人月が100万円だったら、30人月で3000万円です（実際にそのくらいの相場ですね）

プロジェクトHP：30人月　・・・　5人が6ヶ月で攻撃し続けて倒せるプロジェクト

ちなみに家を建てるというのもプロジェクトに近いですが
土地代を除けば2000万くらいだと思うので近いですよね（あちらは材料費とか入るんですが）
イメージ湧きました？

1人月攻撃してその分の報酬をもらう

そういうゲームです
何だ時給制のバイトと同じじゃん！と思った方が居たら、その考えは8割方正しいです

違いは定常業務かプロジェクトかという点くらいです

一つのプロジェクトに対してチームでアタックして
終わったらまた別のプロジェクトが湧いてくる、
ひょっとしたら同時に複数のプロジェクトが湧くかもしれない
とか考えると、定常業務とはちょっと違いますよね？

自社サービス会社の報酬は比例しない

自社サービスの方は依頼者がいません
儲かる鉱脈を掘り当てた結果、儲かる額は1万円かもしれませんし1億円かもしれません

ちょっと受託開発会社とゲームが違うんです

チームがいっぱいあるのが会社（ギルド）

ギルドシステムがあるゲームやったことありますか？（私は無いですが）
つまり人がいっぱいいる大きな場所です

人数が多いと、より大きいプロジェクトを倒せます
1万人月を10人で倒せないですよね、100年くらいかかります
つまり10人ギルドでは1万人月のプロジェクトは倒せません

例え小さくともギルドを構成していないと依頼者は困ります
だってチーム戦なんですから、チームが欠けているところに頼みたくないですよね

依頼を受けるのはあくまでギルド（会社）です
そこから1人1人のプレイヤーがプロジェクトにアタックして1人月の報酬をもらいますが
ギルド（会社）の運営費などがいろいろあるので全部はもらえません
大体1/1.7～1/3程度になります（会社の状況によります）
新人ならもっと少ないことでしょう
（ぼったくりでは無いですよ、社員の厚生年金とか税金とか持ってかれますし、稼働率100%は無理ですから）

ここまでが基本中の基本

色々喩え話をしまくりましたが何となく分かりました？
ゲームの取説を読む時って、完全に把握せずに、プレイしつつ覚えますよね
何となくでいいです

なるほど、神話級のボスを倒せばいいんだな？　→　間違い

このゲームの目的はお金を稼ぐことです

1人月を1人で倒したら1人月分もらえますよね
2人月を1人で倒したら2人月分もらえますが、2ヶ月掛かります
100人月を1人で倒したら100人月分もらえますが、100月掛かります

そう考えると、もしプロジェクトがいくらでもあるなら、その大きさって関係ないですよね？
別に神話級のプロジェクトを倒してもメリットはあまりありません

しかも、プロジェクトが大きくなればなるほどチームも大きくなっていきます
1万人月を10人でやるには100年くらいかかりますよね、皆たぶん死んでます
だから100人とか1000人でやらないといけません

それなのに、さっき言ったとおりに役割が一人でも欠けるだけで厳しいのがこのゲームです
なのでプロジェクトが大きくり、チームが大きくなるほど倒すのは難しくなってきます（基本的に）

じゃあでかい会社は何なの？

大は小を兼ねるみたいなやつです
あと会社の営業力が強くなってきます（より依頼をゲットできる）

それに依頼者が「1万人月100億円のプロジェクトがあるんたけど」
なんて言って、誰もできないから放っておくなんてことも考えにくいでしょう

プロジェクトをもっと知る

とりあえず仕事＝プロジェクトをやっつけたら、それにみあった報酬額がもらえる
というところまでは良いかと思います

プロジェクトには目的と、納期と、企画と、計画があるらしいというのもわかりました

ですがまだ倒せません
もうちょっと必要です

流れを確認

受託開発会社で考えましょう

依頼が発生します
↓
プロジェクトの強さ（HP）を予想する（FFならライブラ）
↓
自分のギルドとチームのメンツを見て、倒す計画を立てます
無理そうなら断ります
↓
人月に応じて額を決め、スケジュールを提示します（先に提示します。額が大きいですからね）
↓
依頼者がGOをだしたらプロジェクト開始
↓
攻撃！攻撃！攻撃！（数ヶ月）
↓
倒した
↓
結果報酬額がもらえます
やった
↓
また別の依頼を受けプロジェクトを狩りに行きます

一番大切なこと

こう見ると、そんなに違和感は覚えないと思います
しかし実際の業務では、「攻撃！攻撃！攻撃！」の中にずーーーーっといることになります
そうなると、いつの間にか攻撃することが目的になってきます

もっとカッコいい攻撃方法はないか、もっと正しいフォームはないか
別の攻撃方法を試してみようとか、隣の人が困っていても自分の攻撃優先
新しい武器はないかとか、何か攻撃が通じてないけど何でだろうとか

特に新人の頃は何が正しいのかが本当に分からなくなりますが
倒しきること（期限内に納品すること）が一番大事なことです

他にも色々ありますが、一番はそれです
どれだけ不格好だろうが、四の五の言わず攻撃して、まず倒せなくては話になりません

倒せなかったらどうなるか

新人にはあまり教えてくれませんが、倒せないこともあります

• 期間が伸びる（リスケ）　依頼者は困るし怒る
• チームメンバーを増やす　　一人あたりの取り分が減る
• 裁判沙汰になる　　金払わないぞ！と言われる

倒さなきゃダメなのがわかると思います

しかも「倒せなかった」は珍しいケースではありません
そんな時でも、報酬は会社（ギルド）が出してくれます
プロジェクトは一匹ではありません
皆に死なれると会社（ギルド）も困るんです
※会社が潰れない限り

スピードだけ求めるとたまに怒られる

おさらいですが、プロジェクトには目的があります
もちろん目的を満たせるなら大抵の依頼者は怒りません

例えばさっきの「お料理アプリプロジェクト」の目的が
「良いアプリをリリースして、ユーザー数100万人ゲットして、年間10億円売り上げる」
だとします

受託開発会社が保証するのは「良いアプリをリリースして」の部分だけです
（自社サービスの開発会社ならもっと範囲が広がります）

良いアプリをリリースするのが目的

つまりドヘタクソに作ってゴミアプリを作ったり、そもそも動かないという状態だとNGなのです
それは倒せていません

良い＝品質

こういうのを品質といいます
あまり聞き慣れない言葉ですが、「品質＝良さ」で理解していいです

「良さ」なんて言ってもフワッとしていて何が何だかという感じですが
この業界では「思った通りに動く」「バグってない」がまず良さの尺度です

スピードと品質はトレードオフ

ゲーム慣れしてる人はすぐに気づくかもしれませんが
納期に間に合わせようとスピードを上げすぎると品質が落ちます
逆に品質を上げ過ぎるとスピードが落ちて納品できません

なかなかのゲームバランスですね

ここまでまとめ

プロジェクトには目的と、納期と、企画と、計画があって
目的を満たすために、「思った通りに動く」ことを前提として
ちゃんと納期までにやっつけるのが目標

ここまで分かれば80点です
私はこれに気づくまですごく時間がかかりました
チームの皆が「良さ」の尺度をいろいろ持っているからです

2.エンジニアの武器と攻撃

攻撃！攻撃！攻撃！　は、プログラマーならコーディングです
攻撃が楽しくてプログラマーになる人も多いと思います
プログラマーがとにかく動かないとプロジェクトは終わらない重要な役割です

もちろんスキルを磨けば強い攻撃力が出ます
とは言っても、例えば2年目と10年目で比較した時、攻撃力の差は５倍もつきません
意外とインフレしないゲームなんです

プログラミングスキルには100倍の差がある！とか聞いたことありませんか？
それは「機械音痴のカーチャンとプロゲーマーの差が100倍ある」みたいなもので
プロの現場では100倍も差がつきません
超多めに見積もって10倍、同期ならばせいぜい3倍くらいです
（じゃないと人月なんて単位使わないですよね）

機械音痴のカーチャンみたいな人は居なくなりますから（哀）

プロジェクトに有効なスキル

プロジェクトの一番最初の頃、チームのリーダーか、何か偉い人が攻撃手段（言語・フレームワークなど）を指定します
もしそれを持ってないと参加できません
なので、どういうスキルが今必要で、今後どういったスキルが必要かは調査しておきましょう
インターネットや先輩、上司など色んな人に聞いておきましょう
ふつうは言わなくても教えてくれると思います

どうやってスキル習得するのが効率的なの？

これは色んな考えがあります
本を読んだりインターネットを見たり、人に聞いたり勉強会に参加したり

でも、その勉強が役に立ってるのかどうかはすごく難しいと思います
何せ覚えることが膨大です

でもちょっと待って下さい
ボスはプロジェクトなんですよ
そしてプロジェクトに必要なスキルは決まってるんですよ
じゃあプロジェクトに一番有効打撃を与えるスキルを習得するのが近道じゃないでしょうか

幸運なことに、プロジェクトというのは期間が長いです
やりながら勉強しても頑張れば途中でレベルアップしますし
それに、プロジェクトを倒すのはチーム戦です
「プロジェクトをやっつけたいんです」
その気持ちがあれば、同じプロジェクトのメンバーが協力してくれるかもしれません
協力までは無くとも「真面目なやつだ、ありがたい」と思うはずです

もしプロジェクトと関係ないことについてスキル習得しつづけていたら
周りはおそらく「ああ、そういうの好きなんだな」「まあ、頑張って」「仕事しろよ」と思うはずです
悪くはないですし、同好の友は寄ってきますが、今必要な攻撃力は上がらないので注意しましょう
それはそれ、これはこれです

3.チームの紹介

プロジェクトはチーム戦です
じゃあどういうジョブがあるんでしょうか

• プログラマー
• デザイナー
• ディレクター
• テスター

最小チームだとこんな感じです
何も不思議じゃないですね
規模が大きくなるといろんな役割の人が増えてきます

ここで「ディレクターって何？？要らなくね？」と思われる方も居るかもしれませんが
ちょっとおさらいです

プロジェクトには目的と、納期と、企画と、計画があって

目的、納期、企画、計画、これらを管理して、かつ実行に移す人が居ないと大変です
何度も言いますがプロジェクトは複数人で長期で行います
居ないと非常に困りますし、プログラマーやデザイナーがそこをやらないといけなくなります
攻撃しながら周りと調整もするとなると大変ですよね
できればボス（プロジェクト）向かって攻撃ボタンを連打していたいです

何か似たような分かりにくい役割

• ディレクター
• システムエンジニア
• プロジェクトマネージャー
• 営業

ここらへんって何が違うの？　というのは3年くらい仕事をしてももやもやすると思います
何故かといえば会社によって役割が違うからです

でも、共通してやってるのは

プロジェクトには目的と、納期と、企画と、計画があって

これです （実行・管理含む）

これを分担したり、対象の大きさによって役割の名前を分けていることがあります
その人の役割の名前より、プロジェクトのどこに責任を持っているかを考えると分かりやすいです
逆に名前だけ見てしまうと、プロジェクトの重要な部分が抜けしまうこともあります
誰がどれを担当してるかで考えたほうが良いです

エンジニアとプログラマ

エンジニアとプログラマがどう違うのかと言えば
エンジニアの一つがプログラマと思ってください

プロジェクトが大きい場合は
コーディングをするプログラマーと、設計をするシステムエンジニア、のように名前を分けていたりしますが

Web系ではそもそも案件が小さく色々なことをしなければなりません
コードを書くだけが仕事ではなくなってきています
だから面倒くさいので技術者を全部まとめてエンジニアと呼んでいるのだと思います
プログラマーと言うとややこしいのでいっそ「エンジニア」で統一しちゃいましょう

エンジニアをもっと細かく

いっぱいあるのでちょっと面倒ですが
乱暴に言ってしまうと

• サーバーサイドエンジニア
• フロントエンドエンジニア
• アプリエンジニア

という風にもわけられますし、使ってる武器ごとに

• iOSエンジニア
• Androidエンジニア
• Javaエンジニア
• Railsエンジニア

みたいに言ったりもします

どういう観点で分かれてるのかといえば、プロジェクト（ボス）に攻撃が通じるかどうかという点だけです
RPGでいう炎属性とか水属性とか、そういうのです

色んな人と仕事をしてると、色んな観点で○○エンジニアという概念が作られています
社内や社外で是非探してみてください

4.会社（ギルド）の紹介

上で説明しましたが、チームがいっぱいあるのが会社（ギルド）です
でもそれだけじゃないですよね

プロジェクトを倒すゲームの、外側のゲーム

プロジェクトを倒す以外にも必要なことがいくつかあります

• プロジェクトを発見して持ってくる（営業）
• チーム間の調整をする（PM）
• チームを集める（PM）
• プロジェクトのHPを分析する
• どういうプロジェクトを取ってくるか方針を決める（経営）
• ギルドメンバーを増やす、調整する（採用）
• 攻撃方針を決める（PMO）
• チーム全体を支援する（間接部門、技術基盤）

こういうのが全部合わさって一つのギルドになっています
ゲームの外側に、もう一個複雑なゲームがある状態ですね
プロジェクトゲームを形作る人たちと思ってもいいです

会社はいっぱいある

当たり前ですが、会社はいっぱいあります
だから競争もあります

依頼者が提示した目的に対して、A社が10人月と言って、B社が5人月と言えば、A社は取れないかもしれません
そうすると自然に相場が生まれるようになります

プロジェクトの発生には波がある

※受託開発会社の場合

例えば100人戦えるメンバーが居る会社があったとして
お仕事は50人月、200人月、10人月、30人月・・・とバラバラに攻めてきます

そうすると、無茶をしないと間に合わない時と、ボスが居ない暇な時が発生します

先ほど言ったとおり、会社はメンバーに死んでもらっても逃げてもらっても困るので給料は出します
だけど常に全員がすりきりいっぱい戦えてるという状態にするのは難しいので、若干安めに給料が支払われます
じゃないと会社が潰れてしまいますから
（稼働率なんて言ったりします。工場の機械みたいな表現ですが怒らないでください）

中間地点1

休憩　説明書はここまで

説明書としてはこんな感じだと思います
新人の頃は何かと迷うことが多く、何をするにもおっかなびっくりになりますが
取説さえあれば今自分がどういう状況なのか、何となくわかると思います
ピンと来ない場合は、1プロジェクトこなす度に見てみてほしいです

一応言うとゲームに喩えるのは周りに言わないでくださいね？
サバイバルを必死に生き残ってきたガチ勢が「仕事をなんだと思っちょるんだぁ！！」と怒るかもしれません

ここからは攻略法です
より詳しい話をします
攻略法なのでプレイしながら気になった時に見る感じで良いと思います

4.プロジェクトの攻略法

先輩なんかがつらそうにしてるのはプロジェクト（ボス）が強いからです
本当に全力を出さないと負けてしまいます

そこでもう少しプロジェクトを掘り下げてみましょう

勝利条件はどこまで？

プロジェクトには目的と、納期と、企画と、計画があって
目的を満たすために、「思った通りに動く」ことを前提として
ちゃんと納期までにやっつけるのが目標

プロジェクトの要素は他にもあります
というかさっき一回言いました

例えばさっきの「お料理アプリプロジェクト」の目的が
「良いアプリをリリースして、ユーザー数100万人ゲットして、年間10億円売り上げる」
だとします
受託開発会社が保証するのは「良いアプリをリリースして」の部分だけです
（自社サービスの開発会社ならもっと範囲が広がります）

「保証する」というのは「ここまでやったら倒したってことね！」ということです
もし良いアプリをリリース出来て、ユーザーが5人しか来なくても開発プロジェクトとしては成功になります
もちろん依頼者は予定通り100万人来て年間10億円売り上げると嬉しいですが
失敗しても開発担当したプロジェクトは責められません

こう聞くと、何だかすごく言い訳っぽくて嫌に聞こえると思いますが
それでも全力でようやく倒せるくらいなので四の五の言ってられません
増して新人なら尚更です

もちろん、依頼者の最終目的に沿うように力を発揮すると、依頼者は喜びます
そしてまた別のプロジェクトを依頼してくれるかもしれません

スコープ

上で言った「保証する範囲」がスコープです

プログラミングを勉強しているならスコープも知ってると思いますが
プロジェクトにもスコープがあります
こっからここまでやったら倒したってことだからね！あとは保証しないよ！　ということです

プロジェクトのスコープはできれば把握しておいてください
多分誰も教えてくれませんが
プロジェクトマネージャーという肩書の人に「どのくらいの物をどこまで作ったらOKか」聞くと教えてくれるかもしれません

スコープを決めるのは要件定義

プロジェクトの最初の方で依頼者と「何を作るか」「何を作ったら終わりか」を決めます
それを要件定義とか、要求分析なんて言います（言葉の違いは気にしなくていいです）
定義！なんて堅苦しく行ってるのはスコープをしっかり定めないと揉めるからです

日常でも無いですか？
「それあんたの仕事でしょ！」「はあ？何で俺がそれやるんだよ！」みたいな
あれが会社間で起こったら吐きそうになりますよね

自社サービス会社のスコープはちょっと違う

自社サービスを運営している会社はこっちです

ある日お金になる鉱脈を見つけました
そこを採掘するにはアプリプロジェクトを倒さなければなりません
テテテテーテーテーテッテレー♪
プロジェクトを倒しました
採掘の結果、550万円儲かりました
めでたしめでたし

なので

「良いアプリをリリースして、ユーザー数100万人ゲットして、年間10億円売り上げる」

この「ユーザー数100万人ゲット」や「年間10億円売り上げる」も目的の中に入ってきます
つまり難易度は受託開発会社の場合よりももっと高いです

ですがもちろん、最初から全部１個のプロジェクトに入れてしまうと超難しいボスになってしまうので
どこかしらでスコープを絞ることがあると思います

既に運営中のサービスならば、「1機能を追加してユーザーの満足度を高める」みたいなのもプロジェクトになります
これならできそうですね

もう一度言いますがプロジェクトのスコープはできれば先輩や上司に確認してください
知ってると知らないとでは大違いです
（真面目なマネージャーは一番最初に全員に説明します。が少数派です。PMもサバイバルの生き残りなので人によります）

スコープを把握していないとどうなるか

「終わったぞ！」「はあ？まだ終わってないでしょ！」

みたいな感じです

プロジェクトを倒したと思った瞬間に第二変形をします
第三変形もあるかもしれません

誰もスコープを答えられない時はそうなることがあります

受託開発会社の新人として正しいのは？

受託開発会社の新人として正しいのはどっちでしょうか

A君：来週が納期だから、何としてもこの実装を終わらせる
B君：来週が納期だけど、このアプリ全然イケてない。ユーザーも来ないよ、最初から見なおすべき

実際にこういうシーンはあります
心のなかで葛藤が生まれます
じゃあどっちが正しいのかといえばA君です
B君はスコープ外のことを優先しています

スコープ外を気にするためにはスコープ内をまず達成しないといけません
悔しかったらレベルを上げる必要があります

（自社サービス開発会社のスコープならB君も正しいかもしれません
　しかし新人なら大抵A君です。これは「タスクのスコープ」に依ります）

プロジェクトを倒すのには手順がある

趣味でプログラミングをしていたりすると意外かもしれませんが
IT業界のプロジェクトは適当に攻撃すれば終わるというものではありません

ここで登場するのがVモデルです

Wikipediaより（https://ja.wikipedia.org/wiki/V%E3%83%A2%E3%83%87%E3%83%AB）

なにこれ怖い、わかんない、死にたい
私は最初こう思いました

何かVの字になってますが、最初は深く考えないでいいです
プロジェクトの基本を思い出してください

プロジェクトには目的と、納期と、企画と、計画があって
目的を満たすために、「思った通りに動く」ことを前提として
ちゃんと納期までにやっつけるのが目標

この、目的と納期と企画と計画をまず立てるのが０番目です
次にそれに基づいて何を作るのかが１番目です（要求分析・要件定義）
次にそれに基づいて設計図を書くのが２番目です（基本設計～詳細設計）

ここまで、新人エンジニアはやりません
大抵は先輩エンジニアとディレクターがやります（やった！全部忘れよう！）

そのあとデザインとコーディングがあって
それが終わったらしっかりテストします（しっかりやります！）
テストが終わったらデバッグして、またテストします
バクがなくなったら終わりです

何か変な用語になってて難しそうですが、よく見てみると意外と大した話ではないです

チーム戦だけど、リレーみたいな感じ

上で言いたいのは、チーム戦だけど一気に皆がプロジェクトをやっつけるのではなく
リレーのように順々に攻撃するということです

これを間違うと、攻撃しても０ダメージだったりします（つまり無意味）

だからこそ、一人でも欠けると大変です
いつまで経ってもバトンが来ません

みんな大嫌いプロジェクト

プロジェクトというボスは多くのエンジニアが嫌いです
こんちくしょうめ！と思ってます
何故でしょうか

プロジェクトは山あり谷あり

15人月のプロジェクトが現れた！　とします
5人60日で終わらせましょう　とします（1ヶ月は20日ですよ？）

上の図は、横軸を日数にして、縦軸を残りHP（残りタスク量、単位は人月）とします
右下でゼロに落ちてますが、つまり「やっつけた」ということです

理想的にはプロジェクト（ボス）のHPは、赤線のようにまっすぐ削っていきたいですよね
でも現実には緑の線みたいになことが多いです（本当はもっとグチャグチャです）

※ちなみにこの図は私が今考えたのではなく、バーンダウンチャートという図です
　あまり使われていませんが、画像検索でググると実際のものが出てきます

この緑の線では何が起こっているでしょうか

まず最初の14日、進んでいません
せっかく予定（赤い線）を立てたのに、何故か攻撃が通っていません
プロジェクトはリレー方式なので、エンジニアはずっと待ってることになります（おそらく他のプロジェクトをしている）

14日が過ぎようやくエンジニアが着手しました
すごい勢いで削っていきます
が、26日目あたりで何かプロジェクトが回復しました（タスクが増えた）

これにはエンジニアブチ切れです
そう、プロジェクトは回復技を使うんです
厄介ですね

最後の方を見ると、何か急激に収束しています
きっと人を増やしたか、徹夜でもしたのでしょう
ツライですね

何でこんなことに？

このようにプロジェクトは山あり谷ありで、しかも回復すらします
なぜそうなるかは色々理由があります

• そもそもHPを見誤った（見積もりミスといいます。先ほどの0番目＝プロジェクトを作る段階）
• 依頼者との調整で止まってる（先ほどの1番目＝要件定義が上手く行っていない）
• やることが全部洗い出せてなかった
• エンジニアの誰かがゴミコードを作ってやり直しになった（ミスって敵に回復魔法使うやつがいた）
• 何か知らないけど仕様変更が入った
• スコープを正しく把握していなくて、本当はもっとHPが高かった

など

どうすればそういうことにならないの？

それはかなり難しいことです
皆が悩んでいて、ベテランですら上手く出来ないこともあります
慣れるまではむしろ、最初から「山あり谷ありなんだ」と思った方がいいです
山あり谷ありをチーム皆で相談して、一個一個解決していくのが仕事です

ちなみに、
ここまでの流れは「タスクを攻略する」にあたってまったく同じなので非常に大事です

少しでも回避する方法

問題を３パターンに分けましょう

1. バトンが来ない（着手できない）
2. 回復される（変更が入る）
3. 回復される（タスクが増える）

回避しやすいのは3です
1,2は自分で何とかするには結構レベルが必要です

ちなみに「なんとかしてよー」と問い合わせる先は1も2もディレクターやPMです

呪文

回復される（タスクが増える）

これは基本的にミスであることが多いです
プロジェクトにおける何かしらの要素が抜け落ちていて、あとで「あっ、そうだった」と気づいてタスクが増えるパターンです

これはよくあります
全体を把握するのは要素が多すぎて難しいんです

そこで、できるだけ全容を把握するために呪文を唱えます
中身は何だよ何のため、いつからいつまでどうやって、出来栄えなんぼで何人で
（内容は何？）（目的は何？）（開始日は？）（終了日は？）（攻撃手段は？）（品質は？）（いくらで？）（何人で？）

「いくらで」と「何人で」は新人エンジニアのうちは必要ありませんが
その他は漏らすとあとで気づいてタスクが増えます（増えたというか、気づかなかっただけ）
常にこれらを意識するとよいです

5.新人として攻略する

新人＝Lv1

新人がプロジェクトに投入されました
どういう状態でしょうか

エンジニア　Lv45
エンジニア　Lv17
エンジニア　Lv7
エンジニア　Lv1　　←　自分
ディレクター　Lv22
デザイナー　Lv15

皆、プロジェクトに必死に攻撃し続けている状態です
そんな中Lv1の初心者が入ってきたらどう思うか
何となく察せると思います
お互いにツライですね

みんな教えるの不得意です、あとそんな暇無いです

ジャングルに放り込まれて、右も左も分からない中どうにか生き残った猛者たち

皆今まで自分で生きるために頑張ってきました
なのでいきなりそのすべを教えてくれと言われても戸惑いますし
皆違うことを言い出します

しかも皆現在進行形でプロジェクトを倒してる最中です
余裕もありません

例えば、サッカーの試合中にいきなり新人が投入されたら「えっ、無理」ってなりますよね
それと同じ状況です

教えてくれるパターン

なので、教えてくれるパターンはこんな感じです

• 見てくれこの武器を、すごいだろう？　お前もこの武器で戦おうぜ、楽しいぞ～（技術や方法論の話題）
• こいつが育ったらプロジェクトの奴をもっと楽に倒せるかもしれない
• やばい、こいつ放っておいたらトチ狂ってプロジェクトに回復魔法使うかもしれない
• 何か教えろって言われたけどめんどくさー

で、内心皆こう思ってます
勝手に育ってくれたらいいのに

泣けてきます
おうち帰りたくなりますね

ぷちサバイバルスタート

とは言えそういう業界です
ここは一つサバイバルを楽しんでやりましょう

3年目までは攻撃力を上げましょう

最初のうちは攻撃力（技術スキル）を上げることが大事です
これは皆気づいてると思います
しかしレベルを上げて物理で殴ればいいというゲームでもないです

何が足りないんでしょうか

タスクを倒せなければならない

新人のうちはプロジェクト（ボス）とは戦わせてくれません
戦うことになったら「この会社どうかしてる」と思ってください（割りとありますが）

ベテランに要求されるのはプロジェクトが倒せることですが
新人に要求されるのはタスクが倒せることです
しかし困ったことに攻撃力をただ上げただけではいい感じに倒せません

プロジェクトがボス　→　タスクがモンスター

薄々気づいたかもしれませんが
プロジェクトとタスクは大きさが違うだけでほとんど同じものです
同じように考えましょう

新人は基本的にはタスクを振られます
例えば１機能を仕上げてくれとか、そういうのです
プロジェクトは多くのタスクに分割することが出来ます

タスクを上手くこなす新人なら、周りは心良く受け入れてくれることでしょう

プロジェクトの小さいのがタスク

例えば自分だけで小さい１機能を実装するのはタスクです
会社によっては「チケット」という形で回ってくるかもしれません

じゃあタスクを上手くこなすにはどうすればいいかといえば
タスクはプロジェクトと似たようなものなんだから、倒し方も同じです

タスクをプロジェクトの小さいやつだと思えば呪文が使えます

中身は何だよ何のため、いつからいつまでどうやって、出来栄えなんぼで何人で
（内容は何？）（目的は何？）（開始日は？）（終了日は？）（攻撃手段は？）（品質は？）

タスクを振られた時どうする？

ちょっと難しいですが、ここまでを踏まえて考えてみましょう

先輩やディレクターは、意外と適当にタスクを振ります

先輩「この画面、この資料見て実装してくれる？　できそう？」

ここで「はい、できます！」なんて言っちゃダメです
ちゃんとヒアリングしましょう

一番大事なのはちゃんと倒せることですが
納期がわからないと倒せるかわかりません

自分「いつまでですか？」

ここで「来週いっぱいまで」と「今日中に」だとだいぶ違うはずです
すると、こう返ってきます

先輩「んー、逆にいつまでだったらできそう？」

これってタスクのHP測れって言われてるんですよね？（見積もりです）
今は1人だから、人月じゃなくて期間のみ（何時間、何日、何週間）でOKです
でも困りました、見積もりなんて言われても検討もつきません、っていうか資料まだ見てません

自分「できるだけ早く頑張ります」
　→ダメです、敵のHPが「できるだけ少ない」とか意味不明です
自分「明日までにはいけます！」
　→ダメです、適当に言わないでください。見積もりミスするとどうなるかは上で書いたのと同じです
自分「資料確認してもいいですか？」
　→これならいいです

先輩「ああ、そこまできっちり聞いてるわけじゃないんだよ」

こういうパターン多いです
先輩も深く考えてないので
そういう時は

自分「じゃあ終わったら報告します」
　→ダメです。上のバーンダウンチャートが先輩から見えない状態になります

自分「じゃあ今日中とりあえずやってみて、明日朝にどのくらい掛かるか報告する感じでいいですか？」
　→私はこれ好きですよ、でも先輩はこう言うかも知れません

先輩「あ、そうじゃなくて１画面どのくらいでできるか聞いてるんだけど」

いやいや、そんなこと言われても分かんないですよね
分かんないですけど、良いから予測してよ！と言われることがしょっちゅうあります
そういう時はずるいですけど範囲で言ったり、上限値で言ったりしちゃいましょう
少なめに見積もるのはNGです

自分「難しいのなら５日くらい掛かると思います」
先輩「おっけー、一旦やってくれる？」

こんな感じのやり取りはあります
胃が痛くなりますね

でもとりあえず一旦これで完璧！！！　...じゃないですよ？

状態を確認します

（内容は何？）　←　資料に書いてる
（目的は何？）　←　？
（開始日は？）　←　？
（終了日は？）　←　とりあえず5日後（資料見たあとにまた相談）
（攻撃手段は？）　←　開発方法は決まってる
（品質は？）　←　？

足りなかったコミュニケーションはこれらです

【開始日】
自分「今からですか？」　←　ちょっと硬い、あと誤解される
自分「それ優先した方がいいですか？」　←　暗に「今からやるべきですか」と聞いてる

【目的】
自分「ちなみにこの画面、何の画面でしたっけ」　←　資料でわからないなら聞いておく

【品質】
自分「これガッチリ組んじゃっていいんですよね」　←　品質は？は裏を返せばスピードは？と同じです、どの程度のバランス感か分からなければ聞いておく

これで情報は揃いました
安心！

安心できない！

どうですか？　できそうですか？
出来ないですよね？　普通テンパります
こんなやり取りができるのなんて、いいとこ3年目です

でも大丈夫です、プロジェクトは長いんです
タスクを振られたあとに、抜けてる項目がないか自分の席で落ち着いて考えましょう
そして疑問ができたら聞きに行きましょう

確認項目をメモっておくとテンパりません

聞く相手が席に居ない！

落ち着いて
とりあえず仮置きして進めておきましょう
相手が戻ってきた時聞いても遅くないです

落ち着いてもできない！

全部考えだすと頭がぐるぐるするかと思います
そういう時は全部忘れてタスクをこなしましょう

指示をちゃんと出さなかった先輩が悪いです（ホントです）

先輩から責められることはありません

質問の仕方

よく仕事の仕方で
5W1Hをはっきりさせて！とか主語をちゃんと言って！みたいな事を言われますが
タスクの場合は「呪文」を思い出してください
あの要素を伝えないと、先輩も理解してくれません

先輩「質問の内容はわかるんだけど、結局何がしたいの？（目的は何なの？）」
とか言われます

不確実性を減らす

上のようなコミュニケーションをちゃんと行っていくと
「あれ、それ決めてないよね？」みたいなのがいっぱい出てきます

先輩「あーそれちょっとわかんないね、ディレクターどうなん？」
ディ「あれ、それって～～ってことですよね？　そういう認識でしたけど」
先輩「こっちのパターンも有るんじゃないかな？　俺はそっちの認識だった」
ディ「あー。ちょっとこれお客様確認ですねー。今日中に聞いときます」
先輩「だそうなので、とりあえずできるところまでやっておいて」

こんなのよくあります
これを放置して、もしやった後に「そうじゃない」ってことになったら大変です
早め早めに分からないことを無くしていくのが重要になります

攻撃しながら常に疑う

例えば「旅行プラン」というプロジェクトを想像してみると
プランではこうだったけど、実際行ってみたら予想外のことがあって、急遽予定を変更した
みたいなことが考えられますよね

計画というのはあくまで計画で、実際とは結構ズレが有ります
完璧な計画というのはありません
実際にやっていくうちに、定まってきます
（分からないことが減ってくる＝不確実性が減ってくるのを、不確実性コーンと言ったりします）

そして「行ってみたら予想外だった」はエンジニアが気づくことが多いので
それはフィードバックしてあげないといけません

フィードバックしないとどうなるかというと、唐突にプロジェクトが回復します（タスクが増える）
ちょっとずつ、ちょっとずつ相談して軌道修正していかなければなりません

なのでそういった疑問点を上げてくれるエンジニアはチームのみならず依頼者からもありがたい存在なのです

タスクも、少しずつ分かっていく

例えば最初「3日ですね」と言ったけど
やってみたら「これやっぱ4日ですね」になって
最終的に「5日掛かりました」みたいなことは日常茶飯事です

最初に予測するのは非常に難しくて、やってるうちに徐々に答えが明らかになります
なので、逐一報告するのが重要です

自分「すいません、3日って言ったんですけど○○を見落としてて、4日掛かりそうです」
先輩「あ、そう」

自分「すいません、4日って言ったんですけど、中々終わらなくて5日になりそうです」
先輩「わかった」

やばい！先輩怒ってる！もう報告したくない！　というのは実は勘違いです
単にどうリアクションしたら良いかわからないだけです
「よしわかった！　問題ない、引き続き頑張ってくれたまえ！」
なんて先輩は居ません
ツンデレ無表情キャラだとでも思ってください
でも報告しないとちょっと怒ります
面倒くさいですけど優しくしてあげてください
少しずつ軌道修正できないと先輩も困るんです

できません！←NG　できます！←NG

なぞなぞみたいですが、呪文を思い出してください
何ができないのか、どういう条件ならできるのか、しっかり言わないといけません
話に食い違いが出て、計画や予定が崩れてしまいます

「すぐ会社に来れますか？」っていう質問にはYES/NOじゃなく
「何時までですか？」となりますよね？

中間地点2

休憩

お疲れ様でした
ここまで分かればもうあまり怖いものはありません

こういうお話はほとんどの人が嫌いですが
でもここらへんができないと常に皆が苦しいことになります
この基本はプロジェクトをやる限りおそらく一生使えるので抑えておいて欲しいです

そして大体何となく理解できたら
あとは存分に攻撃力を上げましょう

ルール理解＋攻撃力、この両方ができていたら、周りが少しざわつきます
上司「彼いいね」
先輩「彼いいですね」
ディ「超いいですね」

ちなみに片方だけだと
「彼、攻撃力はいいんだけどねー、今後に期待かな」みたいに思われます

こっからは本当に攻略で、難易度が上がります
知らなくても何とかなります
でも、知っておくと変なことで悩まなくてよくなり、攻撃力を上げる事に集中できるかもしれません

6.プロジェクト・タスクをもっと理解する

なんで納期が重要なのか

2つ考え方があります

①目的があるから

例えば1/1のイベントのためのプロジェクトなら年内に終わらせないといけないのは分かりますよね
そこから逆算してスケジュールが決まり納期も決まります
これは分かりやすい方です

②複数人でリレーをするから

例）

100人で1人一本の柱を立てて、その後に100人全員で屋根を作ることにしました
100本の柱が立たないと、屋根が作れません

この時、計画を立てる人（PM、ディレクター）は100人に見積もりしてもらいます
そして一番遅い人に合わせて計画を立てます

99人が1ヶ月と言って、1人が2ヶ月と言ったとしましょう
1人のせいで99人が1ヶ月待たされる！　というわけではなく、その間99人は別のことをするはずです

じゃあ2ヶ月後に、屋根を作り始めましょう！

こういう風に計画します

ここで、ある1人が3ヶ月掛かってしまいました

するとどうなるでしょうか、99人が1ヶ月待たされます
その間は屋根を作る予定だったので、他の予定は入れていません
その間、お金は稼げないことになります

1人の1ヶ月遅れ　→　99人月の損失

常に1人しか動いていないリレー状態のプロジェクトなら
1人が1ヶ月遅れても損失は1人月です
でも、例のように複数人で動くことを計画していると、一気に損失がとんでもないことになります

プロジェクトはチーム戦なので、基本的に複数の人に影響が出ると思っておいたほうが良いです

実際にどのくらいの損失になるかは難しい

実際には複雑なリレーが行われます
そういったものをPERT図というもので表したりもしますが
Web系のような小さい案件ではこういうのは作られません
刻々と変化するのでメンテするのが大変です
なので基本的には納期はとにかく大事と思って行動します

プロジェクト・タスクは分割できる

別に難しいことではありません

「朝、会社に出勤するプロジェクト」に例えましょう
とりあえず「飯を食う」「着替える」「荷物準備」にわけられます
「電車に乗る」あたりが当面の納期になるでしょう

普段誰しも何気なくやってることですが
規模が大きくなると途端にわからなくなったりするものです

ところで、「朝、会社に出勤するプロジェクト」って
「仕事をするため」が目的ですよね
「仕事をする」のは「お金を稼ぐ」が目的ですよね

こんな感じでプロジェクトは分割できるし、そもそもプロジェクトが分割されたものです

新人の頃に与えられるのは一番右側の小さいタスクです
もちろん納期があって、その責任を担保するのは自分です

一個上の領域になると先輩エンジニアなどが担当します
その大きいタスクにも納期があって、先輩がその責任を担保します

もう一個上の領域になるとプロジェクトです
プロジェクトにも納期があって、プロジェクトマネージャーやディレクターがその責任を担保します

もう一個上の領域になると依頼者の目的があります
依頼者にも納期があって、依頼者がその責任を担保します

やってることは皆同じ

あれ？と思ってもらえると嬉しいです
単にリレーをしてるだけで、やってることは皆同じです

今まで書いてきたことが誰にも当てはまってきます（タスクを分割する点を除いて）
ここまでの話がどれだけ大事か何となく理解できますかね

何か上の領域の人が怒ってる、何で？

ここまで理解できたら難しくないです
上の領域の人も、間に合わないから焦ってるんです
もしくは、不確実性が減って、分からないことが分かった結果「あ、違った！」となって焦ってるんです

上の領域の人には、更に上に人や目的があります

どの領域の人でも、その人のスコープはどこか考えてみると「何故」が減ってきて
皆幸せになります

計画・見積もりが死ぬほど大事

プロジェクトや小さなタスク、どちらにも同じことが言えますが
リレーの前のほうが詰まれば詰まるほど後ろがきつくなります
というか無理です
駅まで徒歩15分なのに、3分で到着しろと言われても無理ですよね
ちゃんと計画を立てて見積もりして、余裕も用意しておくのが大事です
でも実際やってみると非常に難しいです

難しいから、皆で知恵を出し合います

7.もっともっと理解する

暇を見つけて別記事に書き足します

【噂】IT業界のウソ・ホント【闇】

新人エンジニアに、3年同じ会社で頑張るのをオススメする理由

「わからない」を「わかる」にする方法の話

最後に

私が新人に伝えられることは大体こんな感じです

何かツライことをいろいろ書きましたが、実際知らないとツライです
でも何でツライか知ってると意外と何とかなります

何でツライのかは頭の隅にしっかり残したまま、楽しい開発をしましょう

※疑問点や改善点などあればお知らせください