コーディング規約の重要性と無い場合の対処

ソースコードを書く上で、好みの書き方は個人によってある程度分かれてくると思います。
例えば、if文で定数を右辺に書くか左辺に書くかは、人によって好みが分かれます。

・右辺に書く例

・左辺に書く例

左辺に書く方法は「ヨーダ記法」と呼ばれ、「==」を誤って「=」と書いてしまった時に、代入が行われて処理が継続するのではなく、異常終了でミスを知らせてくれる、というメリットがあります。
しかし、入門者向けの書籍では右辺に定数を書く場合が多いので、左辺に書く方法の方が見慣れていて馴染みやすい、という方も少なくありません。

どちらの書き方にも良い点と悪い点があり、どちらが良いかは一概に言えません。


しかし、ソースコードの書き方で、明らかに悪い書き方があります。
それは、箇所によって書き方が混在した書き方です。
一人でソースコードを書いている場合は書き方が混在することは少ないのですが、複数人で開発している場合は書き方が混在することが良くあります。

人がソースコードを読む際は、ソースコードの書き方から、記述内容をある程度予測して効率良く読もうとします。
ここで、書き方が混在していると、記述内容の予測を誤り、分析ミスや改修ミスに繋がりかねません。

先の例で言うと、if文の定数が右辺に書かれている箇所と左辺に書かれている箇所が混在している場合、定数値と変数値を逆に読んでしまう可能性があります。
これは、分析ミスや改修ミスに繋がりかねません。
注意深く読めば読み誤りは防げますが、ソースコードを読む時にストレスを感じるでしょう。

ソースコードを効率良く読めるようにするために、書き方を統一することは重要です。
少なくとも、一つのソースファイル中では書き方を統一するのが望ましいです。


コーディング規約が存在している現場であれば、ソースコードの書き方が統一されやすくなります。
しかし、コーディング規約が存在していない現場もありますし、存在していたとしても規約が十分に網羅的でなかったり、規約が読まれなかったりすることもあります。

コーディング規約に頼れない場合は、周りのソースコードの書き方を真似る、というのが良い手になることが多いです。
先輩社員からソースコードの書き方を真似るように言われた人も少なくないと思いますが、そのように言われる理由の一つが統一性の確保です。

しかし、全く新しいプロダクトを作成する場合はソースコードの書き方を真似ることができませんし、真似るべきではない書き方というのも中にはあります。
ソースコードの書き方を真似られない場合の対処や、真似るべきではない書き方の判断のためには、一般的に良いとされるソースコードの書き方を覚えるのが良いです。
書籍のサンプルコードは一般的に良いとされるソースコードの書き方がされていますし、良いソースコードの書き方を解説した書籍も存在します。
また、言語によってはコーディング規約が公開されている場合もあるので、その場合はそれを参考にできます。
例えば、C#はMicrosoft社が公式にコーディング規約を公開していますし、JavaScriptはWordPress社がコーディング規約を公開しています。


いかがでしたでしょうか。

プログラムは単に動けば良いというものではなく、後々の保守を考えて読みやすく修正しやすいように書くべきです。
本文に書いた通り、一般的に良いとされるソースコ―ドや周りのソースコードを真似るだけでも一定の保守性を確保できるので、慣れていない内は意識的に真似ることをお勧めします。

シーケンス図の使い所とPlantUMLの紹介

UMLの一つであるシーケンス図は、クラスやオブジェクト間のやりとりを時間軸に沿って表現する図です。
複数の処理が並列で走る場合に、処理タイミングを整理する上で便利な図です。

例えば、マルチスレッドプログラムを開発している時に便利です。
シーケンス図を書くと、ややこしいスレッド間の関連をわかりやすく整理することができます。
マルチスレッドを取り扱う解説書やシーケンス図は良く出てくるのですが、保守開発等で自分がコーディングする時にも頭の整理のために役立てることができます。

以下では、javaでのスレッド制御(joinとsynchronized)で取り上げたサンプルコードを、試しにシーケンス図でまとめてみます。
このように、シーケンス図を書くことで、各スレッドの連関をわかりやすく整理することができます。

・そのまま実行した場合

・①のコメントアウトを外した場合(join)

・②のコメントアウトを外した場合(synchronized)


UMLの図を書く時は、PlantUMLを使うと便利です。
PlantUMLは、テキストからUMLの図を生成することができるツールです。
UMLをテキストで書くことで、手軽に図を書けるようになりますし、Gitでの管理・差分比較もできるようになります。

下記のページにアクセスするだけで、すぐに使うことができます。
図の書き方(文法)についても説明されています。
https://plantuml.com/ja/

オンライン上で図を生成することが可能で、上記ページ中で試しに作ることができる他、「オンラインサーバ」のページにアクセスすることで大きな画面で作ることができるようになります。

セキュリティや作業効率等の問題でオンライン上で図を生成したくない場合は、ローカル上で図を生成することもできます。
ローカル上で図を生成する方法は、「クイックスタートガイド」に書いてあります。

以下、試しに、シーケンス図を書いてみたものです。
前述の「①のコメントアウトを外した場合(join)」のケースについて書いています。

【サンプルコード】

【生成結果】


いかがでしたでしょうか。

UMLの中では、シーケンス図はかなり使用頻度が高い図です。
今回紹介したケースのように、処理のタイミングを整理したい時に便利な図なので、書き方を覚えておくと良いでしょう。
その際にPlantUMLを使えば、図を書いたり管理したりする手間も少なくなると思います。

炎上プロジェクトへの人員追加のまずさと、正しい人員追加の方法

IT業界では、炎上プロジェクトへの人員追加は悪手とされ、遅れが更に拡大する結果になることが多いです。
(一般的には、スコープ見直しやスケジュール延伸が良い手とされます)

このことは「ブルックスの法則」として知られており、その法則では以下の理由により人員追加が悪手とされています。

1.新たに投入された人員を育成するのに時間がかかる

育成するまでの間、新たに投入された人員がプロジェクトへ貢献するのは難しく、逆に育成コストがかかってしまう。
スキル面で問題のない人員だとしてむ、システム固有の知識を得るのにある程度の時間はかかってしまう。

2.人員が増えるとコミュニケーションコストが増大する

人員が増えれば増える程、コミュニケーションに費やす労力が増えることになる。
そのため、人員とパフォーマンスは比例するわけではなく、人員の増加量に応じたパフォーマンスの増加量は徐々に低下する。
仮に、追加人員が全くパフォーマンスを発揮しない場合、コミュニケーションコストが増える分、全体のパフォーマンスはむしろ低下する。
(この問題は、組織を適切に分割することで、ある程度緩和される)

3.タスクの分割が難しい場合がある

労働集約的なタスクであれば、一般的に分割は容易である。
例えば、複数のソースコードの修正であれば、ソースコード毎にタスクを分割できる。
しかし、そうではないタスクは分割が難しい場合もあり、例えば、チーム間調整のタスクは分割が困難である。
タスクの分割ができない場合、新たに投入された人員にタスクを割り振ることができず、遊ばせてしまう。


しかし、人員追加は常に悪手ではありません。
1人でこなすことができるタスク量には限界があり、また人員が何らかの理由(体調不良や家庭の事情等)でパフォーマンスを発揮できなくなった場合のリスクヘッジも考える必要があるためです。
悪手なのはあくまでもプロジェクト炎上中に人員を追加することであり、人員は少なければ少ないほど良い、というわけではありません。

途中で人員を追加したくなるような炎上プロジェクトは、初めから人員を追加しておけば、問題は無かったはずです。
そのため、プロジェクトの計画時に適切な人員を確保することが重要になります。
人員を追加する際、追加する人員の人数やスキル、人員の育成計画、コミュニケーション計画、各人員のタスク、といったものも合わせて計画することが重要です。

仮に、計画時の見積もりが過小であったことが開発途中で分かったのであれば、炎上する前に計画を見直して人員を追加するのが望ましいです。
炎上する前であれば、人員追加が間に合う可能性があります。
炎上するまで放置すると人員追加が間に合わなくなってしまうので、炎上する気配が見えたらなるべく早く計画を見直すことが重要です。


いかがでしたでしょうか。

上記の通り、人員はプロジェクトが炎上する前に適切に追加する必要があります。
人員を追加せずにプロジェクトを炎上させるのも、炎上したプロジェクトに慌てて人員を投入するのも悪手です。

人員を適切なタイミングで適切な人数だけ追加するためには、プロジェクトが走る前の見積もりの段階で先を見通す必要があります。
リーダーになるとプロジェクトの見積もりをする機会も出てくるので、リーダーになる頃には先を見通せるだけの知識や経験を積み重ねておきたい所です。

ソース管理のアンチパターン「リポジトリ内のソースが信頼されない」

ソース管理を行う方法としては、今日ではGitベースのプラットフォーム(GitHub、Bitbucket等)を使用するのが主流です。
しかし、ソースコードがCOBOLで書かれているようなレガシーなシステムでは別の方法、極端な話、共有フォルダにソースを格納してライブラリアンが一括管理するような方法が適している場合もあります。

しかし、どのような方法でソースを管理するにしても、確実にアンチパターンと言えるケースがあります。
それは「リポジトリ内のソースが信頼されない」というケースです。


ソース管理が上手く行われていないと、リポジトリ内のソースが開発者から信頼されなくなります。
例えば、以下のようなケースです。

  • リポジトリ内のソースが最新化されておらず、本番環境にあるソースが最新であった
  • リポジトリ内のソースの改行コードに問題があり、そのままでは使用できない

リポジトリ内のソースが信頼されなくなった場合、開発者に「裏プロセス」を生み出す動機が生まれます。
ここで言う「裏プロセス」とは、リポジトリの管理者・運用担当者を介さない、開発者だけで完結するプロセスのことを指します。
具体的に言えば「開発者自ら本番環境からソースを取りに行くことで、修正元ソースを入手する」「開発者が手元にソースを持ち、そのソースを修正元とする」といったものです。

短期的に見ればこの裏プロセスは上手く行きそうに見えますが、裏プロセスには管理の目が行き届かない、という問題があります。
長期的には見れば、必ずデグレードの危険性が高まります。
特に、同じソースを複数の開発者が開発するようなケースでデグレードが発生しやすくなります。
それどころか、開発者の作業ミスでデグレードが発生することすらあります。


裏プロセスにより開発が行われる状況は、決して放置してはならない状況です。
リポジトリに問題があるのであれば、リポジトリの運用を見直して、その問題を解決する必要があります。
そして、問題を解決した旨を開発者に周知し、リポジトリからソースを取得するように呼びかける必要があります。

また、裏プロセスによる開発を行うことができないように環境やルールを整備することも場合によっては必要です。
例えば、「本番環境のソースを開発者から参照不可にする」という方法は環境整備の方法として検討に値しますし、「開発者に修正元ソースと修正後ソースと修正前後コンペアを提出してもらい、リポジトリ内のソースを元に修正されていることを確認する」という方法も不正なソースを元に開発が行われていないか確認する方法として機能します。


いかがでしたでしょうか。

今回は、経験則を共有するために、ソース管理のアンチパターンを書いてみました。
このようなことが一般的に言われることは少ないと思いますが、仕事をする上ではこのような経験則も重要だと思っています。

役職に応じた役割の違いと、それを意識した行動

通常の会社では、大まかに言って役職が「経営者」「管理者」「担当者」と分かれています。
先に挙げた方が、責任が重い上位の役割であるとみなされます。
そして、組織は通常ピラミッド式になっており、上位者は見る範囲が広く人数が少ない、下位者は見る範囲が狭く人数が多くなります。

それぞれ役割が違うため、その役割の違いを意識して行動することで、仕事がスムーズに進むようになります。
自分の役割をこなすことも重要ですが、組織として高いパフォーマンスを出すためには、役割が違う者と上手く協働することもまた重要です。


「経営者」「管理者」「担当者」の役割の違いは、簡単に言うと以下の通りです。

■経営者

  • お客様を開拓し、お客様にサービスの提案を行う
  • サービスを提供することで利益を得られるようにし、経営を継続可能にする
  • 会社全体の状況を見て、全体最適を考える

■管理者

  • サービス提供の実作業、及びサービスの担当者の管理を行う
  • 複数のサービスについて管理を行う

■担当者

  • サービス提供の実作業を行う
  • 自分が担当するサービスについて専門的に取り扱う

  

ここで重要なのは、下位者が持っている全ての情報を上位者は持っていないということです。
一つ一つのサービスの専門的な知識、ITシステム提供であればプログラムや業務ロジックといったものは、通常は担当者が一番詳しく、管理者や経営者は概要しか知らないことが多いです。


役割の違いにより、持っている情報には差が生まれます。
この差を必要に応じて埋めるためには、上位者への的確な「報連相」が重要になります。
今更書くまでもないかもしれませんが、「報連相」とは以下のようなものです。

■報告

上位者から指示された作業の進捗状況や結果を知らせる。

■連絡

上位者に事実を知らせる。

■相談

判断に迷うことがあった時に、上位者に指示を仰ぐ。

  

何か良くない事象が起きた時に、上位者が作成した方針やマニュアルに沿って対応できる場合には問題ありません。
その場合は、報告や連絡で問題がないことを伝えれば良いです。

しかし、上位者が作成した方針やマニュアルに沿って対応できない場合は問題です。
その場合は、どのように対応するか相談する必要があります。
(IT業界では「エスカレーション」とも呼ばれます)

相談を行う際、自分が担当しているサービスについて上位者は自分ほど詳しくないので、判断に必要な情報を的確に連絡することが重要です。
また、上位者は見る範囲が広く忙しいので、多くの労力をかけずに判断できるような形で相談すると尚良いです。
つまり、「~という事象が起きています。~と私は判断したので~をしたいのですが、それでよろしいですか?」という形で相談を行うことが理想です。

しかし、このような相談を行うためには、上位者の意図を汲む必要があります。
スキルや経験を積まない内は難しいので、その場合は「自分で判断できない何かが起きている」ということを伝えられれば及第点です。自分で抱え込むのが一番良くないです。


上位者の意図を汲んで仕事ができるようになると、自分自身が上位者へステップアップするチャンスを得られます。
この際、自分が担当していた仕事を後任に任せられるかどうかが一つの課題になります。
今の仕事をしながら上位者の仕事もこなすことは仕事量的にできないので、自分が担当していた仕事は後任に任せる必要があります。
(それができない場合は、ステップアップが止まってしまいかねません)

しかし、実際に後任に仕事を任せてみると、教える時間がかかりますし、普段自分がやらないようなミスもします(そのリカバリーでも時間を取られます)。お客様に迷惑をかけてしまうこともあります。
自分よりも知識・経験が浅い人に仕事を任せる場合は特にこの傾向が顕著です。そうではない場合も、仕事に慣れる期間は必要なため、この傾向が見られることがあります。
とはいえ、このようなデメリットは一時的なものであり、長期的に見れば組織にとって以下のようなメリットがあります。

■後任に仕事を任せることによるメリット

  • 自分の技術が他の人にも伝わり、組織全体としてレベルアップする
  • 複数人で作業できるようになるので、残業が減り、アウトプットの量も増える
  • 自分にしかできない作業に集中できるようになり、作業の品質が良くなる(品質チェックと報告、仕事の方向性の検討…等)
  • 休暇や異動等で自分が居なくなった時にも仕事が回るようになる
  • 自分の仕事に他の人の目が入ることで、仕事の改善点に気付くことができる

  

そのため、自分の仕事を後任に任せることは、自らのステップアップのためだけでなく、組織のためにもなります。


いかがでしたでしょうか?

スキルや知識に優れている若手でも、組織での動き方がわからずに躓くことがあります。
それはとても勿体ないことなので、組織の中ではどのように役割が分担されているのか、その中で自分はどのように動くべきなのか、ということを意識していただければ、と思っています。