「わからないことあれば聞いてください」VS「仕様書作ってください」

先日、とある会社の新規開発部門の会議に参加させていただきました。 その会社は、会社のサービスの核となるAPIをインターネット初期ぐらいから構築してきていて、 まあまあでかいシステムを保持しているんですが、 残念なことに、社員が取っ替え引っ替え辞めていく、組織構成の弱い会社でもあります。 そして、新たに新規開発をやるとのことで、システム企画を立ち上げたらしいのですが、 API仕様が分かっていない為に、かつて開発を担当した（今は外部会社のエンジニア）を召喚して ミーティングの場を設けたという、正直自分にはなんの関係も無いミーティングでした。 でも、技術顧問というか、ITコンサルティングを少しだけ兼ねて請け負っている為、お付き合いで会議に参加してあげたというのが本音です。

ブラックボックスシステムにぶち当たったエンジニアの考えること

その会社のAPIは、サーバーを10年ぐらい前にリプレイスされたらしいのですが、サーバーモジュールも今となっては古く、サポート対象から外れている危険な状態です。 それに加えて、APIの内容が数千ファイル存在するみたこともないフレームワークの上、とてもテストをしているとは思えない乱雑なプログラミングコードだったので、 正直ブラックボックスと言ってもいいと思います。 今回このAPIを使わないといけないエンジニアは、とりあえず内容把握の為に「仕様書を作って欲しい」というオーダーを、会議冒頭に依頼していました。 このAPIシステムは、インタプリタなので、頑張って読み解けば仕様を理解することは可能なのですが、 数千ファイル + 過度なバケツリレー方式のオブジェクト指向構造（ファイル名とクラス名などがまるで整っていないツンデレぶりです）。 実際にソースコードはあるけど解析できるスキルを持った人がいない状態（または外部に委託するための前段階）のため、概要すら理解できていないのだそうです。 実際に開発環境などもあり、テストをする状態ではあるんですが、何かを変えるとどこかが壊れそうで怖いし、 何が正解なのかわからないという状態らしく、今回取りかかろうとしているシステムの着手段階でつまづいているようです。

システムを構築した担当者の思惑

一方、そのAPIシステムを初期構築した張本人のエンジニアは、 「わからない事があれば、なんでも聞いてください。」 という物腰柔らかい姿勢で会議に参加していたんですが、仕様書を書いて欲しいというオーダーに対しては、 コード内にコメントで残してあるし、「そもそも、アルゴリズムは、専門書籍を読んで理解してもらわないといけない」という一点張りでした。 その上で、「不明な点は、親切丁寧に説明して、教えて、ご教授させていただきます。」と言い続けていた感じですね。 でも正直、10年以上前のコードなんて、全ての箇所を覚えているわけではないのが本音なんでしょう。 システムって、結局は人力でしか保守できない状態だし、メンテナンスという運用をし続けなければ簡単に駆逐してしまうモノだということが改めて理解できますね。

押して引いてのせめぎ合い

新規開発チームは「ちゃんと情報をもらわないと進められない」と押すのに対して、 元担当者は「ここまで教えたら、あとはなんとかしてよ、わからないところは聞いてくれれば教えてあげる」と食い下がる。 両者の間で調整役が板挟みになる自分としては、どちらの気持ちもよくわかるが、なんとか解決法を見出さなければ、この会議は終わりが見えない状態。 こんな時は、正直どちらが折れると言うのではなく、両方に歩み寄ってもらうというのが、はじめの一歩になるだろうと考えてみた。

何が正しいのか考えてみた

理想はドキュメント整備とナレッジ移譲なのは間違い無いけど、 仮にこうしたAPIのドキュメントを作ろうと思ったら、技術書籍数冊分ぐらいのボリュームになるし、 使い方やチュートリアルみたいな構成の内容にならないと、全部隅から隅まで見て理解するなんて学習コスト高すぎるしそれだけでおそらく数ヶ月費やしてしまう可能性もある。 一方で、テストサイトや、実コードの中身を見てもいない開発スタンスの新規チームは、最初からわからないと決めつけてかかっている為、開発員としての気質が少し低苦感じた為、 こりゃ、水と油状態という事がよく分かった。 現実としては、 目先の納期や人員都合でそれができない「とにかく動かすことが正義」という文化が根付いていると、いつまでも同じことを繰り返す、組織の問題も根底にある。 でも、今回は組織問題は、この部門の上長に委ねて、経営者部門にしっかりと考えてもらうことにするとして、 まずは、開発員はテストサイトで手を動かしてシステム理解をするのと、同時に、ソースコードのコメントぐらいには目を通しておく（これが現時点でのドキュメント）。 元技術者に対しては、テストで何をどうすればいいかの最低限のナレッジ（Howto）ドキュメントを作ってもらうのと、APIシステムのモジュールアップデートに伴うリファクタリング作業のサポートをしてもらう。 これで双方歩み寄ってもらうことにした。

システムはナマモノ

組織と同じで、触れないと腐るというのは、まるで野菜や果物と同じであると言うことを、非エンジニアは知らないんですよ。 誰も手を付けない部分はブラックボックス化していき、ディザスタームービーなどでよくある、廃墟の街みたいになってしまうんですよね。 時間が経つほどリファクタリングコストが跳ね上がるので、経営陣としては、見てみぬふりをしてしまいがちになる。 本来組織は、こういう事態にならないように、ちゃんと運用をするという姿勢を持たないといけないのだが、経営陣にエンジニア（技術者）が存在しないと、 こうした運用計画は形骸化されて、売上や利益に特化した運用しか議論されていない経営会議が行われてしまう。 IT会社であれば、できればこういう状態は避けたほうがいいというのは、技術者としての自分からのささやかなアドバイスです。

半世紀先まで運用され続けるシステムの定義

実際に、Web系の公開サービスで10年以上続くサービスは、割合としても少なく、 2~3年ぐらいで、基本構成やデザインの刷新が必要とされる傾向があるようです。 参考（英語）: What is the Average Website Lifespan? + 6 Ways to Increase It そして、Webサイトの寿命は、3~5年ぐらいが平均的なのだそうです。（業界別に開きがありますが） 保守をしながら行っているサービスでも、6~8年ぐらいが、平均寿命という事も言われているようで、個人的な感覚的にもそう思います。 余談ですが、ハードウェアとしては3〜5年が入れ替えタイミングで、クラウド利用ならば4〜5年の「有効寿命」を想定する例もあるようです。 参考（英語） : Server Statistics じゃあ、どうすればいいのかというと、システム開発者としての意見というかよく言われている事としては、次のような事が重要とされています。

1. 書き換えやすい仕組みを持つ 2. 担当が代わっても解析できる状態を保つ

価値が生まれ続けるからこそ半世紀以上運用されるという、需要と供給の関係があるし、 そもそもマネタイズできて、利益を生み出さないと、運用コストも賄えない状態になりますからね。

あとがき

今回のミーティング、正直ほぼ聞き役に徹しましたが、技術の現場で同じ課題が繰り返される現実を改めて実感しました。 システムと組織の持続性について、もっと考えていかねばと思った次第です。 他人の開発問題は、対岸の火事ではなく、「自分ならこうする」的思考で受け止めるようにしているんですが、 このAPI、自分が使うなら、徹底的に時間をかけて自分コードに書き換えるのにな〜と会議中、心の中で思ってしまいました。 きっと、それに膨大な時間をかけるか、AIなどを使って、手早くやってしまえるかは、仕事スタイルでの効率化を意識できているエンジニアの思考なのかもしれませんけどね。