今回は、システムエンジニアやプロジェクトマネージャーなど、クライアントと直接会話する立場のエンジニアであれば、一度は耳にしたことがある、“クライアントからの迷惑な一言”とその対処法について、まとめてみました。 現在、直接的にはクライアントと関わることはない立場の方も、今後、キャリアップ・スキルアップに伴って、クライアントと直接かかわることも出てくるので、知識として知っておいていただきたい内容になっています。 テクフリでフリーランス案件を探してみる いい感じで 『いい感じで』という言葉は、本当に取り扱い注意です。 なぜか？ それは単純に、「なにを持って“いい感じ”とするか、クライアントとエンジニアの間で認識があっているか、保証がない」という点です。もっと言ってしまえば、エンジニアの感覚で、『いい感じで』作ったシステムがクライアントにとっての『いい感じ』のシステムなのか、誰にもわからない、ということです。 そして、『いい感じで』の基準が明確に共有されていなかった結果、本当にクライアントが求めていたものと異なる機能を開発してしまったために、再開発(手戻り)になったり、納品拒否されるなど、“失敗プロジェクト”になってしまうことも少なくありません。 クライアント担当者から『いい感じで』という言葉が飛び出したら、なにをもって『いい感じ』とするか、しっかりとヒアリングして“要件定義”をしましょう。また、要件定義ができた後は、ちょっとしたことでも、メールや議事録などで良いので、後から「クライアント・エンジニア双方が、どのような内容で合意したか？」を確認できる形で記録を残しておきましょう。 なぜ、そこまでするかというと、『いい感じで』という言葉を発するクライアント担当者は“システム開発がわかっていない人”であることが多いからです。 実際、私が相対した、『いい感じで』をやたらと使うクライアント担当者さんは、機能要件・非機能要件という言葉も知りませんでした。知識がないために、うまく要求事項をまとめられず、『いい感じで』を連呼していたというわけです。 そして、『いい感じで』を多用するシステム開発が分かっていないクライアント担当者は、この後紹介する、『なるはやで』、『思ったより工数かかるんだね』『頼んだじゃん！』もよく使う傾向にあるため、慎重に扱った方が良いことが多いのです。 なるはやで 日本では『なるはやで』という言葉が好きな人が多い気がします。「そちらの予定次第で良いですよ」というニュアンスが含まれていて、一見、親切な言葉に見えます。しかし、ビジネスの世界では使ってはいけない言葉です。 なぜならば、『なるはやで』では、いつまでにやってほしいのかが分からないからです。仕事である以上、納期や、ターゲットとなる時期があるはずなのに、それが隠されてしまいます。 私自身、『なるはやで』という言葉で、痛い目に合いかけたことがあります。 「急いでいる訳ではないんですけど、なるはやでネットワーク作業をお願いします」とクライアントから月次会議で伝えられて、“今期中のどこか手隙のタイミングで対応すれば良いか”と考えていたのですが、翌月「健史郎さんのネットワーク作業待ちなんですけど、まだですか？」と催促されたのです。 よくよく聞いていくと、私の対応は、クライアント会社内部で行われた監査に関連したものであり、クライアント社内で「何月何日までに対応完了予定」と会社の上層部にも情宣されている、ということでした。そして、その期限が、催促を受けた月の月末最終営業日だったのです。 このときは催促がきっかけになって納期の確認ができて、問題が起きませんでしたが、危うく「ネットワーク担当の健史郎というエンジニアがスケジュールを守っていない」という話になるところでした。 そのような事態にならないためにも『なるはやで』と言われた場合は、クライアントの担当者と相談して、「いつまでに行うべきか？」を明確にしましょう。 なお、「いつまでに行うべきか？」を相談すると、システム開発が分かっていないクライアント担当者は、その作業の手間や準備期間、さらには後続作業との関連性が見えておらず、非現実的なスケジュールを提示してくることも少なくありません。 こうしたクライアント担当者を逆にコントロールして、現実的なスケジュールをくみ上げていく手腕も上流工程を行うエンジニアには重要です。 思ったより工数かかるんだね 『なるはやで』と同じで、作業の手間や準備期間、さらには後続作業との関連性が見えてないこともあり、思った以上にお金やスケジュールがかかる、という不満を漏らすクライアントも多いです。 結局、クライアント担当者はシステム開発を発注する側、つまり買う側です。より安く、より早く納品してもらった方が嬉しいですし、その観点でしか見積書や請求書を見ない、あいは、その観点でしか評価する能力がないクライアント担当者も多いのです。 さらに言えば、日本ではIT投資はコストという風潮が強く、安ければ安いほど良い、と考える経営者が多いです。そして、IT企業側も人件費(つまりエンジニアの報酬)を圧縮するなどしながら、価格競争をしている状況です。 “適正価格”というか“相場”があってないような状況にあるのが、ITビジネスの現実です。 私の場合、『思ったより工数かかるんだね』と言われたときは、工数の見積もり根拠を説明するようにしています。「このリンクをクリックしたら、この画面が立ち上がるようにしたい、というお話ですが、これを実現するためには、この画面を作るだけではなく、DBにも手を加えます。なぜならば……」といった風に。 そもそもシステム開発が分かっておらず『思ったより工数かかるんだね』と言ったクライアントは、たいていの場合、これで納得してくれます。 たまに、どこぞかで知識を仕入れてきて「もっと安くできるはずだ」とおっしゃるクライアント担当者もいます。そういう方に対しては、管理工数や実績などを絡めながら「安かろう、悪かろうですよ」という趣旨のお話をすることもあります。 頼んだじゃん！（ 完成したものを見せたら、頼んでいた機能がないとか、思っていたのと違うものが出てきた、と文句を言うクライアント、やっぱりいます。 こういう事態になるのは、『いい感じで』としか言われなかったせいで、ボタンを掛け違ったまま開発を進めていた、というのもありますが、「クライアントが開発スコープを分かっていない」というのもあります。 開発スコープ、つまり、どんなものをいつまでに開発するかは、要件定義で検討され、実装することが確定した機能についてのみ、要件定義書などで明文化されるのが通常です。逆に言えば、検討されたものの、要件定義書などのドキュメントに記載のないものは開発する必要はありません。もっと正確に言えば、開発してはなりません。 ところが、検討した記憶が残っているクライアント担当者の上席にあたる方などから「あれも欲しかったのに」と言われるパターンが一番多いです。 その場合の対応法は、要件定義書などのドキュメントを再確認するようにしています。そして、「スコープ外となったため開発していないんですよ」と説明し、納得してもらうようにしています。 まとめ：クライアント担当者は基本的にはエンジニアではない 結局のところ、クライアント担当者はエンジニアではないため、システム開発やシステム作業について、正しい知識を身に着けている、という期待は持ってはいけません。 分かっていない人、あるいは分かっている風だけど変な知識を持っている扱いが難しいクライアント担当者をうまくコントロールする技術も、ある意味、エンジニアが出世するのに必須となるスキルです。 テクフリでフリーランス案件を探してみる

フリーランスの消費税とは？ フリーランスエンジニアにとっての消費税は、2023年2月現在では課税売上高が1,000万円以上になると支払いが義務づけられています。 そして、フリーランスに業務を依頼する企業も、フリーランスへの支払いに発生した消費税は、消費税の支払いから差し引いて計算することができます。 そのためフリーランスエンジニアとして課税売上高が1,000万円を越えない限り、消費税は特別意識する必要性がない税金でした。 実際に消費税が上がれば、企業による支払いに消費税も含まれるため、受け取る金額が増える案件も珍しくありません。 フリーランスエンジニアとして活動していて、消費税が上がったことによる痛みはあまり感じていない人の方が多いのではないでしょうか。 参考として、国税庁のホームページでは「納税義務の免除」として消費税の納税義務が免除される条件が提示されています。 フリーランスエンジニアなどの個人事業主の場合は、前年度ではなく前々年度の課税売上高が関係してくるところが注意点です。 参考：国税庁「納税義務の免除」 インボイス制度とは 前述の通り、これまで消費税はフリーランスエンジニアなどの個人事業主にとっては、課税売上高が1,000万円を超えた場合に限り関係してくるものでした。 しかしインボイス制度が開始すればその状況は一変します。 インボイス制度が開始されたら、仕入税額控除の要件を満たすための要件がこれまでとは大きく変わるからです。 インボイス制度の開始は「2023年10月1日」となっています。 ではインボイス制度が始まることによって具体的に何が変わるのでしょうか。 その内容について見ていきましょう。 関連記事：フリーランスには税理士が必要？費用などについて詳しく解説します 免税事業者への消費税の支払いが仕入税額控除の要件外となる インボイス制度がスタートしていない2023年2月時点では、企業はフリーランスエンジニアなど個人事業主へ支払った消費税も法人に支払った消費税も、そのどちらも仕入税額控除として計上することができます。 そのため企業は、企業への発注もフリーランスへの発注も同じように仕入税額控除をすることができました。 ところがインボイス制度がスタートすれば、企業が仕入税額控除として計上できるのは企業など課税事業者との取引のみとなります。 企業が免税事業者であるフリーランスに支払いを行った場合、消費税が仕入税額控除として計上できなくなるのです。 そうなった時に影響が考えられるのが、企業によるフリーランスへの仕事依頼の躊躇です。 企業は利益を確保するため、消費税を仕入税額控除できる課税事業者との取引を優先することが予想できます。 免税事業者としてフリーランスで活動している場合、受注できる仕事が減る可能性が出てくるといえるでしょう。 もちろん抜きん出た才能があれば、免税事業者でも良質な案件を受注できる可能性はあります。 しかしフリーランスエンジニアとして案件の受注のしやすさを考えるなら、消費税の課税事業者になることへの検討も大切です。 課税事業者になるために必要な手続き では、免税事業者であるフリーランスが課税事業者になるためには、何をする必要があるのでしょうか。 それは「適格請求書発行事業者の登録申請書」と「消費税課税事業者申告届出書」を提出することです。 「適格請求書発行事業者の登録申請書」とは、課税事業者になるための申請書です。 そして「消費税課税事業者申告届出書」とは、免税事業者が消費税の課税事業者になるための届出書です。 フリーランスであり免税事業者である場合は、適格請求書発行事業者の登録申請書と消費税課税事業者申告届出書、それぞれの提出が必要となります。 ［手続名］適格請求書発行事業者の登録申請手続（国内事業者用）｜国税庁 ［手続名］消費税課税事業者届出手続（基準期間用）｜国税庁 適格請求書発行事業者の申請時期について 適格請求書発行事業者の登録申請は、すでに開始しています。 フリーランスとして2023年以降も活動の継続を考えているなら、制度がはじまる2023年10月よりも前に適格請求書発行事業者としての登録を検討しましょう。 インボイス制度によって予想される負担と問題 インボイス制度が始まった時に、フリーランスエンジニアに予想される負担と問題は二つあります。 一つ目の問題は、先に述べた通り免税事業者であるフリーランスエンジニアに発注した取引先企業が、仕入税額控除を適用できないことです。 仕入税額控除ができなければ、その金額は企業にとって損失となります。 そうなると他の仕入税額控除ができる企業や、フリーランスエンジニアに仕事を依頼する企業が増えることが予想できます。 企業は仕入税額控除ができないフリーランスに業務を依頼するよりも、企業に依頼した方が有利になるからです。 これはつまり免税事業者のフリーランスエンジニアはインボイス制度がはじまることで、受注できる仕事量が減る可能性が考えられます。 二つ目の問題は、元々の免税事業者がフリーランスとしてインボイス制度対応のために消費税課税事業者となった場合、課税売上高が1,000万円以下でも消費税の納税義務が発生することです。 仕入税額控除が適用される事業者となって、企業との取引がある程度確保できたとしても消費税課税事業者となれば、消費税の支払いが義務化されます。 仮に年間課税売上が600万円程度でも、消費税の支払いが発生することになります。 免税事業者であればこれまでは消費税も売上とすることができたわけですが、消費税の支払いが必要となった場合は消費税分の売上が下がるのです。 また、消費税支払いのために経費計算も煩雑になるという負担も発生します。 このような問題があることから、フリーランスとして免税事業者である場合、消費税課税事業者になるのかどうかは慎重に判断すべきだといえるでしょう。 参考：国税庁「適格請求書等保存方式の導入について」 インボイス制度のために今から準備できること フリーランスとしてインボイス制度のために今からできることの一つは、ある程度売上を確保できる状況をつくることです。 課税売上高が1,000万円を超える状況をつくることができれば消費税課税事業者となるため、インボイス制度対応における「消費税課税事業者申告届出書」の提出が不要となり、必要な手続きが少なくなります。 また一定の売上が確保できるなら一人社長として法人化してしまうという選択肢もあります。 そして消費税課税事業者となった場合は経費計算が煩雑になるため、経費管理が簡単になるツールや会計ソフトの導入も検討することが大切です。 もしくは、自分で取り組んでいる経費の管理を税理士に任せるという判断も有用です。 フリーランスは経理担当が常駐する企業とは異なり、経費管理も自分自身で取組むことが一般的だからです。 会計ソフトの操作についても今から慣れておけば、インボイス制度開始後の経理業務の負担を減らせることが期待できます。 インボイス制度開始前にエージェントの利用を検討してみる ここまでインボイス制度について解説してきましたが、それでも免税事業者・課税事業者どちらを選ぶべきか決めきれない……という方もいるでしょう。 そんな時は、フリーランスエージェントの利用を検討してみるのもひとつの手段です。 エージェントによっては、インボイス制度が始まる際に補助制度の導入や、キャンペーンの実施をすることが予想されます。 インボイス制度開始に伴ってテクフリでは、以下の対応を実施します。 課税事業者になる方：2割特例の消費税額の一部等を単価アップ 免税事業者を継続する方：今までの報酬を維持 参考：【PRTIMES】インボイス制度による収入減少分の「テクフリ」対応について まとめ ここまで紹介してきたようにインボイス制度がスタートするのは2023年10月ですが、その時期を迎えるまでにどのように活動するのかを決めておくことが大切です。 免税事業者からインボイス制度対応として消費税課税事業者になるためには、書類の申請など前もって準備することが必要になるからです。 また2023年10月が近くなれば既存の取引先からはフリーランスとして課税事業者になるのかどうか、確認が入ることが予想できます。 免税事業者だったとしても引き続き依頼を継続してもらえるのかどうか、既存の取引先とコミュニケーションをとっておくことも大切です。 こういった納税制度への対応を示すことはフリーランス・個人事業主としての信頼にもつながるからです。 免税事業者のままの方がいいのか、消費税課税事業者になった方がいいのかは取引先の意向や年間売上高など個々の状況によって異なります。 また、テクフリアンバサダーのくるみさんと、税理士の脇田弥輝先生による対談形式で、さらに詳しくインボイス制度について解説した記事もございます。もっと正しく理解したい！という方は動画もございますので、是非ご覧ください。 テクフリがインボイス制度を徹底解説-テクフリアンバサダーくるみ＆脇田弥輝税理士対談- インボイス制度への対応はできるだけ早い段階から検討して、最適な判断ができるように準備することをおすすめします。

エンジニアのテクニカル・スキルとは “カッツの3能力”、“カッツ理論”というものをご存知でしょうか？ マネージャーに必要なスキルを三つに大別したもので、ハーバード大学のロバート・カッツ教授が1955年に提唱しました。 非常に有名な理論のため、その紹介サイトや解説書には事欠かないですが、有名であるが故に、どうしても一般論的になりがちです。 もっといえば、エンジニアは“カッツの3能力”をどのように理解し、どう活かせば良いのかが、具体的に紹介されている資料は少ない、と感じていました。 そこで今回は、エンジニアに重点を置いて、“カッツの3能力”を具体的に見ていきたいと思います。 ということで、“カッツの3能力”で指摘されている能力を1つづつ見ていきたいと思います。 まず1つ目の能力は“テクニカル・スキル”になります。 “テクニカル・スキル”とはカッツ理論によると、“特定業務を遂行するために必要なスキル”と紹介されていますが、エンジニアにとっての“テクニカル・スキル”とは、文字通り、エンジニアとしてのテクニカル・スキルです。 具体的に言えば、プログラミング・スキルであったり、デザインパターンやフレームワークの知識、基盤設計能力やシステムテストの計画能力などもあります。 もう少し乱暴な言い方をすれば、担当者として仕事を任せてもらうために必要なスキルと言えるのかもしれません。 独立を考えているのであれば、最低限、自分のコアスキルといえる分野においては、上位者の指示がなくても単独で仕事を進められる程度のスキルは必要でしょう。 また、今まで日本のエンジニアはどちらかというと、“ある分野に特化したスペシャリスト”タイプが多かったですが、近年は、フルスタックエンジニアという言葉が話題になるように、コア分野以外においても活躍できる“ジェネラリスト型のエンジニア”が好まれる風潮があります。 コアスキルはコアスキルとして知識を深めるのも大事ですが、コアスキル以外の周辺スキルにおいても、知識を深める必要性が増しています。 フリーランス案件を探す エンジニアのヒューマン・スキルとは “ヒューマン・スキル”とはいわゆる対人能力です。 もう少し具体的に言えば、コミュニケーション能力や交渉力、プレゼン力、働き掛けるスキル、それからリーダーシップ力などになっています。 システム開発においては、プロジェクトマネージャーを筆頭とした開発に携わる要員だけでなく、発注者(クライアント)やシステムの利用者(ユーザー)など、さまざまな関係者が登場します。 その様々な関係者と上手くやっていくためには、それ相応のコミュニケーション能力が必要です。 エンジニアの中には「コミュ障(コミュニケーション障害)だからエンジニアになった」と、自嘲半分で口にする方がたまにいますが、私に言わせればコミュ障はエンジニアになれません。 独立を考えるエンジニアであれば、チームリーダーとしてメンバーをまとめたり、あるいは上流工程にアサインされて、クライアントの担当者との打ち合わせに参加するなどの経験を持っている方も多いでしょう。 もちろん、それら現場での“ヒューマン・スキル”も重要ですが、独立を考えているのであれば、現場で使う“ヒューマン・スキル”だけにしか意識が向いていないと、少々、辛いことになるでしょう。 なぜならば、独立してフリーランスとなると、自分で仕事を取ってくる必要が出てくるからです。 仕事を得るために必要な“ヒューマン・スキルスキル”は営業的なものであり、エンジニアが案件の最前線で使われる“ヒューマン・スキルスキル”は、重なる部分も一部あるでしょうけれど、おそらく異なったものとなるはずです。 どうやれば現場に入れるか、もっといえば案件にアサインしてもらえるか、という観点に立った時、もっとも必要となる“ヒューマン・スキルスキル”は人脈を広げるためのスキルでしょう。 あるいは、仕事を紹介してもらったり、面接で有利に立てるように資格を取得するなどのセルフブランディングを行うスキルも大切になります。 エンジニアのコンセプチュアル・スキルとは “コンセプチュアル・スキル”とは、概念化能力とも言いますが、抽象的に物事を考えることができる能力です。 あまり、ピンとこない方が多いと思うので、さらにかみ砕いていえば「物事の本質を見抜き、似た事例で得た知見を応用して活用できる能力」とでも説明すれば良いでしょうか。 ロジカルシンキング（論理的思考）、クリティカルシンキング（批判的思考）、多面的視野、知的好奇心、俯瞰力、先見性などが“コンセプチュアル・スキル”の具体的な発揮例となっています。 ロジカルシンキングや知的好奇心、先見性などは、システム案件の現場でも必要と良く言われるスキルですが、“ヒューマン・スキルスキル”のときと同じで、やはり、待ちの姿勢でも仕事を得られるサラリーマンと、積極的に仕事を取っていく必要があるフリーランスでは、スコープが異なります。 案件内でエンジニアとしての“コンセプチュアル・スキル”はもちろん必要ですが、案件以外のところ、どうすれば仕事を得られるか、案件にアサインしてもらえるか、という部分についても、“コンセプチュアル・スキル”を発揮させる必要があります。 独立エンジニアにとっての各スキルの必要比率について考察 すでにご紹介した通り、 “テクニカル・スキル”、“ヒューマン・スキル”、“コンセプチュアル・スキル”という3つのスキルはいずれも重要なスキルです。 しかし、敢えて、独立したエンジニア向けに3つのスキルを重み付けすると、 “ヒューマン・スキル”が一番重要で、“コンセプチュアル・スキル”、“テクニカル・スキル”の順に重要度が下がるように感じています。 “テクニカル・スキル”が一番じゃないの？ と言われそうですが、いくらエンジニアとしてのスキルが高くても、“ヒューマン・スキル”が低くてうまく人間関係を築けず、有り体にいえば嫌われ者になっていた人に対して、契約改定時に「つぎも来て欲しいので、ぜひ、契約を更改しましょう！」と声をかけるクライアントはいるでしょうか？ また、“テクニカル・スキル”というのは、3つのスキルの中で、もっとも向上させやすいスキルになります。 プログラミング能力などのITスキルの多くは、基本的には学校の勉強と同じで、知っているか、知らないかの問題であることがほとんどです。 ウィザードと呼ばれるような天才エンジニアの仲間入りを目指すためにはセンスが絶対に必要ですが、普通に業務で使う分には、センスはあまり重要ではありません。 もちろん、知らないよりも知っている方が良いに決まっていますが、その気になれば、未経験のプログラミング言語を使うことになっても(“コンセプチュアル・スキル”を駆使して、他の言語の経験を生かしながら)、現場で知識を習得して、活躍することだって可能なのです。 そのため、“ヒューマン・スキル”、“コンセプチュアル・スキル”、“テクニカル・スキル”の順にしています。 さらに敢えて、この三つのスキルの重要度を数値で表すとすれば“ヒューマン・スキル”50％、“コンセプチュアル・スキル”30％、“テクニカル・スキル”20％といったところでしょうか。 まとめ：実体験に基づくナレッジへ 今回は独立を目指すエンジニアの方を主なターゲットとして、“カッツの3能力”についてみていきました。 カッツ理論は素晴らしいものですが、あくまで理論でしかありません。 実際の生活や業務に役立てるためには、カッツ理論について理解を深めつつ、実体験に基づくナレッジへと昇華していく必要があります。 この記事が、そのきっかけになると幸いです。 フリーランス案件を探す