開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2019/07/01

共感力の低いプログラマも共感してしまう30年間のソフトウェア開発経験

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


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



 以下、私が思ったこと。

<コメントやドキュメンテーション>

  • 一つ一つの動作をコメントに残すこと
  • ドキュメントは将来の自分へのラブレター

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

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

<テスト自動化、CI/CD>

  • テストはAPIをより良いものにしてくれる
  • テストはコマンドラインで行える方が良い
  • 自分のコンピューターで実行できない場合は生産性が落ちてしまう
  • (テスト)コードを捨てる覚悟を持つこと

 ローカル環境での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) STPマーケティングによるニーズやターゲット、自分の提供できる価値の分析、(2) コンセプトのトランスフォーメーション、(3) プログラム・マネジメント、(4) ステークホルダー・エンゲージメント・マネジメントを含めた予算取り。

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

<ルーティーン>

  • しょうもないミスで1時間以上無駄にした時は記録を残すこと
  • 馬鹿げたやり方をブログに残すのは何もしないよりは良い
  • 紙のメモはなんだかんだ役に立つ

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

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

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

 オープン系技術に関して、インターネット検索をするエンジニアは多いですが、イントラネット検索をするエンジニアは少ないと思います。なので、イントラネット内にオープン系の技術情報を掲載するのは馬鹿のすることなんじゃないか?と思ったりもします。

 PMO関連の組織は、その辺りについて、再考した方がイイ時期に差し掛かっていると思います。
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告