はじめに
2025年以降も企業が存続するために必要であるというDX（デジタルトランスフォーメーション）は注目されていますが、それを実行するために重要なアクションプラン（行動指針）については語られることは少ないです。
DXには縁がないと思われる人が多いかもしれない地方銀行もコスト削減と地方銀行間で共通のサービスを提供するために「TSUBASAアライアンス」というプロジェクトを推進しDXに取り組んでいます。
ではDXの実行のためには具体的にどうすればよいのでしょうか。
以下のレポートを参考にアクションプランを考えていきます。
～ITシステム「2025年の崖」の克服とDXの本格的な展開～
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf
ドキュメントを書かないエンジニア
７ページ目を読むと「レガシーシステムが足かせと感じる理由」が書かれています。
最も足かせと感じる理由として多いのが「ドキュメントが整備されていないために調査に時間を要する」です。
ようするにコーディングだけはするけれど、「あとはもう知りません」。というエンジニアが多いということかもしれません。そんな人をエンジニアと呼ぶべきかわかりませんが…。
では、ドキュメントが無いことの何が問題なのでしょうか。それはドキュメントがないのでソースコードを読むしかないということになります。するとエンジニアの稼働がそっちにとられます。
こういうことを書くとドキュメントを書かなくてもうちの会社ではサービスの稼働はできているという人がいるかもしれません。しかし、会社は組織でやっているので、あなたが病気になったり会社を退職したときには必ずそれを引き継ぐ人がいます。サービスに不具合が起こった時、サービスの改修が必要になった時退職していたら基本的には頼むことは難しいでしょう。したがって、ドキュメントを書く必要があります。
次にドキュメントの書き方について説明します。
ドキュメントの書き方
ドキュメントの書き方には答えはありませんが、私は以下の内容を書くことが多いです。
・ソフトウェアの概要、目的
・ソフトウェアの利用方法
・クラスの利用方法、メソッドの利用方法
・クラス図とその説明
・ソフトウェアの依存関係
・ソフトウェアを動かすのに必要なライブラリ
必要なことは過不足なく書くことが重要です。
最後に
私はソフトウェアをしっかりと開発できていると自信満々に言うのは現状できません。
日本人ですが文章も分かりやすく書けませんし、日本語も正しく読めないことが多いです。
ですが、何が必要か考えて、本を読んで勉強して行動しています。
今回の記事は自分のことを棚に上げて書きました。失敗に気づいて直していくのが大切だと思います。