エンジニアの条件はプログラミング言語と同じくらいドキュメント力も大事

2020/12/10エンジニアスキルアップ

『言語は何が得意ですか？』

『javaを○年、PHP○年、Rを○年やってます。』

『かなりやってますね～、フレームワークは？』

『SpringとStrutsとRailsと…仕事の機会はなかったのですが、独学でJSFとPlayは使ってます』

『開発経験豊富なあなたを採用します！！』

すごく端折っていますが、大体のエンジニアの面談で開発言語の経験が、プロジェクトの採用の大きな指標となっていることは間違いありません。何でも開発できるエンジニアが理想で、さらに生産性が高い方が望まれるでしょう。

レガシーな言語にいたっては『月に何kstepコーディングできますか？』

一歩間違えるとブラック企業のような質問ですね。最高何時間残業してコーディングしたのか？みたいな…
難易度が定量的にアピールしにくいため、量が採用の判断基準にもなっています。一方、上流エンジニアやプロマネにいたっても、プログラミング経験を聞くための質問は欠かしません。
それはそれで大事だとは思いますが…

ここ10年～20年かけて、大企業SIerはオフショア、ニアショアを進め、自社の社員はプログラミングする機会を奪ってきました。コーディングするのは下請けの会社、もしくはアジア系の会社に委託してきました。私もSIer出身なので、気が付くとプログラミングをそこそこに、設計やら、調整ごとをするポジションに。仕事を通して、自分はコーディングが得意といえるような力量が着いてこなかったと感じています。

そのような時代のなかで、プログラミングをがんばってきた方達が、人手不足となった売り手市場に高い単金で仕事できているのかと思いきや、プログラマーの地位が金銭面で向上していないのが残念でなりません。フレームワークを自作できるぐらいのエンジニアは報酬も高いのでしょうけど、業務ロジックだけであれば、フリーランスになっても単金を上げるにも一苦労なのが実態です。

プロジェクトが崩壊する共通の旋律　見積甘い⇒計画不足⇒人員不足⇒進捗遅延⇒増員⇒教育コスト増加⇒さらなる遅延のループ

私も様々なプロジェクトを見たり、経験しました。

プロジェクトが崩壊していくパターンとしては、見積どおりのスケジュールで作業ができず、人手不足で進捗が遅延し、後手に回って増員してもさらに遅延が広がり、リカバリできないという図式です。

私も数億円単位のプロマネを経験しましたが、１年以上かかる見積りを半年に捻じ曲げて対応させられたときは、多忙を極めてメンタルが壊れてしまいました。

結局１ヶ月リリースを遅延し、商用リリースまでこぎつけましたが、運用が止まるトラブルが頻発し、落ち着くまでリリースから半年かかりました。結果、安定稼動するまで開発着手から１年かかっており、見積どおりの結果となりました。その間、思うように売上が伸びていかず、様々な人が迷惑をこうむって、難癖つけてくるなど、無茶して開発しても喜んでくれる人は極少という結果で散々でした。

発注側に至っては、計画を無理強いさせたにも関わらず、『安定稼動しないのは、システム開発が悪い』みたいな顛末で。こんな仕事を経験すると、辞めたくなるのも当然です。

話が脱線しましたが、無理な計画のなか、何とか遅延を解消するために、（本意ではないですが）さらなる増員を実行しました。

プロジェクトマネージャ経験者なら理解できると思いますが、既に遅延しているプロジェクトに対して、プロジェクトの状況を知らない、開発の作法をしらない新規参画者を増員しても、遅延は大きくなるばかりです。やはりプロジェクトのことを理解していない人にいきなり開発を任せることはできず、既存のＰＪメンバが教育する期間・コストが費やされます。

本当は既存メンバも開発に専念してほしいところに、プロジェクト責任者が無作法に人員をかき集めてしまうため、放置することもできないから、先任者は教育ばかりさせられて、開発ができないという状況になります。結果、さらに進捗が悪くなるというオチにたどり着きます。

プロジェクトが遅延したときの対処法は、リリース時期を延ばすか、スコープを縮小しか有効な手立てはありません。増員はやってはいけない罠だと個人的に思います。
ただ、プロジェクトの事情や利害関係から、増員を強制させられることも多々あるでしょう。

ここで、プロジェクトが今までどのように進めてきたかで、ケガの悪化を最小限に留める事ができる指標があります。
それは、ドキュメンテーションにどれだけ費やしてきたか…です。

プロジェクト計画書のみならず、Excel等の開発設計書もしかり、環境の情報や環境構築のノウハウをwikiにまとめるというようなものも含まれます。

新規参画メンバが導入しやすい環境は、作業品質の向上や早期の立ち上がりに貢献できます。人に聞かなくても勝手に環境を準備できるというのは、教育係も参画者にとっても精神的な負担を軽減できます。全部聞かないと進められない状況からすると、プロジェクトの進捗遅延レベルは雲泥の差です。

では、効果的なドキュメントをどう準備するか…？については、プロジェクト計画時に、遅延リスクを考慮して、どういうドキュメントが必要なのか？をメンバで検討します。ここで開発経験が豊富な人からの意見が重宝する訳です。プロジェクトの状況や集まったメンバスキルに応じて、ドキュメントのレベル感を調整し、後から参入したメンバがスムーズに作業ができるようなノウハウをまとめるように計画しておくと、短い期間でもドキュメントの環境が整っていきます。

このような状況で、ドキュメンテーションが苦手でプログラミングしかできない人に対して、スキル継承が必要な作業を割り当てる事ができないため、この作業が終わったらプロジェクトから外れるような使い方をされてしまいます。上流工程を経験したい方は、ドキュメント力が必須になってしまうことは明らかです。