ジャストインタイム駆動開発(JIT駆動開発)

• ジャストインタイム開発(JIT開発)とは「必要なものを、必要な​ときに、必要なだけ」作成するというシステム開発の手法です。
• 工場におけるJIT、営業におけるJIT、物流におけるJITなどがありますが、システム開発におけるJITがJIT駆動開発ということになります。
• ジャストインタイム駆動開発については、自分が言い出しッペ(提唱者)だと思いますので、命名日は2021年7月10日とします。今後、毎年7月10日はJIT駆動開発の誕生日としてお祝いして下さい。

システムの開発の種類

-　Google先生曰く、システムの開発方法には色々な方法があります。例えば以下の通りです。
　　- ウォーターフォール開発
　　- テスト駆動開発 (Test Driven Development:TDD)
　　- ビヘイビア駆動開発・・・テスト駆動開発の一種
　　- ドメイン駆動開発 (Domain-driven Development:DDD)
　　- モデル駆動開発 (Model Driven Development:MDD)
　　- 証明駆動開発 (Proof Driven Development:PDD)
　　- アジャイル開発(agile software development）
　　- スクラム開発・・・アジャイル開発の一種
　　- フィーチャ駆動型開発(Feature Driven Development:FDD)・・・アジャイル開発の一種
　　- ユーザー機能駆動開発・・・フィーチャ駆動型開発の別名
　　- ユースケース駆動開発(use case driven development:UCDD)
　　- JIT駆動開発　(Just in time Driven Development:JDD) ← New!!
　　- PDRサイクル駆動開発　(Prep Do Review Driven Development:PDRDD)← New!!
　　- 縛りプレイ開発 (Tied up Play Development: TPD) ← New!!

ジャストインタイム駆動開発の考えに至った過程

前置

• 自分は、この1年、自分一人で客先に常駐してシステムを開発するという経験をさせていただきました。しかし、自分のやった開発手法は上記のどれにも該当しないと思いながら作業を進めていました。自分としては、当然やるべき作業を当然のようにやっていただけで、開発手法なんて考えながらやっていませんでした。必要なのでドキュメントを作成して、必要なときにコードを書いてスケジュールを書いて承認をもらってデプロイした、ただそれだけなのです。(たぶん、みなさんも割と同じようにしているのではないかと思っているのですが・・・。)ウォーターフォールでもない、アジャイルでもない。そこには、別の言葉で定義できる何かがあるのではないか、と考えていました。

困惑

• また昨日、自分は困りました。転職エージェントの人に「どのような手法で開発されていたのですか？アジャイルですか？ウォーターフォール型ですか？」と聞かれたからです。何ということでしょう・・・。自分は、本当にどちらの手法で開発したというわけではないのです。でも、嘘をつくわけにはいかない。しかし、現実問題として、システムの開発が完了していて、開発方法は本に書かれている方法とは違う。自分は教科書に書かれているような開発のルールに従って仕事をしているわけではないのでした。

天啓

• そして、自分がやっていた開発方法は、ジャストインタイム駆動開発であると気づきました。ジャストインタイムという生産管理のシステムは、既にみなさんもご存知だと思われます。釈迦に説法なので詳しい説明は省きますが、この生産管理システムはITシステムの開発手法にも導入できるのではないかと思いました、というより、自分のやっていた開発手法はJIT駆動開発なのだと思いました。

ジャストインタイム開発の特徴

• JIT駆動開発の開発ルールはだた一つです。必要なものを必要な段階で必要なだけ作成するということです。そのため、融通が効きやすい開発方法だというメリットがあります。
• 例えば、新しいツールを使うので、ドキュメント作成よりも調査を先にやって多く実験をしてみたり、ドキュメントの作成を後回しにしてみたりなど、いろんなやり方に適用でき、それが本当に必要な作業なのかどうかという点だけを軸にして、作業を進めていくということができます。
• ジャストインタイム開発には、こうしなくてはいけないという縛りプレイはありません。必要であるならやる。だだそれだけです。
  • 例えば、レビューが必要だと思うならレビュイーとレビュワーのルールを決めてレビューをすればいいのです。

ジャストインタイム開発の諸ケース

• 自分だけが利用するVBAやフリーツールの作成、又はお客様からドキュメントを必要としない作業を受けた場合などは、仕様書などは書かなかったり、後からドキュメントを要求されたりすることがあるのではないでしょうか、この場合は何開発というのでしょうか？
  • この場合、開発者は必要なときに必要なだけ作成しています。まさに、ジャストインタイム開発をしているというのが妥当なのではないでしょうか。
• 自分の場合、データベースを作成する前に、データベース定義書は必ず用意します。これを先に書かないと、後々、理論名がわからなくなってしまってヤバい、ということを実体験で知っているためです。その代わり、仕様書などは必要なら作るという消極的な感じです。また、この処理については図を書かないと後任の人が絶対に困るという場合は、リーダーが予定していなくても、自主的にデータの流れ図を書いて、その図の必要性をミーティングで力説するということもありました。スケジュールが遅れている場合などは、ドキュメントを省略するという場合も多いのではないでしょうか？
  • このような場合も、開発者は必要なものを必要なだけ作るというジャストインタイムの考え方にマッチしています。
• 品質をもっと上げたい場合は、テストをもっと多くやればいいという結論になります。但し、時間があればですが。
  • これも、ジャストインタイムで説明ができます。マネージャーが必要であると判断したならば、テストコードを書いて、例外の行のテストをして、カバレッジを増やせばいいだけです。
• プロジェクトの途中で仕様が変更されることもあります。調査の結果、もっと良いやり方が見つかったりもすることもあります。
  • この場合も、アジャイルだからウォーターフォールだからではなく、当然そうせざる負えないという理由(=必要性)の方が多いと思います。できるかどうかわからない場合は、「持ち帰らせて頂く」と言った表現を使ったりして、まずは調査する必要性があるものだと思います。お客様に会議で説明するなら、当然ドキュメントの必要性が生じますし、業務を理解するためには、現場の人の意見をヒアリングする必要性が発生します。それも、必要だから必要なだけ作業を行うということであり、ジャストインタイムを既に皆さんもやっているのではないでしょうか。

アジャイル開発について

アジャイル開発のメリットは、反復ごとに開発・提供を行うため、より速いスピードでユーザーにプロダクトや新機能を提供できることです。

• agile［名・形動］俊敏であるさま。機敏な。敏捷な。
• アジャイル開発については、都合よく解釈されて説明されていると思います。どの開発方法にも該当しないので、消去法的にアジャイル開発だと言っている人も多いのではないでしょうか。Google先生に聞いても具体的なやり方を実務レベルで実行できるほどに書かれていないので、作業中に「この場合はアジャイルと言えるのだろうか？」などと、よく思います。
  • Web上で色々なルールが解説されていますが、これがアジャイルだという説明が増えるほど、自分のやった開発方法はアジャイルではないことになります。なぜなら、自分はアジャイルをよく知らないので、アジャイルのルールを無視しているからです。自分は必要なので必要なときに実装・作成・調査するという自然な考え方に則って、システム開発をしているので、開発手法に特別な縛りプレイや思想は必要ないと考えているからです。

スクラム開発について

• スクラム開発はアジャイル開発の一つと言われていますが、ウォーターフォール型の開発でも、スクラムを組んで作業はできるので、アジャイルの専売特許ではありません。デメリットとして、同じ箇所を重複して作業したら、時間の無駄が生まれます。そのため、ある程度分担して作業をすることになると思われますが、それは通常の開発です。またデメリットとして、一人で開発した場合には、一人でスクラムを組むという寂しい状況になり精神的ダメージが生じるため注意が必要です。

ユーザー機能駆動開発について

• ユーザー機能駆動開発とは、ユーザーの目線を重視する手法です。ユーザー機能のことをFeatureと言うらしいので、フィーチャ駆動型開発がエイリアス(別名)です。なぜユーザー機能駆動開発がアジャイルの一種なのかは疑問です。ウォーターフォール型でも、顧客目線のシステム設計は可能です。アジャイルが仕様変更がしやすいからユーザー機能駆動開発はアジャイルの一種だという発想だと推測されます。
• 個人的には、ユーザー機能駆動開発の方が、アジャイルという言葉よりも好きです。アジャイルと言う言葉を使ったときに、意味不明な言葉でごまかされたような気がするからです。ユーザー機能駆動開発のように、ユーザ目線でユーザが必要としているから実装するという明確な考え方の方が、ごまかしではなく、内容をしっかり伝えられると思うからです。
• ユーザー機能駆動開発の場合、業務をシステムに合わせるか、システムを業務に合わせるかという点が重要になります。具体的には、自分の場合、Salesforceの開発をした際に、Salesforceの営業から「業務をSalesforceのシステムに合わてくれ」と言われましたが、自分はユーザ(作業者)の立場を重視して、ユーザ(作業者)から要求されたシステムを実装しました。この結果、ユーザから使いやすいという評価を得ることができ、評判も良いと言われました。デメリットとしては、そのぶん工数を余計に使ったという点があります。

PDRサイクル駆動開発について

• PDRサイクル駆動開発とは、ハーバード大学のリンダ・ヒル氏が考えたPDRサイクルによって、システムを開発するという考え方です。
• すいません。PDR駆動開発ですが、これもたった今、自分が考えました。急に閃いたので。Google先生も聞いたこと無いとおっしゃっています。そのため、PDR駆動開発も命名日は2021年7月10日になります。毎年7月10日はPRDサイクル駆動開発の日・誕生日としてお祝いして下さい。

PDRサイクルとは

• PDRサイクルとは、「Prep（準備）」「Do（実行）」「Review（見直し）」の3ステップから構成されるマネジメントサイクルのことです。
• PDCAのデメリットを回避するために提唱されているサイクルの一つです。
• PDCAはそもそも衣服業界のような一年のサイクルを前提にしているため、ITのような日進月歩の業界には遅すぎるサイクルと言われています。このため、IT業界においては、PRDサイクルのようなスピード重視の管理手法が好ましいので、システム開発の手法としても相応しいということです。

PDR駆動開発の考え方

• アジャイル開発も機能の実装などについて、小さなサイクルを作って回すという説明がされています。このため、PDR駆動開発はアジャイル開発の一種だと言ってもいいと思います。
  • むしろ、逆にPDR駆動開発の一種がアジャイル開発だと自分は主張します。理由は、実際にこれらのクラスを継承関係つけてプログラムで実装することを考えた場合、アジャイルは細かく説明が書かれているので親クラスにするには重すぎます。このため、PRDクラスの機能を継承したクラスがアジャイルクラスだと考えて継承させた方が自然であり、PDR駆動開発の一種がアジャイル開発だと考える理由です。

縛りプレイ開発(Tied up Play Development: TPD)

• アジャイル開発ではこうだから、ウォーターフォールはこうだから、こうやるべきと決めつけてしまって、融通が効かなくなり、結果的に効率が悪くなっているような開発方法です。おもにリーダーのミスリードにより発生し、リーダー側は縛りプレイであることに気づいていないことが多いと思われます。テスト駆動開発も然りで、無理にルールに従うと、かえって非効率的になったり、中途半端になってしまうこともあります。一般的に自然体で仕事を進めていく方が作業しやすいと思います。
• この開発方法も自分が最初の提唱者です。2021年7月10日が誕生日です。

最後に

• 正しい英語だと、ジャスト・オン・タイムらしいですね。
• この記事よりも前にJIT駆動開発やPDR駆動開発、縛りプレイ開発について言及している記事がありましたら、教えて下さい。
  • 教えていただかない場合は、自分が第一提唱者としてドヤ顔をし続けます（笑）