- 追加された行はこの色です。
- 削除された行はこの色です。
「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>開発基盤の選定ガイドライン]]
*目次 [#xdcd2c07]
#contents
*概要 [#g1df2d52]
以下に面白い情報がありました。
-builder by ZDNet Japan~
生産性向上を前提にしたソフトウェア開発に警鐘--IPA~
https://builder.japan.zdnet.com/off-topic/35115706/
--データの裏付けがない過度に高い生産性目標は、リスク増大や品質低下を招きかねない。
--開発側と発注側の双方がデータに裏付けられた共通認識をもとに、~
ソフトウェア開発プロジェクトを検討・計画すべきだ。
ソフトウェアというより業務システム開発の話なんじゃないか?という気もしますが。
*AS-IS [#i73e4970]
現状は、こんな状況でしょうか?
**分析 [#aff6c2c2]
感覚的に、
>「世界的にICTのスタックは、クラウド & モバイルと、プラットフォームが厚くなるだけでなく、~
IoT & AIと応用の幅についても広がりも見せており、これに合わせて、要求レベルも上がり続けている。」
ように思います。
***PoC案件 [#t952227a]
色々と任せてもらえるため生産性向上施策も打ちやすい。
***受託案件 [#b1477290]
「日式の SI / Web ドメインのスタックは dry なのかどうか解りませんが、~
依然として、積み上げが薄くて人月工数の追加で対応している。」
という慣例が続いているように思います。
-スタックするより上手くポジショニングした方が効率がイイ。
-結果、スタックできない企業群がサプライチェーンを成す。
**生産性の変遷 [#h3b181b8]
上記の記事のLOC(lines of code)と言うトコロに突っ込んでいた方がいらっしゃいましたが、~
その場合、アウトプットを測る指標として、FPや価値自体を考えてみたらイイと思います。~
時代の変遷で、環境が変われば、FPの指標がいくら高くなっても、価値自体は高まらない訳です。
>「ステップ生産性 → FP生産性 → 粗利生産性で言った場合、~
ステップ生産性は減った、FP生産性は増えた、粗利生産性は変わらず。」
※ SI / Web 事業の収益性を分析してみるのが近道です。
ということで、デファクト・スタンダードな新技術を覚えてステップ生産性 → FP生産性を上げる行為は、~
F1のレギュレーションのようなもので、参加者全てに適用され競争力や差別化に結び付きません。
*TO-BE [#g2240370]
こんな風になっていったら良いなぁなどと思っています。
**分析 [#d3f68a4d]
人月商売脱却は、「積み上げ」だと思います。~
積み上げができない企業が淘汰されていくと思います。
これについては、
-ここがクソだよ日本人エンジニア~
https://anond.hatelabo.jp/20170728223725
「人月商売」、「衒学趣味のマウンティングドリブン開発」を止めて、~
コードやサービスをしっかりアウトプットしたらイイと思います。
ただし、個人的に、上記の「情報格差」はあまり気にしおらず、
>「実際に自分の事業ドメイン上の積み上げをどのようにやるか?」
と言うところにフォーカスしたいと考えています。
**積み上げの対象 [#r7ca56bb]
***フレームワーク [#c93e6e8d]
-フレームワークには以下のものがある。~
※ フレームワークという言葉、いろいろな解釈をされるので定義。
--ビジネス・フレームワーク
--ソフトウェア・フレームワーク
-積み上げには、結局、フレームワークが必要だと思います。~
フレームワークは、特定のユースケースを抽象化します。~
この抽象化によって、スタック(積み上げ)が可能になる。~
※ 抽象化 = 「簡単に説明する。」・「ブラックボックス化する。」など。
-フレームワークを別の言い方で表現すると、~
PMBOKの「組織のプロセス資産」でしょうか。~
PMBOKの「企業知識ベース」でしょうか。~
ソフトウェア開発の範囲で言うなら「開発基盤」というのもイイ気がします。
-特に「ソフトウェア・フレームワーク」などの場合、クローズドなプロジェクトと比べると、~
オープンソース・プロジェクトとした方が圧倒的にスタックし易いと思います。~
-組織のプロセス資産に対して貢献に等しいのだから、~
-「企業知識ベース」に対して貢献に等しいのだから、~
オープンソース・プロジェクトに企業として貢献した際の~
結果の評価方法が明確になっていくと良いかもしれません。
--Microsoftのエンジニアが語るOSSメンテナーの選び方 | Think IT(シンクイット)~
https://thinkit.co.jp/article/13618
┌ ビジネス企画 - < BABOK
組織のプロセス資産 ┼ プロダクト開発 - < 開発基盤 < ソフトウェアフレームワーク
「企業知識ベース」 ┼ プロダクト開発 - < 開発基盤 < ソフトウェアフレームワーク
└ プロジェクト管理 - < PMBOK
***脱、独自・オレオレ [#n551c5fb]
-習得した人物にインセンティブを与えるスキームが必要。
--[[独自・オレオレ>https://techinfoofmicrosofttech.osscons.jp/index.php?%E9%96%8B%E7%99%BA%E6%94%AF%E6%8F%B4%E3%83%84%E3%83%BC%E3%83%AB#v8ef209c]]の定義は曖昧
--とは言え、[[前述のレギュレーション変更に合わせる>#h3b181b8]]程度ではダメ
-と言う事を考えると、何か、明確な指標などがあるとイイ気がします。
--[[開発基盤のKPIとKGI]]
---標準技術との対応の度合い。
---サポートするアーキテクチャ
*参考 [#ec3cacbb]
-生産性向上を前提にしたソフトウェア開発に警鐘--IPA - builder by ZDNet Japan~
https://builder.japan.zdnet.com/off-topic/35115706/
-ここがクソだよ日本人エンジニア~
https://anond.hatelabo.jp/20170728223725
-Microsoftのエンジニアが語るOSSメンテナーの選び方 | Think IT(シンクイット)~
https://thinkit.co.jp/article/13618