最近、以下が話題になったような気がしました。読んでみると結構参考になりそうだったので、コレについて、チョット思った事を書こうかと思います。
＜参考＞
コレを読んでて思ったのですが、施策と結果に相関は無くて、「CIを使いこなし始めたメンバーがいて、WebAPIのドキュメントサイトのデプロイ作業が自動化できる見込みがあった。」のCIの部分もあまり関係が無く、端的に、
"ドキュメントサイトの自動更新が
モチベーションになった。"
という感があります。
前半で、「Swaggerもうやりたくない。」と言う雰囲気が出たのは、「Swagger導入も言う程、楽では無いタメ。」だとは思います。しかし、その導入の費用に対する効果、費用対効果が勝れば、導入のモチベーションになります。
...ですが、新技術導入で「ありがち」なのは、導入する技術の導入先のセグメンテーションやターゲットを意識していないケースだと思います。
これについては、以前も書きましたが、
技術単独の良し悪しダケで考えていると、導入先での主に現場目線での費用対効果が悪く、結果的に頓挫するというケースが多いかと思います。
なので、導入の決め手は、
- 先ず、導入する技術がハマる現場であることが第一条件としてあり、
- 次いで、現場にニンジン（モチベーション）を提供できるかどうか？
なんじゃないか？と言う気がします。
例えば、Swaggerの問題に書かれている「WebAPIの仕様が正確に表現できない。」という類いのWebAPIが多数を占めるようなケースでは導入は難しくなると思います。また、稼働する人と、恩恵を享受する人が違うケース等では、また、別途、工夫が要るのかもしれません。
更に、「現場のモチベーションとなる効果」と、「実際の効果（副次的効果）」は、また違っているケースがあって、仕様書の更新漏れと不整合の解消された事が、「おまけ」の部分に書いてありました。
この「実際の効果（副次的効果）」は、現場目線での費用対効果ではなく、マネジメント目線の費用対効果と言う気もしますが、特にSIのPMはココまで技術的に細かい事を考え無い事も多いので、コレが、新技術導入の障壁になっている可能性はあるように思います（まぁ、技術者の提案がPMからみて理解可能なモノになっていないと言う話もありますが）。
＜まとめ＞
新技術の導入の際には、
- 先ず、導入する技術がハマる現場であることが第一条件としてあり、
- 次いで、現場にニンジン（モチベーション）を提供できるかどうか？
が重要。以下の様なケースでは、工夫が必要になる。 - 稼働する人と、恩恵を享受する人が違う場合。
- マネジメント目線の費用対効果に対して、
PMや、出資者の理解が得られない場合。
余談ですが、「Swaggerに関連したNode.js用のOSSを開発し、npmパッケージとして公開」について、某弊プロジェクトでも、「npmパッケージを作成・公開したいな。」と考えています。具体的には、「SPAとNativeでのPKCE認証を行うためのJSファイル」を登録する予定で、やっぱ、AppAuthの利用は、やめると言う話です。
Open COBOL Solution WG
新技術導入とか言うアレに対してチョット思った事を書いた。
