- スモールシステム スモールチーム
-
何かを始めようとするときに、次のビルジョイの言葉は、我々を勇気づけてくれます。
「世界を変えるものも、常に小さく始まる。偉大な世界を変えたシステム、たとえばJavaだって、最初は小さくスタートした。理想のプロジェクトチームは、会議もせず、ランチを取るだけで進んでいく。チームの人数は、ランチテーブルを囲めるだけに限るべきだ。」
プロジェクトは機能を細分化し、チームが大きくなればなるほど、マネジメントやコミュニケーションの時間が増大してしまいます。理想のAgileチームはスモールシステムのなかから生まれ育っていきます。新しい時代の小さな革新のコアを生み出しそれを育てていくそうした歩みが成功への近道かもしれません。
- 開発チームの組成
-
プロジェクトの成功に向けてどういう開発チームを組成するかは、極めて重要な要素です。プロジェクトの成否のかなりの部分が、この部分に依存します。
ビジネス面を引っ張るリーダー システム面を引っ張るリーダー。それぞれの資質もさることながら、両者の関係も重要で まさに ビルジョイの言う ランチテーブルを囲った議論で方向性が決まっていくそうした関係を築いていく事が理想です。
そして、チーム全体としての個々人の考え方×熱意×能力の総和を最大化するよう、全体リーダーは、考え方をあるべき方向にもっていく努力を続けなければなりません。
- 開発基盤の戦略策定
-
個々の開発者の熱意が別々の方向に向き、からまわりしないように、基本的な開発基盤に一貫した思想を持つべきです。
開発言語・アプリケーションフレームワークのレイヤがよく議論されますが、プロジェクトの共通ライブラリ・共通サービスのレイヤを充実させ、Agileプロジェクトの過程で育てていくことにも大きな関心を持つべきです。
開発基盤が、外注するベンダーによって、あるいは担当するリーダーによって毎回異なる組み合わせが採択されることがありますが、これは望ましいことではありません。かといって古い基盤に囚われ続けてもいけいません。ある程度の時間軸で戦略を持って考える必要があります。
- 自前のアプリ基盤で標準化
- アプリ基盤のすべてを自前で作成することを推奨するわけではありません。アプリケーションフレームワークは、信頼性の高く人気の高いものを採用したうえで、その上に自社の業務に適合するサービスクラスをライブラリ化して標準化すべきです。（ライブラリ化に当たっては基盤とするアプリケーションフレームワークの作法に従うのが重要です。） 自前のアプリ基盤のライブラリが充実すると、自然と標準化が進み、セキュリティ基準も満たし、他の人の作成コードも見やすく、雛形化（scafford対応）も容易になります。
- プロジェクトノウハウの継承
-
自前のアプリ基盤を作ったら、それで終わりといううわけではありません。継続的にニーズに応じた機能を追加し、ライブラリをバージョン管理し、次のプロジェクトでも、利用することで、ノウハウを累積的に蓄積することができるのです。複数のサブプロジェクトで蓄積されたノウハウの継承は、次のプロジェクトで圧倒的な生産性を生み出すことになります。
しかし、自前のライブラリを継承して育てていくといっても、何から始め、どうやったら継続できるのかは難しい問題です。活動を維持する推進力が必要になります。 AGILE DEVELOPMENT menu ↑
- 基本機能のサービス化
-
サービス化について意識の高いプロジェクトでは、サービスオリエンテッドな開発を推奨し、サービス層のクラスライブラリやAPI群の整備がすでに行われていることも多いかと思います。
これに加えて共通的な機能は画面自体もサービスライブラリ化することで AgileのPOC開発の初期フェーズを圧倒的なスピードで立ち上げることがことができるようになります。
画面をもつ機能のサービス化には、言語ごとに異なる手法があります。画面自体をサービス化する場合、configやCSSなどの管理にも工夫が必要になってきます。 AGILE DEVELOPMENT menu ↑
- スクラム開発
-
スクラム開発の方法論やHowToには多様な書籍がでていたり、研修プログラムも豊富ですのでここでは触れません。
いくら優れたスクラム開発の手法をとっても、同じ機能を開発するのに３者３様のコードが作られるのでは、コードレビューも労力を使いますし、長いスパンで生産性を悪化させることになります。いろいろなスキルセットを持つメンバーがいる中で、スクラム開発をうまく回すには、開発のアプリ基盤のライブラリを用いた標準化が重視されるべきと思います。
一般に標準化は開発者の自由を奪うものとして嫌われがちですが、セキュリティ上、当然実装しなければならないが、実装が面倒な部分をアプリ基盤を利用してコードを削減し、機能実現に必要なアプリロジックの開発に集中できるようするということには賛同してもらえるでしょう。 AGILE DEVELOPMENT menu ↑
- スキャフォルドツールの作成
-
スキャフォルドツールとは、アプリケーション原型の自動生成ツールです。一部のフレームワークではフレームワーク自体にこの機能を持つものもあります。特にマスター登録、条件検索画面などに適用されることが多いです。
一見、プロジェクトにあった雛形を生成するのは難しそうですが どの言語でも スキャフォルドプログラムを作ることは可能です。よいスキャフォルドツールができると圧倒的に高い生産性を生み出すことができるようになり、Agile開発の現場で圧倒的な生産性を生み出します。スキャフォルドツール作成には、機能の汎用化とベストプラクティス作成から始めます。
スキャフォルドされるソースコードは、その後のエンハンスがやりやすいものでなければなりません。 AGILE DEVELOPMENT menu ↑
- 運用につながるPOC
-
DX系のシステムでは、POC開発をやってから本格運用のための開発を行うということがよくあります。
よくあるのが、POCが POCでストップしてその後の運用につながらないということがよく見受けられます。なぜでしょうか？それは、POCでの短期間開発が重視されるため、セキュリティーや運用性の配慮を行うレベルで実装することが難しいからです。
一方で、アプリ基盤で生成される部品や認証サービス、スキャフォルドツールで生成されるソースが セキュリティ基準を満たし、運用性にも配慮した長年のノウハウを詰め込んだものだったらどうでしょうか？POCで作ったシステムをその後の運用に継続使用できるようになります。
AGILE DEVELOPMENT menu ↑
