この業界で仕事をしていると、日々本当に困ることが沢山あります。
その中でもかなりプライオリティの高い共通問題としては、ドキュメントが整備されていないということではないでしょうか。
プログラムやサーバーの設定については、いきなりコードを書いたりコマンドを打ったりせず、必ず事前に設計という行為をします。
設計とは、「作成、変更した際の影響範囲を明確にし、コードを書く際の考え方と方針を明確にする」行為のことです。
予め断っておきますが、「設計書を書く、修正する」ことが設計ではありません。
設計した結果をまとめるのが設計書です。
同じ人がずっとメンテナンスするならその人の頭の中だけで良いかも知れませんが、エンタープライズ(企業向け)システムにおいては、仕事が属人化することは既に想定外です。
第三者が見ても、どうやって設計したのかがわかるように、今後追加変更をしたい時にはどうやって手を入れれば良いか、ドキュメントに記載しておくのが鉄則。
でも、業界を見渡すと、出来ていない会社がいかに多いことか。
業界人なら、「あるある」という声が聞こえて来そうです。
では、そもそもどうしてこんな当たり前のことが出来ないのでしょうか？
僕なりに分析した結論は、以下の通りです。
1. そもそもコーディング作業が好きな人が多い
この業界でエンタープライズの仕事をするということは、建設現場の仕事と何ら変わりありません。
つまり、「人と協力して決められた手順で作業する」ということです。
でも、プログラミングが好きな人は、大抵自由にコードを書いて好きなように動かしたいから、この仕事を選んでいることが多い。
つまり、規律よりも創造性を仕事に求めており、なるべく独自のコードを書きたいという欲があるのは事実だと思います。
しかしながら、エンタープライズシステム開発の現場では、その欲はあまり発揮する余地はありません。
なぜならば、独自性より安全性を重視してコーディングするからです。
アートではなく、工業製品なのです。
独自なコードでは、他の人にはわかりません。
つまらなくても、分かりやすいコードが求められます。
工業製品という認識を持った瞬間、設計書などのドキュメントや手順書、方針書が必要だという思いに至るのでしょうが、そもそもその意識が乏しいことが、ドキュメントを軽視した現場が出来る根本原因なのかな、と個人的には考えてます。
だから、システム開発のSEとしてのスキルを満たす条件は、この背景を正確に理解し、ドキュメントの重要性を認識し、精度の高いドキュメントを作成出来ることです。
2. 納期重視で品質確保の考え方が薄い
システム開発現場にありがちなのは、ロクに仕様も決まらないうちに「見切り発車」せざるを得ない状況になり、設計やコーディングをしている際に、ユーザーから仕様変更が入り、更に工数と手戻りが増えるという悪循環です。
そもそもウォーターフォールの開発方式が既に時代にそぐわない部分は出て来てますが、品質確保を考えると、しっかり工程ごとに「立ち止まって考える」時間が必要です。
でも、納期が差し迫って来ると、普通のプロマネがやることは、「ショートカット」です。
大抵、間に合わせるために、本来必要な「何か」を飛ばします。
そして、重大なバグを潰せずにリリース前にストップがかかったり、運悪く本番運用してから発覚し大きく信用を失うという失態を繰り返している現場は、現実的にかなり存在しています。
この失敗を繰り返さないためにも、設計書などのドキュメントで考え方を確り整理し、「立ち戻る」ことが出来れば、最悪手戻りが発生してもある時点までの品質確保は出来る可能性が高くなります。
でないと、一からコードを調べて影響範囲を確認するというデスマーチコースが待ってます。
必要なドキュメントを作成することは、自分たちの身を守ることでもあるのです。
3. コミュニケーションが苦手
上記2つをクリアしても、決定的なスキルベースとして、コミュニケーションが苦手な人がエンジニアには多いのが実態です。
それがどうしてドキュメントの問題になるかと言うと、ドキュメント作成の前提に立ち戻る必要があります。
ドキュメントを残すということは、考え方を整理して紙に落とすということです。
後半の「紙に落とす」という行為の前に、「考え方を整理する」という、重要なフェーズがあることを見落としているエンジニアはかなり多いと思っています。
そもそも、「紙に落とす」のは、「誰が見ても考え方が分かるため」なのです。
だから、単にドキュメントを作成すれば良いというものではなく、確り課題を議論し考え方を擦り合わせた上で、実施しないと「紙に落としても分からない（笑）」という、ホントに笑えない状況になります。
では、なぜ考え方を整理出来ないかと言うと、そもそも議論やコミュニケーションが苦手な人が多いので、「話し合うくらいなら手を動かした方が早い」と思ってしまうのです。
これは、まさに属人化の大きな温床です。
マネジャーは、この文化を廃除しなければ組織化は進みません。
だから、システム開発のSEとして優先度が高いのは、実はコミュニケーションスキルだと考えてます。
いかがでしょうか？
僕は、日々のシステム開発現場のプロマネをしながら、これらの点について本当にリアルに痛感しています。
こうした背景があるために、システムベンダーはシステム開発のプロと見做されず、システム化案件はコンサルティングファームと一部大手SIerの独壇場なのです。
彼らは、少なくとも上記３点のリスクを充分熟知した上で、先輩から後輩へ厳しく指導とノウハウ継承が行き届いています。
今回のテーマは、主に中堅ソフトハウスが抱えている問題です。
そういう意味では、当然ながら中堅ソフトハウスから人材を調達(発注)する際にも、考慮しなければならない点です。
なので、中堅ソフトハウスの実力を見極めたいならば、ドキュメントの質を見ると明らかです。
キチンとドキュメントに対するノウハウがある会社がつくるドキュメントと、急場凌ぎのドキュメントは全く質が異なります。
忙しいシステム開発現場でつい忘れ去られがちになることですが、ドキュメントを整備するだけで、品質が圧倒的に向上するのは間違いないと思います。
古き良き根性論に頼らず、戦略的に論理的にバグを減らす努力をしてみませんか？
本日も最後までお読み頂き、誠に有り難うございました！
