我々の世界は、どちらかというと「腕っ節の世界」という印象があるかもしれません。この事の否定はできません。我々技術者はやはり職人ですから、個人の力を否定することはできません。だけど、そのことを前提としてプロジェクトを進めていく事は大きなリスクに繋がります。リスクとは、その人がいなくなったときに誰も分からない、という事です。
どうすれば個人に依存する問題を回避できるか。個人に依存しないとは、チーム（会社）として同じサービスを提供すると言うことです。
飲食業を例にとるとより分かりやすいかもしれません。マクドナルドに代表するファストサービスやファミレスなどは、どのような方法で一定のサービスを提供しているのか？それは一定のサービスが提供できるようなマニュアルがあるということです。
マニュアル主義などというと、世の中ではあまり良い言葉として表現されていません。しかしマニュアルがすべてではなく、マニュアルの本質は「ミス」を無くす（減らす）ことなのです。
つまり、マニュアル通りにおこなうことが最終目標ではなく、マニュアルに何かしらのエッセンスを付加してその人なりのサービスができるようになることを最終目標とするということです。
マニュアル化というと、我々の世界では、誰が作っても同じプログラム・ドキュメントができる、と言うことですね。でもそれが難しいことも理解できますし、誰が作っても同じものができるなら、もしかしてプログラマはいらず、機械が自動的にプログラムを作ってしまう事ができる、と同意だと思いますから。
さて話を戻して「同じサービスを提供する」ということ。
チーム（会社）として、ある一定の品質を担保できない、ということがエンジニア個人に依存して、そのリスクを回避できない、ということです。お客さんからの電話に「前の担当者が退職したから分かりません」など最悪です。
人に依存する部分は否定しませんが、このリスクを回避するために何かしら対応しなければサービスを売っている会社として恥ずかしいです。
同じ物はできなくても、同じ思想で作ることを目指したいですね。
同じ思想で作ることを目指す、といいました。では同じ思想とは何でしょうか？思想なんて仰々しい事をいってますが、「同じサービスを提供する」ことを具体化していき、その具体的な項目・内容に準じて開発することではないでしょうか。同じ思想の具体化は、つまり標準化に他なりません。ただ標準化すれば、すべて収まると言っているわけで無く、飲食業の例で説明したように、あくまでミスを減らし一定のサービスを提供できることが標準化であり、それぞれの開発者が標準化のライン上で、どうエッセンスを付加することができるかが重要であることは言わずもがなです。そのエッセンスが「さすがＡさん！」と言われることなのです。
この標準化という方向を皆が考え、進んでいきたいと考えています。それが属人化からの脱却に繋がると信じています。
一つの例ですが、
１、技術
言語やフレームワークを統一化することで新しい技術だからわかんない、というリスクを排除します。統一した技術のノウハウの共有化をおこなって、効率もあがることも期待できますしね。
それとは別に新しい技術などは、会社をもっと大きくし、新しいことが好きなスタッフが増えたら、社内オフ会（勉強会）などで盛り上がりたいですね。
２、コーディングスタイル
エントリー系のコーディングスタイル標準、印刷系のコーディングスタイル標準を考えていきます。
エントリー系であれば、項目名とかテーブルのカラム名とかを記述した定義ファイルがあれば、ソースのひな形ができる事が理想です。こう考えるとマスターメンテなんてコーディングしたくはないですね。それこそ自動化、自動化、自動化を目指しましょうよ。
帳票の場合は、連票・１ページ毎に集計がある帳票・ページの中間に小計などがある帳票などでロジックの標準を決めます。結局はループをどう使うか、どこでデータを読み、集計するかが標準化されていれば、見やすいソースになるのではないでしょうか？！コーディングスタイルと言っても変数の命名規約などではなく、モジュール構成や制御分の使うタイミング等に重きを置きます。
エントリー系で言えば、エントリー項目が追加になったときなど、どこのモジュールを見れば良いかを重視します。どこに何が書かれているか、一発で分かるようなソースが理想ですよね。
またSQLについても、すべてSQLで集計できても保守性が悪くなるようならば、SQL＋プログラムで作るようにします。保守性が悪くなるかどうかの判断が難しいのですが。
３、ドキュメント
ドキュメントと言っても、用途として大きく２種類ありますよね。それは、作るためのドキュメントと残すためのドキュメント。
残すドキュメントを詳細設計のレベルにすると、逆に保守性を悪くします。ドキュメントは、メンテナンスされていなければ結局ソースを見ることになりますし。
ドキュメントは、システムのイメージが分かるレベルで統一します。
システムを構成するプロダクト、機能、コマンドの一覧。ある修正でどこが影響するかをチェックするときなどに使えますし、システムのすべてはこれです、と言えるドキュメントになっていることが重要です。
以前、システムのすべてって何？どんなサブシステムで構成されているの？って確認したところ、担当者が知らなかったり、そういう資料が無かったりしたことがあります。それって最悪ですよね。
次は、業務というキーワードです。なぜこうなっているのかが分かる資料が必要です。ソースをみて処理は分かりますが、なぜその処理になったのか、必要なのか等、その理由は分かりません。それを補う資料が必要です。
業務フロー、データ関連図、プログラムの関連図などの資料も必要です。それぞれの関連ってソース見ただけじゃ分かりませんものね。
このシステムが構成されているのすべてって何とシステムの概念が分かれば残す資料としては十分だと考えます。
データベース定義は、リバースエンジニアリングでドキュメント作れば良いし、プログラム仕様はヘッダに記されているはずですし。
必要最低限のドキュメントを目指します。
まさにアジャイルでしょう、プログラマ諸君。
４、テスト項目
エントリー画面や帳票のテスト項目は標準化できるはずです。
エントリーの画面や帳票などは、コントロール数や印刷項目数に対して項目数が計算できます。これに３で記した業務というかビジネスロジックのテストが加わります。
体系的・定量的に考えていけば、ある一定のテスト項目や項目数の標準化は可能です。
５、レビュー
コードレビュー、ドキュメントレビューは必ずおこないます。
社内のスタッフの中でも、一番大事だといっているスタッフもいます。
コードやドキュメントが最低限、標準にあったものであるか、チームとして確認していきます。チームとして確認し、作った人しか分からない、を脱却します。レビューした人たちは、俺が作ったんじゃないから知らないとは言わせませんよ。
などなど。
こういう標準化を考えることで人に依存する部分が減ってくると思います。頭を悩ますのではビジネスロジックやプログラマが一番苦手なレイアウトだけにしたいですね。
もしゃ＠東京支社
