経緯
要求仕様は漠然とあるものの、社内向けなのか社外向けなのかすら不明という驚くほど適当な仕事が回ってきました。
また、開始当時は自分ひとりのプロジェクト（？）。ただし要求仕様自体は上流工程である程度作られる……という話でした。
また、後からテストメンバが追加される、という話もありました。ていうか自分ひとりでは行き詰ることが目に見えていたので要求しました。
申請が必要な社内リソースは、そもそもお願いしても使わせてもらえませんでした。
さて、上で「プロジェクト（？）」と書いた通り、この仕事プロジェクトとして回すべきものだったのですが、上記の通りものすごく適当な始め方をしました。有体に言ってプロジェクトとしての体をなしていないです。
私が勤めている会社は、完全にトップダウン型で、ボトムアップの意見は全て死ぬという特徴があります。（社内ではＰＤＣＡという言葉をよく見かけるのですが、そもそもＰの時点で却下されるので何も変化が起きません。変化がないＰＤＣＡってすごいなー）
もっとも、よく言えば統制がとれている、ということもできます。その会社組織において、こんな適当なプロジェクトはまたとないチャンスです。
つまり、専任が私一人しかいない＝私が担当者 でやりたい放題に近い、というわけでです。
せっかくなので、これまでのやり方を色々変えてみることにしました。
変更点一覧
ソース管理：TFS → GitBucket
連絡： 電話・メール → Teams
仕様書：Excel → Markdown
ソース管理
TFSはGitではなく従来のもの。チェックアウトしてチェックインして……というものです。
主に一人で開発していくため、ソース管理を怠ると
開発マシンの死＝ソースの全滅＝プロジェクトの死
となりかねません。というわけで、ソース管理は最重要です。
しかし、TFSは管理責任者がいます。責任者の許可がないとプロジェクトを追加できません。そして上記の通り、申請が必要な社内リソースは使わせてもらえませんでした。
というわけで、以前空いているPCに立てたGitBucketを使うことにしました。
これならGitなのでいちいちチェックアウトなんてしなくても快適に開発を進められます。
また、Issue 管理やWikiも使えるので簡単なプロジェクト管理もできます。
連絡
プログラミング中のプログラマにかける電話の数と、バグの数は比例すると私は考えています。
また、要求仕様を作成する人は、本業のプロジェクトを別に持っており、そちらにリソースの大半を食われていました。そのため、打ち合わせや電話はほぼできません。
よって、非同期に連絡がとれる手段が必須となりました。
そこで、リリースされたばかりのTeams を使うことにしました。これを利用するのに申請不要だった、というのも大きな理由です。
さて、この手の「連絡手段」は、放っておくとメールになってしまうのですが、それは全力で止めました。
具体的に言うと、メールの内容は「私的会話」とみなしました。「メールで送った内容なんですが～」と言ってきたら、「メールだったから読んでない。Teams に上げて」と言いました。
サラリーマンとしては非常に良くない態度なのですが、そうしないと勝手にメールを使い始めてしまうので断行しました。
ここまでメールを拒否したのは、
・後から人員が追加される＝その人たちに状況を説明する際、過去のメール全てを確認してもらうわけにはいかない
・増減する人員が不明＝誰がメールを必要とするのか全く分からない
・メールだとレスポンスが遅すぎる
・特定の人たちだけで交わされるメールを防止する
という問題と狙いがあったためです。
意外なほどに、メール連絡を止めさせるのは難しいのです。
仕様書
個人的にExcel方眼紙はそこまで嫌いではないのですが、Excel で書かれた仕様書は差分比較がしにくい（できないわけではないが）のが嫌だったので殆どMarkdown に切り替えました。
差分比較ができないがゆえに一番初めのシートが「更新履歴」になっているというのは本当無駄だと思います。しかも更新履歴に漏れ・間違いがあるという。
色々な反発
変化を嫌う人達はたくさんいます。
変化を受け入れないでＰＤＣＡとか笑わせるな、と言いたいですが、ＰＤＣＡを叫ぶ人ほど変化嫌いで規制こそマネジメントだと思っている節があります。
というわけで、まずソース管理はTFSでやらなきゃダメだ、と駄々をこねる人が出てきました。
私も本音では、そこらのパソコンサーバに建てたGitBucketより、専用サーバで運用されているTFSに乗り換えたかったのですが、いかんせん許可がでないので何もできません。
「じゃあ許可とってきてください」でこの件は終了させました。
次に口頭で済ませようとする人たち。
短期的な時間効率では直接、あるいは電話による口頭は最大効率を誇るコミュニケーション手段なのですが、いかんせん話している人たちにしか情報共有されないんですよね。限られたメンバ間でしか成立しないこのやり方は、今様に言えば「場の共有」がされないコミュニケーションになってしまいます。
もちろん、状況によっては口頭でもいいし、ある程度は許容してきたのですが、基本的にはTeams に上げさせるようにしました。これについては、だんだん理解されてきた（あるいは私が強制したので諦めた？）らしく、後半になると「Teams に上げておきます」という人が増えました。
そしてTeams上で「会話をしない」人たち。
「ほげほげ の件なんだけど、おかしくない？」「ほげほげ の件、どうなってる？」と話題を振ってきた後、他のメンバがそれに応えても、ありがとう も 分かりました も何のレスもなく、解決したのかなんなのか分からないというもの。
多分、メール＋トップダウ���文化の名残なんでしょうが、やたら投げっぱなしにしてくる人がいます。
これに対しては具体的な打ち手が構築できず、最後まで悩まされました。
Git を使おうとしない人たちも困りました。
最近はVSでもGit が使えるので、VSからTFSにアクセスしている人たちは、Gitも利用できるはずなのですが、なぜか頑なにGitを使おうとしませんでした。
Clone して 中を見てもらうだけでも良かったんですが……。それすらやってもらえませんでした。
Markdwon で仕様書も作っていましたが、これも見向きもされませんでした。悲Ｃ。
Temas の大失敗
知らなかったというのが最大の理由なんですが、Teams って会話の中にアップロードしたファイルがsharepoint の中で管理されちゃうんですよね。てっきり使い捨ての領域だと思っていたのですが。
例えば、「キャプチャ.png」の画像を二枚上げると、「上書きする？ 別管理する？」というように聞いてきます。
これの何が問題って、書きかけの仕様書がTeams の会話にアップロードされて「どうよ～」「どれどれ～」と言っていたら、そのままそこで仕様書が管理されはじめてしまったんですね。
そこは仕様書の置き場所じゃないっちゅうねん。
と言っても後の祭り。一回運用が始まってしまうと、他で管理することは難しく、あっというまに管理できない仕様書が増えました。
Slackの感覚で使っていたので、このTeams の仕様は想定外、かつ極めて不便なものでした。
使い勝手からすると最悪だと思えるのですが、きっとこれはofficeの連携を重視した結果なのでしょうね……
成功したと思える部分
上で散々問題点として挙がったTeams ですが、評判は上々のようです。
「メールより気楽」「メールよりレスポンスが早い」「議論しやすい」など。
やはりメールと比較してどうか、という点がポイントのようです。
GitBucket については、私が使いこなせていない・他メンバに説明しきれなかった面が目立ちましたが、当初の目的は達成されました。仕様書へのアクセスのしやすさ、ではやはりTFSより上であり、後半はなかなかの活躍だったのではないかと思います。
まとめ
一度に色々変えましたが、やはり手を広げすぎた感じはします。
個人的にはやりやすかったですが、他メンバがやりやすかったかというと疑問が残るところでしょう。
説明不足だった点もあって、この辺は反省点です。
また、ＰしてＤしてＣした結果、「いいんじゃね？」というところも出てきた今回のチャレンジですが、
「全部止めろ」
というＡが（上層部より）さっそくきているようですｗ
私が勤めている会社は、完全にトップダウン型、ボトムアップの意見は全て死ぬところなので、この展開は予想通りでしたが、やっぱり虚しいものがありますね。
