異なるプロジェクトに参画するITエンジニアが、情報交換をする場合、顧客情報の漏洩リスクを低減する必要があります（低減はリスクコントロールのひとつです。リスクコントロールの種類は前回のブログを参照してください。）
www.three-wise-monkeys.com
社内勉強会は以下の制約を設けて行いました。
- 顧客企業名はイニシャルとする。その際、企業名の頭文字は使わない（例：鈴木食品（株）⇒S 食品はNG）。
- プロジェクトに関わるメンバーの名前は自社の要員以外は、役職名とする（例：部長、チームリーダー、メンバー）。
- 顧客企業を特定出来るような業界内でのランキングなどの情報は使わない。
- 顧客企業で採用しているソリューション製品・サービスは、固有名詞を出来るだけ避けた上、汎化した表現で伝える。
汎化というのはオブジェクト指向の設計で、よく使われます。汎化は複数のクラスに共通する性質をまとめ、親クラス（スーパークラス）として定義することです。
下図のようなある会員制のサービスは無料会員、一般の有料会員、特別の有料会員とクラスが分かれている場合、一般の有料会員と特別の有料会員は、有料会員として親クラスを定義します。これが汎化です。さらに、無料会員と有料会員のクラスは会員の親クラスで汎化できます。汎化のUML(Unified Modeling Language：統一モデリング言語）は白抜きの矢印で表します。矢印の指している方が「スーパークラス」です。
汎化すると抽象的な表現になります。これは顧客情報を特定しにくくする有効な手段だと思いました。
この制約を設けた勉強会を毎月やりました。期待以上にエンジニアの満足度は高かったはずです。制約を設けることで、純粋にシステムエンジニアリングに必要な知見を高めることに貢献したと思います。
システムエンジニアリング力を高めるのに必要な要素は「機能要件」と「非機能要件」の実現方法を考えられるようになることです。
「機能要件」とはシステム開発において必須の要件です。お客様から要件をヒアリングし、それを「要件定義」として落とし込みます。「要件定義」→「外部設計」→「内部設計」→「実装」→「テスト」→「納品」→「検収」と、順次工程を歩みます。
「機能要件」はお客様が絶対に必要とする要件ですので、「機能要件」が完全に実装されないシステムは欠陥品です。
一方「非機能要件」は「機能要件」以外の全ての要件をさします。これは幅が広く、明確に定義するのが難しい領域です。
たとえば、倉庫の棚卸業務のシステム改善に関する、機能要件と非機能要件をひとつ書いてみます。
機能要件
- 現状の課題：月末棚卸で倉庫内にあるすべての品目をカウントしているが、品目点数が多く、作業時間がかかり倉庫作業員の業務負荷が大きい。
- 課題に対する機能要件：通常月の棚卸は当該月に入出庫が発生した品目のみを対象とする。その為、倉庫内の保管場所と棚番単位で入出庫のある品目と想定される在庫（理論在庫）のみを抽出したリスト（棚卸チェックリスト）をコンピュータから出力して欲しい。
非機能要件
- 現状の課題：月に一度、フルバックアップを取り、日々は増分バックアップをとっている。この方法だと一斉棚卸業務のような作業日程が決められているときに障害を起こすと、バックアップからの復旧に時間がかかり、棚卸業務に支障が生じる。
- 課題に対する非機能要件：棚卸の開始前にフルバックアップをとり、棚卸期間中は差分バックアップを行うことで、迅速なリストアを可能とする方法にする。
フルバックアップ、増分バックアップ、差分バックアップの違いは、以下の記事を参照してください。
www.three-wise-monkeys.com
