これまで超高速開発ツールを使ったビジネスをしてきて、大きなベクトルを持った考えに辿り着いたと思える様になった。
私自身ここ3年ほど本腰を入れて超高速開発ツールを利用した開発をメインとしたビジネスをしてきた訳だが、そこで試行錯誤、紆余曲折してきた。成功と失敗となかなか再現性が出ない中で、いくつかの成功事例から見えてきた、超高速開発ツールを利用した開発の方向性。
アジャイルだのなんだの技術力やら様々な言葉に惑わされながら辿り着いた自分の中の現時点での一つの解。自分の考えを整理する為にも記事としてアウトプットしておく。
「SEは仕様書を書き」「PGはコードを書く」
この原理原則に沿った形で超高速開発ツールを利用する事が最適解なのではないかと言うのが結論です。
超高速開発ツールはプログラマー
超高速開発ツールをツールとして捉えた場合、PGの支援ツールだと考えていた。超高速開発ツールが求められている事を理解すると、超高速開発ツールは道具と言うより、それ自体がプログラマーだと気が付く。
どういう事か？これはPGとSEの仕事の内容を考えると一目瞭然となる。
SEの仕事とPGの仕事
SEは「仕様を考える」事が仕事になる。
SEの仕事
利用者の要求を満たす仕様を考える事が専門の職業となる。オーソドックスな仕事のスタイルは要件定義書や機能設計書と呼ばれるドキュメントを記述し、利用者の要求をどの様に満たすか検討し、時には利用者と直接話をして要求がどれほど満たされているかを利用者に検討してもいながら仕様を調整していく作業となる。
顧客にドキュメントだけでは伝わりにくいのでデモ版と言った実際に動かせるものを見せての検討なども行われたいたりもするが、その際はプログラマー経験のあるSE自身がコーディングをしたり、またはプログラマーが要件定義工程から参画したりして、デモ版を作成したりしている。こういった作る事はPGの作業領域になるからだ。
PGは「仕様書通りに作る」事が仕事だ。
PGの仕事
機能設計書に基づき、機能設計書に記載されている機能を実現していく事が仕事となる。仕様書に記載されている内容を正確かつ素早く高品位に再現する事が要求される。
もちろん、お互いがお互いだけしか考えていないような事ではなく、相互に連携する事が大切なのは言うまでもない。例えばSEがいくら「仕様を考える」仕事だと言っても、技術的に無理な事を仕様にしても仕方がない。その逆で「仕様通りに作る」仕事だからと言って、仕様に矛盾があるのにそのまま作るのは愚の骨頂と言える。ただし、極論をするとお互いの主たる作業領域は上記の通りだと思う。
端的に言えば、SEは仕様書を書いて、PGはプログラムを書くという事になる。
SEとPGの違いはこちらの方でも語っている。
超高速開発ツールとは何なのか？
「超高速開発ツールとは何なのか？」この考え方に沿って考えて超高速開発ツールを定義してみる。
仕様書を理解してプログラムを書く
という事からすると、間違いなくプログラマーと言える。
プログラマーと言う事は、作業のためのインプットが決定される。それはSEが作成するシステムの仕様書がインプットなる。
超高速開発ツール
している事はプログラマーに他ならない。位置づけとしてプログラマーなのだ。
超高速開発ツールの目的
ここで改めて超高速開発ツールの目的を考えてみる。まぁ、これは単純明快。
超高速に開発するのが目的だ。
この場合は超高速開発ツールを利用して達成する事を目的としている。
超高速開発ツールを利用する事で、どうやって超高速な開発を実現するのか。
ここがポイントです。
プログラマーの作業の流れに立ち返る
プログラマー作業の流れについて改めて考えてみよう。
PGはSEの作成した仕様書を読み解きプログラムを作成する
この流れが原則だ。プログラマーが仕様に関して他のプログラマーに伝達する事は基本的にあり得ない。しかし、現場では超高速開発ツールをPGに利用させているケースが多々ある。
PGからPGへ仕様を説明しているのと同じ
これはこの様な形でPGからPGへ仕様を説明しているのと同じ構図になっている。明らかに変だ。
仕事の流れから考えるとSEがプログラマーに仕様を説明するのがベストだと言える。
かと言ってSEが仕様書を書きながら超高速開発ツールを操作するなどとなると、SEの仕事が増える一方で作業効率は更に落ちるだろう。
SEの仕様書を書きながら仕様をPGにも指示をする
プログラムエラーが混在する理由
ではプログラムエラーが混入してしまう理由は何だろう？
SEとPGは仕様書を介在して意思の疎通を図っている。SEは仕様書を作成し、PGは仕様書を読み解いてプログラミングを行う。このやりとりでシステムでエラーが混入するポイントは大別すると次の3パターンになる。
- SEの書く仕様書に誤りがある場合、プログラマーは忠実に再現するので、その誤りのままシステムが作られてしまう。
- SEが書く仕様書をプログラマーが正しく理解できずに課開発した場合、正しく理解できていないままシステムが開発されてしまう。
- SEが書く仕様書をプログラマーが正しく理解できたが、プログラミングにミスがありエラーが混入してしまう。
1はSE側、2と3はPG側のヒューマンエラーによって発生する。
PG側のヒューマンエラーをなくすために、読み解く時にミスリードをなくすため、仕様書を定型的なものとして書く内容に揺らぎがなくなったとしてもヒューマンエラーはなくならない。
しかし、定型的な仕様書をバッチ的にコードに落とすツールが用意できたら、ツールから出力されるコードにはヒューマンエラーが混入する事がない。
ここに超高速開発ツールの一つの解があると思う。
SEの書いた仕様書を理解できるツールがあったら？
超高速開発ツールの進化の方向性としてあるべき姿を考えた時、よりプログラマーとして進化していくのが正しい姿だと言える。それは「仕様書を理解して仕様書通りのシステムを開発する」事。インプットは仕様書である点がポイントになる。人が書くなにがしらのコードの類ではない。ましてや、プログラマーが書くコードではない。人が読んで理解できて、利用者が仕様を理解できるドキュメントであり、人のプログラマーでも読めば開発ができるドキュメントがインプットとなる。
これこそが究極の超高速開発ツールの形と言える。SEとPGの住み分けも出来る上に、SEがSEの仕事に没頭でき、余計なヒューマンエラーが介在せずに仕様バグの改修に集中できる。それも仕様書を修正するだけで仕様バグが改善される。まさしく超高速開発ツールの正当な進化の方向性であると言える。
超高速開発ツールと人のプログラマーのすみわけ
超高速開発ツールはIT業界の中にいる、とりわけプログラマー達の反発は相変わらず大きいものを感じている。彼らの主張は「こんなの使って良いシステムが出来る訳ない」「技術力の低下」と言った主張がほとんどだ。
「こんなの使って良いシステムが出来る訳ない」に対して
まず、良いシステムかどうかの判断基準は顧客にあり、プログラマーが決定するべき話はない。費用対効果などで推し量ってく必要があるべき指標なので、超高速開発ツールで開発したら「良いシステムが出来ない」は成立しない。
「技術力の低下」に対して
例えば画面フォームから数値を入れて、送信ボタンを押すとサーバーに送信されサーバサイドで入力値チェックを行って、データベースに登録する。これをわざわざプログラムする事に技術はいりません。むしろ極力省力化して生産性を上げる事が技術力です。
技術力は未踏の地でこそ発揮すべき力だと思います。
超高速開発ツールが手を出せない所をプログラマーが作る
そうです。超高速開発ツールはコモディティー化された領域こそ得意ですが、新しい技術やツールがサポートされていない個所には当然手出しができません。
そういう所こそSEが書いた仕様書通りに人のプログラマーがきめ細かくプログラミングをして実現をするべきだと思います。
人は優秀なんです。未踏の地でも経験と知識を応用する事が出来ます。これこそがプログラマーが主張すべき技術力なんじゃないでしょうか？
また、今まで作らなくても良いコードを作っていて持っていかれていた時間が空くことで、プログラマーは高度な技術を学習する時間が生まれます。この時間を活用する事でさらに高度な技術を高生産出来る環境をプログラマー自信が用意出来れば素晴らしい事になると思います。
まとめ
超高速開発ツールの正当な進化は、SEの書いた仕様書を理解してプログラミング出来る様なる事。
超高速開発のあるべき姿
PGは仕様書を理解していプログラムを開発する事を基本として、SEはあくまで仕様書でPGに指示をだす。超高速開発ツールを利用する事により不要なヒューマンエラーを排除する事で、仕様バグを取り除くことに集中出来る環境を実現する。PGは超高速開発ツールでは実現できないより高度な技術力が必要な個所を受け持つ事で、より高度な技術習得に集中する事が可能となる。
これが今の自分の超高速開発の最適解となっている。
コメント