BlogIT・WEBエンジニアのキャリア相談/転職支援サービス【TechLeadCareer|テックリードキャリア】(career.techlead.jp)を運営するグローバルシフト株式会社のブログ2018-03-01経営者や事業責任者なら知っておいて欲しい、単価150万円と70万円のIT系エンジニアの違いTweetグローバルシフト株式会社、代表の小川です。弊社のエンジニア・デザイナーの皆さんの働きで、なんとか直近のシステム開発プロジェクトも納期通りのリリースを迎えられそうなので、1週間ぶりにブログ更新します。今回は、少し前のはてブで盛り上がっていた、以下の記事について考察して行きたいと思います。togetter.com*いつも通り、このブログにおける「エンジニア」とは、IT・WEB系の開発業務に従事されているエンジニアを指します。件のつぶやきは何を伝えたかったのか?オリジナルのTweetは、以下のように呟かれていました。人月単価150万のところに出したらめちゃくちゃ優秀で仕事早くて半月で終わったんですよ。人月を単価が高いと内部から文句が出て70万のとこに変えさせられた。結果、半年かかるようになった。価値云々というよりは、単価ベースになったら単価切り下げ圧が必ず発生する。それが調達部門の論理。ITの場合は単価がよりによって人月なので賃金が永久に削られ続ける。概要は「人月単価150万円のエンジニアの方に依頼したら2週間で終わった仕事が、単価の高さを理由に調達部門から取引先の変更を指示され、変更した取引先の人月単価70万円のエンジニアの方は(恐らく)同じ仕事に6ヶ月かかった」という事かと推察されます。エンジニアの方と期間による業務委託契約した際の、一ヶ月あたりの費用。期間契約ではなく、成果物作成の請負契約の場合、人月単価を平均稼働日数20日で割った人日単価の場合もあれば、単発作業のためそれよりも人日単価が高額になるケースもある。420万円/24週間」という単純比較ではない事も付け加えておきます。”別ツイートでも言ってるけど、発注の継続性が安定したのでトータルコストが上がったとは言い切れないし、管理費やリスク考えると損とは言い切れないんだよ”恐らく、人月150万円のエンジニアの方はフリーランスか非常に忙しい方で、いつも仕事の委託が可能なわけではなく、また大きな法人でないため取引の安全性も低い、と言うことが示唆されていますね。多くのエンジニアが同意する「優秀と凡庸の間にある数倍のパフォーマンス差」このTweetは非常に多くの反響を呼びました。コメントの記載内容やそのニュアンスから、多くの方がエンジニアの方である事が推測されますが、大半の方が優秀なエンジニアとそうでないエンジニアとのパフォーマンスの差に共感を示すと共に、その事実に対する非エンジニア職種(決裁者や調達部門など)の理解の無さに対する嘆きにも似たコメントが多数寄せられていました。私も上記について全くの同意見です。ここで、私が上記のような意見となるきっかけとなった過去の体験を共有したいと思います。計画に対し3ヶ月遅延。計画上の開発フェーズ期間はテストを含め4ヶ月で、遅延を考慮すると残り1ヶ月しか残されていなかった。当時の所属は大手企業で、社内向けの技術開発グループから優秀な若手エンジニア3名が火消し役として派遣された。まともな設計書もない中、ホワイトボードを中心に座席を配置し、大まかな構成と仕様をホワイトボードに記載。主要なクラス設計や共通モジュールの作業分担を口頭で行い開発着手、わずか3週間で開発完了。システム開発プロジェクトでしたが、一口にエンジニアと言ってもそのスキルやパフォーマンスに大きな差がある事を深く理解しました。開発リーダーは90万円前後でその他委託メンバーは70万円前後であり、今回のTweetのケースと比較的に近い状況だったと思います。私が過去のシステム開発に纏わる仕事において、大きな失敗もなく進めてこられたのも、優秀なエンジニアがプロジェクトに与えるインパクトの大きさを、この体験から身をもって学んだからに他なりません。この様な事が起きてしまうのか?Tweetにも「調達部門」と記載がある通り、呟かれた方も一定の規模の組織に所属されている方かと推測されます。調達部門などが出来ると、社内規程で「必ず3社に相見積りを行い、合理的な理由が無ければ低価格の取引先を選択」のようなルールが生まれ、ほぼ強制的に従わなければならなくなるのは容易に想像がつきます。個別のエンジニアのコストパフォーマンスを合理的に説明出来れば良いのですが、そもそも決裁者が低コストを重視し過ぎていたり、調達部門がエンジニアの技術評価を適切に出来ない事がほとんどのため、発注を依頼するエンジニアの方の社内における発言力がよほど強くない限り、Tweetの様な不幸な出来事が生まれてしまうのです。その様な不適切な意思決定の影響を受けた社内のエンジニアの方のモチベーションが著しく下がり、いずれ退職してしまうであろう事も容易に想像がつきます...。すれば良いのか?この問題を解決する事は、非常に簡単です。自社のエンジニアの方の目利きを信じてあげて下さい。少なくとも、技術理解の無い経営者や調達部門よりは精度の高い選択をされるはずです。自社にエンジニアや、技術の分かるスタッフがいない場合は、外部の方に技術顧問という形で、部分的に業務をアウトソースすると良いと思います。因みに、私たちグローバルシフト株式会社でも、技術アドバイザリーサービスを提供しておりますので、お困りの際は是非ご相談下さい。globalshift.co.jpまた、初見の取引先・エンジニアの方の場合、期待した成果が上がらず選択を誤る事が、私たちも含め少なからずあります。これは、一定程度発生する事は仕方がないのですが、この様な初見の方との取引についても、出来る限り小さくすぐに評価しやすいお試しの仕事を依頼してみて、本当に自社が求める取引先なのかどうかを判断してはいかがでしょうか。最後にいかがでしたか?Tweetに対するコメントでも、現役のエンジニアと思われる方々から「よくある!」といった声が多かった事からも、多くの企業・開発プロジェクトで起きている事ではないかと思います。17:29経営者や事業責任者なら知っておいて欲しい、単価150万円と70万円のIT系エンジニアの違いTweetコメントを書くもっと読む2018-02-21日本のエンジニアの給料を上げるために必要な事Tweetグローバルシフト代表の小川です。「エンジニア*の給料上がらない問題」が話題となっているようです。president.jp*ここでは、日本のIT・WEBエンジニア、WEBアプリケーションエンジニア、ソフトウェアエンジニアなどの、IT系エンジニアを「エンジニア」として表記し、話を進めます。提供する私たちも、この問題について考察してみたいと思います。大前さんの記事で比較対象として挙げられていた中国の「ファーウェイ(華為技術)」や、優秀なインド人をヘッドハンティングする「グーグルやフェイスブック、Amazonなど」が、高い報酬で世界中から優秀な「エンジニア」を集めていることは事実です。「給料が上がらない」と比較対象に挙がった日本の「エンジニア」というのは、本当に日本における「ファーウェイやグーグル、フェイスブック」に位置付けられる企業に所属する「エンジニア」なのでしょうか?(とは言え、前述の外国企業の給料はかなり高騰していると思いますが...)VCやエンジェルなどのリスクマネーの規模の違い記事では言及されていませんでしたが、日本とアメリカで生まれるスタートアップ企業の数や、VCやエンジェル投資家からの資金調達規模の違いも大きな違いがあると思います。大きなアメリカのIT系スタートアップでは、初期の段階から「エンジニア」にも高い給料を支払う原資があるため、給料の差に表れるのではないかと思います。「エンジニア」が所属する企業属性の違い日本とアメリカの「エンジニア」がそれぞれ所属する企業には、その属性に大きな違いがあります。日本の「エンジニア」は、受託開発企業に所属する割合が相対的に高く、人月単価の上限が給与水準を規定する傾向にあります。逆に、アメリカでは事業会社に所属する「エンジニア」の割合が多く、グーグルやフェイスブックなど世界的に事業展開する巨大で高収益な企業が多いため、事業収益の規模や人材の需給バランスで「エンジニア」の給与水準が押し上げられていると思います。付加価値の低い業務はインドやフィリピンなど、英語圏の人件費が安い国にオフショアで業務委託するため、アメリカ国内の「エンジニア」の平均給与をさらに押し上げる要因になっており、企業属性を揃えた比較を行う必要があると思います。解雇規制の違い日本とアメリカで比較した場合、日本は労働者が強く保護されており、昔から存在する企業では退職金制度も充実しているため、見えない報酬や採用ミスのリスク回避の観点から、相対的に給与が低く抑えられる傾向があると思います。詳細なファクト調査は行っていないため、誤った認識があるかもしれません。その場合、ご指摘いただけると幸いです。前提条件が揃えば、日本の「エンジニア」の給料も上がるのか?結論から言うと、日本の「エンジニア」も給料上がります!と言っても、まずは比較対象となる「エンジニア」の企業属性の絞り込みや、現在の日本のような正社員にとって安定した雇用環境を劇的に変える、という前提の話ですが...。比較対象とする「エンジニア」を都市部の事業会社だけに絞る日本でも近年、空前の「エンジニア」不足の状況にあるため、事業会社における「エンジニア」の給与は上昇を続けていると思います。東京の事業会社に所属する「エンジニア」に絞れば、平均給与は600万円前後まで上昇するのではないでしょうか?解雇規制を緩和し、「エンジニア」雇用の流動化を実現する解雇規制が緩和され、企業が雇用リスクを感じなくなれば、現在多くの事業会社で一般的に活用されている、社内常駐の業務委託エンジニアに支払うフィーと同程度の給料まで引き上げられる可能性が高いと思います。85%*消費税(1.08)、及び企業の社会保険負担率(15%)つまり、アメリカと同様に雇用の流動化が進めば、理論上、現在の日本企業でも業務委託費用に近しい水準で報酬を支払うことが可能であると思います。(その分、レイオフリスクは当然高まります)前提条件を揃えても、アメリカの3/4程度。日本の「エンジニア」の給料を、世界のトップ企業レベルまで引き上げるためには?比較対象とする日本の「エンジニア」を給与水準の高い都市部の事業会社に絞り、解雇規制の緩和まで行っても、まだ日本の「エンジニア」の給料はアメリカの3/4程度までしかポテンシャルがありません。当たり前の話になってしまいますが、日本の「エンジニア」にも高い水準の報酬を支払えるようになるためには、それに見合った企業収益をあげる将来的な超大企業・ユニコーンが増加する必要があると思いますし、チャレンジする起業家を支えるリスクマネー・エコシステムの広がりも必要となるでしょう。2つの視点があると考えています。一つは、既に現時点で十分な付加価値を創出しているにもかかわらず、正当に評価されていない「エンジニア」の評価を是正することで、付加価値の高い「エンジニア」を増加させる、ということです。企業経営者や「エンジニア」の評価者にあたる人の技術理解度の問題で、あるいは「エンジニア」自身が、創出した価値をビジネスにおける価値に置き換えて説明できていないと言った要因で、正当に評価されていない「エンジニア」が日本にはまだまだいるのではないでしょうか?こちらのブログでも、「エンジニア」が自分が創出した価値をビジネスにおける価値に置き換えて説明できていない、と言うことを非常に分かりやすく解説されています。NAEの仕事効率化ノートもう一つは、現在の日本における「エンジニア」の中に、企業が求めるレベルでの付加価値の高い仕事をされている方がまだ少ない(と感じる)ため、付加価値の高い仕事の出来る「エンジニア」の数そのものを増加させる、ということです。先ほど”空前の「エンジニア」不足”と記載したものの、有名企業や成長企業の「エンジニア」採用では、「エンジニア」であれば誰もが簡単に転職できるわけではない、という現実を日々目の当たりにしています。これまでの日本では、受託開発を中心とした「相手の要望に沿ったシステムを作る」と言う仕事が多かったためか、事業会社におけるビジネスの戦略や目標を理解し、その実現や達成に貢献すると、という視点・姿勢を強く持った「エンジニア」の方がまだまだ少なく、世の中の需要に対して不足していると感じています。相談に来ませんか?もちろん、転職前提でなくてもOKです。08:46日本のエンジニアの給料を上げるために必要な事Tweetコメントを書くもっと読む2018-02-15防火シャッターでも防げなかった?文化シャッターのシステム開発プロジェクト炎上の考察Tweetグローバルシフト株式会社、代表の小川です。2月13日のはてなブックマークの人気エントリーに、以下のような衝撃的な見出しが踊りました。xTECH(クロステック)私たちが提供する、IT・WEBエンジニアのキャリア相談・転職支援サービス「TechLeadCareer」のtwitterアンケート企画「#エンジニア世論調査」でも、時を同じくしてシステム開発プロジェクトの状況についての調査を行っており、その調査結果でも今回の記事と同様に多くの開発現場でプロジェクトが炎上していることが推測される結果となりました。上記の調査結果や、私が過去に体験した炎上プロジェクトの経験を併せながら、今回の記事に登場した文化シャッターのシステム開発プロジェクト炎上を考察してみたいと思います。システム開発プロジェクトにおいて遅延・炎上は決して珍しくない2003年10月〜2008年8月の間、私はIBMビジネスコンサルティングサービス株式会社(現日本IBM)という企業に所属していました。その間、参画した数件のシステム開発を伴うプロジェクトは、大半が大幅な遅延もしくは炎上と呼ばれるような手がつけられない状況に陥っていたと記憶しており、同期が配属された他のプロジェクトも似たり寄ったりでした。炎上中”という回答が寄せられました。2018年2月7日さらには、日経コンピュータによるプロジェクト実態調査が2003年と2008年に実施されていますが、クライアント視点で失敗と評価されたプロジェクトは約70%という調査結果も出ています。これらを見る限り、システム開発プロジェクトを行う際には、遅延・炎上が発生する事は決して珍しいことではない、という事が言えるのではないでしょうか。システム開発プロジェクトは炎上するのか?当然の事ながら、プロジェクト毎に開発内容や体制など前提条件がそれぞれ異なるため一概に論ずる事は難しいのですが、私の経験やブックマークのコメント欄で言及されていた内容を整理すると、以下の3つの内容に要約できるのではないかと思っています。欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップそれでは、それぞれの内容について詳しく考察を行っていきたい思います。過剰なセールストークで決まる、安易な流行の採用システム開発の営業・提案活動において、システム開発に関する経験・深い理解の無い営業担当者が行う、クライアントへの過剰なセールストークや技術的な裏付けの無いその場だけで決まった口約束は、その後の開発プロジェクトをスタート前から失敗に導くことになります。今回の記事に「セールスフォース(SF)の導入にもかかわらず95%をカスタマイズ」「開始当初はアジャイル+ウォーターフォール(WF)」といった内容が記載されています。技術選定の背景やその目的が定かでないため一概には言えないのですが、「はやりのクラウドで開発したい(しましょう!)」「アジャイルやりたい(やるべきです!)」といった感じで、これまでの開発プロジェクトとの差別化を図ろうとした結果、話の流れの中で手段が目的にすり替わり、最終的にプロジェクトがキックオフされるに至ったのではないかと推測しています。大手の開発ベンダーであれば、社内に提案内容を精査するリスクマネジメント部門・機能があると思います。リスクマネジメント部門は「95%をカスタマイズするならパッケージ・クラウドの意味がない」など、真っ当な指摘をされたことかと思いますが、大規模なシステム開発案件が少なくなってきている昨今、受注を確実なものにするため、様々なリスクヘッジ策を講じることを条件にGoサインを出してしまうのではないでしょうか。残念ながら、リスクヘッジ策が適切に講じられることはほとんど無いに等しく、システム開発現場のエンジニアやクライアント担当者が疲弊し、最終的にプロジェクトは頓挫することになります。ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題ここで言う「企画(計画)」とは、プロジェクトの目的やゴール、対象システム(サービス)の内容と開発範囲、マスタースケジュールや各開発フェーズの定義、ステークホルダーの役割と責任、及びトレードオフを伴う意思決定事項の基本方針などが取り纏められたものを指します。ゆるふわな企画(計画)とは、要件定義を行う前の段階で「前述のような企画内容がシステム開発の要件定義を行うのに、十分なレベルで明確になっていない」という事を意味しています。この「ゆるふわな企画(計画)」は、まずプロジェクトの序盤である要件定義フェーズで”要件バブル”を引き起こします。プロジェクトの根幹となるしっかりとした企画(計画)が固まっていないため、要件定義を進めていく中で「あれもやりたい、これもやりたい」「こんなユーザーがいるかもしれない、こんな使い方も用意しなければ」と、無限に要件(の候補)が膨れ上がることになります。その結果、本来時間をかけて詰めるべき大事な要件に対して、十分な調査・検討時間をかけられず、要件定義が緩いまま次のフェーズへ進まざるを得なくなるのです。今回の記事の中でも「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」がバグ発生の原因として挙げられています。この「要件定義フェーズの遅延」を生み出している大きな要因の一つが”要件バブル”であり、「企画(計画)」が不明確なままに要件定義フェーズを進めている事に他ならない、と私は考えています。「ゆるふわな企画(計画)」の影響は、要件定義フェーズにとどまりません。”要件バブル”の影響で生み出された、”要件定義の不良債権”という名の様々な隠れた要件・仕様が、やっとたどり着いたプロジェクト終盤のユーザーテストであぶり出され、勢いよく一気に火を噴くことになるのです。欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップここまでは、システム開発プロジェクト炎上の要因が、より上流の営業・企画(計画)策定フェーズから生み出され、プロジェクトの炎上にどのような影響を及ぼすのかを整理してきました。システム開発プロジェクト炎上の最も大きな要因は、もっと根本的な別の要因にあるのではないかと私は感じています。それは、このトピックで言及する「欠落したベンダーのプロフェッショナリズム」と「不十分なクライアントのオーナーシップ」に他なりません。「欠落したベンダーのプロフェッショナリズム」とは、前述した「過剰なセールストークで決まる、安易な流行の採用」と「ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題」において、開発ベンダーがプロフェッショナルとしての役割を十分に果たせていない、という現状を指しています。プロジェクトの目的に即していない技術の適用方法や開発アプローチの提案はもってのほかであり、仮にクライアントから不合理なソリューションの提案を求められたとしても、プロとしてメリット・デメリットを整理し、正しい意思決定をサポートすべきであると考えます。システム開発プロジェクト炎上の要因は、全て開発ベンダーにあるのでしょうか?私は決してそうは思いません。過去、私が開発ベンダーサイドの人間としてシステム開発プロジェクトに参画していた時に、炎上プロジェクトに共通して感じるある違和感の存在に気付いた事があります。それは、クライアントサイドのプロジェクトメンバーの中に「自分達のシステムを作っている。絶対に成功させるんだ」という当事者意識を持ち、主体的にプロジェクトを進めているメンバーの比率が圧倒的に少ない、という事です。クライアント全てがそうと言うわけではないのですが、ここで言う「不十分なクライアントのオーナーシップ」とは、炎上プロジェクトには必ずと言って良いほど「主体的に意思決定できず、問題を先送りにする」方や「建設的に議論を進めずに、常に批判的な姿勢で悪戯に検討を長引かせる」方々の存在があり、クライアントのプロジェクト成功に対するコミットメントが不十分である、と言わざるを得ない状態を指しています。今回の記事に対するブックマークコメントでも「クライアントの丸投げ体質」に関する言及や、「既存システムをそのまま新システムにリプレイスしようとしていたのでは?」といった、プロジェクトの目的自体が正しかったのかについての問題提起が見られました。クライアントサイドに十分な当事者意識・オーナーシップがあればこのような事態にならないのではないか、という意見には私も同感です。どんなに課題を抱えたプロジェクトでも、ベンダー・クライアントのいずれかが責任を持って行動していれば、納期のリスケジュールやスコープの縮小、あるいはプロジェクト途中での開発ベンダーの変更など、開発プロジェクトが頓挫する前にできる対応は多々あると思います。本件は恐らく、双方が課題を抱えたままプロジェクトを進め続けてしまったがために、修復不可能な状態まで大炎上してしまった、典型的な失敗プロジェクトであると推察されます。すればシステム開発プロジェクトは炎上しないのか?私たちグローバルシフトでは、所属するエンジニアの技術力向上・経験の蓄積を目的として、スタートアップやベンチャー企業の新規システム開発・システムリニューアル開発の案件を中心に、事業の一部としてシステム受託開発を行っています。その際、私が過去に経験した炎上プロジェクトの要因分析から、各要因に対して以下のような考え方・取り組みでシステム開発プロジェクトを進めています。私たちから、クライアント受けを狙った流行の技術・アプローチを、過剰なセールストークでお勧めすることはありません。最近は「クラウド」「アジャイル」という流行りのキーワードをやりたいとご相談頂く事もあるのですが、プロジェクトの目的や開発内容の特性をヒアリングした上で、安易に適用すべきでない場合にはその理由と共にはっきりとお勧めしない旨をお伝えします。確実にプロジェクト炎上リスクを高めるだけの場合には、開発のご依頼自体をお断りする事もありますし、クライアントが新しい技術・アプローチを適用したい理由がリーズナブルな場合には、しつこいと思われる程に想定されるリスクや影響をご説明した上で、両者合意の下で開発プロジェクトを進める事もあります。何れにしても、提案を行うベンダーもそれを評価するクライアントも、耳障りの良さや目新しさに高い価値を置くのではなく、本質的なプロジェクト価値に目を向け、その実現可能性を最大限高めるアプローチを共に策定・合意できない限り、今後も本件のような不幸な開発プロジェクトは後を絶たないと思います。意思は本物なのですが、企画(計画)に曖昧な部分が多く残っていたり、アイデアレベルという事も少なくありません。コンサルティング(2週間~1ヶ月)をご提案させて頂き、クライアントの想いやアイデアを明確な企画(計画)に一緒に落とし込んでいきます。企画(計画)を一緒に策定する中で、システム・サービスの目的や機能の重要性・優先度の確認、トレードオフが発生した場合の優先するQCDの観点などについて合意形成を行うため、要件定義フェーズで”要件バブル”が発生しそうになっても、「これらの要件(候補)は重要性も低く、納期を優先させるためには初期リリースの範囲から外し、リリース後の検討にしましょう」といった形で、クライアントとの共通認識のもとに”要件バブル”を防ぐ事が出来るようになります。要件の不良債権を後続フェーズに残さないため、プロジェクトの上流工程(企画や要件定義)であっても、可能な限り仕様の定義を具体的且つ明確に行うように心掛けています。この点は賛否両論あると思いますし、クライアントによっては実際に動かせるプログラムがないと、イメージが湧かず定義しづらいという声も実際にあります。クライアント自身が開発を望んでいるシステムに対し、自分事として具体的なイメージを早期に持っていただく機会を作ることは、開発サイドとの認識齟齬や隠れた開発要件の炙りだしに有効であると私たちは考えており、クライアントの皆様には時折面倒に思われながらも、ご理解とご協力を頂いています。自社のメンバーに要求する高いプロフェッショナリズムは当然のこととして、私たちはそれ以上にクライアントのオーナーシップや本気度、根拠に基づくリーズナブルな意思決定を許容されるタイプかどうかの見極めに重点をおいています。極論・暴論にはなりますが、クライアントのオーナーシップが低かったり、根拠のないこだわりや気分による意思決定に固執されるタイプのクライアントの場合、プロジェクトの炎上・失敗リスクは飛躍的に高まります。何よりも一緒に仕事を行うパートナーとして、このようなタイプのクライアントと仕事をする事以上に、自分達のモチベーションを下げる事が他に無いからです。グローバルシフトは2015年の創業以来、幸いにも友人や知人、クライアントの皆様に恵まれ、全ての受託開発案件をご紹介・追加発注という形で継続的にいただいております。過去にプロジェクトをご一緒したクライアントからは、さらにその友人・知人の会社をご紹介頂く事も多く「これほど信頼できる開発パートナーはこれまで会った事がない。ここに任せればスムーズにプロジェクトが進み、サービスをリリースできないという事はない」と、最高のご推薦文と共に繋げていただく事もありますが、このような評価が頂けているのも「システム開発炎上の要因に対し、課題が顕在化する前から一つ一つ丁寧に課題解決に取り組んでいるから」ではないかと考えています。最後にシステム開発プロジェクトの炎上や失敗は、クライアント・ベンダーなど全てのステークホルダーにとって不幸な事であると思います。プロジェクトがスタートを切る時点で、システム開発プロジェクトの炎上・失敗を望んでいるプロジェクトメンバーは、誰一人いないはずです。今回の考察が少しでもシステム開発プロジェクト関係者の目に触れ、今後の開発プロジェクトにおいて少しでも遅延・炎上の解消に寄与すれば幸いです。行い、なんとかプロジェクトを成功させようと身を粉にされたエンジニアの皆様、本当にお疲れ様でした。はてなブログProIT・WEBエンジニアのキャリア相談/転職支援サービス【TechLeadCareer|テックリード】を運営するグローバルシフト株式会社のブログ。ベンチャー・スタートアップ・事業会社の新規事業に特化したシステム受託開発、ビジネスコンサルティングも提供しています。月別アーカイブ検索スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。