組織として用意すべきナレッジ（プログラミング・単体テスト工程）

Question

現在私が所属する部署で、後世のために
以下のような観点でナレッジを作ろうと考えています。

・ 新人、業務経験が浅い社員の開発効率、品質を上げる
・ 派遣社員をチームに入れた際、その派遣社員が戦力になるまでの勉強期間を短縮する

ナレッジが対象とする工程は、
主にプログラミング・単体テスト工程を想定しています。

みなさんの会社や部署ではどのようなナレッジを残していますか？
業務情報を漏らさない範囲で良いので、ご教授いただけると幸いです。

Answer 1

経営的視点において、社内でナレッジを共有することにより、ノウハウの属人化を防ぎ、効率・品質の向上を図る施策となるように考えられていることと思います。

しかし、私の経験では、この業界においては変化の速度が早すぎて蓄積したナレッジが次のブレークスルーへの足かせになる場合のほうが多いように思います。5年前の常識は今の非常識になり、お客様を巻き込んで buzzword で新製品を売り込むことを繰り返している業界です。

御社では IoT、 c10k問題、 ux デザイン、ディープラーニング、map-reduce、SaaS、AR など次々と出てくる buzzword やそれを実現すると言われているフレームワークに追従できてますか？

一度、すべてのナレッジ（と勝手に思われているもの）を捨てて組織をアジャイルにするための施策を考えるほうが良いと思います。たとえば、毎日新しい buzzword で検索してその結果を発表し合うみたいな活動をしたほうが効果的です。検索も日本語に限定せず、英語で流行り始めているものをいち早く取り入れるなどの努力が必要かと思います。

---

あ、プログラミング・単体テスト工程の例を忘れていたので追記です。

• MVCモデルはもう古いかも
• まだ、Webアプリをサーバサイドでレンダリングしますか？
• Go 言語って知ってますよね？　あ、 es6 とか Live script とかも。
• テスト駆動型開発やモデル駆動型開発は当然ご存知ですよね
• ソースコード管理は svn ですか？そろそろ git に変えますか？
• daily build は今や常識。 jenkins とか使ってますよね。
• え、ソースコードにコメント入れすぎじゃないですか。
• 詳細設計書って、役に立ちますか？
• DI って古いように思えてきましたけど、流行ったのそんなに昔じゃないんですよね。
• アスペクト指向、SOA、EA、オブジェクト指向・・・

Answer 2

今となってはちょっと古い話ですが、
汎用機とオープン系ではやり方が大きく違います。汎用機からオープン系への移行に何度か携わった経験で何度も汎用機の事しか経験のないメンバーから汎用機のやり方を続けるように圧力を受けたこともあります。汎用機のやり方でオープン系のシステムを作ってもパフォーマンスは上がりませんから、説得なり無視して、そんな妨害する暇があったらオープン系の勉強をするよう指導はしましたが、指導に従って自腹を含む有償研修に行って会社に残れた人は数割でしょうか。
きちんとしたネーミングの大切さは将来も必要でしょうが、将来も今のやり方が通用するかはわかりません。この方法は現在のこのシステムでは最良の選択だが、後世の人たちの足かせにならない程度のもので良いかもしれません？