投稿者: tonosaki

棋士の羽生善治さんが書いた「決断力」という本を読みました。

その道の第一人者というのは、経験に裏打ちされた独自の哲学や考え方を持っていて、ハッとさせられることが沢山あります。今回は、そのうちの幾つかをご紹介します。

読んでいれば、相手の刀がかすめても怖くない

著者は、複雑な局面になった時、何度も整理し直すそうです。そして、時間をかけて次の手を決断した後は、例えそれが返り討ちにあう恐れのある危険な手であっても、踏み込んで行くそうです。

「よく考えて行動しよう」と「悩む前にまず行動」。私の人生の中で、どちらも耳にしたことのある教訓です。前者は、考えなしの軽率な行動を戒め、後者は行動に踏み切れない臆病さを戒めています。

（私を含む）アプリ開発者にとっては、「よく考えて設計しよう」とするものの、複数浮かんんだ設計案に優劣をつけられず、「悩む前にまず行動」と気まぐれで決めてしまう事が、良くない例といえるでしょう。

私が質の高い設計をする為に大切にしているのは、一見どちらの設計案でも良いように見えても、そこで思考停止せず、論理的な理由付けできるまで両者の違い（メリット・デメリット）を考え抜くことです。

ポイントは「考え抜く」ことで、「悩み」に陥らないことです。
「イシューからはじめよ―知的生産の「シンプルな本質」」の安宅さんは、「悩み」は問題解決を目的としていない思考であり、仕事においては無駄な時間でしかないと説いています。時間をかけても判断材料が増えないようなら、それは考えているのではなくて悩んでいると言えます。

考え抜いて、可能な限り判断材料を集めて、勇気を持って決断する。これが、あるべき設計の姿だと思います。

しかも、設計中は小さい差だと思っていたものが、コーディング・テスト・実運用と進むにつれ、大きな違いに変わっていくこともよくあります。小さい違いだからといって、油断はできません。

対局後は、体重が２〜３Kgくらい落ちる。

著者は、大舞台での対局後に体重が２〜３Kgくらい落ちているそうです。サッカーなどの激しいスポーツであればいざ知らず、純粋な頭脳競技と言える将棋でそうなることに、とても驚きました。

「考える力」というものは、抽象的なものではなく、スクワットで大腿筋を伸び縮みさせるのと同じくらい、リアルな「運動」なのかもしれません。

私は、考え抜くことを要求されるアプリ開発者なので、実は、設計が終わったら体重が落ちているのかもしれません。今度、測ってみます。お菓子を食べながらやっているので、むしろ増えているのかもしれませんが。

業務システム、Webサイト、クラウドサービスなどを提供している企業やIT部門では、通常、本番環境の他にテスト環境（ステージング環境）を持っています。改修を加える度にテスト環境で動作確認を行い、検査にパスしたプログラムのみを本番環境にインストールします。

このような用途の為、テスト環境は本番環境と同じシステム構成になっています。
しかしながら、同じシステム構成であるがゆえに「テスト環境を使っていたつもりが、実は本番環境だった！」というトラブルも起きやすいのが実情です。

NCSwitchを使えば、このようなケアレスミスを予防して、本番環境とテスト環境を安全に使い分けることができます。

NCSwitchの導入イメージ

まず、本番環境とテスト環境の双方にアクセス可能なWindows端末へ、NCSwitchをインストールします。その後、後述する設定手順に従って操作すると、「本番環境」「テスト環境」という２つのショートカットがデスクトップ上に作成されます。

使いたい環境のショートカットを起動すると、デスクトップの背景が切り替わると共に、他方の環境へのネットワークアクセスがブロックされます。

 

設定手順

以下の手順で、テスト環境用の設定をNCSwitchに保存します。

1. Windowsファイアウォールに新しい規則を追加
   本番環境へのネットワークアクセスをブロックする規則を作成します。
   「コントロールパネル」から「Windowsファイアウォール」を選択し、”詳細設定”を開きます。画面左側の”送信の規則”を選択してから、画面右側の”新しい規則…”を選択すると作成ウィザードが開くので、以下のとおり入力します。

   規則の種類	カスタム
   プログラム	すべてのプログラム（デフォルト）
   プロトコル及びポート	任意のプロトコル、全てのポート（デフォルト）
   スコープ	ローカルIPアドレス：任意のIPアドレス、リモートIPアドレス：本番環境マシンのIPアドレス
   操作	接続をブロックする（デフォルト）
   プロファイル	ドメイン、プライベート、パブリックを選択（デフォルト）
   名前	“本番環境アクセス禁止”

2. デスクトップのテーマを選択
   「コントロールパネル」から「個人設定」を開き、Windows7テーマを選択します。
3. NCSwitchに設定を保存
   スタートメニューからNCSwitchを起動し、「ファイアウォール」と「デスクトップのテーマ」を保存します。名称は「テスト環境」にします。

   

   

続いて、本番環境用の設定を保存します。

1. ファイアウォール規則を無効化
   「コントロールパネル」から「Windowsファイアウォール」を選択し、”詳細設定”を開きます。先ほど登録した規則のプロパティを表示し、有効のチェックを外します。

   

2. デスクトップのテーマを変更
   デスクトップ背景を、注意を促す「赤色」に変更します。
3. NCSwitchに設定を保存
   「ファイアウォール」と「デスクトップのテーマ」を保存します。名称は「本番環境」にします。

まとめ

NCSwitchは使い方も簡単で、すぐに導入効果を実感できます。NCSwitchを活用して、安全なシステム運用を実現しましょう！

NCSwitchのダウンロードはこちらから。

人や物の動きを検知

前回に続いて、今回もOpenCVを使ったデモです。Lucas-Kanade法を使った移動物体のトラッキングをご紹介します。

トラッキングにより、Webカメラに映っている人や物の動きを、コンピューターが検知できるようになります。例えば、寝ている赤ちゃんがグズった時に親のスマホに通知したり、マウスやタッチパネルに触れることなく、画面を操作するようなアプリが作れるという事です。

Lucas-Kanade法は、有名なトラッキング手法の一つです。ざっくり説明すると、この手法は、動画のフレーム画像の個々の画素（ピクセル）の色や明るさが、時間と共にどの方向へ移動していくのか探索することで、物体の動きを把握しようとします。

こんな感じになりました

左上に、動いた方向が表示されています。赤い線が、追跡できた動きです。この動画の終盤を見て分かる通り、１センチ程度の震えでも、コンピューターに検出されてしまいます。もしこれを使って「だるまさんがころんだ」遊びをすると、きっと、最初に鬼が振り向いた瞬間に全員つかまります。

デモを作っていて分かったこと

探索精度よりも、ノイズの除去が大事

人が写るくらいの距離で撮ったビデオや写真には、探索に使用できるピクセルパターンが山ほどあります。なので、探索精度をいくら向上させても、ノイズだらけで役には立ちません。人の動きを期待どおりに検知するには、ノイズをきちんと除去する事が大切でした。

試行錯誤した結果、思い切ってフレーム画像を1/10まで縮小してから処理させてみると、ノイズを９割がた消してくれるようになりました。残り１割は、ローカット（閾値よりも動きの小さい線を除外）して対処しました。

縮小することで、処理画素数が減ってCPU処理コストも下がって一石二鳥でした。

光源の向きにも気を配る

光源の向きにも気を配る必要があります。コンピューターは、顔や手など、特徴的な見た目の物体をトラッキングするのは得意ですが、壁のような一様でのっぺりした物体は苦手です。特に顔の動きを追跡しようとするとそうなのですが、逆光になってしまうと、カメラから目、鼻、口の輪郭が捉えにくくなり、精度がガクッと落ちます。

今後の課題

今回は、誰もいない部屋でデモしました。もし、屋外や、パーティー会場など、絶えず何かが動いているような場所でデモしたとすると、これほどの精度は出せないかも知れません。

また、普通のWebカメラではなく、赤外線カメラやKinnect などの深度カメラを使うと、どれくらい精度が上がるのかも気になるところです。

今後は、その辺りも調べてみたいと思います。

OpenCV でHaar分類器を自作してみる

昨年の１２月に、OpenCV の バージョン3.1がリリースされました。画像認識の分野では、おそらく一番有名なプログラミング用ライブラリです。

OpenCVには、既に出来合いのHaar分類器があって、これを使うと、画像のどこに顔があるか認識できます。この分類器の認識精度に満足できない場合は、分類器を自作する必要があります。というわけで、試しに作ってみました。

分類器の自作にあたっては、「Create Your Own Haar Classifier for Detecting objects in OpenCV」というブロク記事と、「詳解 OpenCV　-コンピュータビジョンライブラリを使った画像処理・認識-」という書籍を参考にしています。

Haar分類器とは？

Haar分類器は、教師あり機械学習手法の一つです。教師あり機械学習の場合、大量の正解画像（例えば、画像＋顔の位置を表す矩形領域のXY座標）を予め人の手で用意しておいて、それを分類器の入力データとして与えます。そうすると、顔の位置を特定する為に最適な”パラメーター”を求めます。このパラメーターを求めるプロセスが、いわゆる「学習」に相当します。

パラメーターとは、-0.29384 とか、 2.3734509882 といった実数の集まりです。使う分類器の種類によって、パラメーターの意味合いは変わります。人間がその数字を見ても、デタラメな数にしか見えません。正解画像を１枚ずつ与えていくと、パラメーターの個数は変わらずに各々の値だけが刻々と変化します。値だけ眺めていても、どれくらいの認識精度を実現できそうなのか、さっぱり分かりません。テスト画像を実際に分類器にかけてみて、初めて精度を実感できます。

Haar分類器の作り方

Haar分類器で「顔」の位置を特定するデモはよく見かけるので、今回は少しひねって「目」の位置を特定してみます。

一般的に、Haar分類器は、最低でも１０００枚単位の正解画像が必要だと言われています。前述のブログ記事を参考に、以下の手順で正解画像を用意しました。

1. 動画撮影（Webカメラで自分を撮影）
2. 動画の各フレームをbmp画像化（このやり方だと、一度に大量の画像が作れます。ffmpegを使いました）
3. それらの画像から、目の位置をマウスで囲む（下の画像の赤い四角形）

黙々と作業すること２０分、なんとか２００枚作成できました。この生産性だと、１０００枚作るのに約１時間半、ひたすら自分の顔が映った画像と向き合わねばならず、なかなか辛いです（笑）。ということで、１０００枚集めるのは早々に諦めました。

実験結果

以下が、正解画像１０枚の結果です。丸の箇所を「目」の位置と認識しています。

以下、１００枚の場合。

以下、２００枚の場合。

 

正解画像の増加に比例して、検出漏れが少し減り、誤検出が”激増”しました。この作業の延長線で１０００枚集めても、シャボン玉で埋め尽くされる残念な結果になる気がします。

 

今後の課題

正解画像の集め方とか、正解画像の前処理とか、学習方法とか、識別アルゴリズムの種類とか、チューニングすべきポイントは山ほどあります。今回は、チューニングを一切考慮しないでHaar分類器を作るとどうなるか？という実験でもありました。

今後は、少しずつチューニングを施して、どこをいじるとどれくらい効果的なのか、検証していきたいと思います。

３ヶ月くらい前に、あなたの1日は27時間になる。――「自分だけの3時間」を作る人生・仕事の超整理法という本を読んだことをキッカケに、今まで手を出さなかったTo-Doアプリを使い始めました。

AppStoreにはタスク管理のアプリが山ほどありますが、私は永年、紙の手帳を使っていて、それで不自由なかった為、アプリを使うモチベーションはありませんでした。

そんな私が、著者オススメのToodledoを使ってみた訳ですが、なんと、３日坊主の私が今日までの３ヶ月間ずっと使い続けています。自分でもビックリ（笑）。

以下、ToDoリストを３か月使ってみた感想です。

サブタスク機能、いらなかった。

著者も使っていないようですが、私も、結局使っていません。

サブタスクというのは、親タスク–子タスク–孫タスク…といった階層関係のあるタスクのことです。階層化できると、例えば、プロジェクト–工程-作業…といった感じで、直感的にタスクを表現できます。

やってみようと思い立った時、「サブタスク」機能がどこまで充実しているか？という観点で色々なアプリを評価しました。

タスクを作成しているうちは気づかなかったのですが、”今日やるタスク”という視点でタスクを串刺しすると、どのアプリも、該当する子タスクのタイトルしか表示してくれません。「設計書作成」というタイトルでは何をすべきか分かりません。「〇〇プロジェクトの設計書作成」というところまでタイトルに含まれている必要があるのです。

じゃあいっそ、子タスクのタイトルに、親タスクのタイトルも入れてしまえば良いのでは？と思ったのとほぼ同時に、サブタスク機能いらないのでは？と気づいた訳です（笑）

今では、「親タスク」＋空白文字＋「子タスク」というタイトル表記法を取り入れて、サブタスク機能は使っていません。

予実は気にしない。期限管理のみ。

著者は、コンテキストを時間帯毎に区切って、その中にタスクを放り込んでいるそうです。さらに、各タスクに実績時間を入力して、自分の生産性を測定し、作業時間の見積精度を上げているそうです。本を読んだ時は、このPDCAサイクルの美しさに感動し、私もやってみたいと思ったわけですが、いざ始めてみると…やってないです（汗）。

実は昔、個人レベルの予実管理は、独自システムまで作って２年くらいトライしてみた結果、あまり役に立たなかった経験があります。自分の感覚を裏付ける数字は取れたものの、そこから先の改善に繋がらなかったのです。

そういう訳で、実績入力には二の足を踏んでいます。終わったタスクをチェックして消し込むという、シンプルな実績管理をしています。

その代わり、各タスクに期限(Due Date）を入れる事にしています。期限から逆算して、各タスクにどれくらい時間をかけるべきか頭の中で計算しているのです。今のところ、こんなやり方でも役に立っています。

週１のバックアップを忘れなくなった！

ToodleDoを使うまで、これは不可能なことでした（笑）。紙の手帳は１０年以上続けているですが、こういう周期的なタスクを紙の手帳で管理しようとすると、毎週・毎月、次のページに同じタスクを記入する必要があります。私はものぐさなので、重要なタスクならまだしも、忘れてもそれほどインパクトのないタスクは、いちいち記入しません。

ToodleDoは、タスクに周期を設定しておけば、自動的に次のタスクを差し込んでくれるので、とっても便利です。実は、「週１回、アメブロをバックアップしています」は、これをトリガーにしています。

タスク粒度は粗め。

タスクは細かく分けるべきという主張には、見習うべき教訓が含まれていると感じています。実際、私がタスク管理してみようと思ったのは、著者のタスクの細かさにドン引きすると同時に、なぜそこまで熱中できるのだろう？と不思議に思った好奇心がきっかけです。

とはいえ、今の私のタスク粒度は、結構粗めです。ToDoリスト外の割り込みタスクがちょくちょく入ってくる状況なので、粒度を細かくするとタスクの組み替えが面倒になる気がして、躊躇しているのです。

そこまで細かくしなくても、ちゃんと役に立っているので、まぁいいかなと。

タスクの見直しは通勤中に。

毎朝、私は今日やるタスクに星をつけています。（フラグのようなものです）ToDoリストは、星・期限順で並べていて、終わったタスクはチェックをつけて消し込みます。

通勤中、電車の中でToodledoのiPhoneアプリを開いて、今日やることをチェックしたり、もっと効果的な順番にできないか考えたり、追加すべきタスクや漏れているタスクがないか思い返したりしています。

 

 

 

みなさんは、日々のタスクをどう管理していますか？

 

iPhone5で、QRコードをまとめて読み取るデモを作りました。
iOS標準装備のバーコード読み取りAPIを使ったのですが、とてもサクサク動くので感動しました。

少し前の話になりますが、2016年2月16日に、「空飛ぶ電波タワーとしての小型無人機活用の取組みとUWBを用いた高精度屋内測位技術の開発」という、電子情報通信学会主催の一般講演会に参加してきました。発表者は、NICT ワイヤレスネットワーク研究所の三浦 龍 室長でした。

大規模災害時に、地上の基地局が被災して情報孤立してしまった被災地へ、小型無人機（ドローンみたいな無人飛行機）を飛ばして電波タワー代わりにすれば、素早く通信を復旧できるのでは？というのが研究テーマです。

実証実験で使用された小型無線機はPUMA-AEで、元々アメリカの軍用だったものが、商用利用可能になったのだそうです。（購入しようとすると数千万するらしいです。気軽には買えないですね（笑））

このPUMA-AEに、専用の無線モジュールを搭載して、電波タワー代わりにします。実証実験では、１０Km程度の圏内まで通信できたそうです。

実証実験をするにあたっては、電波を遠くまで飛ばす必要がある為、総務省から、許可が必要な通信帯域を割り当てて貰ったそうです。電波法に準拠する為にこのような手続きが必要になるそうで、提出書類が多く、時間もかかるので大変だと言っていました。

私を含めほとんどの一般市民は、市場に広く出回っている携帯、Wi-Fiルータ、BlueToothデバイスなどの通信機器しか使ったことがないので、電波法を意識する機会はまずありません。

携帯が使用している帯域は各キャリアが総務省から免許をもらっているし、Wi-Fi、BlueToothはそもそもISMバンドと呼ばれる免許不要な帯域を使っています。

私は、今回の講演会で、これらの通信機器以外を使った無線ソリューションが研究されている事を初めて知りました。加えて、それを実現しようとすると、電波法という壁があるのだということも初めて知りました。

とても面白く、タメになる講演会でした。

前回の続きです。

前回は、業務システムの検索画面が遅い理由を３つ挙げました。今回は、これらの対策を、業務システムの全体設計を担うアーキテクトの立場から考えてみます。

最小限の手戻りで、テーブル設計を見直したい

検索画面の遅さは、テーブル設計を見直すことで解決できます。とはいえ、前回も触れましたが、開発終盤に手戻りの大きい見直しをかけるのは現実的ではありません。なんとか最小限の手戻りで、テーブル設計を見直すことができないものでしょうか？

非正規化テーブルを追加する

こういう場合、大抵は「非正規化テーブルを追加する」ことになります。非正規化テーブルとは、他テーブルが保持しているデータを、性能上のメリットが得られる形（予め集計しておく等）に変換した上で、重複して保持するテーブルのことです。非正規化テーブルの追加であれば、既存テーブルの設計には一切手を入れる必要がなく、性能アップしたい機能のみをテコ入れできます。

例えば、検索時にオプティマイザが使うインデックスを間違えてしまうのは、１つのテーブルに多くのインデックスが割り当てられていることが原因です。この場合、検索に特化した非正規化テーブルを追加することで、インデックスを分散させる事ができます。

同期処理がネック

この手法を導入する際に避けて通れないのが、重複データの「同期処理」です。同じデータを複数テーブルに重複して保持している為、データ更新時には、それらのテーブルを同時に更新しなければならないのです。

この同期処理は、業務システムの更新機能に組み込む必要がある為、手戻りが発生します。この手戻りをどこまで限定的にできるかが、「非正規化テーブルを追加する」案の良し悪しを決めると言っても良いでしょう。

更新処理をAPI化すべし

私は、この同期処理による手戻りを限定的にする為に、「更新処理を始めからAPI化しておく」ことが必要と考えています。

大半の業務システムは、テーブルそのものが、画面間を繋ぐAPIと位置付けられてています。そして、テーブルを読み書きするデータアクセスは、各画面が個別にSQLを設計しています。

このような構造だと、今回のような同期処理が必要となった時に、各画面の手戻りが必ず発生してしまいます。更新処理をAPI化しておけば、同期処理はそのAPIの中で吸収できる為、各画面まで手戻りが及ぶことはありません。加えて、業務寄りのロジックとシステム寄りのロジックを綺麗に分離できる為、コードの見通しも良くなり、保守しやすくなります。

加えて、RDBを使っている大抵の業務システムは、更新処理が単純です。（逆に、参照処理は複雑なことが多い）単純なので、更新処理をAPI化する開発コストも、さして大きくありません。

おわりに

私は、アーキテクトとして、今までに大小様々なシステムの全体設計に携わってきました。その都度、ああすれば良かったとか、凝り過ぎたなぁとかいろいろ反省させられます。

今回は、そんな試行錯誤の中で見つけた解決策について、書かせて頂きました。

社内で業務システムを日常的に使う方であれば、検索画面のレスポンスの遅さにイライラした経験があるのではないでしょうか？

実際のところ、遅いレスポンスでよしと考える開発者はいません。頑張ってチューニングしたくてもできないから、そのような状況に陥ってしまうのです。

業務システムの仕組み

大抵の業務システムは、リレーショナルデータベース（RDB）と呼ばれるミドルウェアを使って、データを管理しています。業務データはすべてそこに格納されており、日々バックアップされています。RDBのイメージが湧かないのであれば、「システムが使うExcelブック」と考えていただければ良いかと思います。

どのRDBにも、「インデックス」と呼ばれる機能があります。これは、特定の列を常にソートされた状態に保っておく機能です。ソートされていると、検索が素早くできます。国語辞典が、５０音順に並んでいるのと同じ理屈です。

このインデックスは、１つのテーブル（Excelで例えるとシート）に複数貼ることができます。例えば、「５０音順」の国語辞典と、「品詞順（名詞・動詞など）」の国語辞典の２種類を持っていれば、２つのインデックスがある状態と言えます。この場合、業務システムの検索画面は、入力された検索条件に応じて、どちらの国語辞典を使うべきか選択する必要があります。

RDBの場合、この選ぶ作業は「オプティマイザ」と呼ばれるRDBの内部機能が担っています。利用者の検索パターンに合わせて、予めインデックスを用意しておくのは開発者の仕事ですが、使うべきインデックスを選択するのはオプティマイザの仕事です。オプティマイザは、利用者が入力した検索条件に基づいて、自動的に適切なインデックスを選択します。

前置きが長くなりましたが、ここまでの仕組みが分かっていれば、業務アプリの検索画面が遅い理由を理解できるようになります。

検索画面が遅い３つの理由

大別すると、遅い理由は３つあります。

1.使うインデックスを間違える

インデックスが多すぎて、オプティマイザが選択を誤ってしまうケースです。開発者としては、その検索で使うインデックスはこっちでしょ！と言いたくなる状態です。
更に悪いことに、オプティマイザはなまじ賢いので、インデックス選択の判断材料として、入力された検索条件の他に、格納データの内訳（統計）も使っています。その結果、同じ検索条件を入力しているのに、昨日と今日で使うインデックスが違うという事が起こります。利用者からすると、昨日までレスポンス早かったのに、今日いきなり遅くなった、と感じるわけです。

2.使えるインデックスがない

これは、文字列の部分一致検索をしようとするとよく起きます。普通のインデックスは、前方一致検索にしか対応していません。部分一致検索する為には、フルテキストインデックス（転置インデックス）と呼ばれる特殊なインデックスが必要になるのですが、普通のインデックスよりも運用が大変なので、採用しないケースも多いのです。

3.インデックスはあるけど役に立たない

国語辞典で例えるなら、「あ」から始まる単語が99%で、それ以外が1％といった状態です。データがある程度均等にばらけていないと、インデックスを使っても早い検索はできません。オプティマイザは、使えないと判断したインデックスは、あっても使いません。

解決策は？

根本的に解決しようとするなら、テーブル設計を見直すことが一番です。
ただ残念なことに、このような性能問題は開発終盤に発覚することが殆どなので、そこまで遡って見直しする時間が残されていないケースが殆どなのです。（家を建てることに例えるなら、完成間近に間取りを変えるようなものです）

じゃあ、開発者としてこの問題にどう立ち向かうべきなのか？長年の経験の中で、私が思い描いている解決案がありますので、次回のブログで公開したいと思います。

システムの廃棄

IT業界でシステム開発に携わって、かれこれ15年が経ちました。

大規模システムの保守や機能拡張もやってますが、どちらかというと新しいシステムを一から作る事が多かったです。小規模なシステムだと、納品後数ヶ月くらいで安定運用できてくるので、それ以降クライアントからは音沙汰なし、というケースも多々あります。

最近、5〜6年前に私が開発したシステムを運用終了するという話を、偶然耳にしました。クライアントの当時の担当者が定年退職を迎えた事がきっかけのようです。

ソフトウェアは賞味期限付きのナマモノなのだなぁと、改めて実感しました。

ソフトウェアの経年劣化とは

表面的には、ソフトウェアに経年劣化はありません。今日でも、100年後でも、全く同じように動きます。ソフトウェア本体は不変でも、周囲の環境が変わるため、相対的に賞味期限切れになるのです。

例えば、昔のWebアプリは、WinXP + IE6のPCでのみ動作保証する事が当たり前でした。今、このPCを調達するのはまず無理です。業務ニーズが変わり、従来のシステム仕様のままでは使えないケースもあります。

結局、ソフトウェアを長く使おうとするなら、保守が欠かせないわけです。では、保守できているかどうかは、なにで決まるのでしょう？過去の経験を振り返って考えてみました。

イニシャルコストだけでは長く使えない

IT業界でよく言われている、設計書などの開発ドキュメントの有無というのは、実は直接関係ないのかなと思います。そうではなくて、”ランニングコスト”をきちんと払っているかどうかです。

システム開発は、クライアントから見るとイニシャルコストです。開発が終わって運用が始まると、そこから先がランニングコストです。

クライアントが開発ベンダーと保守契約を結んでランニングコストを払っている場合、仮にある開発者が離任することになっても、保守責任を全うするために「引き継ぎ」という作業が必ず発生します。逆に、保守契約がなければ、ベンダーには引き継ぎしたくなるモチベーションがありません。開発ドキュメントが整備されていようがいまいが、同じことです。開発ベンダーが個人事業主でも大企業でも、同じことです。

開発ベンダーに頼らず、クライアントがプログラミングのできる社員を保守担当に据えるケースもあります。これも、ランニングコストの支払い先が開発ベンダーから自社社員に変わるだけで、本質的には同じことです。

長く運用されているシステムは、どれも相応のランニングコストをかけています。