生産性をあげるのはリモートワークかリアルオフィスか
最近、自由な働き方の一つとして、リモートワークが話題になっています。
実際リモートワークで生産性はあがるのでしょうか?
リモートオフィスのメリット
通勤時間が無くなる
私は、片道1時間程度の通勤時間がかかっています。
もしリモートワークをすれば、1日2時間が浮くことになります。
一日平日10時間働くとして、20%程度生産性がUPする計算に。
オフィスの賃料が安くなる
立地にもよりますが、省スペースになるためオフィスの賃料が安くなります。
一人あたりのオフィス賃料が10万だとして、給与が50万だとすると、ざっくり20%程度のコストカットになります。
離職率が減る(かもしれない)
介護・育児や家庭の事情で、社員にとって家を離れたくない時期は発生するものです。
そんな時、優秀なエンジニアの離職率が減るかもしれません。
差し込み(集中の妨害)が減る
エンジニアにとって差し込みは致命的な生産性低下をもたらします。来客・営業電話・雑談等々の差し込みが減ることで生産性が上がります。
リモートオフィスのデメリット
アイディアが生まれづらくなる
新規事業等のアイディアは生まれづらくなるでしょう。
アイディアは情報交換から始まる思いつきから生まれることが多々あります。
作るものが決まっていて、アイディアはいらない場合はデメリットでは無いかもしれません。
エンジニアの成長が遅くなる
新しい言語やフレームワーク・プロジェクトでは、変な所で詰まったりします。
そんな時、気軽にコミュニケーションできる方が、詰まりは少なくなり、エンジニア同士の相互教育が進みます。
リモートワークでは、そのような効果が薄れます。
結果的にどっちがいいのか?
会社の状況によるかと思いますが、
うちの会社の場合、
・アイディアがどんどん出て欲しい
・一人一人のエンジニアのパフォーマンスをどんどん上げていきたい(しかも若いエンジニアが多い)
という点が大きいため、リアルオフィスのほうがメリットがあると感じています。
「システム開発オフショアに仕事を取られる」は恐るるに足らず
最近、システムエンジニアの仕事はオフショアに取られる、などという論調を良く聞くが、普通のエンジニアの皆さんは全く恐れる必要はないと思う。
但し、あくまで「普通の」エンジニアのみに限った話になる。
あんまりいない普通のエンジニア
「普通の」エンジニアとは、チーム内で正の仕事をして、プロジェクトを納期内に完成する能力のあるエンジニアを指す。
世の中には、チームで負の仕事/ゼロの仕事をするエンジニアが数多くいる。可読性の低いバグだらけのコードを生産するエンジニア、全く進捗しないエンジニア。
そういったエンジニアが生存し続けられる理屈はわからないが、実際に存在する。
プロジェクトを納期内に完成する、という条件はやや複雑になる。
人を増やせば増やす程、オーバーヘッドが生じて生産効率が落ちるというのは有名な話だ。
納期を達成するためには、一定以上の能力を持ったエンジニアが必要十分な数プロジェクトに携わる必要がある。
コミュニケーションオーバーヘッドとエンジニアに求められる能力の関係
ここで、オーバーヘッドが少ないエンジニアは、求められる能力も下がる。
日本語が堪能で、オフィスに出社できるエンジニアをチームに追加した場合と、東南アジアのどこかの国にいて、文化的背景が異なり、英語しか話せない(しかもネイティブでない)エンジニアを追加した場合では、オーバーヘッドは全く異なる。
これは、僕の経験だが、
チャットのレスを半日も待たなければいけない、日本人であれば当たり前に理解できる概念の説明に2時間かかる、等々、オーバーヘッドは想像以上に大きかった。
ぶっちゃけ安くない
ここまでで、海外エンジニアに開発を依頼する際は、同じ仕事を任せるためには、日本人エンジニアよりも高いレベルの技術力(と稼働)が必要となることをご理解頂けたと思う。
しかし、海外エンジニアはぶっちゃけ安くない。
odeskというサービスをご存知だろうか?ワールドワイドなクラウドソーシングのプラットホームである。
例えば、モバイル・アプリエンジニアで、ある程度高いレベル(Expert)の人を探そうとすると、相場が33ドル/時以上となっている。フルタイム換算すると、53万円。
グローバル化によってエンジニアの市場機能は最近ますます整ってきている。世界のエンジニアの給与は上がっていくと見ていいだろう。
こちらの対応コストや、リスクを考えると、果たして見合うだろうか。
とはいえ活用の仕方はある
エンジニアの需給が崩れている今の状況下では、金を積んでも日本ではいいエンジニアが獲得できない、というケースもある。そういった場合には、オフショアで高額報酬を払ってでも良い人材を引っ張ってくるという使い方はありそうである。
いかに会社のキャッシュ・利益を増やすか
ちょっとした自己紹介と、問題意識
初めに私の会社は、
・めっちゃ小さい・若い会社
・受託開発とか自社サービスとか
・メインの売上はまだ受託開発
てな感じです。
そんなわけで、エンジニアでありつつも、人材獲得・工数/原価管理・要件定義・営業、、、とやることが沢山あります。
小さくて若い会社なので、課題は山積です。
必然的に課題の優先順位付けが重要となります。
(もちろんでかい会社でも同じことですが、小さい会社は課題の優先順位づけを間違うと即死しかねないので)
そもそも何が目標か?
優先順位をつける前提として、そもそも何を目標とした課題か?と、考えると
・キャッシュ・利益
・理念の実現
が、会社の大目標となると私は思います。
問題を単純化するため、ここではキャッシュ・利益に焦点を絞ります。
それでは、いかにして会社のキャッシュ・利益を増やすか?
「ゴール」という本を読んだことがあるでしょうか?
工場の生産性向上のお話です。
要点としては
・工場のキャッシュ・利益を増やすために何をすればよいか?
・ボトルネックが、売上を決めるため、ボトルネックの生産性を改善すること以外の努力は、売上を増やす目的にとっては無意味
・コスト削減も、従業員をクビにできないんだったら無意味。コスト計算方法(指標)はキャッシュ・利益を増やす目的に沿っていなければ有害
というお話です。
この、お話では、ある装置がボトルネックとなっていて、その装置の稼働率を上げること
で工場をたてなおすというストーリーになっています。
システム開発に工場のアナロジーは使えるか?
「ゴール」のストーリー中の問題設定は非常に単純です。
果たしてこんな簡単なモデルをシステム開発に持ち込むことができるのでしょうか?
結論としては、アナロジーが使えると思っています。
しかし、システム開発と、「ゴール」に登場する工場の間には違いがあります。
エンジニアは複数のスキルを持っています。凄いエンジニアの中には、営業・要件定義・設計・実装・テスト全てができてしまう人もいるでしょう。
特定の作業しかできない、工場の機械とは違います。
ステップ1 まず、アサインの最適化
システム開発は工場よりももっと混沌としています。
整理のために、受託のスマフォアプリ開発を前提として工程をかんがえてみましょう
営業・企画→要件定義→設計→機能大枠(APIやDBの部分等)実装→細かい処理実装→デサイン等の入れ込み・表示調整→出荷
※テスト・修正は各工程に含みます
と分けると、熟練エンジニアは設計〜デザイン等の入れ込み・表示調整までの工程にアサイン可能、
一方開発を始めたばかりのエンジニアは、デザイン等の入れ込み・表示調整くらいしかできない、となります。
開発を始めたばかりのエンジニアに、機能の大枠実装を任せた場合、汚いコードで工数は増大してしまうでしょう。
少々単純化した上記のような前提だと、スキルの少ないエンジニアからタスクを割り当てて行くと、アサインの最適化ができます。
ステップ2 調達が容易なエンジニアを獲得する
すると大抵の場合は、熟練エンジニアが足りなくなります。
エンジニアチームの状況によっては、熟練エンジニアはデザイン等の入れ込みにまで入り込むことになり、回せる案件の量は頭打ちになります。
各工程で、人材調達の難しさは異なります。
デザイン等の入れ込み・表示調整であれば、IDEの使い方を教えれば、比較的短期間でできるようになります。
一方、API連携やDB設計・クラス設計がまともにできるようにするには、長い時間を要します。
調達が容易な(育てやすい・獲得しやすい)工程のエンジニアを捕まえることで、熟練エンジニアをより、難しい工程に集中させることができます。
ステップ3 熟練エンジニアを獲得する
人材を獲得することで、熟練エンジニアは難しい工程に集中できるようになります。
しかし、熟練エンジニアの更なる獲得に成功しなければ、熟練エンジニアがボトルネックであり続けます。
なぜならば、熟練エンジニアは代替不可能だからです。
このステップの状態では、設計→機能大枠(APIやDBの部分等)実装が終わり次第、速やかに残りの工程が処理され、製品は出荷されていきます。
スキルの比較的少ないエンジニアの稼働はあまり激しくなく、時には仕事が無いこともあります。
ステップ4まで辿り着いた場合、熟練エンジニアを育てるか、魅力的な報酬で熟練エンジニアを引っ張ってくる必要があります。