Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

AS-ISTO-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」などの実装をしているが、
独自フレームワーク実装と、ソフトウェア開発の難易度はそう変わらない。
(英語の仕様を読んでいるか?いないか?程度の違いぐらいしか無い)
(仕様の検討や検証をする分、独自仕様を実装する方が難易度が高い)

  • なので、何が究極的に低レベルか?と言えば、言われた業務仕様を実装できるように、
    言語やフレームワークの仕様を学んでる(と言うか都度ググってる)ヤツなんじゃないか?と。
    最新の言語やフレームワークを学んでいるからレベルが高いとか言われたら、それは違うよ。と。
  • スタートラインは、
    • 自社事業に必要なプロダクトを開発する。
    • そして、それをペイラインに乗せ、ライフサイクルを保つ。

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

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

参考

OSSコンソーシアム

近年のソフトウェア開発の傾向

その他の外部サイト

ZDNet Japan

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

  • ソフトウェアの信頼性が向上している一方で、
    生産性は低下傾向にあることがデータから判明した。
  • データの裏付けがない過度に高い生産性目標は、
    リスク増大や品質低下を招きかねない。
  • 開発側と発注側の双方がデータに裏付けられた共通認識をもとに、
    ソフトウェア開発プロジェクトを検討・計画すべきだ。

日経 xTECH(クロステック)

その他

  • 「独自路線」や「車輪の再発明」はただのクソ
    でしかなく、世界にとって無価値な存在である。
  • マウンティングドリブン開発。衒学趣味。
    • 「登壇します」「登壇しました」とTwitterやブログで言いたいだけである。
    • コードやサービスではなく、専門性の高い発言や振る舞いによってマウンティングをしてくる。
  • 発表やブログ記事の多くが
    • 「公式Docsを和訳してみました」「Get Startedを試してみました」レベル
    • 「勉強になった」「知見が得られた」「あとで読む」などと
      コメントがつき、承認欲求が満たされてまた次のクソ記事を産み出す。

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-08-02 (金) 12:18:48 (79d)