dbSheetClient継承編(2)
DX（デジタルトランスフォーメーション）時代には、いままでの常識を疑うことが大事です。
プログラマーの中には、プログラミングは好きだけど、仕様書や手順書を作るのは面倒くさいと思っている人が少なからずいるのではないでしょうか。
筆者もその一人です。
仕様書や手順書は「必ず作る」という常識をそろそろ疑ってみてはいかがでしょうか。
働き方改革の第一歩
長時間残業や休日出勤を強いる諸悪の根源は、課せられた業務量が処理能力を上回っているということです。
しかし、コロナ禍によって、課せられた業務の中に相当数の不要不急の業務が存在していたことに気づかされたのではないでしょうか。
やらなくても誰も困らない業務、作っても誰も読まない文書、これを機にすべて棚卸しましょう。
まず、棚卸対象業務が、ジョブディスクリプション（職務記述書）に記載されていないことを確認します。
次に、「やらなくても誰も困らない業務」を判別するために、その業務を実施しない、もしくは実施するけど実施したアウトプットを非公開にしてみます。
結果として、どこからも苦情が来なければ、「やらなくても誰も困らない業務」ですね。
仕様書は必要か
システム仕様書とは、ユーザー要件を満たすために必要な具体的な機能・性能に対する要望を文書化したものです。
システム仕様書は、そもそもITベンダーが身を守る術だったのではないでしょうか。
従来のウォーターフォール型開発手法では、開発がスタートした後の仕様変更は、多大な追加作業が発生し、コスト増大や納期遅れに直結します。
システム開発を請け負ったITベンダーにとっては、開発開始後の仕様変更は相当のリスクになります。
つまり、システム仕様書は、ITベンダーがユーザーの仕様変更要求を突っぱねる、あるいは相応の費用をユーザーに負担してもらうための証拠書類という性質が強いのではないでしょうか＾＾；
現在主流となりつつある「アジャイル型開発」では、開発開始後の仕様変更を歓迎する手法です。
システムは、現場の要望に応じて常にアップデートされるべきで、その改善スビードが速いことに価値があります。
仕様変更のたびにシステム仕様書を作り直していては、開発スピードが落ちる原因ともなりかねません。
いま話題のDXを推進する上で、一つの切り口として、システム開発の内製化があります。
内製化とは、ITベンダーに頼らずユーザーが自ら業務システムを開発する体制作りです。
システム仕様書は、この内製化時代にどんな形になっていくのでしょうか。
必要最低限のドキュメントとは
筆者は、dbSheetClientを導入してから6年間、ほぼ独りで開発・運用していました。
その間、ミッションクリティカルなプロジェクト（止まったらヤバイ）がドンドン増えていきました。
このままだと筆者が不在中にシステムトラブルが発生した場合、タイミングによっては、会社の決算に影響を与えてしまうことも危惧されました。
長期休暇も取れないし、病気や怪我で入院もできません＾＾；
情報システム部門が人員不足とは知りながら、7年目にして何とか上司に頼み込んで担当をつけてもらいました。
さて、システムを引き継ぐために必要最低限のドキュメントは何でしょうか。
それは、そのシステムが止まった時に、どんなヤバイことが起こるかを説明した文書だと思います＾＾；
「不要不急」なのか、「必要至急」なのかを明確にすることです。
クラウドに移行すべきか
最後に、システム継承の点からクラウド化への対応について、筆者の見解をお話します。
クラウドコンピューティングは、大きな潮流であり、誰も抗えないでしょう。
炊事やお風呂に使う水を川や井戸から汲み上げていた時代から、上水道が整備され蛇口をひねると水が出る時代に変わるようなものです。
問題はいつからクラウドに移行するかではないでしょうか。
水道に例えると「蛇口から出る水は安全か」とか「急に水が出なくなった時、どうするか」などのリスクを徐々に許容していくことになるのでしょう。
dbSheetClientのクラウド化についていえば、データベースが既にクラウド上にあれば、最初からクラウドで良いのではないでしょうか。
クラウドの恩恵については過去記事「クラウドがもたらすもの」も参考にしてください。
また、dbSheetClientには、経営環境の変化に柔軟に対応できるサブスクリプション契約も用意されています。
こちらも過去記事「サブスク」を参照してみてください。
次回は、「開発技術の継承」をテーマにします。
dbSheetClientのシステム開発者を短期間で育てるコツについてです。
皆さん本日もお疲れ様でした！
おやすみなさい（挙手）