いう言葉を使わず、「正しいこと」という言葉で統一しました。言い方は、文書名の細かい差異を無視して、一般的に考えれば妥当だと思います。「正しいこと」は、(第一義的に)「設計書」や「仕様書」に書く。「設計書」や「仕様書」に書くのは、権限が必要な(と筆者が思っている)「正しいこと」(のみ)である。なると非常に困ります。書きたいこといろいろ書きたいことがあります。1.正しいことこれは間違いなく書いて問題ないことだと思います。2.否応ないこと技術的などうしようも無い制限などで、正しいことと相違し、しかもこちらを優先しないとならなそうなことです。依存関係が思わぬ方向にあり、思っていた様にプラガブルにできない規約で、ソースがない変換モジュールをかます必要があり、思っていたソフトが使えないといった感じのことです。次項の補足すべき事よりもこちらがふさわしいのではという事項にコード体系が決まっているのに、そのコードの利用者の要望により、追加・変更を余儀なくされることもあると思います。あるコードが「1、2、3」で決まっていたのに、「4」を追加してくれと言われることなどが、該当します。筆者は前から、“データの意味は利用者の総意である”のではないかと考えていました。「総意」という言葉は代議制を否定するものでは無く、DB管理者をdisる意図も有りませんが、かといってDB管理者というのは、わりかしコードなどは「自分としては何でもよく」、「えいや」で決めるように見えます。考えると、利用者の要望というのは、技術的にはどうしようもないことと同等の重さと考えます。これらの事は、尊重され、その線で記述を変えるべきです。3.補足すべきこと個別のプログラムのみで使うテーブルレイアウトやコード体系です。項目転送関係のごく細かいことは、プログラムができてみないと分からないので、当然後からということになりますし、それを書く権限は、プログラムを作る当人に委嘱してもらわないととても間に合わないと思います。前項の否応ないことと違い、こちらは正しいことと相違するものでなく、別文書(基本設計と詳細設計の様な)で共存するのだと思います。4.聞いたこと末端のプログラマにとっては、もっともなじみ深い事項だと思います。要するに、正しいことなどとして文書化されていないが、個別のプログラム限りかと言うとどうかという決め事を、リーダなどに相談して得た知識のことです。何気ない小さな決め事ですが(そうでなければリーダ止まりで判断はできないです)。プロジェクトを進めていく音頭取り上、要石となるようなことが多々あります。この手のことは残りません。聞いた末端のプログラマには設計書・仕様書を更新する権限が無い。有っても広く頒布する権限がない聞かれたリーダは、即興の判断で、聞いた側は一心に墨守するつもりでも、仮置きだと認識してしまい、文書化しない正しいことだと正式には認められていないことでも、組織運用的には、リーダの発言は極力通しきる傾向にある。それは不文律に過ぎず、なにか文書化しづらいと言った複合的な要因により、うやむやになってしまうのです。この場合、末端のプログラマが文書化を担当するのがもっとも忘れにくいと思います。末端のプログラマでも、文書のどこかしかるべき枠に、聞いた事を注記できるだけの権限を与えられるべきだと思います。5.意見あまりに“やばそうな”ことに出くわした際、注意を促す文句を付記します。大事になってから暴露されるより、ましかと思います。「ここはMaxだから何とかなっているが、もし将来Sumとかに変えたら目も当てられないことになるだろう」といったことです(もっとも、その様な事は、プログラムのソースに注記すべきことかもしれません)。l●「正しいこと」にどう抗していくか特に、「否応ないこと」を、正式な「正しいこと」にしていくフォーマルな根拠がないと思います。根拠がないので、表立って言えず、リーダの腹芸だよりになってしまいがちです。残念なことに、筆者のやっている仕事の範囲では、まず100%「アジャイル」的な進め方にしてもらえる可能性がありません。「アジャイル」的な進め方の場合、その様な点に対し、プロフェッショナル的な寛容さがあるのだと(本やインターネットで見た限りですが)認識しています。筆者は、「ウォーターフォールの局所的な逆流、または渦」を制度としてもらえるとよいと思います。必要な場合、プログラマの理解や整理を「正しいこと」の中に取り入れたらいいなという趣旨です。そんな事ばかりやっていたら、仕事が終わらず大変ですので、1つ起動条件を加えるといいと思います。それは、「仕事のその部分が全く進まず、それが末端の人間の能力のせいでない場合」です。現在でも、リーダの見識の1つとして当たり前の様に行われているとは思いますが、それらは、絶対に公式ルール上のものではないと思います。それを公式ルールにすると良いはずです。すると、こちらの方が粒度が小さいので、「アジャイル」的なプロジェクトの進め方より、さらに俊敏な進め方になる可能性すらあると思います。(もちろん「アジャイル」が酸っぱいと主張している訳では有りません。)まぁ、今回はこんな所です。●コラムのコメント欄の方針コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。・わたしは基本的にコメントに答えない・コメントを書く人は、回答がない前提で議論を進めていただくとさせていただきます。名前を記憶しておくコメント:くわぢ初めてのPCはMZ-80Cでした。終わるまで」とか習わされました。書籍「誰でも身につく!暗算力」を読んでみた。未成年者略取ムチャか?男気か?部下も立て続けに。利用規約ITmediaはアイティメディア株式会社の登録商標です。