ソース管理ルールが信頼されないことによるデグレード例と対策

新人にソース管理ルールを教えている時にふと書きたくなったので。
　
ソース管理は、Git等のバージョン管理ツールを使用し、運用ルールを整備することで行います。
ソース管理の概要は下記のページがわかりやすいと思います。
　
【社内勉強会】バージョン管理の重要性とGitの運用について

https://techracho.bpsinc.jp/hachi8833/2017_03_14/36735

　
しかし、運用ルールを頑張って整備して運用しようとしても、その運用ルールが開発者に信頼されない場合、開発者はその運用ルールを無視し始めます。
そして、運用ルール無視の結果、不具合の修正や機能追加を行った後の最新のソースではなく以前のソースを修正元としてしまい、デグレード（修正したソフトウェアの品質が修正前よりも悪くなること）が発生してしまいます。
　
私が知る限りでは以下のような事例があります。
共に管理者から貸し出されたソースを修正元とするルールであるのにも関わらず、開発者自身でソースを取得していたという事例です。
・開発者が最新ソース置き場から勝手にソースを取得していた
　管理者から貸し出されたソースが古かったことがあったため
・開発者が直近の案件から勝手にソースを取得していた
　Windows環境のソースをLinux環境で管理しているのが不安であったため
　
このようなルール違反によるデグレードを防ぐためには、管理者の方で以下のような対策を行うのが有効になります。
・管理ルールを明文化し、開発者へ説明会を行う
・開発者に修正元ソースと修正後ソースと修正前後コンペアを提出してもらい、正しい修正元ソースを元に修正されていることを確認する

メンタル不調による休暇・離職を防ぐための心構え

ＩＴ業界はメンタル不調者が多い業界と聞きます。
前職ではメンタル不調で休暇・退職する人を何名か見てきましたし、他社の技術者の人からもメンタル不調の話はよく聞きます。
幸い今の職場ではメンタル不調者は現れていないのですが、ＩＴ業界にいる限りはいつ使うかわからない知識なので記事にしておきます。
　
よく言われるように、メンタル不調で休暇・退職する方は、本来遅刻や欠勤等をせず、仕事ぶりも真面目な方が多いです。
そのような方がメンタル不調になりかけると、以下のような前兆が現れます。
　・勤怠が乱れ始める（遅刻や突休をするようになる）
　・風邪を引きやすくなる等、体調不良が増える
　・声のトーンが暗くなる等、明らかに元気がなくなる
これは私の経験上もそうですし、以下の記事でも似たようなことが書かれています。
　
社員のメンタル不調のサイン、気づいていますか？ エムステージ 産業医サポートサービス

https://sangyoui-navi.jp/blog/31

　
家庭の事情で勤怠が乱れていたとか、単純に風邪が流行っていたとか、前兆に見えて前兆ではない場合も多いのですが、前兆が現れる前に以下のような変化がある場合は仕事が原因のメンタル不調の可能性が高いです。
　・急に仕事量が増えた（仕事の振り方や残業時間から推測する）
　・本人が経験したことがない重い責任の仕事が降ってきた
　・裁量が少なく、自分で自分の仕事をコントロールできない状況に置かれている
　
メンタル不調になりかけていると思われている場合は、関係者から裏を取った後、本人に声をかけた方が良いです。
本人の口からも仕事が負荷になっていると確認できた場合、仕事量を減らしたり、仕事の内容を変えたり、一時的に休暇を推奨したり…という手立てをすることで対処します。
ただし、メンタル不調になる方は元々自尊心が低い方が多いので、「メンタル不調を勘付かせてしまった」「自分の能力が低いせいで仕事内容を変えさせられた」と思わせてしまうとかえって逆効果になりかねません。
本人に声をかける時はあくまでも雑談や定期的な面談として声をかけた方が良いですし、何かしらの対処をする時も外的要因（お客様要望で仕事の進め方を変えるように言われた、会社の規則で決まっている、等）にした方が良いです。間違っても本人を責めるような言い方はしてはいけません。
　
ただ、メンタル不調者が出る職場は、そもそもそのような対処をするのが難しい人間関係だったりすることも多いです…。
（自分自身も追い詰められていて他人を気遣える状況ではないとか）
そのような場合は、他部署の上司や人事、産業医等、信頼できる人に状況を伝えた方が良いです。
何かしらの対処をしないと貴重な戦力を失うことになるので、将来のことを考えると放置はしない方が良いです。

ドキュメント整備の要員を確保し属人化を防ぐ

仕事をする上で上手く行った事例があるので記事化します。
　
ＩＴ業界では、たびたび属人化が問題になります。
（「ドキュメント　属人化」とかでググれば事例がいくらでも見つかります）
属人化を防ぐ王道的な手段は「ドキュメントを作る」なのですが、既に属人化状態に陥っている業務では有識者に仕事が偏っているので、有識者にドキュメントを作る時間がないというのが問題になります。
　
今回、他のプロジェクトでリリースを終え、フリーな状態で離任間近になっている方がいたため、離任するまでの間、私が関わっているプロジェクトに携わってもらいました。
私のプロジェクトでは既に属人化が問題になっていたので、その方に引継ぎドキュメントの作成をお願いしました。
有識者と一緒に仕事をしてもらい、有識者がしていることをドキュメント化する、という方法です。
結果として、有識者しかできなかった２～３の作業についてドキュメントが作られ、それらの作業について他の人に振ることが可能になりました。
　
ドキュメントを作りたいけどドキュメントを作る時間がない、という時は、ドキュメントを作る要員を別途確保することが一つの解決策になると思いました。
他の人が読んでもわかるドキュメントを作れる方は重宝するので、ドキュメントスキルも重要なスキルだということも実感しました。
（SESだと人の出入りが激しいので尚更です）

サクラエディタ：ソースコード中の変数名を完全一致で検索する

結論から言うと、正規表現で以下の指定をすることで、ソースコード中の変数名を完全一致で検索できます。
（javaの場合を想定しています。また、ソースは適切にインデントされ、文頭に変数名が存在しない（左側にスペースを全く入れずに変数名を記述するということはない）という前提です。）
　
[^a-zA-Z0-9_\$]hoge[[^a-zA-Z0-9_\$]|\r\n|\n]
　
【解説】
・「a-zA-Z0-9_\$」は「英数字・アンダーバー・ドルマーク」という意味です。
　英数字・アンダーバー・ドルマークは、javaの変数名で使用可能な文字です。
　これを[^...]（否定）で囲むことで、
　検索文字列の前後にjavaの変数名で使用可能な文字が存在しないか、
　つまり変数名を完全一致で検索することが可能になります。
・これだけだと、変数名が文末に存在するケースに対応できません。
　（英数字・アンダーバー・ドルマーク以外の文字が後ろに続く必要があるため）
　[...|...]（or条件）で改行コード(\r\n、\n)を指定することで、
　変数名が文末に存在するケースにも対応しています。
　
【確認】
下記のようなソースコードがある場合に、左辺のhogeと右辺のhogeのみが検索され、headhogeやhogetailは検索されません。
　
    hoge = hoge
         + headhoge
         + hogetail;

ゲーム理論（二人・二択）の混合戦略の確率をjavaで求める

以下の記事の続きです。
　
ゲーム理論（二人・二択）の混合戦略の確率を求める

https://akira2kun.hatenablog.com/entry/2018/12/23/180906

　
プログラムで計算する場合の計算式を書いたので、javaでサンプルプログラムを作ってみました。
　
【ソースコード】
public class GameKongoMain {
    public static void main(String[] args){

        // 各選択肢の利得を定義
        double valueAa = 2;
        double valueAb = 6;
        double valueBa = 5;
        double valueBb = 4;

        // 例外処理
        if (valueAa > valueBa && valueAb > valueBb) {
            System.out.println("劣等戦略未除外エラー");
            return;
        } else if (valueAa < valueBa && valueAb < valueBb) {
            System.out.println("劣等戦略未除外エラー");
            return;
        } else if (valueAa == valueBa && valueAb == valueBb) {
            System.out.println
            ("混合戦略の確率　選択肢Ａ：0.5　選択肢Ｂ：0.5");
            return;
        }

        // 選択肢の傾きの計算
        double slopeA = 0;
        double slopeB = 0;
        slopeA = valueAb - valueAa;
        slopeB = valueBb - valueBa;

        // 選択確率の計算
        double probabilityA = 0;
        double probabilityB = 0;
        probabilityA = (slopeB * -1) / (slopeA + (slopeB * -1));
        probabilityB = slopeA / (slopeA + (slopeB * -1));

        // 結果出力
        System.out.println
        ("混合戦略の確率　選択肢Ａ："+ probabilityA +
                       "　選択肢Ｂ：" + probabilityB);
    }
}
　
【実行結果】
混合戦略の確率　選択肢Ａ：0.2　選択肢Ｂ：0.8
　
【注記】
・各選択肢の利得の値を変えて、各例外ケースも確認しています。
・片方の選択肢の傾きが0でもう片方が0ではないケースも確認しています。
（この場合、傾きが0の選択肢の選択確率が1.0、もう片方の選択肢がの選択確率が0.0になる）

ゲーム理論（二人・二択）の混合戦略の確率を求める

ゲーム理論についてはこちらの記事で触れています。
　
情報処理技術者試験対策「ゲーム理論」

https://akira2kun.hatenablog.com/entry/2018/07/10/234859

　
上記の記事では、「混合戦略」にも触れています。
混合戦略は、何度も同じゲームを繰り返す場合において、相手がどのような確率で選択肢を選んだとしても、全ゲームで得られる平均の利得を一定にすることを意図したものです。
長期的な目で見て、利得が下がるリスクを最も軽減できる戦略です。
各選択肢の選択確率をある値にすることで、これが可能になります。
その「ある値」の求め方を、今回の記事では解説します。
　
今回は以下の前提を置きます。
・劣等戦略（相手がどのような選択肢を選んだとしても、他のある選択肢以下の利得しか得られない選択肢）はあらかじめ除外
・プレイヤーが二人で、選択肢は二択のゲームを想定
　
【今回の例で取り扱う利得表】

　
【混合戦略の求め方】
１．連立方程式を解く方法
選択肢Ａを選ぶ確率をp、選択肢Ｂを選ぶ確率を1-pとおく。
混合戦略が成り立つ時、相手が選択肢ａを選んだ場合の期待利得と相手が選択肢ｂを選んだ場合の期待利得は等しくなるため、以下の式が成り立つ。
　
選択肢ａを選択…2*p + 5*(1-p)　…①
選択肢ｂを選択…6*p + 4*(1-p)　…②
①＝②のため
2*p + 5*(1-p) = 6*p + 4*(1-p)
2p + 5 - 5p = 6p + 4 - 4p
-3p + 5 = 2p + 4
-5p = -1
p = 0.2
　
以上より、選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が1-0.2(=0.8)の時に、混合戦略となる。
　
２．微分方程式を解く方法
選択肢ａが選ばれる確率pが決まる時、選択肢ｂが選ばれる確率は1-pという形で一意に求まる。
また、混合戦略の定義は、「相手が選択肢ａを選んだ場合の期待利得と相手が選択肢ｂを選んだ場合の期待利得が等しくなるように選択肢を選ぶ」である。
そのため、混合戦略の定義は、「相手が選択肢ａを1の確率で選ぶ場合の期待利得と相手が選択肢ａを1-1(=0)の確率で選んだ場合の期待利得が等しくなるように選択肢を選ぶ」と置き換えることができる。
　
そこで、相手が選択肢ａを選ぶ確率をx軸、自分の利得をy軸に置くと、以下のグラフを得られる。
下記のグラフについて、線分Ａ-Ａ'は選択肢Ａを選んだ場合の利得、線分Ｂ-Ｂ'は選択肢Ｂを選んだ場合の利得、線分Ｃ-Ｃ'は混合戦略となる場合の利得を示している。

線分Ａ-Ａ'と線分Ｂ-Ｂ'を式に表すと以下のようになる。
線分Ａ-Ａ'の式…4x + 2
線分Ｂ-Ｂ'の式…-x + 5
　
線分Ａ-Ａ'と線分Ｂ-Ｂ'を微分し傾きを求めると、以下のようになる。
線分Ａ-Ａ'の傾き…4
線分Ｂ-Ｂ'の傾き…-1
　
ここで、線分Ｃ-Ｃ'は混合戦略であり、xの値によらずyは一定のため、傾きは0である。
線分Ａ-Ａ'をpの比率で、線分Ｂ-Ｂ'を1-pの比率で合成し、線分Ｃ-Ｃ'を生成する場合、比率pは以下の式で求まる。
　
4*p + -1*(1-p) = 0
5p - 1 = 0
5p = 1
p = 0.2
　
以上より、選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が1-0.2(=0.8)の時に、混合戦略となる。

【検算】
選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が0.8の時の期待利得を求める。
　
相手が選択肢ａを選んだ場合、自分の期待利得は以下のようになる。
2 * 0.2 + 5 * 0.8 = 0.44　…①
　
相手が選択肢ｂを選んだ場合、自分の期待利得は以下のようになる。
6 * 0.2 + 4 * 0.8 = 0.44　…②
　
①と②が等しいため、選択肢Ａを選ぶ確率が0.2、選択肢Ｂを選ぶ確率が0.8の時に混合戦略となる。
　
【混合戦略の簡単なイメージ】
教育機関で教えられるのは連立方程式を解く方法で、複雑な状況に対応することを考えるとこちらの方法を用いるべきです。
しかし、プレイヤーが二人で選択肢が二択というような簡単な状況では、微分方程式を解く方法の方が簡単にイメージできます。
　
傾きを合成して0にするだけなので、簡単に書いてしまうと「選択肢Ａの傾き:選択肢Ｂの傾き*-1」の逆数がそのまま「選択肢Ａを選ぶ確率」と「選択肢Ｂを選ぶ確率」になります。
上記の例で言うと、「4:1」の逆数「1/4:1」=「1:4」=「0.2:0.8」が「選択肢Ａを選ぶ確率」と「選択肢Ｂを選ぶ確率」になります。　
　

手続き型のプログラムで計算できるように計算式を書くと、以下のようになります。
　
   選択肢Ａの傾き
 = (選択肢Ａ・選択肢ｂの時の利得 - 選択肢Ａ・選択肢ａの時の利得)
　
   選択肢Ｂの傾き*-1
 = (選択肢Ｂ・選択肢ｂの時の利得 - 選択肢Ｂ・選択肢ａの時の利得)*-1
　
   選択肢Ａの選択確率
 = 選択肢Ｂの傾き*-1 / (選択肢Ａの傾き + 選択肢Ｂの傾き*-1)
　
   選択肢Ｂの選択確率
 = 選択肢Ａの傾き / (選択肢Ａの傾き + 選択肢Ｂの傾き*-1)
　
　　※以下の場合は劣等戦略未除外エラーとする。
　　　・選択肢Ａ・選択肢ａの時の利得 > 選択肢Ｂ・選択肢ａの時の利得 かつ
　　　　選択肢Ａ・選択肢ｂの時の利得 > 選択肢Ｂ・選択肢ｂの時の利得
　　　・選択肢Ａ・選択肢ａの時の利得 < 選択肢Ｂ・選択肢ａの時の利得 かつ
　　　　選択肢Ａ・選択肢ｂの時の利得 < 選択肢Ｂ・選択肢ｂの時の利得
　　※以下の場合は選択肢Ａの選択確率・選択肢Ｂの選択確率を共に0.5とする。
　　　・選択肢Ａ・選択肢ａの時の利得 = 選択肢Ｂ・選択肢ａの時の利得 かつ
　　　　選択肢Ａ・選択肢ｂの時の利得 = 選択肢Ｂ・選択肢ｂの時の利得
　
人間がイメージしやすいように書くと、リスクの高い選択肢（相手が選ぶ選択肢によって利得が大きく変わる選択肢）を選ぶ確率を少なめに、リスクの低い選択肢（相手が選ぶ選択肢によって利得が大きく変わるらない選択肢）を選ぶ確率を多めにすると、混合戦略に近くなる、と書けます。

戦略考察を行う上でのゲーム評論の考え方の有用性

完全に趣味の話になりますが、ゲーム評論の話です。
私の趣味は戦略の考察なのですが、ゲーム評論の視点は戦略考察の幅を広げるのに役立ちます。
　
中でも参考になったのはGameDeep様の考察です。
　
GameDeep

http://gamedeep.niu.ne.jp/
　
ゲーム評論の世界では、「ゲームとは何か」という哲学的な問いや、プレイヤーとゲームの関係性、ゲームの楽しみ方といった話題について取り扱っています。
与えられた問題に対する合理的な解答はゲーム理論の考え方や情報学（人工知能）の考え方から導くことができますが、問題の定義はこれらの考え方では行うことができません。
問題の定義を行う上で役に立つのが、ゲーム評論の考え方です。
　
例として、ある対戦ゲームで使われる戦略の流行を読む場合を考えてみます。
ゲーム理論の考え方から流行を読む場合は、「プレイヤーは勝率の最大化を目的とする」という前提を置いた上で、他の戦術と比べて何かしらの面で優れている戦略（劣等戦略ではない戦略）をいくつかピックアップし、利得表を作成し、利得表に基づいて各々の戦略が使われる確率を推測する（混合戦略の確率を求める）、という手順で流行を読みます。
しかし、実際には、世界観を楽しむ目的で他の戦術と比べて劣っている戦略を使ったり、交流を楽しむために見ごたえのある戦略を重用したりするプレイヤーが存在します。そのようなプレイヤーは「プレイヤーは勝率の最大化を目的とする」という前提から外れているため、誤った前提から導いた結論も誤りとなってしまいます。
正しい前提の求める上で、ゲーム評論の考え方が役に立ってきます。
対戦ゲームの世界感や対戦会の形式等を分析することで、どのようなプレイヤーがその対戦ゲームに誘引されるのかを予想することができます。誘引されたプレイヤーの目的が、本当に置くべき前提となります。上記の例では、「キャラクターに魅力があるゲームである」「意外性のある戦略で勝つと気持ちいいしギャラリーも盛り上がる」といったゲーム評論的な分析が行われていれば、「勝率の最大化を目指すプレイヤーもいれば、キャラクターの魅力を引き立てようとするプレイヤー、見ごたえのある戦略を使おうとするプレイヤーもいる」という正しい前提を求めることができます。
　
なお、個人的な話をすると、ゲーム評論の考え方は、「プレイヤーの目的が多種多様」という特徴を持つ恋愛分野にて特に役立ちました。