ソフトウェア開発を長年していて、後天的に、共感力が低下してしまっている気がしますが、以下の内容には"とても"共感することが出来ました。なので、共感力が下がったというより、共感するポイントがフツーの人と違ってきているんじゃないか？と思ったりします。


　プログラマ同士で話をすると、きっと意気投合できる気がします。...と言っても、私の周りには肝心のプログラマが少ない気がします。恐らく、「エンジニアならFAXも直せるでしょ？」的な意味で、孤独な戦いを強いられているエンジニア諸兄も多いと思いますが、色々と情報を共有して、苦難を共有 ＆ 勇気を与えあうことが出来たらイイんじゃないか？と思います。

---

　以下、私が思ったこと。

＜コメントやドキュメンテーション＞

　コメントは超重要ですね。

　昔、コメント消すプルリクが来た時は、申し訳ないケド、無視しました。OSSでコメントが少ないのは、サプライサイド都合なんだと思いますが、それを「カッコイイから。」と言う理由で単純に真似るの、くそダサくないですか？って思ったりします（こういう人はファッション・コントリビューターなんだと思います）。あと、ドキュメントもコメントと同様に重要だと思います。

＜テスト自動化、CI/CD＞

　ローカル環境でのCUIでの迅速なビルド＆テスト実行は、プロジェクトの成長に伴い、重要性を増して行くと思います（某弊プロジェクトでも、NuGetパッケージ・マネージャ対応、クロス・プラットフォーム対応で、まさに、こう言った感じになって来ている）。

　昨今、流行りのテスト自動化、CI/CDに関しては、適合するドメインがありますので、先ず、最優先すべきは、ローカルでの迅速なビルド＆テスト実行だと思います。

　また、テストコードについては、オフショアしていたものを実際に、一度捨てたことがあります。そして、現在、新たに別のテストコードを書いていますが、各種検証の寄せ集めになりがちで、凝集度が低くなりがちですね。そういう意味で、細かくやり過ぎると、最終的にテストコードを捨てることになるかもしれません。

　諸々考えると、疎通テストのレベルで止めたテストコードが、最もコスパが高いと思いますので、未着手であれば、先ずソコを狙うのがイイと思います。

＜開発言語シェアバトル＞

　私の嫌いな言語シェアバトルの類ですが、これも何の技術がどのドメインに適合するか？という話ですので、これを無視した論争に巻き込まれ ＆ 振り回されるのは時間の無駄ですね。

　そして、これは、熟練した老害だけではなく、新興技術でカタストロフィを狙う若者を含め、老若男女問わず、自分のスキルセット内の技術を擁護してしまうモノなので、自分が、コノ低俗な情報の発信者にならないように注意しましょう。

＜ライブラリの利用 or 自作＞

　私もNuGetパッケージは沢山利用させて頂いていますが、以前にも報告させて頂いた通り、必要に応じて、重複した開発ライブラリ開発を行うケースもあります。何を利用して、何を開発すべきか？思慮深いプロダクトのオーナーなら判断できると思います。

＜度重なるビルドシステム・エンハンス＞

　コレ、翌々読んでみると、IDEとビルド・システムの話だったりします。私も「ビルド・システムのエンハンス」とか言うWikiページを作成してあるぐらい、コレには苦労させられています。

　IDE（Visual Studio）を用いたビルドと比べ、MSBuildなどのツールを使用したビルドの敷居は高いです。最近、SAML2スクラッチ実装なんかも行いましたが、（違う意味で）「難しいなぁ。」と思うのは、殆どこのビルド・システム系だったりします。Visual Studioのバージョンが上がる毎に、苦労させられている感があり、この辺、何とかして欲しいなぁ。と思ったりしています。

＜ライブラリ＆フレームワーク
　＆テンプレートの開発時の注意点＞

　私の場合、行動規範を明記してはいないのですが、適用先のプロジェクトが厳しい（言い方が悪いけど、クレーマーレベルで厳しい）事もあり、"彼ら"を無視した行動は取れません（≒暗黙の行動規範）。

　しかし、実際に"彼ら"を無視した場合、ユーザは、蜘蛛の子を散らしたかの如く、一目散に逃げ出して、ユーザ基盤を失ってしまう気がします（書いていて、"彼ら"と言うのは、エンプラSI界隈の商習慣なんだろうな。と思ったりしました）。

＜コミュニティ関連＞

　本ブログでも、度々、ステークホルダー・エンゲージメント・マネジメントについて言及することがありますが、上記は、誰が重要なステークホルダーであるか？を見極めるために重要な情報を提供していると思います。


　前述のステークホルダーの反応は、重要だと思います。特に、面倒なトラブル報告をしてくれるようなユーザは、確実に重要なステークホルダーであるので、当然、無視したらイケナイし、無視するようなプロジェクトは長続きしないと思います。


　逆に、ステークホルダーではない外野の誹謗中傷は無視してイイんじゃないでしょうか？Twitterでありがちですが、本質を捉えていない誹謗中傷は無視してイイですね。ただ、評判を落とす原因にもなるので厄介ではあります。

　人間はネガティブな情報に敏感らしく、これを、何時までも検索上位に表示してしまうGoogleの問題かもしれません（きっと、広告ビジネスに傾倒し過ぎると、検索エンジンも、その信頼を失う、という構図なんでしょう）。

＜disconについて考える＞

　disconの類はイヤなものですが、このdisconに対して無策で抵抗し続けること程、人生時間を無駄にする行為も無いと思います。私も、価値が下がってきて継続が難しくなってきた機能やテンプレート、コレまで幾つもdisconにしてきました（某M＄製UIサブシステム関連の機能やテンプレートに多かったですね）。

　...と言う事で、disconをコントロールすることは、極めて重要であり、決して諦めてはイケナイ事だと思います。例えば、


　など、やれる事は沢山あると思います。...が上記の (1) - (4) は、日式企業の組織内プロセスとしてまだ浸透していないので、仮に、あなたがdisconに対処しようとしても、その辺りから是正して行く必要がある気がします。

＜ルーティーン＞

　私の場合、インターネット上にコミュニティが運営しているWikiを持っており、職務の特性上、顧客情報や、クローズドな技術情報に触れることが殆ど無いので、オープン系技術の話であれば、ほぼ、コチラに書き込むことが出来ます。

　管理職から見た場合、このフィルタリングは難しいと思いますが、昨今の「組織体の環境要因」の下では、なるべく技術情報開示を行うようにして行けるとイイのではないでしょうか？

　...と言うより、直接マネタイズ可能な技術を除き、サービスの治工具関係のソフトウェアは、オープンにしないと、「組織のプロセス資産」としても続かない時代ではあると思います。


　PMO関連の組織は、その辺りについて、再考した方がイイ時期に差し掛かっていると思います。