「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
AS-ISとTO-BEから傾向を分析してみる。
AS-IS †
現状は、こんな状態。
分析 †
感覚的に、
「世界的にICTのスタック（積み上げ）は、
クラウド & モバイルと、プラットフォームが厚くなるだけでなく、
IoT / ビッグデータ / AIと応用の幅についても広がりも見せており、
これに合わせて、要求レベルも上がり続けている。」
ように思います。
受託案件 †
一方で、
「日式の SI / Web ドメインのスタックは依然として、
積み上げが薄くて人月工数の追加で対応している。」
という慣例が続いているように思います。
- スタック（積み上げ）するより上手くポジショニングした方が効率がイイ。
- 結果、スタック（積み上げ）できない企業群がサプライチェーンを成す。
PoC案件 †
しかし、最近はPoC案件も増えてきており、
- 実際に高度な技術を実務に応用する姿勢が見える。
- 失敗も多いのかもしれないが、生産性向上の観点から、侮れない。
生産性の定義の変遷 †
生産性指標の問題 †
ステップ生産性という指標は時代に適合しなくなった。
※ 簡単に言うと、成果物の量 ≒ 価値と言う時代ではなくなったと言う事。
しかし、FPも同じで、これがいくら高くなっても、収益自体は高まらない。
「ステップ生産性 → FP生産性 → 粗利生産性で言った場合、
少ないステップ数で、多くのFPのアプリケーションを開発できるようになった。
故に、ステップ生産性は減った、FP生産性は増えた、しかし、粗利生産性は変わらず。」
※ 可能であれば、新旧のFP生産性と事業の収益性を分析してみるのが近道。
レギュレーション変更 †
デファクト・スタンダードな新技術を覚えてステップ生産性 → FP生産性を上げる行為は、
F1のレギュレーションのようなもので、参加者全てに適用され競争力や差別化に結び付かない。
...となると、当然、「新技術によるレギュレーション変更」では収益性を改善できない。
近年のステップ生産性 †
- ソフトウェアの信頼性が向上し、生産性は低下傾向にある。
- しかしながら、コスト削減や単価の低減が要求されている。
TO-BE †
将来は理想と言うより、
時代に求められる姿に変わらざるを得ない。
（変われない企業は淘汰されていく）
と言う事かも知れない。
分析 †
- 人手不足と言うが、単純作業員が求められているわけではない。
- 社会インフラの維持ができなくなっているといわれているが、
単純作業員ではなく、ある程度の技術力のある人材の労働力が足りず、
また、機械化が必要になっている（前述のPoCなどが該当する）。
- 単純作業員は余剰な状態であるが、賃金が安いから人が集まらないため、
外国人の「単純労働者」を受け入れを受け入れている。
（ICTでは、別の方法で解決想定のため、求められていない。）
脱、従来型IT人材、従来型SE †
単純作業員ではなく、高度な技術力が求められている。
脱、人月商売 †
- 働き方改革で、労働集約型の事業が難しくなってきている。
- 高度専門職を増やして、人月商売から脱却したい。
スタック（積み上げ）の対象 †
- 実際に自分の事業ドメイン上のスタック（積み上げ）をどのようにやるか？
- スタック（積み上げ）ができない企業が淘汰されていくと思います。
フレームワーク → 企業知識ベース †
- フレームワークには以下のものがある。
※ フレームワークという言葉、いろいろな解釈をされるので定義。
- ビジネス・フレームワーク
- ソフトウェア・フレームワーク
- スタック（積み上げ）には、結局、フレームワークが必要だと思います。
- フレームワークは、特定のユースケースを抽象化します。
- この抽象化によって、スタック（積み上げ）が可能になる。
※ 抽象化 = 「簡単に説明する。」・「ブラックボックス化する。」など。
- フレームワークを別の言い方で表現すると、PMBOKの「企業知識ベース」でしょうか。
ソフトウェア開発の範囲で言うなら「開発基盤」というのもイイ気がします。
- 特に「ソフトウェア・フレームワーク」などの場合、クローズドなプロジェクトと比べると、
オープンソース・プロジェクトとした方が圧倒的にスタック（積み上げ）し易いと思います。
- 「企業知識ベース」に対して貢献に等しいのだから、
オープンソース・プロジェクトに企業として貢献した際の
結果の評価方法が明確になっていくと良いかもしれません。
┌ ビジネス企画 > BABOK関連の企業知識ベース
「企業知識ベース」 ┼ プロジェクト管理 > PMBOK関連の企業知識ベース
└ プロダクト開発 > 開発基盤 > Software Framework
脱、独自・オレオレ †
...と言いつつ、
重要なのは、「独自性の有るコンテンツ力」であることはコチラで既に述べたとおり。
と言う事で、「独自性のある状態でレベルの低く見えてしまうオレオレ臭」を消す必要がある。
- 何か、脱、独自・オレオレを評価する
明確な指標などがあるとイイ気がします。
- 最終的には、第三者からの評価が必要。
- 習得した人物にインセンティブを与えるスキームが必要。
- ...
...最近は、「OAuth2 / OIDC / SAML2 / FAPI」などの実装をしているが、
独自フレームワーク実装と、ソフトウェア開発の難易度はそう変わらない。
（英語の仕様を読んでいるか？いないか？程度の違いぐらいしか無い）
（仕様の検討や検証をする分、独自仕様を実装する方が難易度が高い）
- なので、何が究極的に低レベルか？と言えば、言われた業務仕様を実装できるように、
言語やフレームワークの仕様を学んでる（と言うか都度ググってる）ヤツなんじゃないか？と。
最新の言語やフレームワークを学んでいるからレベルが高いとか言われたら、それは違うよ。と。
- スタートラインは、
- 自社事業に必要なプロダクトを開発する。
- そして、それをペイラインに乗せ、ライフサイクルを保つ。
と言ったトコロだと思います。
可能であれば、さらにその上を目指してもイイでしょう。
参考 †
- ソフトウェアの信頼性が向上している一方で、
生産性は低下傾向にあることがデータから判明した。
- データの裏付けがない過度に高い生産性目標は、
リスク増大や品質低下を招きかねない。
- 開発側と発注側の双方がデータに裏付けられた共通認識をもとに、
ソフトウェア開発プロジェクトを検討・計画すべきだ。
- 「独自路線」や「車輪の再発明」はただのクソ
でしかなく、世界にとって無価値な存在である。
- マウンティングドリブン開発。衒学趣味。
- 「登壇します」「登壇しました」とTwitterやブログで言いたいだけである。
- コードやサービスではなく、専門性の高い発言や振る舞いによってマウンティングをしてくる。
- 発表やブログ記事の多くが
- 「公式Docsを和訳してみました」「Get Startedを試してみました」レベル
- 「勉強になった」「知見が得られた」「あとで読む」などと
コメントがつき、承認欲求が満たされてまた次のクソ記事を産み出す。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
