「[[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] -積み上げには、結局、フレームワークが必要だと思います。 >フレームワークがユースケースを抽象化する理由は、~ ユースケースを何らかのドメインに特化しないと~ スタックを積めないため、フレームワークが重要になります。 -フレームワークには以下のものがある。~ ※ フレームワークという言葉、いろいろな解釈をされるので定義。 --規格的フレームワーク --ソフトウェア・フレームワーク -特にフレームワークなどの場合、クローズドなプロジェクトと比べると、~ オープンソースプロジェクトとした方が圧倒的にスタックし易いと思います。~ 企業として貢献した際の結果の評価方法が明確になっていくと良いかもしれません。 --Microsoftのエンジニアが語るOSSメンテナーの選び方 | Think IT(シンクイット)~ https://thinkit.co.jp/article/13618 ***脱、独自・オレオレ [#n551c5fb] -習得した人物にインセンティブを与えるスキームが必要。 --[[独自・オレオレ>https://techinfoofmicrosofttech.osscons.jp/index.php?開発支援ツール#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