技術の移り変わりってものは激しいもので、数年も経てばそのとき最新だった技術はすっかり廃れたものへとなっていたりします。
大学のときにIT業界の流れって言うのはドッグイヤーだってたとえ話を聞きましたが、10年この業界に身をおいてみたら確かに入社当初の技術そのものって随分と変わってきています。
そうやって次々と生み出される技術そのものにエンジニアとしてどうやって付き合って、それを実際の現場にどのように適用していけばいいのでしょうか。
導入効果と現場での説明
新しい技術を導入する際には、それを導入することの効果ってものを算段して示しておく必要があります。
エンジニアのエゴとしてそれが面白そうだからという理由だけでは、反って開発現場に混乱を招くだけでなく、非効率な開発というものが行われてしまいます。
技術そのものの話としては、現在の最新のサービス基盤となるシステムであっても10年前の技術で少なくとも同等の機能は構築が出来たりもします。
まぁ、そこがコンサバ派のエンジニアの新しい技術への反感を招くところにもなったりするんでしょうけど、それを導入することでより効率的なシステム開発が行えるとか、ガラパゴス化したシステムを作るのではなく、業界標準への対応などの理由が出てきたりもするわけです。
ただ、新しい技術への対応というのは初期展開時に時間がかかったりもするので、小規模なシステム開発であればわざわざ新しい要素を組み込む必要も無かったりします。
今後の保守の対応への想定や、大規模システムでの工期短縮、新米エンジニアの技術習得の容易さ（その技術に慣れた後に関しての効率化とか）、現在の技術そのものが時代遅れになっておりメンテナンスされていない場合などへのセキュリティリスクへの対応などなど、導入することによって何が変わりどんな効果がもたらされるのかって事をはっきりさせておく必要があるでしょう。
新しい技術の導入効果って言うのは、なかなか定量的な効果として計測しにくいものもあったりします。
なんせ今の現場のスタンダードな開発手法などをそのまま適用しても開発が進められるところがあったりしますので。
そういったことをさらに現場で保守的な姿勢を取るエンジニアとか、さらに現場を長く離れている（もしくはまったく経験がない）上司へ説明しなければならなかったりもするのでなかなか骨が折れたりもする作業にはなります。
また、現在では外部に優れたサービスが安価に提供されている時代にもなっているので、それをわざわざ現場に導入することへの比較と効果も示しておく必要が出るかもしれません。
新技術に精通したエンジニアと教育
新しい技術を導入する際には、その技術に精通したエンジニアというものが必要になります。
これが流行っているんだぜ！ということで導入したものの皆手探りで開発をするということでは、効率化も何もありませんし、工期に余裕があればまだいいにしても大抵の開発の現場ではそんな余裕もありません。
そして、それが原因で品質の悪いシステムが出来上がり、リリース後に不具合が頻発しては自分たちの首を絞めることにもなりかねません。
そういったことを回避するためにも、その技術に精通してその技術に関して周りへの教育や使い方に関しての基本方針を決定することができるエンジニアが必要になってきます。
教育というのは思った以上に時間がとられたりもするので、1人だけではそこに手一杯になり、本業となる開発に専念することも出来なくなるケースもあります。
OSSの技術を持ってくる場合は、ドキュメントが充実していることやコミュニティが活発化していること、その技術のこれからのマイルストンがはっきりしているなども教育への影響上、重要になってきたりします。
例えば開発の効率化という名目で新しいフレームワークを導入したとしても、初めてそれに触れる人たちはその習得には1ヶ月ほど時間がかかったりしますので、ほぼ1ヶ月は本来のスケジュールほど開発作業が進まないことになったりもします。
教育がきちんといきわたっていない場合、想定しない使われ方をしたりして品質が低下したり、後半になって大きな手戻りを生んだりしてスケジュールを圧迫することにもなります。
そういったことを手厚くフォローするエンジニアが必要になってきますし、その役割を担う人が現場にどれだけいるかってところも技術を導入する際のキーとなってきたりします。
新しいプロジェクトでいきなり新技術を導入するって事をするよりは（案件によってはそうせざるを得ない場合もありますけど）、前もって新しい技術を検証する期間とそれを習得できるような教育方針を予め作っておくことも重要になってくるでしょう。
エンジニアの立場としては、常に何らかの案件でスケジュールを終われてたりもしますので、余裕を持って教育を受ける暇が無かったりはするんですけどね・・・。
なので、場合によってはその技術を持ったエンジニアを外部から招き入れることも検討が必要になってくるでしょう。
技術対象との相性
どんなにその新技術がすばらしいものであったとしても対象システムとの相性を見極めないと想定していた効果を得ることが出来なかったりもします。
先のフレームワークの話であっても、大規模システムの開発を効率化できるという効果があったとしても、適用する対象が小規模なものであった場合、そこでの作業は反って冗長なものを招いたりもします。
そういったものって開発手法が極めて統一化されているため制限事項も多いですし、教育期間を考えたら効果が出始める頃にはもう開発が終わっているよというものがあったりします。
また、最近のシステムではそれ単体で動くよりは、他のシステムと連携してというものが多かったりもするので、その技術が周りの環境にうまく適用できるかってところも見極めておく必要があるでしょう。
言語やOS、開発環境やクライアント環境などある特定の条件だとうまく動かない（またはサポートしない）というものもあったりしますので、適用する条件なども詳細に調査しておく必要性があります。
技術だけでなく、開発手法などを導入する場合でも開発現場だけでなく、主管となるクライアント側の業務そのものを変えてもらわないと効果が出ないという場合もありますので、総じて効果が出にくいという結果を生み出すことも考えられます。
クライアントにそんなことを強要するなと怒られるかもしれません。
そういった意味で、最初に書いた効果をはっきりさせておくとか、説明することでコミットメントを取り付けておくことが重要になってくるんでしょうけど。
こういったことに対しては、ある特定の綺麗に収まる範囲でまずは適用してみてその相性を見極めてみるというのも良いかもしれません。
自社内でやってみるとか、ある独立したシステムにだけ適用してみるとか。
ただし、無理に新しい技術を導入する事だけを優先するのではなく、まずはその準備として周りの状況を把握し、その周りから改善していくという必要も出てくるかもしれません。
まとめ
エンジニアの立場としては、日々生み出されたり進化している新しい技術への羨望というものは強かったりしますが、単にそれだけの自分のエゴで導入してみた場合、反って不利益をもたらしたりもします。
導入する目的や効果をはっきりさせ、それを導入した際の教育プランや適用範囲をはっきりと考えておくことがまず重要になってくるかなと思います。
自分としては、効果が出ることに関しては自明だったりもしますが、周りへうまく説明できなかったり理解が得られない場合は、導入することに関しては今一度検討する必要が出てくるかもしれません。
[PR]
[PR]