タグ: ①開発サポート

  • ローコードとノーコード

    1.ローコード(Low Code)

     プログラムコードをほとんど記述しないで
       アプリケーションやシステムの開発を可能にするツールや手法

     従来の開発手法よりも圧倒的にソースコードの記述量を減らす開発が可能

    2.ノーコード(No Code)

     ソースコードを全く書かずに
       アプリケーションやWebサイトの開発を可能にするツールや手法

     プログラミング、コーディングに関する知識が全く無い非エンジニアでも、
       パーツやテンプレートを組み合わせて開発できる

    3.注目ポイント

     エンジニア不足の解消に役立つ
       経験不足の人でもアプリケーション開発に貢献できる可能性が高くなる
       近年のエンジニア不足を解消するために有効

     DX支援ツールとして強力
       デジタルトランスフォーメーションを推進するツールとして有効
       エンジニアが不足する状況で短期間・低コストの開発に適している

     有力ツールが続々とリリースされている
       日本製・・・NoCode Japan株式会社 Click
       外国製・・・Amazon・・・Amazon Honeycode、Amplify Studio
             Google・・・・AppSheet
             Microsoft・・・Microsoft PowerApps

     将来性が高いジャンル
       開発業務の分業化が進み、
         設計部隊と開発部隊とに分業化され
         開発部隊にノーコード・ローコードツールが採用される

    4.双方の比較

    ローコードノーコード
    ノーコードに比べて拡張性が高い
     コード記述が可能なので、オープンAPI等の利用が可能になる

    利用範囲(目的)が広い
     コード記述が可能なので、必要とする機能をニーズに応じて追加できる

    既存システムと連携できる
     最初からアプリとの連携が用意されている
    非エンジニアでも開発できる
     コードの記述が無いので容易に開発できる

    小規模・単機能システムの開発が楽
     用意されている機能だけで完了する

    開発チームが不要のケースもある
     担当者がツールを利用するだけで開発できる

    拡張やメンテナンスが簡単
     機能拡張等のメンテナンスはベンダーが行う

    5.共通する「強み」

     設計・開発工数を抑えられることが多い
       フレームワーク、DB、ネットワーク等を意識する必要はあまりない
       要件に対してそれぞれの機能をどう組み合わせるかを考える
         事前検討にかかる時間や開発にかかる時間の削減ができる

     インフラ管理の負担が小さいことがほとんど
       クラウド環境やサーバーといったインフラを”込み”で提供している
         利用者は自社環境内に開発環境を構築する必要がほとんどない

       ツール類は世界規模の大手IT企業が提供しているものがある
         コストパフォーマンスの高い環境が得られる
         開発経験が少ないユーザにとって心強い 

    6.デメリット

     開発の”自由度”が低い
       一般的な開発ツールより、機能面で制限・制約を受けやすい
         仕様として対応できない部分があり、制限を受けることがある

       導入に際しては、ギャップ分析等で事前によく確認しておく
         
     大規模開発や先端技術、動的な開発が苦手
       イレギュラーな仕様への対応が苦手
       最先端技術を取り扱いたい場合も苦労する

     「資産継承」問題がある
       ツール提供企業の倒産などあれば事業継続が難しくなる

     セキュリティ・品質面が弱い
       情報漏洩対策・セキュリティ対策はツールまかせ
         クラウド利用のためデータの持ち出し、ツール利用に制約が掛かる

     「シャドーIT」問題を引き起こす可能性がある
       手軽に開発すると管理部門が把握していないシステムが作成される
     
     属人化問題にも気をつける
       手軽なため作成者しか内容を把握していないことが生じる

     ブラックボックス問題がネックになることも
       ツールベンダーに頼るため習熟度が低くなり誰も何も知らなくなる

    7.補足

     注意点:便利で使いやすいので利用するべきだが
           ある程度システム運用が成熟した組織が取り入れるべき
           開発経験のある人が使うと極端に生産性がアップすると思います

           使い易いからと言っても未経験者では全く手が動きません
           不足しているエンジニア対策には直結しません
             ツールを使う人ではなく、全体を読み解く人が必要です
         
         個人が趣味で個人的なシステムを構築する分には利用を勧めますが
         十二分に準備をしてから、組織としての利用を勧めます

  • GitHub

     ”バージョン管理システム”の一つである
       「Git」は主に個人で使用するが、複数人で使用するのが「GitHub」
         個人が持つ「ローカルリポジトリ」をWebを使って集約し
         サーバー上に「リモートリポジトリ」を構築しバージョン管理する

    「リポジトリ」の意味
       バージョン管理される「ファイル、履歴情報」を保管する領域のこと
       
     個人のローカル環境に「Git」を使って「ローカルリポジトリ」を構築し
       作業が完了した時点でサーバーの「リモートリポジトリ」にアップする
       サーバー側の「リポジトリ」は共有され、グループでの共同作業が可能
       
       必要な都度、サーバーより「リポジトリ」をダウンロードし修正する
       修正が終われば再度サーバーに「リポジトリ」をアップする

     以上のように変更したリソースだけでなく、
       管理情報を一緒に受け渡すことによって、バージョン管理を行う


    文書管理に使っている事例

     経済産業省ではモデル契約書への意見募集をGitHubを使って行っている
       https://www.meti.go.jp/press/2021/05/20210517003/20210517003.html

       どの意見に対する意見なのかが紐づけされて分かりやすい

  • Git

     ”バージョン管理システム”の一つである
       「Git」は主にプログラム開発の現場で使われて来たので
         「プログラムコード」のバージョン管理に適している思われているが
         「マニュアル」や「議事録」等の文書に関するバージョンが可能

       当記事は「開発サポート」のカテゴリーに属しているが
         バージョン管理を広く捉えて事務作業の管理にも使用することが可能

     よく使われるバージョン管理の方法として
       ファイル名に更新日付を付けたり、担当者別にホルダーを分けたりする
       よく管理されていれば便利で簡単な管理方法ではあるが

       ファイルが作成されて現在に至るまでの更新履歴が一切わからない
       どの時点のどのファイルが使用目的に合っているのかが分からない
         「Git」はこういった悩みを見事に解決してみせる

     「Git」は仕組みを理解するのに時間が掛かるという難点はあるが
       履歴を辿り「いつ、誰が、どのように、修正した」かが分かる利点がある

  • Mermaid(マーメイド)

     Mermaid(マーメイド) は独自の記法で図やグラフを描画する
       Markdown のコードブロック中に記述するだけで図が完成する

     2022年2月14日、GitHubが以下の様に発表した
       GitHub上でJavaScriptベースの作図ツール
       「Mermaid」が使えてインラインで作図が可能になったと

     テキスト定義を使用すると、様々な図が作成される
       フローチャート、UML、Gitグラフ
       ユーザージャーニー図、ガントチャート

       ソフトウェアプロジェクトでよく使われる図をサポートする

    <使用例>

    ```mermaid
      graph TD;
          A-->B;
          A-->C;
          B-->D;
          C-->D;

     上記のようにテキスト文をGitHubに入力すると
       こういった図になって表示される