Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

以下に面白い情報がありました。

  • データの裏付けがない過度に高い生産性目標は、リスク増大や品質低下を招きかねない。
  • 開発側と発注側の双方がデータに裏付けられた共通認識をもとに、
    ソフトウェア開発プロジェクトを検討・計画すべきだ。

ソフトウェアというより業務システム開発の話なんじゃないか?という気もしますが。

AS-IS

現状は、こんな状況でしょうか?

分析

感覚的に、

「世界的にICTのスタックは、クラウド & モバイルと、プラットフォームが厚くなるだけでなく、
IoT & AIと応用の幅についても広がりも見せており、これに合わせて、要求レベルも上がり続けている。」

ように思います。

PoC案件

色々と任せてもらえるため生産性向上施策も打ちやすい。

受託案件

「日式の SI / Web ドメインのスタックは dry なのかどうか解りませんが、
依然として、積み上げが薄くて人月工数の追加で対応している。」

という慣例が続いているように思います。

  • スタックするより上手くポジショニングした方が効率がイイ。
  • 結果、スタックできない企業群がサプライチェーンを成す。

生産性の変遷

上記の記事のLOC(lines of code)と言うトコロに突っ込んでいた方がいらっしゃいましたが、
その場合、アウトプットを測る指標として、FPや価値自体を考えてみたらイイと思います。
時代の変遷で、環境が変われば、FPの指標がいくら高くなっても、価値自体は高まらない訳です。

「ステップ生産性 → FP生産性 → 粗利生産性で言った場合、
ステップ生産性は減った、FP生産性は増えた、粗利生産性は変わらず。」

※ SI / Web 事業の収益性を分析してみるのが近道です。

ということで、デファクト・スタンダードな新技術を覚えてステップ生産性 → FP生産性を上げる行為は、
F1のレギュレーションのようなもので、参加者全てに適用され競争力や差別化に結び付きません。

TO-BE

こんな風になっていったら良いなぁなどと思っています。

分析

人月商売脱却は、「積み上げ」だと思います。
積み上げができない企業が淘汰されていくと思います。

これについては、

「人月商売」、「衒学趣味のマウンティングドリブン開発」を止めて、
コードやサービスをしっかりアウトプットしたらイイと思います。

ただし、個人的に、上記の「情報格差」はあまり気にしおらず、

「実際に自分の事業ドメイン上の積み上げをどのようにやるか?」

と言うところにフォーカスしたいと考えています。

積み上げの対象

フレームワーク

  • フレームワークには以下のものがある。
    ※ フレームワークという言葉、いろいろな解釈をされるので定義。
    • ビジネス・フレームワーク
    • ソフトウェア・フレームワーク
  • 積み上げには、結局、フレームワークが必要だと思います。
    フレームワークは、特定のユースケースを抽象化します。
    この抽象化によって、スタック(積み上げ)が可能になる。
    ※ 抽象化 = 「簡単に説明する。」・「ブラックボックス化する。」など。
  • フレームワークを別の言い方で表現すると、
    PMBOKの「企業知識ベース」でしょうか。
    ソフトウェア開発の範囲で言うなら「開発基盤」というのもイイ気がします。
  • 特に「ソフトウェア・フレームワーク」などの場合、クローズドなプロジェクトと比べると、
    オープンソース・プロジェクトとした方が圧倒的にスタックし易いと思います。
  • 「企業知識ベース」に対して貢献に等しいのだから、
    オープンソース・プロジェクトに企業として貢献した際の
    結果の評価方法が明確になっていくと良いかもしれません。
          ┌ ビジネス企画 > BABOK関連の企業知識ベース
「企業知識ベース」 ┼ プロジェクト管理 > PMBOK関連の企業知識ベース
          └ プロダクト開発 > 開発基盤 > Software Framework

脱、独自・オレオレ

  • と言う事を考えると、何か、明確な指標などがあるとイイ気がします。

参考


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-06-21 (木) 15:45:18 (3d)