2日連チャンの勉強会でしたが、この2つの共通点はユーザの視点でのIT活用という、ITが既に技術者だけのものではないということを感じさせる勉強会でした。
今後の展望について思うこと
従来のビジネスモデルではシステム開発と言うのは、要件が発生してから受託して仕様を顧客と詰めて(要件定義、設計、レビュー)製造(コーディング、環境作り、テスト)、受入(顧客テスト、納品)が終わった後に運用保守(トラブル対応、システム改修、ログ分析)が技術者の仕事になってました。
運用保守はシステムが動いている間続くためこちらの方を収入源としていたところが多いので、DevOpsのように開発だけやって運用保守を顧客に渡してしまう事を嫌う企業も少なくないです。
ただ、市場のニーズの変化はどんどん速くなっているのでログ分析などを外に頼んでそれをレポートにまとめてもらい(ログを収集した結果をExcelに落としてグラフ化したものが多い)それを持っていって上司に報告すると言うのは時間のロスと考えられてしまうのでしょう。
ベンダー企業のレポートも意図したものと一致しているとも限らないため、何度か再提出もよくある話です。
それならば、使いやすいツールがあればあとは自前で分析した方が速いとなればそちらを使うようになります。
運用保守にこだわる理由
開発と言うのは、実際に出来上がるまでわからないリスクの多いフェーズです。 赤字になる事も多々あり、この時点の赤字を運用保守で補うということが今までのやり方でしたし、今もそれで続けているところは多いです。
システムも一度動き始めれば5年、10年、中には40年(大型のシステムはそのくらい動いています)と使うので長期に渡り安定した収入があります。
トラブルがあれば契約によりますが、その対応で収入になる事もあります。
また、この点が最大の問題点でもあるのですが、10年動くシステムであれば、10年間新しい技術を覚える必要がないと考えるところもあります。 10年前がどのような時代かというと、
iPhoneが登場(今年が10周年)
JDKのバージョンが6(2006年リリース)
Git(初版リリース2005年)よりもSubversionが多かった、MS VisualSourceSafe(2012年サポート終了)もまだサポート内のため使われていた
Redmine初版が出たばかり(2006年)
クラウドコンピューティングという言葉が登場(2006年)
AWSでEC2サービスが開始されたばかり(2006年)
この時代で止まってしまうのもちょっと恐ろしい話です。
時代の変化
私の知り合いで、10年以上大規模案件に携わってきて抜けてきた方がいました。
20年以上前に作られたCOBOLのシステムのようですが、今COBOLでの新規案件は激減してCOBOLからの移行が主なプロジェクトになっているため、汎用機を使うような大型案件でもCOBOLとJavaを知ってる人に対する需要が増えてCOBOLだけではなかなか仕事につけないと言っていました。 10年前でもCOBOLはそろそろ無くなるのではと言われてた一方で、まだまだ使われると言う意見もありましたが、当時はまだCOBOLは年寄り案件と言われるくらい古くからのシステム開発に携わってきたベテランエンジニアの案件で金額もよく、長期間の案件で定年までこれでやっていけるという思いで就業する人が多かったようです。*1
ちなみに、私はこの歳でCOBOL未経験者です。
ただ、COBOLが悪いとか、Javaがいいとか(Javaももう20年と言う古い言語になりつつありますけど)と言うわけでなく、需要に対していつでも応じられる体制は必要かと思います。
Javaだっていつ無くなるかわからないし、そもそもプログラミングと言うものが必要ない時代も来ないとも限りません。
しかし、どんな時代でも技術の最先端というものは技術者が作り、技術者が発展させて広めていくものなのでどんな時代になっても対応できる姿勢が大切だと感じました。