最近よく聞くワードで「ノーコード」耳にしませんか？プログラムコードを書かずにアプリケーション開発を行う事です。ノーコードツールの売り文句であります「簡単、誰でも」が仇になる場合もあります。
ノーコードアプリは作るのが簡単なので、仕様設計などせずに作りこみ直ぐに結果が出るので乱立します。その結果、時間の経過の中で担当も変わり仕組みだけが残り仕組みの維持管理継承が出来ない「属人化」や「野良アプリ」となってしまう訳です。
例えると
冷蔵庫の中にある材料でパパッと料理を作ったり無計画でいきなり1人旅に出る様な感覚です、これも個人で有れば何の問題もありませんがチームや組織で有れば大問題です。
この章では「システム開発の基礎部分」について掘り下げます。結構大切な内容です。
システム開発と言いますと何をイメージしますか？
システムエンジニアがユーザーからヒアリングを受けて、仕組みを設計してプログラムを作る
こんな感じかと思います。それを簡単にブロック分けしますと
- ユーザーヒアリング、要件定義
- 外部設計（フローチャート、Ｉ／Ｏ）
- 内部設計（ＤＢテーブル構造）
- コード化（プログラム開発）
- テストデバック
- 仕様書作成
細かくはもっとありますが、大括りでこの様な流れになります。システム開発を大きく分類した場合、上記のブロックに中で「プログラム開発」は一つのブロックでしか無い訳で、その前に仕様設計、その後の仕様作成が結構なボリュームになります。
そこで、前述の課題「属人化」に関しては、この前後がすっぽり抜けていきなり「プログラム開発」の部分からノーコードで入って終わりにしてしまう訳です。
ここに大きな落とし穴があります。
前段の仕様設計部分、これは仕組み作りを行う上で一番大切な部分です。仕様はあくまでもユーザーニーズファーストではありながらもユーザーの行っている行為が全てではありません。
ユーザーは仕事のプロであっても仕組み化のプロではありません。ユーザーヒアリングからＩ／Ｏ（必要なアウトプットから必要なインプット項目を洗い出し)テーブル構造（DB構成）を決定、正規化やID化を実施全体処理の流れをフローチャート化して無駄な動きを可視化して効率的な流れのために無駄を排除それらを仕様設計としてプログラム開発に繋げていきます。
後段の仕様書作成
ここが地味に重要な部分で、設計図として文書化（明文化）して残します。次の改編時どこを改修するか？違う会社に委ねる際の説明書としてこの仕様書を最低限残す事で、継続性が出て来て開発者しか知り得ない（属人化）リスクを排除する目的にもなります。
仕様書作成の部分が「簡単、誰でも」から入った「ノーコードエンジニア」はないがしろにする危険がありその結果、非効率な仕組みのままシステム化を進めてしまい汎用性が無い仕組みが出来る。
ドキュメントが無いので担当がいなくなった瞬間に継承が出来なくなり負の遺産になる。この様な大事な部分がすっぽり抜けて「オリジナルな継承出来ない野良アプリ」が乱立する、こんな流れが現場の大きな社会問題？にもなっています。
ノーコードは「誰にも簡単に」出来ますが、仕様設計や仕様書作りはある程度の経験や学びが必要です。
ではその部分に何らかの打開策は無いのか？
対応策については次回の内容に続きます。
－ＰＲ－