最近の仕事で、色々もやもやしてきたので書き留める。
誰も何も考えていないようなルール
パートナー稼業でのSEという仕事柄、旧来からのシステムに触れる案件がいくつもあり、 たいがいの保守的な現場でいつ立てたかわからないお触書のようなルールをたくさん見てきた。
- Gitを採用し変更履歴がすぐに見れるのに、修正の際に // add や // mod コメントを付与し旧コードはコメントアウトし記述は残す。
- JavaのWebアプリの案件で、COBOLのクライアントアプリのときに作られた汎用的なコーディングルールを順守するようにしている。
- 先進的なフレームワークを取り入れるのに、社内プロキシによりブラウザからGithubへのアクセスが禁じられている。
明らかに開発ワークフローを阻害するルールはだいたいわかりやすく一覧化されている。
きっと、作った当初はそれなりに考えていたし、今まで変えられずに引き継がれているのはそれなりの理由があると考えるのが妥当だ。
つまり、過去プロジェクトにより開発された資産/手法/知識が、来るべき時にメンテナンスコスト（負債）としてこの手に渡ってきただけのことになる。
コードにちりばめられた暗黙のルール
昨今の技術系記事で「〇〇パターンに従って鵜呑みに実装するのは全然理解できてないよね」と言及しているのをよく見る。
むやみやたらに「操作を抽象化したクラスから実態を生成し動作を動的に切り替えているから〇〇Strategy」とか命名規則をつけてコメントに「〇〇のStrategyクラスです」とだけつける、など。
この実装は、開発ワークフローにおいて「Strategyというパターン名を事前に理解しておくこと」という暗黙のルールを組み込む。 Strategyパターンというのが、実装上非常に理にかなっていて理解必須なのであれば有用だが、それ以上のメリットは見込めないだろう。（いわゆるDIもこのパターンを継承しているが、恐らくStrategyの名前を出すだけで終わるのは非常に厳しい。）
また、システムを覗くと、文面化・一覧化されてすらいないルールで埋め尽くされていることが多い。
仮にセミナー管理システムがあっとしたら、きっと次のようなルールがあるだろう。
- あるセミナーを設定するには、講師を選択する
- 講師は講師グループに属しており、大阪、名古屋などの地理的な分類、セミナーの専門性による分類を反映したものであるセミナーの種別によって選択できる・できないがある
- ある講師グループは、特定のセミナーしか受けられないような特殊な条件が含まれる
- 講師は資格や業務上のランク、および稼働時間上限ブッキングや休暇を考慮する必要がある
これだけなら小中学校の面倒くさい文章題を解くようなものかもしれないが、ここから画面やバッチに落とし込んだとき、もはや別制約が生まれてくる。
- 講師は事前に審査などのワークフローを追加したシステムを経由して登録されている必要があり、適切なデータを用意して担当部署やバッチの処理を待たないと登録できない
- 講師グループ入力は間違えることができず変更が多々あるので、担当部署で一元的にマスター管理している。また、現場目線での管理項目を持っている。
- セミナー実施または中止後の実績入力は、各部署が必要なすべての管理項目を入力する必要がある。
もはや誰も理解したくないような現状が突貫で出来上がり、だいたい初版システムは「各位の利害のすり合わせが十分にできなかった」と評価が下される。
そしてだいたい、改修案件がちょろっとした工数で「うちもAI取り入れる」とか「マーケティングツールと連携する」と立ち上がる。
業務ルールが増えていく中、「三方良し」よろしく各位の効率の良いワークフローを維持し続けるのは至難だ。
ゴシップ的に「古いルールが悪」というのは危険思想
システムのルールに対して、最初参画したときは文句を言う人はいれど、長らく保守で馴染んだり開発したりした後はごく少ないはずだ。
ごく個人の分析では、それを踏襲しないとワークフローが成立しないことを知っているか否か、とみている。
たとえば、冒頭で出した３例からとりあげよう。
- Gitを採用し変更履歴がすぐに見れるのに、修正の際に // add や // mod コメントを付与し旧コードはコメントアウトし記述は残す。
これも、並行開発・納品されたコードをマージするときは、何も考えずにコメントの範囲を切り貼りすればよく、加えて必要範囲外の修正を抑制する効果もある。 コミット作業する人物がGitに不慣れで、色々修正した後に一括コミットしてしまい、どこが誰の修正によって入ったかがGitログで判別できなくなった、というの避けられる。
これらを低減するには、「他社や他プロジェクトからのマージは、必ずGitのコミットログごと納品させる」「マージした時点、手直しした時点で２段階にコミットを分ける」などの新たなルールで置き換えて、わざわざ各開発者必読の読み物を１つ用意する必要がある。
こんなとんでもルールだって、実はISO9001を取得した際の重要な証跡であり、変更するには全社的に見直しをする必要があるかもしれない。
管理視点、コストゲーム観点からすれば、そのままにするのも理解できないことではない。（現状をそのままにしておくのは、感性が鈍いとしか言いようがないが）
もしほんとうに根絶しようとするなら同じ土俵に上がりこんで、理解して否定すべきではないか。
蚊帳の外から好き放題に言うのは、ゴシップ誌が揶揄されている点にひどく似ている。
ワークフローとルールをデザインするために、恐れずルールを持ち込む
ワークフローを規定する上で、ルールは非常に強力な道具だ。 ワークフローを破壊する規定外の行為を制限する一方、プラス方面への想定外の作用も制限する。
１つのコードを持ち込むことで、ルールが生まれる。 つまりはそのコードをメンテナンスしたり、別ベンダーに渡したり、読んだり、あるいはシステムを使ったりするうえで影響する。
つまりは、どうあがこうと書いたコードは引き継ぐ誰かに影響するし、ならばこそいいものを作ればよい。
ちなみに、私は、ルールを必要最低限に最小化しようとする。
一番の理由は至極個人的で、あまりあれこれと試行錯誤しようとしない、色んな手段があると管理できなくなる、一つのよくできたツールを深く使いこなすのが好きだからだ。
だが、最近Golangに触れ評価されているところを見ると、割と普遍的かもしれない。 ミニマリズムは、コードを引き継ぐものが抱えるルールを減らしてくれる。開発ワークフローについてまわるすべてを効率化してくれる。
書いているものは例え小さいコードであっても、デザインの余地はある。
