建設業界とIT業界の差異からアーキテクチャを考える
はじめに
おはようございます。Kogawaです。
これは設計・アーキテクチャ Advent Calendar 2018の15日目の記事です。
月日が経つのは早いもので、14年ほどSIerで働いてました。
大きなSIプロジェクトにも携わりましたが、順風満帆に終わることは珍しかったです。(*1)
IT業界はまだまだ若い業界なので、他業種との差異から吸収できることも多いと思います。
なかでも会社間の関係や構造が似ている、建設業界との差異についてよく考えを巡らせます。
引き合いに出されがちな話と思いますが、一度私なりに纏めておきます。
SIerやユーザ企業の組織や文化に対する視点が多めです。
建設業界にいた経験は無いので、外から見た所感であったり、書籍などから得られたことを基礎として書いています。
非常に狭い視点からの記述なので、実態は違うよ、な情報は是非とも教えてください。
どういった点が差異となるのか
差異が大きいと感じる部分を下表に纏めました。
| 観点 | IT | 建設 |
|---|---|---|
| 許可制度 | 技術面での許可制度は無い。基準などの制約が緩やかなシステム要求事項として存在する。 | 29種類の工種(*2)別に仕事が別れており、工種ごとに建設業の許可が必要となる。 |
| 資格 | 資格は存在するが業務上必須では無い。(入札に対する必要資格などの要件は存在する) | 建築士の資格種類に応じて可能な業務範囲が異なる。(*3) |
| 技術変遷の速度 | (比較的)早い。基礎となる技術要素は大きく変わらないが、陳腐化の速度は早い。 | (比較的)緩やか。 |
| ライフサイクル | サービス自体は10年以上続くが、アーキテクチャは5-6年程度で見直される。 | 少なくとも10年以上。(内装の変更等はある) |
組織構造に対して考える点
先の表のような差異から、どういった組織が望ましいのかを考えます。
ITエンジニアは多才であることを要求されるように思います。
特にSIer界隈で働くシステムエンジニアは、本来エンジニアがすべきタスク以上のタスクが多数割り当てられ、かつ仕事が一部の人員に集中しがちです。
先の表の29工種ほど細かく無いと思いますが、システムのフェーズや得意分野に応じて分業が進むことで、タスクの集中が発生したとしても緩やかになり、各々の得意分野を磨けると考えます。
一方で人手不足に起因して、少ない人数で回していくことが、多くの組織では求められると思います。
各エンジニアの得意領域を押さえつつ、複数の案件/プロジェクトやプロダクトへアサインしていくような組織が現在の解と考えられます。
システムアーキテクチャに対して考える点
目線をシステムアーキテクチャに変えます。
技術変遷の速度が早く、要求に対する実現方式も数多く存在するため、システムの姿が一定に定まりません。
長期に渡るプロジェクトでは、提案時点では先進的と謳っていたものが、リリース時点では陳腐化しているような状況もよくあります。
周知のことではありますが、ITシステムは要求事項の変化ならびに関連技術の革新により、短期的な変化が求められます。
この点がITシステムと建築物との一番の違いと思います。
そういったことを念頭に置くと、変化を受け入れ易いシステムである必要があります。
"変化に強いシステム"については、数多の情報が存在すると思いますが、個人的には次のような要素が変化に強いと考えます。
- SaaSやPaaSなどの積極利用(機器手配などのリードタイム排除)
- 疎結合化
- システム状態の追跡性
なお建築においても、壁や柱などの骨格と内部の部屋構造を個別に作ることで、リフォームやリノベーションをし易くする工法や、都市計画においては人口変動や周辺都市環境などの変化に対応していくことが求められるなど、ライフサイクルが長命であるが故に変化を意識することが数多くあるようです。
システム要求に対して考える点
組織ともアーキテクチャとも異なるのですが、システム要求事項について考えます。
SIerにおいては、ユーザ企業のシステム要求を一緒に考え、RFI/RFPなどに仕立て、受注から実装を経て、運用に入っていきます。
ユーザ企業側の内製化が進んでいけば、SIer不要論もより活発になると思いますが、ユーザ企業側のエンジニア確保などを考えると、あと10年くらいは関係が続くように思います。
ユーザ企業側は実現したいことやシステム要求を提示する努力が必要ですし、SIerからの提案を鵜呑みにしない判断力も必要です。
SIer側も真にユーザ企業へ必要なことを提示し、一緒に考える姿勢が必要です。
建築などの目に見えるものと違い、ユーザからすると仕様理解への差や、仕様変更の要求が簡単に発生しがちです。
この点は人間同士で仕事する限りは、ゼロには出来ないと思います。
ただ建築士の方が模型を作るように、プロトタイプの提示などをすることで溝を埋めていく努力は可能です。
SIの世界では責任の所在が時折曖昧になり、その文化からウォーターフォール開発が根強いように感じます。
要求整理や設計はもちろん重要ですが、実際に作ったものを横において、要求確認や設計をする方が確実に高精度です。
このような進め方が、双方に合意される文化や体制が重要と考えます。
さいごに
すみません。設計・アーキテクチャ Advent Calendar 2018の内容に合うか疑問な内容になってしまいました。
考えていたことを文章化する機会と捉えて、枠を利用させていただきました。
当たり前の結論ではありますが、文章化しておくと、次に知りたいことなどが明確になって良いですね。
これが初投稿でしたが、今後は技術面の記事も発信していきたいと思います。
SIer界隈を含めIT業界がより良い方向へ進むことを初詣で祈ってきます。
参考資料
*1 順風満帆にいくと組織上注目されず、事故ってからの火消しが尊ばれる、といった悪習もあったように思います・・。
*2 業種区分、建設工事の内容、例示、区分の考え方
http://www.mlit.go.jp/common/001209751.pdf
*3 建築士の種類と業務範囲
https://www.jaeic.or.jp/shiken/1k2kmk/type_of_architects.html