先輩、ソースコードのコメントがメンバでバラバラで読みづらいんですが

「あの、ふと思ったんですがソースコードにコメントって必ず書かないといけないですか」
「どうしたの」
「ほら、プログラムに機能追加するチケットを拾ったじゃないですか。で、他のメンバのソースコードを見ていたら微妙にコメントの差があってどうしたらいいなかなーっと思って」
「そういうことなのね。そうね難しい課題ね」
「難しいですか」
「コメントを書くことが難しいわけじゃないよ。それはプロジェクトの決め事にしてしまえばいいのね。ソースコードにコメントを書きなさいって。でも、そんな単純な話でもないわね」

「なぜ単純な話じゃないんですか。コメントを書く・書かないの選択ですよね」
「ソースコードのコメントだけ、で課題を捉えるならそうなのよ。でも」
「でも」
「仮定でシナリオを考えてみましょうね。プロジェクトだから全員がソースコードにコメントを書くことにします。この仮定は理解出来るわよね」
「それはもちろん」
「ソースコードにコメントを全く書かないケースとではどんな違いがあるかしら」
「違いですか。ソースコードはプログラムだけになりますね。当たり前ですが」
「それってどういうことを意味していると思う」
「意味、ですか。意味なんてありますか」
「質問しているということはあると思っているからよ。

「えぇ…どうかなぁ。意味なんてあるのかなぁ」
「ヒント、欲しい」
「いえ、もう少し頑張ります。えっと、diffとったら違いはコメントがあるかないか、だし。ううん、わからない」
「観点が違うのよ。対象はソースコードのコメントだけれど、それって」
「あーちょっと待ってください。ヒントはまだいいですから」
「そうなの、わたしは教えてあげたいのよ」
「だから」
「あと３分待つわ」
「短かっ」
「もう１分ね」

「えっ、勝手に３分で話が進んでいるの。それはスルーしてっと。そういえば他の観点って言っていたような。先輩はプロジェクトマネージャだからプロマネの視点かな。なんだろうプロマネの視点って」
「いつでも言ってね。ヒントをサービスするわよ」
「先輩ってSでしょ」
「そんなことを言っているとタイムアップになるわよ」
「もういいです、ヒントください」
「プロマネの観点はいい線いっているわ。プロジェクトはどんな指標でベンチマークするのかしら」
「プロジェクトの指標とベンチマーク、ですか。プロジェクトってQCDで評価しますよね」
「いいわね」
「QCDとソースコードのコメントって繋がりあるの…」
「（あらもう少しね）」
「Qはコメントのばらつきかな、Cはコメントを書く時間かな。Dは関係ないと思って大丈夫かな」
「（もうちょっとね）」

「うーん、どっちかな、先輩なら。Qから言ってみよう…。でも、ばらつきだともともとの質問に戻っちゃうな。」
「答え出たの」
「コメントがプロジェクトの品質を満たさないことになっちゃう、とか」
「なるほどね、そう捉えたのね、Qとコメントの関係を」
「Qは品質ですよね。で、今はコメントの話をしているので」
「Qの品質とはね、プロジェクトのアウトプットが備えなければならない性質と考えるといいのよ」
「アウトプットが備えていないといけないの性質」
「ソースコードにコメントを入れることを決めたら、コメントがないソースコードがあったら品質を満たしていないことになるわね」

「それは大変かも」
「大変でもなんでも、備えていなければならない性質ならやらないといけないのよ」
「まぁ、仕事ですから」
「でね、ソースコードにプログラムが存在するわね」
「それはそうですね」
「そのソースコードにもう一つ存在するのは」
「コメントですよ」
「それの違いは」
「プログラムかコメントかですね。堂々巡りみたいになって…」
「コメントを別の表現にしてみたら」

「別の、ですか。箇条書き、手続き、メモ…」
「それってどんな分類になる」
「あっ、あぁ、ドキュメントですね」
「そういうことなの。一つドキュメントを要求しているということになるの」
「ドキュメントになると品質の定義も必要だし、記述のガイドも必要になりますね」
「そうなのよ。そうなったら更に掛かるコストも増えていくのよ」

「反対にコメントを書かないケースのシナリオにすると、ドキュメントが一つ減るんですね」
「もしそうしたら何が起きると思う」
「ソースコードを読み直すときにソースの書いたメンバのレベルで理解に時間がかかる、かな」
「この話のきっかけはそれだったのでしょう」
「そうです」
「ソースコードを書くメンバのレベルでソースコードに違いが出ることをあなたは認める、それとも認めないのどちらを選ぶかしら」
「認めると今の状況ですしね。認めないとみんなレベルが高くないといけなくなるし。悩ましい…」
「ね、どっちを選んでも何か負担が生じるのよ」

「それってどうしたらいいんですか」
「理想を言うなら、あなたがプロジェクトのソースコードの品質基準を作る、かしら」
「え」
「だから、理想だけれど。なぜは今までの話でわかるわよね」
「なんとはなくですが。可読性のあるソースコードを書くことでコメントをソースコードから無くそうと」
「あら、わたしソースコードのコメントはあってもいいと思っているわ。実際、今のプロジェクトでは仕様が難しいところはコメントを入れるように言っているでしょう」
「ええ。とすると、ソースコードはプロジェクトのルールとして可読性を確保した基準を作る、と。コメントは必要なら入れる、と」
「そうなるわね。で、今のプロジェクトでの運用との差異だけやればいいのよ」
「それ大変そうです」
「でもあなたのきっかけになったことは解決できるでしょう。メリットはあるわよ」
「そうですね、でもガイドを作ったりするのはどうしよう」
「別にガイドの体裁で無くてもいいじゃない。サンプルコードでもいいのよ」
「それなら今日にでもできそうです。そうしようっと」