車輪の再発明とは、既に存在する技術を流用せずに一から再開発するようなシステムエンジニア業界の行いを言う。人類で最も有用な発明になぞらえて揶揄しているわけだが、さてこの行いの良し悪しはインフラSE的に如何なものか。

流用モデルが多いケース

インフラエンジニアとして、富士通・Oracle社のSPARCサーバにSolaris OSとミドルウェアの設計、導入作業を長年やってきたが、ニッチな市場であるため案件が集中しコンスタントに類似構成の仕事が多い。

設計書や導入作業手順書に関してはほぼ流用を続けていて、新規で設計しなければいけないものがあるパターンが稀で、ほとんどの場合は既存の資料のアップデートで済んでいた。我々のチームに発注することで顧客もドキュメント生産コストを抑えることができ、実績もあるため正確な仕事を期待できていた。作業の勘所もある人間が作業するので、致命的なミスなどはゼロに等しかった。

これを他社に依頼すると広義の意味で所謂「車輪の再発明」が発生し、製品仕様のインプット工数、ドキュメントの新規作成工数、作業ミスのリスク増が発生する。顧客としては、出来れば専門家に依頼したいと思う事は自然だろう。

新人技術者の教育の面でもメリットがあり、ほぼほぼ実績のある作業手順書等を用いることで高度なサーバ構築作業を、産みの苦しみなく手動実行することができ、先輩について実作業経験を積むことが早期にできる。イチから勉強しこの域に個人で辿り着くことは非効率的で、短時間でまずはサーバを構築したいといったケースに向いていた。

流用モデルが少ないケース

SEとして長期のSI案件に従事すると、こういった経験を新人に積ませることが難しい。基本的にユニーク構成がほとんどで、要件定義書から移行手順書まで応用問題のオンパレード。となると新人技術者には自力でほぼ介入不可能な領域だ。全行程の中で、構築作業の期間は一瞬であり、積める経験のスケールは広いがボリュームが少ない傾向に陥ってしまう。個人的に「こなした数」が「センス」の成長につながると考えているので、社員の技術教育には不向きなのかもしれない。

インフラエンジニア界隈では導入作業のコード化で、今後、より頻繁に流用度が増すだろう。車輪の再発明を良しとするのは、学習・研究初期段階でのインプットとして、既存のコーディングや設計等を振り返る場合。問題によっては答えがあった方が勉強しやすいケースもある。

ドキュメントレス

仕事として「なぞる」行為は再利用を基本とし、イチから作成の頻度は勉強目的以外では極力減らしたいものである。とは言え実際には、車輪の再発明は多く見られるようで、資産に該当する類は共有が難しい。ベンダーオフィシャルは不必要に情報量が多く汎用性が低く、信頼性の高い資材は経験のある企業に依存してしまうからだ。

かと言って、共有が難しいドキュメントを根絶する事は理解が得られないのが現状。将来的にDevOpsの思想浸透が鍵か。