「[[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の「企業知識ベース」でしょうか。~ ソフトウェア開発の範囲で言うなら「開発基盤」というのもイイ気がします。 -特に「ソフトウェア・フレームワーク」などの場合、クローズドなプロジェクトと比べると、~ オープンソース・プロジェクトとした方が圧倒的にスタックし易いと思います。~ -「企業知識ベース」に対して貢献に等しいのだから、~ オープンソース・プロジェクトに企業として貢献した際の~ 結果の評価方法が明確になっていくと良いかもしれません。 --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