ゲームサーバー勉強会を言った際に、
「作業人員の増減や、人員配置は、起きて当然という事を前提に、支障が出ないように対策をした」
のようなニュアンスの話が上がった。
プロジェクト進行を円滑に行えるようになりたいと思っていたが、この前提の事は深く考えたことが無かったという事で、少し考えてみた。
〇引継ぎってそんなに頻繁に起こるの？
引継ぎというと、何か大がかりな事のように思えるが、そんな事はない。
例えば、開発中期でメンバーAさんがフレンドリストの実装を行ったとして、その時点では完了していたが、メンバーAさんが他のチームに移動した後のフレンドリストの仕様変更が入れば、それはもう立派な引継ぎが発生しているのだ。
つまり、他人が書いたソースコードを読む可能性がある時点で、それは引継ぎをする可能性があるという事だ。
〇引継ぎをしないと、何が問題なのか？
そして、筆者が思う引継ぎをしないと問題、というよりも実際に困った事は2つある。
１．何故そのように実装されているかの設計思想が無いので、何となく気持ち悪く感じる
２．ツールの使い方や、ファイルの命名規則など、何かしらのルールや手続きが必要な作業があるが、それがわからないので、作業に支障がでる（推測して正しいかどうか根拠がない状態で運用するか、1から作り直す事になる）
この2点だ。
１に関しては、大きな実害はそんなにないかもしれないが、それでも例えば本来必要である箇所の処理がコメントアウトされていたりすると、そのコメントアウトを外してはいけない理由等をトレースして追わなければならなくなってしまう。
２に関してはかなり深刻で、作業が属人化してしまっているのがそもそもの問題なのだが、ルールや情報がチームに共有されていないと、作業に支障が出る事がある。
実際、別の記事にも少し書いたことがあったが、一番初めの会社で、プロジェクトで独自の画像変換ツールを使い、独自のフォーマットを使用するという事をしていたが、Windowsアップデートか何かの影響でそのツールが使えなくなってしまい、急遽ツールを作ることになった。
しかし、そのツールのソースコードもなければ、画像のフォーマットの詳細説明資料もなく、存在した情報は
・変換前と変換後の画像ファイル
・それらを読み込んでいるゲーム側のソースコード
ここから、全てを推測して作る事になってしまった。
時間がかかったのは言うまでもないし、それが正しいかどうかの根拠は「とりあえず正しく表示されているようにみえる」という、何も裏付けがない状態になってしまっていた。
〇問題を解決するのは、どのような事が考えられるか
筆者が思うのは、1，2の問題どちらにも言える事だが、結局の所、資料を残してもらわないと困ると考える。
しかも、それはプロジェクトの終盤にまとめて作成するのではなく、機能等を作成したら、その都度その資料を作る必要があると考える。（これは、ある日突然居なくなったら、引継ぎも糞もないため）
となると、資料作成というのは特別な事ではなく、実装業務の一部として捉えて日頃から行える体制づくりが必要だと考える。
ぶっちゃけ、今までこのトピックに関して考察した事が無かったため、上記提案も試したことが無いしうまく行くかわからないが、せっかく考案したので、今居るプロジェクトから早速試してみる事にする。
〇余談：他の方法は考えられるのか
恐らく、読者の中には、「ソースコードレビュー」だとか「設計を予め全員で共有する会」だとか、いろんな方法は考えた方が居たと思うが、それはそれぞれ間違いではないと思っている。なぜなら、それらは問題解決（目的）の為の手段なので、それを行う事で問題が解決されるのであれば、それはそれでいいと思う。
ただし、漫然と目的が無くソースコードレビューをしているだけだったら、それは間違いなく何の問題解決にはなっていないとだけ言っておく。
