最近の投稿

アーカイブ

カテゴリー

最近のコメント

  1. にんじん
  2. アバター
  3. アバター
  4. タロウ
  5. アバター

アジャイル

皆で真の栄光を目指そう!民主化革命としてのローコード導入2

リプリパ編集部

今まで、ソフトウェア開発の経験がない人が自分が作りたいアプリケーションを作ることができたり、ビジネスユーザーがわざわざ社外のSIerや社内のエンジニアに頼まなくてもニーズに合ったソフトウェアを作れる。それはもう「ソフトウェア開発の民主化」と呼んでいいでしょう。その鍵となるのが、プログラムコードをほとんどまたは全く書かずに開発できる、ローコードプラットフォームです。

とはいえ多くの場合、ソフトウェア開発を民主化するには、組織と個人の両方に、それまでの方法や意識の大胆な転換や決断が必要です。例えば、今までウォーターフォールでしか開発したことがないチームが、ローコード開発基盤によるアジャイルなスタイルへの移行を検討する場合、さまざまな阻害要因が立ちはだかります。新しいシステム開発手法への「革命」を成功させ、民主化を実現させるにはどうしたらいいでしょうか?

前回の記事と併せてお読みいただければ幸いです。

ローコード開発を受け入れられるアジャイルな環境か?

ローコードによる開発は、アジャイルと切っても切り離せません。アジャイルとは、柔軟性や応答性、継続的な改善を優先する、顧客重視のスタイルです。ソフトウェア開発に限らず、チームのマネージメントでも使われる考え方ですが、設計から開発、テスト、リリース、アップデートを高速に繰り返していく開発スタイルとして、広く認知されています。

一方、アジャイルと対比されるウォーターフォールは、伝統的で確立された従来型のソフトウェア開発手法です。この両者は、比較の文脈で語られることが多いのですが、特徴や目的へのアプローチが違うだけで、単純に優劣では説明できません。

チームやメンバーによっては、慣れ親しんだウォーターフォールの手法や構造に安心感を覚える人もいるでしょう。ウォーターフォールからアジャイルへ移行する際には、チームや組織文化の問題が露呈することもあります。アジャイルという手法が本当に自分のチームや組織に適しているか、受け入れられる素地があるのか、ローコードツールを機能や価格で選択するのとは別の角度で、チェックしてみましょう。

アジャイルな環境かどうか、評価するポイントはいくつかあります。もし、十分な環境でなければ、チームのカルチャーを育てていく具体的なアクションを実践することが必要です。信頼できる専門家に相談したり、経験豊富な実践者に指導を仰ぎ、チームの現状や将来像、阻害要因を評価することは、開発手法の民主化に重要な第一歩です。

チームのカルチャーや考え方を評価する

アジャイルでは、継続的な改善・変更が必要です。そのため、コミュニケーションやコラボレーションの環境、オープンマインド、柔軟性・寛容性、実験と適応への意欲などが不可欠です。今のチームに、アジャイルに適したカルチャーや考え方があるかを評価してみましょう。

潜在的なメリットとデメリットを検討する

もし、現在のチーム体制がウォーターフォールを前提としているのであれば、それと比較してアジャイルに変更した場合のメリット・デメリットを冷静に評価しましょう。そして、それらがチームとプロジェクトにどのように影響するかを、検討することは不可欠です。

プロジェクトの要件を評価する

アジャイルは、変動性・不確実性・複雑性・曖昧性(いわゆるVUCA ヴーカ)が高いプロジェクトに適しています。プロジェクトの要件が、変化に柔軟に適応しやすいアジャイルのメリットを活かせるかどうかを評価します。

チームのサイズと構造を検討する

アジャイルが成功する鍵の一つが、チームのサイズ(メンバーの人数)です。緊密にコミュニケートするには、小規模から中規模のチームが最適です。今のチームのサイズと構造が、アジャイルに適しているかどうかを評価してみましょう。

顧客の関与の度合いを判断する

アジャイルでは、顧客の参加と協力も重視されます。現在のやり方をアジャイルにシフトさせ、今以上、顧客に関与してもらうことがプロジェクトにとって有益かどうかを評価します。

チームの技術力や専門性を評価する

ローコード開発が、非ITエンジニアにもソフトウェア開発の道を開くのと違って、アジャイルでは、高度な技術的専門知識とスキルが要求されます。チームメンバーの中に、ソフトウェア開発の民主化を支援するノウハウを持っている人材がいるか、確認することも重要です。

ローコード開発のメリット

従来の手法では、ソフトウェア開発は、そのスキルを持つ社内外のエンジニアやSIerに依頼しなければなりませんでした。さまざまなアプリケーションや現場の担当者が複雑に連携することで、生産性が低下していました。

設計情報からITシステムを自動生成するローコード開発では、現場の担当者が自分でアプリケーションを開発することで、生産性が向上します。システム開発を内製化することで、チーム内にノウハウも蓄積で、自社システムに適した次世代のIT人材育成が可能になります。

ローコード開発の民主化・内製化

ローコード開発の民主化・内製化
ローコード開発の民主化・内製化

「ITシステム開発の民主化」によるベンダー企業依存からの脱却

「ITシステム開発の民主化」によるベンダー企業依存からの脱却
「ITシステム開発の民主化」によるベンダー企業依存からの脱却

ローコードによる民主化を進めるには?

変化への抵抗を克服し、ローコード開発へのスムーズな移行を実現するためには、次のことが重要です。

ローコード開発の目的と利点を共有する

ローコードプラットフォームを選択する時に最も重要なのは、目的とメリットを正確に共有すること。ツールやプラットフォームを使うことそのものが、本当の目的ではないはずです。柔軟な開発環境に変えていくことで、私たちは一体、何を実現すべきなのか?チームのメンバー全員が、何のために新しい開発手法に移行するのか、その目的を理解していることが不可欠です。

リーダーやマネージャーは、ローコード開発がもたらす、潜在的なメリットを理解していることも重要です。柔軟性の向上や納期の短縮は人件費の抑制にもつながり、顧客満足度の向上はビジネスの発展にプラスに作用します。

メンバーが新しい民主的なアプローチを理解し、より安心して作業できるように、補佐や調整役を置くことも有効です。

ローコード開発の不安や恐怖に対処する

今までの環境ややり方が変わってしまう、不安と未知の恐怖は計り知れません。しかし、リーダーは二度と元に戻れない転換が必要なことを知っています。メンバーも薄々気付いているとしたら?多くの場合、開発プロセスの移行に関する不安や懸念、恐れの原因は、前述の目的や利点が共有されないこと以外にもあります。スケジュールやリカバリー体制が提示されないことや、情報が十分に共有・理解されていないことも、大きな心理的障害です。チームメンバーには、オープンかつ正直に、丁寧に対処しましょう。相手や状況によっては、個別に対話する細やかさも忘れずに。

移行プロセスにチームを参加させる

ローコードへの移行プロセスには、必ずチームメンバーを参加させ、その実施方法について彼らに発言権を与えましょう。自分事として捉えることで、自分の立場や役割を明確に理解できます。また、移行を成功させるために、メンバー同士がどのようなタスクを完了させるべきかを認識できます。

小さな成功でもチームで祝福・感謝する

『上手くいくのが当たり前』な日本企業のカルチャーには、なかなか馴染みがない習慣かもしれません。しかし、新しい方法にチャレンジするチームの機運や熱意を高めるために、移行過程での小さな成功とマイルストーンを祝うことは非常に重要なアクションです。小さな目標でも達成できたことを素直に喜び、メンバー同士の健闘を讃え合い、次の目標を目指しましょう。


前回の記事では、フランス革命記念日について触れましたが、今、自転車ロードレースのツール・ド・フランスの熱戦が繰り広げられています。塊になった集団は、その時々の状況の変化に応じて、競い合いつつも時に協力して助け合いながら、各地を転戦していきます。チームとしてのサポートと、安全を影で支えてくれる運営、沿道からの熱い声援を受けつつ、次のゴールを目指します。

ローコードは、非エンジニアのシチズンデベロッパー(市民開発者)を育成するだけでなく、DX人材としてのエンジニアの可能性を広げます。民主的なソフトウェア開発を実現するには、オープンでコラボレーティブ、継続的に改善する組織カルチャーが必要です。分かりやすい敵を作り上げたり、闘うべき相手や方法を見間違えるのはマイナスです。変化への抵抗を克服するには、リーダーとメンバーがそれぞれの行動や仕事で、アジャイルとローコードプラットフォームの価値と原則を理解し、熱意を示すことも欠かせません。これらの価値観と原則を育むことで、チームが革新的な開発手法を受け入れ、スムーズな移行という真の栄光を手にできるでしょう。

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

ABOUT ME
リプリパ編集部
リプリパ編集部
編集部員
リープリーパー(略称:リプリパ)編集部です。新しいミライへと飛躍する人たちのためのメディアを作るために、活動しています。ご意見・ご感想など、お気軽にお寄せください。
リプリパ編集部の記事一覧

記事URLをコピーしました