私は一時期地方の開発拠点に勤務していた。首都圏で受けた仕事を開発工程だけ地方で行うビジネスモデルだ。オフショア開発は言葉の壁や中国の発展で単価上昇。地方には仕事が無い。賃金が安い。それをうまく使う戦略。
会社で実際にやってみるとなかなかうまく行っていない。いくらネットが普及したとはいえ、海外だろうが地方だろうがコミュニケーションの問題は無くならない。
photo by You X Ventures on Unsplash
1970年代初頭、アメリカの心理学者アルバート・メラビアンが、ノンバーバルコミュニケーションを語る上で非常に有用な実験結果の報告をしました。 その報告は、「話し手」が「聞き手」に与える影響がどのような要素で形成されているのか、というものです。
- 視覚情報…見た目、身だしなみ、表情（視線）など…55%
- 聴覚情報…声の質・大きさ・速さ（テンポ）…38%
- 言語情報…話す言葉そのものの意味…7%
私が担当したプロジェクトでもネットによる会議システムはあった。画質がいまいち、リアルで対面することから比べれば情報が落ちるのは仕方ない。そして地方というのは圧倒的にプロジェクトマネジメントできる人が少ない。そもそも小規模案件が主流だから首都圏ほどマネジメントの必要が無いという事情があるのかもしれない。
そんな開発拠点に私は異動した。だから異動した瞬間に炎上プロジェクト。マネジメントされていないのだから仕方ない。でもみんなプログラミングは好きだから、プログラミングが全くできない私とはWinWinの関係だ。
私が地方拠点にいたのは3年弱という短い期間だった。
それでも今まで自分が経験した事の無い業界のシステム開発を経験。下請け仕事の大変さも経験。自分にとっては良い経験となった。それが他の人も役立つことを祈っている。
ココがポイント
- リモート開発におけるプロジェクトマネジメントで必要なこと。
目次【本記事の内容】
- 1.リモート開発におおけるプロジェクトマネジメントで必要な事
- 1-1.発注者側がリモート開発をする目的
- 1-2.リモート開発拠点のエンジニア特性
- 1-3.リモート開発プロジェクトマネジメントを始めよう
- 2.まとめ
リモート開発におおけるプロジェクトマネジメントで必要な事
発注者側がリモート開発をする目的
発注者がオフショア開発やニアショア開発などのリモート開発に期待することは何か？
- 一人月あたりの人件費の削減
- 開発人財の確保
- オンサイト開発メンバーのスキル向上
１．人件費の削減
オフショア、ニアショア開発を利用する目的は人件費の削減なしには始まらない
東京だと新人でも５０～６０万円一人月あたりのコストを要求されることがある。
リーダークラスだと８０～９０万円ぐらいか。
それがニアショアだと５０万円でOKという会社がある。実は地方でもそれだけ安い人材を探すのは難しくなっている。
IT業界が全体的に好調だということだろう。しかし首都圏の会社が値段が安いからという理由だけで、準備もなくリモート開発を始めればどうなるか？炎上プロジェクトになるのは明らかだ。
２．開発人財の確保
photo by シャッタースナップ on Unsplash
IT業界全体が好調だから、プロジェクトは有るのに必要な人材があつまらないことがある。これは私が転職活動をした時にエージェントから聞いた話だ。IT業界の求人の98%は首都圏の求人である。
だから地方で仕事がなくて困っている人は一念発起して東京に行けばいい。開発経験が有るのなら2019年現在で仕事にあぶれることは無いだろう。
しかし、そうも行かない人がいる。
- 実家で介護をしなければならない
- 地方で家を買ってしまった。
- 地元が大好きで故郷に貢献したい。
そういう私も22年間東京で働いて、親の介護問題や地元への想いがたかまりUターン転職した。しかし地方だとITの仕事が無いという事も有るだろう。
そういう人たちを雇用することで首都圏の会社が不足する人材を獲得できる。しかし後述するような理由でリモート開発はトラブルプロジェクトになりがち。私は疲弊した人たちが辞めていくのを何人も目の当たりにした。人材から人財へ。リモート開発をする会社は雇うからには人財への育成責任が私はあると思う。
３．リモート開発を始めよう。
そうはいっても東京への一極集中。地方の衰退。止めなければと私は思う。日本で起こっているこれらの問題を解決する一つの解決策がリモート開発ではないか。IT業界が地方創生に貢献する。システムエンジニアの自分が社会貢献する。地方にシステムエンジニアがいるということは地方の中小企業を支えるシステムエンジニアが地元にいるということだ。
私がUターン転職して切実に思うのは地方の会社はIT化が遅れているということだ。それでも地方の人達の頑張りでなんとかなっている。でもそれもいつまで続くのか？未だにメインフレーム、COBOLで業務を続けている会社がたくさんあるのだ。
COBOLができるエンジニアだっていつまでもいない。若い人が進んでCOBOLを覚えるだろうか？メインフレーム・オフコンのプロジェクトにアサインされたいだろうか？そんな事をさせたら、せっかく入社してくれた若い人たちが辞めてしまうだろう。
地方でシステムエンジニアが生活できるようになるという事。地方の会社のIT化を支える人財になるという事。首都圏の会社にとってもメリットがあって地方のIT会社にもメリットがある。そんなビジネスモデルだと私は思うのだ。
リモート開発拠点のエンジニア特性
地方のIT会社では小規模な開発が多い。また、リモート開発もここ数年は盛んになっているので開発には強いがマネジメントやコミュニケーションが苦手な人が多いという私の印象だ。もちろん、そんなことは無いという批判も有るだろう。ただ、私が勤務した地方開発拠点がそうだったということだけかもしれない。地方にも優秀な人がたくさんいることは居ることは理解しているうえでの記載であることをご容赦願いたい。
私が地方に転勤して参画したプロジェクトもまさにそんな状態であった。みんな一生懸命開発をしている。でも首都圏で仕事を発注してくるのは百戦錬磨のプロジェクトマネージャやシステムエンジニアだ。こういっては首都圏の発注者側の人には悪いが、口でうまく言いくるめていないか？自分たちの都合のいいように地方拠点のエンジニアを使っていないか？そんなふうに私の目には写った。
地方拠点のメンバーは反論しても無駄。そんな諦めなのか真面目なのか。一生懸命プロジェクトをなんとかしようとしている地方開発拠点のメンバーを私は見た。
こりゃすごいところに来てしまったかな
当時３０代後半だった私が最年長レベル。プロジェクトに参画したら自分が全面に立つしか無いと私は決断。
リモート開発プロジェクトマネジメントを始めよう
photo by timJ on Unsplash
その日から私の試行錯誤の日々が始まった。
- 口頭だけで基幹システムのリプレースを依頼してきてそれを受けてしまっている。ドキュメントはない。
- 一ヶ月以上放置されているQA、課題管理台帳。良いからやれよという下請けを見下す発注者側のシステムエンジニア。
- 単体テストのやり方をしらない。というよりも教育を受けたことが無いエンジニア。
普通にプロジェクト管理していると有るはずの資料が無いことに私は驚いた。
さて、何から手を付けたものか。途方に暮れている暇はない。まずはメンバーに状況ヒアリングだ。
既存のドキュメントが無い
これ既存のドキュメントなくても作成できるの？私がメンバーに聞く。当然できないと答えるメンバー。依頼をしたことも無いらしい。
頼むだけ頼んでみたら「100%信頼はしないでほしい」と注意されたがドキュメント一式が発注元から送られてきた。
そこになにげに追加要望が書かれている。
と発注者側に私は問いただした。
「今の見積もりに含めてできませんかね？」
と発注者側の人が言う。私はこいつはバカかと思ったが、そんなことはできかねると冷静を装って答えるのが精一杯だ。こんな事を普段からやっていたのだろうか。
一ヶ月以上放置されているQA、課題管理台帳
私がプロジェクトに入った時に最初にチェックするのがQA、課題管理台帳。トラブルプロジェクトの場合、これが無いか放置されているかのどちらかだ。
その時はQA・課題管理台帳は作っていたが、一ヶ月以上前に起票されたものが回答期限が来ているのに放置されている。
私はメンバーを責めないように注意して聞くようにしている。
聞かなくてもわかっているのだが、念の為聞かざるを得ない。発注者側のひとが厳しい人で中々回答をもらえないらしい。
問題が山積しているのでテレビ会議でこれこれのQAの回答がまだないのだがどうなっているのか？聞いたら
「自分たちでなんとかできないのか？」
という発注者側の返事。仕様に関わることだから聞いているのだが、どうしてこういう回答ができるのか。できませんね。仕様を確認するのは発注者の責任ではないですかと喧嘩口調になってしまったのは今思うと反省点だ。
単体テストのやり方を知らない。そもそも教育を受けたことがない。
プログラマーにとって単体テストは重要な作業。作成したプログラムが仕様どおりなのかどうかを検証する作業。しかしこの重要な作業、この方法を体系的に教えているITベンダーは皆無ではないか？
かくいう私も研修期間が四ヶ月あったにもかかわらず単体テストのやり方は習わなかった。プログラム言語、アルゴリズム、マナー研修、基本設計のやり方。そういうことは習ったのに単体テストのやり方は習っていないのだ。
これでは駄目だと思ってシステムエンジニアになって２～３年目だったか単体テストについて書かれている本を読んで自習した。
下記の本は少々高いのだが、刊行が古く重版を経て今でもたまに読み返すことがあるソフトウェアテストに関する名著だと私は思う。
これは地方のIT会社に限った話ではない。東京で働いていたときもなんでこんな単体テストのやり方をするのか結合テストや本番障害の原因をたどると単体テスト不足に行き着くのだ。
私は地方開発拠点で働いたときと東京で働いていた時に様々なITベンダーのSEと話をした。単体テストについて研修を受けたことがあるのか？
驚くべきことに会社で研修を受けたことが有るという人は私を含めて皆無である。
それはテスト漏れが出てしまうのも仕方ないと私は思った。だから、新しく参画してくれる人には単体テストの基準について私はかなりの時間を割いていた。特に新規の取引先には注意した。注意しても最初のプロジェクトではうまく行かない。
うまく行かないからと言ってその会社が駄目だから契約終了だと言っていたのでは、せっかくの教育工数が無駄になってしまう。次のプロジェクトでも引き続き参画してもらい、１年ぐらいたってやっと頼りになるパートナー会社となるケースが多いのだ。
リモート開発も一回限りで終わってしまったのではきっと失敗する。東京でオンサイトで参画していたパートナー会社ですらそうなのだから。リモート開発というさらに難易度が高い仕組みで開発をするのであるから長期視点でリモート開発に取り組むことが必要なのだと思う。
まとめ
プロジェクトは一回限り。同じ条件で仕事をすることは二度とない。だからこそ面白い。プロジェクト型の仕事の醍醐味だろう。そして難しさでも有る。炎上プロジェクトがなくなることは無いだろう。でもみんなの知恵を結集すれば減らすことができるはず。私はこの記事を書きながら改めて思ったことだ。今日の自分より明日の自分はできる人。そのために今日を一生懸命生きようじゃないか。