「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>開発基盤の選定ガイドライン]]

*目次 [#xdcd2c07]
#contents

*概要 [#g1df2d52]
[[AS-IS>#i73e4970]]と[[TO-BE>#g2240370]]から傾向を分析してみる。

*AS-IS [#i73e4970]
現状は、こんな状態。

**分析 [#aff6c2c2]
感覚的に、

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

ように思います。

***受託案件 [#b1477290]
一方で、

>「日式の SI / Web ドメインのスタックは依然として、~
積み上げが薄くて人月工数の追加で対応している。」

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

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

***PoC案件 [#t952227a]
しかし、最近はPoC案件も増えてきており、

-実際に高度な技術を実務に応用する姿勢が見える。
-失敗も多いのかもしれないが、生産性向上の観点から、侮れない。

**生産性の定義の変遷 [#h3b181b8]

***生産性指標の問題 [#fe696ca7]
ステップ生産性という指標は時代に適合しなくなった。

※ 簡単に言うと、成果物の量 ≒ 価値と言う時代ではなくなったと言う事。

しかし、FPも同じで、これがいくら高くなっても、収益自体は高まらない。

>「ステップ生産性 → FP生産性 → 粗利生産性で言った場合、~
少ないステップ数で、多くのFPのアプリケーションを開発できるようになった。~
故に、ステップ生産性は減った、FP生産性は増えた、しかし、粗利生産性は変わらず。」

※ 可能であれば、新旧のFP生産性と事業の収益性を分析してみるのが近道。

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

...となると、当然、「新技術によるレギュレーション変更」では収益性を改善できない。

***近年のステップ生産性 [#d6274d55]
-ソフトウェアの信頼性が向上し、生産性は低下傾向にある。
-しかしながら、コスト削減や単価の低減が要求されている。

*TO-BE [#g2240370]
将来は理想と言うより、

>時代に求められる姿に変わらざるを得ない。~
（変われない企業は淘汰されていく）

と言う事かも知れない。

**分析 [#d3f68a4d]
-成果物の量 ≒ 価値と言う時代では無い。

-人手不足と言うが、単純作業員が求められているわけではない。

-社会インフラの維持ができなくなっているといわれているが、~
単純作業員ではなく、ある程度の技術力のある人材の労働力が足りず、~
また、機械化が必要になっている（[[前述のPoC>#t952227a]]などが該当する）。

-単純作業員は余剰な状態であるが、賃金が安いから人が集まらないため、~
外国人の「単純労働者」を受け入れを受け入れている。~
（ICTでは、別の方法で解決想定のため、求められていない。）

***脱、従来型IT人材、従来型SE [#z2b7f00d]
単純作業員ではなく、高度な技術力が求められている。

***脱、人月商売 [#v5dfbf26]
-働き方改革で、労働集約型の事業が難しくなってきている。
-高度専門職を増やして、人月商売から脱却したい。

**スタック（積み上げ）の対象 [#r7ca56bb]
-実際に自分の事業ドメイン上のスタック（積み上げ）をどのようにやるか？
-スタック（積み上げ）ができない企業が淘汰されていくと思います。

***フレームワーク → 企業知識ベース [#c93e6e8d]
-フレームワークには以下のものがある。~
※ フレームワークという言葉、いろいろな解釈をされるので定義。
--ビジネス・フレームワーク
--ソフトウェア・フレームワーク

-スタック（積み上げ）には、結局、フレームワークが必要だと思います。
--フレームワークは、特定のユースケースを抽象化します。
--この抽象化によって、スタック（積み上げ）が可能になる。~
※ 抽象化 = 「簡単に説明する。」・「ブラックボックス化する。」など。

-フレームワークを別の言い方で表現すると、PMBOKの「企業知識ベース」でしょうか。~
ソフトウェア開発の範囲で言うなら「開発基盤」というのもイイ気がします。

-特に「ソフトウェア・フレームワーク」などの場合、クローズドなプロジェクトと比べると、~
オープンソース・プロジェクトとした方が圧倒的にスタック（積み上げ）し易いと思います。~

-「企業知識ベース」に対して貢献に等しいのだから、~
オープンソース・プロジェクトに企業として貢献した際の~
結果の評価方法が明確になっていくと良いかもしれません。
--Microsoftのエンジニアが語るOSSメンテナーの選び方 | Think IT（シンクイット）~
https://thinkit.co.jp/article/13618

 　　　　　　　　　 ┌ ビジネス企画 > BABOK関連の企業知識ベース
 「企業知識ベース」 ┼ プロジェクト管理 > PMBOK関連の企業知識ベース
 　　　　　　　　　 └ プロダクト開発 > 開発基盤 > Software Framework

***脱、独自・オレオレ [#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]]の定義は曖昧

-何か、脱、独自・オレオレを評価する~
明確な指標などがあるとイイ気がします。
--[[開発基盤のKPIとKGI]]
---標準技術との対応の度合い。
---サポートするアーキテクチャ

-最終的には、第三者からの評価が必要。
--習得した人物にインセンティブを与えるスキームが必要。
--...

...最近は、「[[OAuth2 / OIDC / SAML2 / FAPI>汎用認証サイト（Multi-purpose Authentication Site）]]」などの実装をしているが、~
独自フレームワーク実装と、ソフトウェア開発の難易度はそう変わらない。~
（英語の仕様を読んでいるか？いないか？程度の違いぐらいしか無い）~
（仕様の検討や検証をする分、独自仕様を実装する方が難易度が高い）

-なので、何が究極的に低レベルか？と言えば、言われた業務仕様を実装できるように、~
言語やフレームワークの仕様を学んでる（と言うか都度ググってる）ヤツなんじゃないか？と。~
最新の言語やフレームワークを学んでいるからレベルが高いとか言われたら、それは違うよ。と。

-スタートラインは、
--自社事業に必要なプロダクトを開発する。
--そして、それをペイラインに乗せ、ライフサイクルを保つ。

>と言ったトコロだと思います。

可能であれば、さらにその上を目指してもイイでしょう。

*参考 [#ec3cacbb]
-builder by ZDNet Japan~

**[[OSSC > 開発基盤部会 Blog>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9APDU%20-%20%E3%82%B3%E3%83%B3%E3%83%94%E3%83%86%E3%83%B3%E3%82%B7%E3%83%BC#r3f3004c]] [#t9ef43f7]

**その他の外部サイト [#ye349d78]

***ZDNet Japan [#e5603c86]
生産性向上を前提にしたソフトウェア開発に警鐘--IPA~
https://builder.japan.zdnet.com/off-topic/35115706/

--ソフトウェアの信頼性が向上している一方で、~
-ソフトウェアの信頼性が向上している一方で、~
生産性は低下傾向にあることがデータから判明した。

--データの裏付けがない過度に高い生産性目標は、~
-データの裏付けがない過度に高い生産性目標は、~
リスク増大や品質低下を招きかねない。

--開発側と発注側の双方がデータに裏付けられた共通認識をもとに、~
-開発側と発注側の双方がデータに裏付けられた共通認識をもとに、~
ソフトウェア開発プロジェクトを検討・計画すべきだ。

-日経 xTECH（クロステック）
--技術者不足の衝撃実態、従来型IT人材は2030年に10万人余る~
***日経 xTECH（クロステック） [#y99885aa]
-技術者不足の衝撃実態、従来型IT人材は2030年に10万人余る~
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00166/050700030/
--「従来型SE」不要論が席巻　業務知識を生かす道を探れ~
-「従来型SE」不要論が席巻　業務知識を生かす道を探れ~
https://tech.nikkeibp.co.jp/atcl/nxt/mag/sys/18/060700075/061000001/

***その他 [#o62dc37c]
-ここがクソだよ日本人エンジニア~
https://anond.hatelabo.jp/20170728223725

--「独自路線」や「車輪の再発明」はただのクソ~
でしかなく、世界にとって無価値な存在である。

--マウンティングドリブン開発。衒学趣味。
---「登壇します」「登壇しました」とTwitterやブログで言いたいだけである。
---コードやサービスではなく、専門性の高い発言や振る舞いによってマウンティングをしてくる。

--発表やブログ記事の多くが
---「公式Docsを和訳してみました」「Get Startedを試してみました」レベル
---「勉強になった」「知見が得られた」「あとで読む」などと~
コメントがつき、承認欲求が満たされてまた次のクソ記事を産み出す。

-Microsoftのエンジニアが語るOSSメンテナーの選び方 | Think IT（シンクイット）~
https://thinkit.co.jp/article/13618
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS