ノーコード・ローコード開発者の参画初月にやること｜現場で信頼される進め方

ノーコード・ローコード開発者の参画初月は、いきなり作り始めず、今あるアプリと業務の現状をつかみ、変更の決め方と権限を関係者とそろえ、小さな改善を一つ形にして見せることが目標です。画面をすぐ直せる職種だからこそ、最初の1か月で「速く作る人」より「壊さずに整える人」と見てもらえるかが、その後の任され方を左右します。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備と、職種を問わない初期の動き方は参画前の準備と参画初期の進め方で扱っています。

初月のゴールを3つに分ける

1か月でやり切ることを、次の3つに分けて考えると、動きがぶれにくくなります。

大きな構築の案件でも、最初の1か月で全部を作り終える必要はありません。この3つが揃っていれば、2か月目以降の構築は速く、手戻りも少なくなります。

1週目：環境と業務の現状を集める

既存の環境を読む

まず、今ある環境を一通り見ます。アプリの一覧、各アプリの項目と一覧の設定、アプリ同士の参照、通知や承認の流れ、入っているプラグインや拡張のコード、外部サービスとの連携を書き出します。データベース型の場合は、テーブルの構成とスクリプトの一覧、バックアップの方法も確かめます。

前任者がいる場合は、設計の記録や手順書が残っているかを確かめ、残っていなければ、自分の読み取りをメモにまとめながら進めます。引き継ぎの受け方は引き継ぎの記事で解説しています。

権限と作業の場所を確かめる

自分に与えられた権限（管理者か、一部のアプリの設定だけか）と、作業してよい場所を確かめます。本番の環境で直接直してよいのか、検証用の環境やアプリの複製で試してから反映するのかは、現場によって違います。個人情報を含むアプリがある場合は、閲覧してよい範囲と扱いの決まりも確かめておきます。考え方は個人情報の取り扱いを任されたときの記事をご覧ください。

利用者と短く話す

業務部門の利用者や管理者に、15〜30分ほどの短い時間をもらい、今のアプリで困っていること、アプリの外で手作業になっていること、使っていない機能を聞きます。最初は解決策を出さず、聞いた内容を一覧にすることに徹します。

2週目：変更の決め方と進め方をそろえる

要望の受け方を決める

ノーコード・ローコードの現場では、要望がチャットや立ち話で直接届きやすく、そのまま直すと誰が何を頼んだかが分からなくなります。要望をどこに集めるか（課題の一覧、チケット、共有の表など）、誰が優先度を決めるかを、発注側の窓口と決めます。

変更の手順を一枚にまとめる

要望の受け付け、優先度の判断、検証、承認、公開、利用者への周知までの流れを一枚にまとめ、発注側と確かめます。承認者がはっきりしないまま進めると、後から「聞いていない」という声が出やすくなります。

報告の形を合わせる

週に一度の報告で、何を伝えるかを決めます。今週直したこと、次に直すこと、判断してほしいこと、の3つに絞ると、短い時間で伝わります。リモートが中心の案件では、文字での報告の比重が大きくなるため、書き方の型を早めに決めておきます。リモートでの進め方はリモートの記事で整理しています。

3〜4週目：小さく直し、次の計画を引く

影響の小さい改善を一つ形にする

1週目に集めた困りごとの中から、影響の範囲が小さく、効果が見えやすいものを一つ選び、検証してから公開します。入力の手間を減らす、一覧の見え方を整える、通知の宛先を直す、といった改善が候補になります。公開したら、利用者に使ってもらい、反応を確かめます。

現状の見立てをまとめる

集めた情報をもとに、環境の現状、困りごとの一覧と原因の見立て、手を入れる順番の案をまとめます。アプリの作り直しや統合など大きな変更が必要な場合も、いきなり結論を出さず、選択肢と影響、必要な期間を並べて示します。

次の1〜2か月の計画を引く

契約で決めた範囲の中で、次に取り組むことと、その順番を発注側と合意します。範囲の外の作業が見えてきた場合は、この段階で切り出して相談します。扱い方は業務範囲が変わったときの記事をご覧ください。

案件の型によって初月の重心は変わる

新しく業務アプリを作る案件

業務の聞き取りと、アプリの分け方・データの持ち方の設計に重心を置きます。画面を早く見せたくなりますが、設計が固まる前に作り込むと手戻りが大きくなります。たたき台の画面を使って聞き取りを進めるのは有効ですが、それが完成形ではないことを利用者と確かめておきます。

既存の環境を整理・改修する案件

1週目の「環境を読む」作業に時間をかけます。使われていないアプリ、重複したデータ、誰が作ったか分からない設定を洗い出し、残す・まとめる・やめるの方針を発注側と決めます。いきなり消したり統合したりせず、影響を確かめる期間を置きます。

社内展開・内製化を支援する案件

社内の作り手が誰で、どこまで作れるかを把握することに重心を置きます。作成と変更のルール、相談の窓口、教える範囲を決め、自分が作るより、相手が作れるように支える動きを中心にします。

初月に避けたい動き

• 本番の環境でいきなり直す：利用中のデータや業務を止めるおそれがあります。試す場所を確かめてから手を入れます
• 要望をその場で反映し続ける：構造が崩れ、誰の依頼か分からなくなります。一覧にして優先度を決めます
• 前任者の作りを否定する：作られた当時の事情があります。直す理由を、業務の目的に照らして説明します
• 自分の慣れたツールや拡張を持ち込む：発注側が保守できない仕組みが増えます。入れる前に承認を得ます
• 記録を後回しにする：自分しか分からない変更が積み上がります。直したことは、その都度残します

1か月の終わりに振り返ること

月末には、次の点を自分で振り返り、発注側の窓口とも短く確かめます。

1. 環境の全体像と、困りごとの一覧を説明できるか
2. 変更の手順と承認者が、関係者の間でそろっているか
3. 公開した改善は使われているか、反応はどうだったか
4. 次の1〜2か月の計画に、発注側と合意できているか
5. 契約の範囲と、実際に頼まれている作業がずれていないか

5でずれが見つかった場合は、早めに発注側やエージェントに相談し、範囲を見直すか、契約を変えるかを決めます。この分野でつまずきやすい場面はつまずきやすい点の記事で整理しています。

よくある質問

前任者の設計の記録がほとんどありません。何から始めればよいですか？

まずはアプリの一覧と、アプリ同士のつながり、拡張や連携の場所を自分で書き出すところから始めます。分からない設定は、利用者や管理者に「何のためのものか」を聞いて補います。書き出したものは、そのまま発注側に共有できる記録になります。

参画してすぐに、大きな作り直しを求められたらどうすればよいですか？

現状を把握する前に作り直しの範囲を決めると、必要な機能が抜けたり、手戻りが大きくなったりします。最初の2〜3週間で現状と困りごとを整理し、作り直しと部分的な改修の選択肢を比べたうえで判断してもらうよう提案するのが安全です。

社内の作り手が勝手にアプリを変えてしまいます。どう対応すればよいですか？

相手を止めることより、変更の手順と相談の窓口を決めることが先です。誰がどのアプリを変えてよいか、変える前に誰に知らせるかを発注側の責任者と決め、社内に周知してもらいます。権限の設定で変更できる範囲を分けることも、選択肢の一つです。