| Bottom | Home | Article | Bookshelf | Keyword | Author | Oxymoron |

 

Non-Waterfall Type Software Development
Cat: ICT
Pub: 2014
#: 1401a

Kanzo Kobayashi (小林寛三)
14101u/18208r

Title
 Non-Waterfall Type Software Development 非ウォーターフォール型ソフトウェア開発
Index
  1. Introduction:
  2. Background of NWF software development:
  3. Paradigm shift of Owner:
  4. Overseas Agile SW development:
  5. Glossary of Scrum, etc.:
  6. Preferable Contracts for NWF Development:
  7. Why Agile development is agile?:
  8. Herrmann Model and NWF Development;
  9. IT Human Resources:
  10. IPA's recommendation for NWF development:
  11. Why NWF SW Type couldn't proliferate in Japan?:
  1. 序:
  2. 非ウォータフォール型ソフト開発の背景:
  3. オーナーのパラダイムシフト:
  4. 海外のアジャイル・ソフト開発事情:
  5. Scrumなど用語集:
  6. NFW開発にとって適切な契約:
  7. なぜアジャイル開発は迅速なのか:
  8. ハーマンモデルとNWF開発;
  9. IT人材:
  10. NWF開発普及のためのIPA提言:
  11. なぜ日本でNWF型が普及しないのか？:
Why?
  • Here is the summary of non-waterfall software development
  • ICT Management Partners Association to which I'm involved aslo promoting "Ultra Rapid SW Development Community"
  • 以下は非ウォーターフォール型ソフトウェア(NWF SW) 開発に関する参考情報をまとめた。
  • ICT経営パートナーズ協会でも超高速開発コミュニティティーを立ち上げに関与した。
Ref.
  • There are many reports and tips of NWF type or Agile development, or Scrum/XP, etc. on the Web.
  • IPA, a Japanese governmental IT promoting organization now publishing several in-depth report about NWF type SW development.
  • But most reports are general, and more actual examples or field reports are expected hereafter.
  • ネット上にはNWF型やAgile開発、あるいはScrumやXPについての多くのレポートが掲載されている。
  • 経産省系のIPAでもNWF型開発について相当詳しい報告がある。
  • しかしまだ一般論が多く、今後さらなる現場からの実例報告が増えると想う。
English resume
Japanesse resume

>Top 0. Preface:

  • Change of society and business environment is called 'context' herein.
  • There are serous troubles in software development based on the waterfall type (WF) in Japan.
  • Recent rapid changing business environment required non-waterfall type (NWF) software development, which would be suitable for such changing environment, or business context.
  • Though NWF software development is not so much penetrated in Japan, but not a few success stories are getting reported.
  • Agile SW development has related to the lean production methodology in 1980s applied in Japanese automobile industry.
    • Lean SW development is also proposed in US in 2003, aiming; 1) minimize uselessness, 2) keeping qualification of SW, and 3) total optimization, as well as paying attention to the developing peoples thinking quick delivery of SW products.
    • Now LEfSE (Lean Enablers for Systems Engineering) is considered at INCOSE (Lean Enablers for Systems Engineering) in US.

0. 序:

  • 社会やビジネス環境の変化＝"Context"と称す.
  • WF型(Waterfall型)ソフトウェア開発の深刻なトラブル
  • 一方で、NWF (Non-Waterfall) ソフトウェア開発による成功事例も増えてきている。
  • リーン開発システムは日本のトヨタ生産方式から発展してきた。

>Top 1. Background of NWF software development:

  • NWF SW development has following features:
    1. appropriate response to changing business needs:
      rapid SW development is required to meet with rapid change of business
    2. solution against WF SW development:
      all RFP is decided before SW development, which may cause discrepancy or delay of SW completion, or the completed SW become obsolete at the cut over. Also, frequent returning of the development process consume useless time and money.
    3. solution for the structural problems in SW industry:
      The present SW industry contains multi-layered sub-contractors structure, which causes degraded morale or less achievement goals of SW developers.
  • Favorable area of NFW SW development:
    1. the changing business paradigm: shortening of TTM (Time to Market)
    2. global competition
    3. frequently changing SW functions (Web services, package development, etc.)
    4. visible achievement of each SW engineer involved
  • Definition of NWF SW development:
    1. SW development other than WF SW development defined by Winston W. Royce in 1970 "Managing the Development of Large Software Systems."
    2. As the examples of NWF development are:
      • Prototype: Frederick P. Brooks, 1975
      • Spiral: Barry w. Boehm, 1988
      • RAD (Rapid Application Development): James Martin, 1991
      • RUP (Rational Unified Process): Philippe Kruchten, 2000
      • EVO (Evolutionary Development): T. Gilb, 1981
      • Scrum (Agile Software Scrum): Ken Schwaber, 1993
      • DSDM: DSDM Ver-1, 1995
      • XP: eXtreme Programming: Knet Beck, 1996
      • FDD (Feature Driven Development): Peter Coad, 1997
      • LSD (Lean Software Development): Mary & Tom Poppendieck, 2002
      • Crystal Clear: Alistair Cockburn, 2004
      • EssUp (Essential UP): Ivar H. Jabobson, 2005
      • ASD (Adaptive Software Development)
      • MDA (Model Driven Architecture)
      • Kanban: David Anderson, 2010
  • Agile Manifesto (Manifesto for Agile Software Development) by 17 developers in 2001, which values:
    • More human dialogue than process or tool
      (Face-to-face communication is most effective to enhance team capability) usually no more than 10 people team.
    • More functioning SW than overall documentation
      (cycles within a few weeks or a few months.) usually 2-4 week iterations
    • More collaboration with client than contract negotiation
      (works collocation with the client and developer)
    • More responsive to the changes than keeping the original plan.
      (best architecture is made from autonomous team; simpleness matters.)
  • Trial and error areas of NWF SW development:
    • Large scale SW development requiring more than 10 developers
    • Distributed or offshore development: multi location and time difference are bottleneck.
    • Development beyond organization or company:
    • Embedded software: version up after release is difficult.
  • Viewpoint from User and Developer of NWF SW:
    • Viewpoint from User:
      1. quick confirmation by moving software
      2. quick start of SW development before finalizing RFP
      3. flexible to the change of priority or RFP
      4. avoidance of useless or obsolete function during development.
    • Viewpoint from Developer:
      1. quick confirmation of the user's merit
      2. short cycle of development can accumulate development experiences
      3. maintenance of motivation by achievement.
  • Premises of both U and V sides:
    • Vender understands the User's business.
    • User participated development team and makes timely decision making
    • Both V/U allows changes of scope.
  • Relation between Agile SW development and Employment:
    • Agile SW development, in-house SW development, and liquidity of employment relates each other, particularly in Japan.
    • Cloud age changes the ownership of SW development resources; human resources for in-house development is getting cost or risk factor.
    • Former in-house SW development like major steel companies experienced similar SW development environment like Agile development.
    • Offshore SW development supplies enormous human developers, but the highly skilled engineers are still short in supply, which is required for Agile development.

1. NWF SW開発の背景:

  • NWF SW開発の特徴a
    1. ビジネス変化への対応
    2. WF開発の問題点対応
    3. SW産業構造への対応
  • NWF SW開発の得意領域
    • ビジネスパラダイム変化する領域
    • 国際競争力
    • 最近のSW機能の変化
    • SWエンジニアの達成感の可視化
  • NWF SW開発の定義
    • Prototype
    • Spiral
    • RAD
    • EUP
    • EVO
    • Scrum
    • DSIM
    • XP
    • FDD
    • Lean SW development
    • Crystal Clear
    • EssUp
    • Kanban
  • Agile SW開発宣言:2001
    • プロセスより個人の対話重視：10名以下の開発チーム
    • 動くSW：2-3週間〜2-3ヶ月; 通常2-4週間のイテレーション
    • Documentより動くSWを
    • 契約より顧客との協調
    • 計画より変化への対応
  • NWF SW開発の試行錯誤領域:
    • 大規模開発
    • 分散, Offshore拠点
    • 組織・会社をまたぐ開発
    • 組込SW開発
  • 顧客(U側)および開発者(V側)からの見解
    • <U側>:
    • 動くSWで早期確認
    • 要求不十分でも開発開始可能
    • 優先順位やRFP殉難
    • リスクの早期軽減
    • ムダな開発をしない
    • <V側>：
    • U側の価値確認しながら開発可能
    • 短サイクルでの経験積み上げ
    • 達成感によるモチベーションup

 

>Top 2. Paradigm shift of Owner:

  • Paradigm shift for corporate executives:
    • Active role of CEO/COO/CIO is required, particularly for Agile development.
    • IT governance and Corporate governance are closely related (like as internal control and corporate control)
    • IT issues are getting to be the issue of executives, which could be a crime of omission.
    • NWF SW development relates closely to:
      • end user computing
      • IT risk evaluation
      • maintenance and operation of IT systems
      • IT systems troubles
      • project management
      • outsourced assignment control
  • What is the system?
    • cluster of SW
    • IT system is SW life cycle process, showing performance more than the sum of components; (Holonisum)
    • system is autonomous and has fractal features (because SW itself is a system).
    • In case of system troubles, causing the problem which the system itself created.
    • Thus to solve such system trouble, it is needed to change the whole system.
    • The system comprise HW and SW; HW can be estimated exactly its behavior, but SW is not, because which is man-made product.
    • In making a IT system, there are 'Owner', 'Designer', and 'Constructor'
  • IT System Cycle:
    • IT system should be like a town development which needs administrator (CIO) to maintain its function, continuing crating corporate values (or corporate culture)
    • This long-term framework should be Enterprise Architecture (EA).
    • Corporate business is on-going; just like enlarging a ship while sailing.
    • Royce never uses a term of 'Waterfall,' on the contrary he admitted one or twice return of the process (Build Twice!)
    • If there were no return of process, it put the problems later stages or making simple mass production.
    • In Boem's spiral models, confirmation by prototyping is needed to proceed the next stage.
    • SW development in 1970's was mostly report design; by since 1980's SW is used on-site, which means 'market' factor become a component of SW.
    • NW computing compose of HW, OS, DBMS, and NW which are collectively called 'Cloud' become now prevailed.
    • Former SW should keep QCD; Quality (less bug), Cost (cheap), and D (on time).
    • But recent SW is required EEE (Efficacy; correct answer), Efficiency, and Effectiveness; in a short which should be effective for the business object (like response time, or inventory turnover)
  • Large scale SW development by NWF model:
    • Burden of owner increases, participating qualified staff to the project teams.
    • Hierarchical formation such as Scrum of Scrums or meta-Scrum team is needed to adjust the large scale SW development.
  • Analogy with construction industry:
    • In 1980's, general contractors in construction industry focussed technology-oriented building of skyscrapers and gigantic buildings, paying limited attention to the environment and city view. (People tend to behave according to the farming database of legal & technical restriction, preference, and cost)
    • Since 2000, new trend of designing process (Ultra Liner Process) is proposed to respond to such social requirement; the process should be 1) not jump, 2) not divide into branches, and 3) not return the former steps. Also making models to keep the logs are needed to proceed steps. This process looks like waterfall liner model, but also it resembles to agile process.
    • Intimate communication with owner using such models is also effective in NWF SW development.
  • Value of NWF SW development for owner:
    • NWF SW development has unique problems or risk except for WF development.
    • It is important to start from the project which would be most appropriate by developing NWF type.
    • Client (End-user, EU): who bears all costs related to IT services and promote business effectively using IT system.
    • IT Division; who supplies IT service for their clients. Usually IT Division and Client belong to the same company or group, and generally use outsource. SMB may have only a few staff and outsourced personnel.
    • There are two types of SW development:
      1. Reliance-centric SW: ERP, SaaS
      2. Agility-centric SW: SW used for new Web & mobile-using business. RFP could not be determined preemptively due to business reason. (Business requirement is flexible and chargeable depending on the situation.)

2. オーナーのパラダイムシフト:

  • 経営者のパラダイムシフト
    • CEO/COO/CIOの役割
    • 特にNWF SW開発の場合
  • 情報システムとは何か :
    • System Lifecycle Processに関わる部分
    • 要素の総和以上のPerformanceを示す
    • 自己組織化・フラクタル性を有する (SWも一つのシステム故)
    • システム=HW+SW
    • HWの振る舞いは予測可能だが
    • SWの振る舞いは予測は困難。人間が関与した
  • 情報システムサイクル:
    • Owner (CEO/COO)はSW利用により企業価値と企業文化を生み続ける必要あり。
    • そのために小さな保守を繰り返して維持する (都市計画の如く)
    • この長期の取組こそEAである
    • 企業活動は継続的であり、ITシステムは航海しながら舟を増築しているようなもの。
  • NWF型による大規模ソフト開発:
    • 施主の負担の増加、プロジェクトチームへの適任者選定
    • 大規模開発にはScrum of Scrumsの様な階層的組織が必要。
  • 建設産業との比較:
    • 建設業界は1980年代は、工学主義に基づき超高層・大規模建設を実施が、環境や景観への配慮は少なかった。
    • 2000年以降は、超線形プロセスのような新たなトレンド、即ち戻らず、枝分かれせず、後戻りしない方法論で、次のステップに進む毎にログを取る方法論を確立。これはNWFに似ている面がある。
  • NWF開発の施主の意義
    • NWFにはWFとは異なる固有リスクはある。
    • NWFが最適と思われる案件からの着手が重要
    • 社内にはITサービス費用を負担し、それを活用する顧客(EU)とITサービスを提供するIT部門とがある。IT部門は通常外部リソースを活用する。
    • SW開発には２種類ある。信頼性重視のシステム (ERPなど)と、俊敏性重視のシステム (Web,モバイル活用など)。後者は、ビジネス上の理由で要件を予め決められない。

>Top 3. Overseas Agile SW development

  • Forrester Research, Inc published in 2010, that Agile method has become major in SW development, mentioning, Agile development 35% vs. Waterfall 13% as of 3Q inn 2009; also hybrid development at site to meet with large project is challenging.
  • Share of Agile development method: Scrum 52%, Scrum+XP Hybrid 14%, Custom Hybrid 9%.
    • # of qualified Scrum (CSM+CSPO+CSP) engineers; US 67,000; UK
  • Case of Denmark：
    DBT (Danish Board of Technology) issues a warning report to avoid failure of IT project, and strongly recommends to use NWF SW development. Essence of the report is as follows;
    1. To start the project at minimum scale, say, developers be no more than 30 and the first delivery be no more than 6 months.
    2. To contract be flexible and changeable.
    3. To include incentive clause than penalty clause.
    4. To include communication plan covering all scope of project.
    5. To make participate of the end user at full-time basis and define their function.
    6. To clarify the function of user and vendor respectively, and review their collaboration (retrospective) at each end of the iteration (sprint).
    7. and so on.

 

3. 海外アジャイル開発事情:

  • デンマークの事例
    デンマーク技術委員会がITプロジェクトの失敗を警告。NWF型開発を推奨。特に以下。
  1. 小規模より開始。30名以下、最初の納期は６ヶ月以内
  2. 柔軟で変更可能な契約
  3. 違約金でなくインセンティブのある契約とする
  4. 体制全体のコミュニケーション計画
  5. 実ユーザのフルタイム参加と役割の定義
  6. 調達側と提供側の役割明確化、協業を納品毎にレビュー等
  • It is no exaggeration to say the the entire global IT industry is experiencing an agile wave. The philosophy is summarized in the following table (from the Manifesto for Agile SW Development)
Important More important
processes and tools individuals and interaction
detailed documentation functioning software
contract negotiations collaboration with the customer
following a plan adapting to changes
  • The agile method are a reaction to the processes that look good in theory but that do not hold up in practice. The agile methods are therefore described as empirical - they are base entirely on practical experiences and work methods that are proven to work.
  • Where older methods are predictive and attempt to foresee future meeds, the agile methods are adaptive and quickly adapt to new demands, adhering to the "Embrace change!" motto. The only measurement of success is functioning products.
  • Another important principle is simplicity and lean thinking.
  • <Scrum> deals with how the project is organized and planned. Experience shows that 30 days (about 1000 effective hours for a group) give a comfortable work pace and adaptability.
  • For larger project, so-called Scrum of Scrums can include hundred of programmers, organized in dozens of Scrum Teams.
  • Scrum is a rugby team for the close-knit shoulder-to-shoulder formation a rugby team forms to jointly move the ball forward. The word is first used by Takeuch and Nonaka in a famous article published in HBR describing the most successful product development projects in Japan.
  • <XP> deals with how to work with programing; such as pair programming and test case production before coding.
  • <Lean Development> stems from the manufacturing industry's Just-In-Time and Lean Production concepts. It deals more with how to organize the entire company's development activities at management level.
  • 欧米ではアジャイル開発ブームと言えるような状況
  • アジャイルSW開発宣言の骨子
  • アジャイルは理論的には正しいプロセスだが実際にはうまくいっていない点に着目して生み出された方法論
  • 従来の計画重視の方法論と異なり、変化を歓迎する方法論である。
  • 簡潔さとリーン思考から成る。
  • <Scrum>は、特に組織運営を重視。30日毎のスプリント (1000人時の作業量)が有効。
  • 大型案件の場合は、Scrum of Scrumsを編成。
  • Scrumの由来はラグビーから。日本の野中・竹内のHBSへの論文が起源。
  • <XP> はプログラミングの方法論。ペア・プログラミングやコーディング前のテストケースなどが特徴。
  • <リーン開発>これはJust-In-Timeとリーン成算方式が起源。経営レベルを含めた全社に適応可能。

<Scrum formation> Re: The new new product development game, , by H. Takeuchi & I. Nonaka, HBR

  • Under the rugby approach, the product development process emerges from the scrumconstant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process in born out of the team members interplay.
  • A group of engineers may start to design the product (Phase-3) before all the results of the feasibility tests (Phase-2) are in. Or, the team may be forced to reconsider a decision as a result of later information.. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process.
  • The exhibit illustrates the difference between the traditional, linear approach to product development and the rugby approach.
  • This approach is essential for company seeking to develop new products quickly and flexibly. The shift from a linear to an integrated approach encourages trial and error and challenges the status quo. It stimulates new kinds of learning and thinking within the organization at different levels and functions.

>Top 4. Glossary of Scrum, etc.:

  • Adaptive: adjustable that project goals or schedule are adjusted in line with how the external factors change.
  • Burn-down Chart: a diagram that monitors how much work remains to implement a segment of the SW being developed during a Sprint.
  • Daily Scrum; brief, daily meeting ( about 15 min.) between the Scrum Master and the Scrum Team. The purpose is to keep work flowing smoothly and eliminate any impediments.
  • Empirical: based on experience.
  • Agile development: a methodology for SW development which emphasized adaptability, short paths between ideas and implementation, and simplified forms of collaboration.
  • Sprint Retrospective: meeting (about 3 hours) held after each Sprint. The Scrum Master and the Scrum Team review both what went well and what should be improved in the next Sprint.
  • Predictive: foresighted, in this context, project goals and schedules based on a prognosis of external factors made at the beginning of the project.
  • Product Backlog: current "to-do list" that contains the project's goals and priorities.
  • Product Owner: the person responsible for the product's Product Backlog and that the project is working with the right things from business perspective.
  • Release Backlog: the same as a Product Backlog, but restricted to a release of the product.
  • Scrum Master: the team leader for the Scrum Team. But the leader doesn't decide alone.
  • Scrum Team: the work force, in this case SW designers in a Scrum project. Organized its work itself and lacks a formal group manager.
  • Sprint: the iteration comprised of normally 30 days during which the Scrum Team concentrates on realizing the goals defined by the project's current Sprint Backlog.
  • Sprint Backlog: a to-do list for a Sprint. Consist of the assignments that the Product Owner has defined as having the highest priority. Is given its final structure during the Sprint's first day at a meeting between the Product Owner and the Scrum Team.
  • Sprint Review: an informal meeting (about 4 hours) at the end of a Sprint during which the team presents and demonstrates, if relevant, for management, customers and the Product Owner what has been created during the Sprint.
  • Timebox: a period during which something is to be carried out. A Sprint is a result of timebox thinking. Deadlines may not be exceeded - parts of the assignment are deleted instead.
  • Story: XP: memorandum for user written on B6 card, containing simple expression. The details, if needed, are prepared separately. The development scope is decided by the team using this story card.
  • YAGNI (You Ain't Gonna Need It): XP: It is important to maintain simple design and simple architecture.

4. Scrumなどの用語集　:

  • Adaptive：適応的
  • Burn-down Chart：作業残務チャート
  • Daily Scrum：毎日のスクラム会議
  • Empirical：実証的
  • Agile development：アジャイル開発
  • Sprint Retrospective：スプリントの反省事項
  • Predictive：予測
  • Product Backlog：作業残務量
  • Product Owner：オーナー
  • Release Backlog：完成済量
  • Scrum Master: スクラム長
  • Scrum Team: スクラムグループ開発メンバー。但しグループ長は独断しない。
  • Sprint: 通常30日間のイテレーション期間
  • Sprint Backlog: SprintのTo-Doリスト。オーナーとのSprint初日に提示される。
  • Sprint Review: 各Sprint終了事の非公式会議(約４時間)で、このSprintの成果物を関係者に説明。
  • Timebox：時間ボックス。Sprintの考えはこの時間枠から来ている。なお期限の延長はなく、作業量の一部が削除される。

>Top 5. Preferable Contracts for NWF SW Development:

  • There are two types of contract; 1) lump sum contract, and 2) consignment contract:
  • <Lump sum contract - Fixed price and fixed scope>
    An user asks a certain vendor to complete some software (=deliverable) within a certain budget and period. The user is to pay the lump sum price for the deliverable.
Risk

User side
(contract order)

 Vendor side
(contract receiver)
unclear RFP - as the requirement of the project in uncertain, the project may not be finished within the contract price.
unclear deliverable - as the deliverable are not clearly defined, acceptability of it may be uncertain.
unclear quality of deliverable The project period may be elongated, and the completion be delayed. the contract period may be elongated endlessly, and cannot be completed within the budget.
unclear man-hour overestimate may cause excessive contract price. reasonable profit cannot be obtained due to underestimate of the project cost.
unclear cut over # members from the user side could not be decided due to unclear project period. cannot assign an appropriate # of engineers due to unclear project period
collaboration of user and vendor. demarcation point is unclear, and in case of trouble it is unclear who is responsible. demarcation point between user and vendor is unclear, so the risk arisen, it is unclear who is responsible
communication of user and vender instruction from user to the member from vender may be regarded as illegal. -
  • <Consignment contract - Time and materials>
    A user asks c certain vendor to consign to complete some software within a certain budge and period. The vender agrees to try to best efforts (due diligence) to make the software within the condition, but not necessarily commits to make it.
  • Other than the above contracts, the following clause can be contracted:
    • Sprint Contract: Basic contract plus additional contracts after the acceptance of each Sprint stage.
    • Time and Materials with fixed scope and cost ceiling contract:
      • fixed scope is not suitable for NWF development.
    • Time and Materials with variable scope and cost ceiling contract:
      • collaboration of U and V is important.
    • Phased development contract:
    • Bonus/Penalty clause:
      • scope is fixed.
    • Fixed profit (paid after the target delivery date)
    • Money for nothing, charge for free clause:
      • This is Time and Material with upper limit contract price.

5. NWF SW開発にとって適切な契約:

  • NWF SW開発契約：
  • 請負契約と準委託契約とがある
  • 請負契約の特徴：
    • 成果を頼めば請負。成果にミスがあれば瑕疵担保責任あり。請負が結果に対する責任
    • V側が成果物の完成を請負、U側は成果物に対する報酬を支払う契約
    • 注文者による解除は、V側が瑕疵または未完成の場合可能
    • 完成前でも契約解除可能。但し損害賠償は必要。
    • （比較的自由）
    • 請負人(V側）からの解除は原則できない。
    • 但し、Vが破産の場合は可能
    • その他、契約による約定加除権も特約できる。
    • 所有権の移転時期の明記は重要。検収後か報酬支払後か。
    • 知的財産権に場合、帰属がUか、Vは使用許諾なのかが重要。
    • 危険負担については、特定物の場合は、債権者主義でUのリスクとなるので、特約によって、危険負担についても納入時・検査完了時とすべき。
  • 準委託契約の特徴：
    • 行為そのものを頼めば委託。成果の完成責任はないが善管注意義務はある。委託は過程に対する責任
    • 準委託とは法律行為でない業務を委託すること。V側の責任は業務を実施することにあり、成果物の完成責任は負わない。
    • 派遣契約は、要員派遣を目的としたものであり、当該要員への指揮命令は (Uの企業内で作業しても)派遣先のVが持っている。
    • 委託契約は、いずれの側(U/V)もいつでも契約解除可能。但し、解除条件 (催促解除も含め)を契約で明示する意味はある。
  • 成果物の要件未定故、契約金額、工期が未確定
  • 見積の過大・過少リスク
  • 開発期間が未定故、開発メンバが決まらない
  • 発注側(U)と受注側(V)の責任分岐点 (Demarcationn point)が不明確
fixpricfixscope

<定額請負型>

  • 早期完工はV側に有利
  • 完工遅延はV側に赤字
  • U側にはリスクなし
  • Scopeが固定しまうのでNWFには適さない。
 timematerial

<実費精算=準委任>

  • V側は完工責任なし。生産性上げるIncentiveなし
  • Project riskは全てU側
  • Scope変更容易
  • 確実なProject管理が必要
timemateriacostceiling

<準委任・支払上限付>

  • V側が利益重視なら早期完工を目指す。但し完工期限過ぎると利益減少
  • 期限以降は請負型と同じ
  • U側に有利な契約形態
  • Scopeは固定的

<準委任・上限打切型>

  • V側は完工責任なし
  • U側は予算切れで完工できないリスクあり
  • Scopeは非固定的
bonuspenalty

<Bonus/Penalty方式>

  • Scopeの固定が前提でその変更=遅延となりVはいやがる
  • U側も早期完工でBonus払いたくない
  • V側は完工日以降Penaltyでやる気減退
 tmprofitceil

<固定利益型>

  • U側は早期完工でPay減らしたい。V側には早期完工で売上利益とも減少
  • 期限超過後はV側コストはカバーできる。売上重視ならだらだら開発もあり

<準委任・利益固定型型>

  • Scope変更は自由
  • U/V共に早期完工にメリットあり
  • 雑な完工にならないか？

<準委任・利益漸減型>

  • デンマークの事例
  • 早期完工は、U側はPayが少なく、V側は利益率大なので歓迎する
  • コスト計算が正確にできるかどうか
  • Profit線が水平ならは左図と同じ

>Top 6. Why Agile development is agile?:

  • Because is it iteration of small cycles method of the development?
    • Probably no. Because only iteration or division of parts is equal to the total. Loss may be caused by only split.
  • Because is it using efficient tool or language?
    • Probably no. Even using Ruby, the efficiency is not guaranteed.
  • Because is the development team compose of able and efficient engineers?
    • Partly yes. Efficiency varies very much among engineers, but it requires to keep good environment not to disturb such efficiency.
  • Because is it not intending to make all the scope from the beginning?
    • Affirmatively yes. Agile development starts from the important and urgent portion, then gradually expand to other scopes. If the total scope is diminished, it it natural that the completion become shorter or agile.
      Also, it is important to start without requiring strict completeness from the beginning. Relaxed and communicative environment also give positive impact for efficiency.
  • Because is it the small team and frequently check mutually, or is it not allowed to be lazy in the team?
    • Probably yes. But too much pressure each other may cause negative impact. The character and role of the team leader is also important.
  • Because is it refactoring process accepted in the development team?
    • Surprisingly yes. Refractoring is a process of improving or cleaning code without increasing visible function. Thus works will not be evaluated in WF development. This refactoring process is a kind of hidden investment of the future extension and maintenance of the system.

6. なぜアジャイル開発は迅速なのか？:

  • 開発が小サイクルのイテレーションからなっているためか？
    • おそらくNo。単に分割しただけでは短縮化は不能。む
  • 効果的なツールなどを使用するからか
    • おそらくNo.。ツールの使用と効率性は必ずしも一致しない
  • 少数精鋭のチームだからか
    • 一部はYes。但し、SWの効率性は人によって大きく異なる
  • 全体のスコープを作らないからか
    • Yes。まず需要度や緊急度の髙部分から作ることは効率上も重要。かつ作業量自体が減れば確実に早期に完工する。
  • 少数チームで頻繁に相互チェックするからか
    • 一部はYes。少人数ではさぼりにくい。但し、相互圧力のかけ過ぎもよくない。

>Top 7. Herrmann Model and NWF Development:

  • According to Herrmann model, our brain has following features:
    1. Thinking styles can be best described as a coalition of four different thinking selves (A/D are left/right neocortex, and B/C are left/right primitive limbic cortex)
    2. We are a product of both nature and nurture. It is the nurture aspect that predominates in who we are and who we can become.
    3. We have already done this with our right hand or left hand, and developed a lifetime of handedness preference and skill.
    4. We have developed our mental dominance into such strong preferences. We have developed language and math skills, or are exceedingly organized, or can accurately sense the feeling of others, or are always coming up with new ideas.
    5. Such competitive approaches can lead to better decisions and better solutions.
  • NWF SW development team requires more frequent collaboration and communication between User and Vendor, which means the sense of right limbic cortex is important.
  • Furthermore, the more use of right brain (both neocortex and limbic cortex) may cause creative works.

7. ハーマン・モデルとNWF開発:

  • 人の大脳には４つの得意分野がある
    • A: 左脳の新皮質　
      • 論理思考
      • 事実分析
      • 数値処理
    • B: 左脳の辺縁系
      • 計画立案
      • 組織力
      • 詳細レビュー
    • C: 右脳の辺縁系
      • 対人関係
      • 直感力
      • 表現力
    • D: 右脳の辺縁系
      • 創造力
      • 構想力
      • 概念化
  • NWF SW開発には、特に右脳辺縁系の得意分野であるチームの人間関係が重要となる
  • さらに右脳の活用は創造力を生む

>Top 8. IT Human resources:

  • Source: IPA SEC, report, 2011/3
  • IT Human resources belong to User company or Vendor company?
  US China India Japan Brazil Russia Korea Vietnam
User 2362300 554069 365416 254721 150000 124170 104732 49669
Vendor 941410 1452000 1446809 771426 450000 100000 128000 49024
Total 3303710 2006069 1812225 1026147 600000 224170 232732 98693
  • Where IT engineers are working? (%)
  US China India Japan Brazil Russia Korea Vietnam
User 72 28 20 25 25 55 45 50
Vendor 28 72 80 75 75 45 55 50
  • Scrum engineers (CSM=Certified Scrum Master), CSPO=Certified Scrum Product Owner, CSP (Certified Scrum Professional)
  US UK China Denmark Brazil Japan Total
CSM 67000 11800 3800 3700 4600 350 91250
CSPO 8000 1800 400 750 900 120 11970
CSP 1100 0 30 30 60 6 1226
Total 76100 13600 4230 4480 5560 476 104446

8. IT人材:

  • 日本は103万人、74%がベンダ
  • 米国は330万人、28%がベンダ
    • ベンダーへのIT人材の集中がアジャイル開発普及の障害になっていると思える。

  • Scrum資格者の数
    • 米国は日本の160倍
    • 中国も日本の9倍

>Top 9. IPA's recommendation for NWF development:

  1. Realtime communication within the development team
  2. Publish more case studies of NWF development
  3. Publish contract samples based on NWF development
  4. Promote in-house development without contract
  5. Enlighten that the value of SW is a key success factor.
  6. Adopt J/V formation with User company and Vendor.
  7. Public procurement should be NFW development.
  8. Establish HR curriculum of wide knowledge applying to various educational institutions
  9. Enhance practical education (PBL= Problem Based Learning)
  10. Promote education through Industry- Academia collaboration
  11. Enhance the status of IT engineers.
  12. Invite more foreign students
  13. Increase mobility of IT personnel
  14. Enlarge community
  15. Establish training center for NWF SW development
  16. Publish guidelines and/or Tips of NWF SW development
  17. Involve qualified engineers in a NWF development team

9. NWF開発のためのIPA提言

  1. リアルタイム・コミュニケーション
  2. ケーススタディの公表
  3. NWF型契約の事例公表
  4. ユーザ企業内開発 (契約不要)
  5. SWの価値湯煎がビジネスの成功要因であることの啓発
  6. J/V方式の採用
  7. 国や自治体のNWF型採用
  8. 幅広い知識をもった人材育成
  9. PBLなど実践的な教育コース
  10. 産学連携推進
  11. IT技術者の待遇改善
  12. 海外留学生受入拡大
  13. IT人材の流動性向上
  14. コミュニティの拡充
  15. NWF開発トレニングセンタ
  16. ガイドライン＆TIPS集作成
  17. NWF有資格者を含める

>Top 10. Why NWF SW Type couldn't proliferate in Japan?:

  • I think the major reason would be that both User and Vender put emphases on keeping stable relationship on long-term basis. Most of the Japanese have considered it is valuable that the business relation should be long-term and stable one. This sentiment encompass not only business sphere, but also private life including getting job, getting married, getting to be trained, getting to keep human relations, or even selecting banks and the political party or even religious appetite; all these should be stable, unchanged, and conservative relationships.
  • NWF contract aims to be most suitable in a changing environment; based on scope, delivery, human ability are changeable ones. Thus, the contract should be made on monthly iteration basis, evaluation the achievement. This may be felt by most of Japanese, a kind of dolphin show; giving bonus evaluating each time their achievement!
  • Though long-term reliance and relationship is important, its evaluation and payment is different. Bonus and penalty should be fair, accountable and changeable at any time. But this visual and direct idea probably could not be acceptable both of Japanese User and Vendor.
  • I'd say that both User and Vender look to be not confident, or even are afraid of having clear-cut relationship between job and payment: User could not show their clear business requirements, and Vender could not accomplish profession jobs with exact QCD. They want to be embraced each other, without asking what is your requirement and what is your professional jobs.

10. なぜNWFが日本で普及しないのか？

  • 日本の商習慣などは長期安定的な関係を重視
  • NWFは、短期の成果に基づく契約の繰り返しであり、成果と支払が明示的になることはU側もV側も好まないのではないか。
  • ビジネスの長期的な関係は大事だが、評価と支払は別物と思うが....
  • ともかく日本では、U側が自分の要求を明示できず、V側も契約内でQCDを示す自信がないので、双方がもたれ合っているのではと思われる。
Comment
  • Proliferation of NWF SW Development could be not only a revolutionary change in IT industry, but also revitalization of all Japanese industries.
  • NWF SW開発は、IT業界に革命的な変化をもたらすだけでなく、日本の産業の再活性化に通じる。

| Top | Home | Article | Bookshelf | Keyword | Author | Oxymoron |