GeneXus、Wagbyといった、原則ノンプログラミングの開発ツールを使ってシステムを作ると言うのはどういうことか、その理想形とも思える講演に出会った。
講演していただいた市進ホールディングスの今林様の許可を得て紹介する。
１超高速開発ツールの選定手順
・ベンダー紹介のユーザを訪問し確認する。
・そのツールのユーザを自ら見つけ訪問し確認する。
・ベンダーと一緒にパイロットシステムを作ってみる。
パイロットシステムを作る目的は２つある。
一つは機能の限界を知ること。もう一つはプロジェクトの進め方を体得すること。
新しいツールにはそれに合った仕事の進め方がある。
１．現状調査をし、業務分析・業務フローを書く。
これは共通。
![]()
２．業務フローは模造紙・付箋を使う。
・データ化するのは固まってから。
![]()
３．プロジェクト憲章の制定
・自動生成された画面には手を入れない。
（自動生成された画面は使い難いが、開発途上では一切手を入れないし議論もしない）
：仕様の確定は３日期限とする。
（キーマンが出てくればその場で決まるが、持ち帰りでも３日以内とする）
・安易な仕様変更はしな。
（これがないと動かないというのは入れる）
これらは、ユーザが歯を食いしばって守り抜く覚悟が必要。
![]()
４．画面の使い勝手はプロジェクトの最後に、予算と時間の許す限り行う。
![]()
・開発途中では、何度も再構築があるので、自動生成機能を生かすために、画面には手を入れない。
・帳票は、BIツールや帳票ツールを使ったほうがよい場合があるので、そちらに任せる。
・画面については、レスポンスや操作性が高度に要求される画面のみ 完成後にBiz／Browser等を使って組みなおすのもよい（片貝独自コメント）。
５．イテレーション（設計・試験・調査・改善という一連の工程）のスケジュールを守る。
![]()
・二週間に一回行う。
・会議には、迷ったときどうするか、実質決定できる人が、万難を排して出席する。
・開発チームは、次回のイテレーションまでに、必ず機能をを修正する。
６．アジャイル型プロジェクト管理手法の採用。
![]()
・よくわかりません（片貝）
７．作業状況を誰にもわかるように貼り出す。
![]()
・相手が何をしているかわかることで助けあうことができる。
・プロジェクトチーム員は全員小部屋に集結し、すべての情報が耳に入ってくる場所で会議も仕事もした。
８．ゆとりを持った開発とサービスイン後の３００回のリリースの実現。
![]()
・システムは自動生成なので、ほぼ毎日新しいリリースを出せた。
・最初の３か月は操作性のクレームが多発したが、その後落ち着いた。慣れはある。
・システムが安定してから、頻繁に使う画面だけ別途バイパス的に作り組み込むことは可能（片貝コメント）
９．データ移行と経営の視点。
![]()
・旧システムからのデータ移行は、ユーザではなくベンダーにお願いすべきだった。
・オペレーションの視点ばかりで、日々の経営判断の材料になるような情報提供ができなかった。
・ユーザからはクレームはないが、素晴らしいという評価もない。しかしITコストは激減した。
１０．超高速開発ツールがあたりまえのように選択される時代であるべきだ。
![]()
・プレゼンテーションで、役員から、名称を直す程度の修正なら自分たちで簡単にできるのか？と聞かれて、はい！と答えたことが、だったら検討してみたらいいじゃないかという発言につながった。この一言は大きかったが、そうでなくても、普通に選ばれるツールになって欲しい。
１１．ベンダーと一度も喧嘩しなかった。
・当初ベンダーは自社提案の素晴らしさを喧伝するのではなく、現場を回って、今のシステムの問題点を真剣にヒアリングしてくれた。これで現場の雰囲気がガラッと変わった。ここで信頼感が大きく膨らんだ。
・ベンダー側から、ユーザとして責任を持ってやるべきことの提示を受け、ユーザは納得してそれを守った。
・ベンダー、ユーザとも共通の目的に向かって走ることができた。
