価値の評価

[tomoyuki-nakabayashi]

3つの視点から、コンセプトの候補を3個程度見つける。

• 顧客の目
• 市場の目
• 商品の目

[tomoyuki-nakabayashi]

顧客の目

日頃、ソフトウェアエンジニアとして働いている上でのUDEを考えて、グルーピング。

[tomoyuki-nakabayashi]

人の持っているスキル、ツール・制度あたりが根が深そう、ということで、現状問題構造ツリーを整理した。

[tomoyuki-nakabayashi]

自分で勉強してスキルを上げる人と、そうでない人との、スキル格差が広がり、そのことが、さらにスキル共有を阻害し、スキル格差を広げる、という負のフィードバックループがあることに気づいた。

[tomoyuki-nakabayashi]

エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史 -

他者でエンジニアの技術力評価に力を入れているところ(市場の目)。 知っているところで言うと、VOYAGE GROUPでは、技術評価にかなりのコストを割いている。

これはテールと言えないだろうか？

[ghost]

そもそもなんですけど、これのテーマはなんですか？ ソフトウェアエンジニア向けサービスという最終アウトプットに対して、目的（ゴール）が何かわからないとUDEが妥当かわかりません。

1 にあるUDEを見る限り、「ソフトウェアエンジニアとして本業（開発業務）に注力したい」みたいなのがテーマかな思いました。スキル格差や割り込み雑務があるとか会議が長いとかが、要するに何を生み出していて、それを解消することによって得られる姿を一言にまとめたものがTOCでいうテーマになります。

今回の場合、最終テーマは一朝一夕では解決できないものだが、その一部でも解決するサービスを提供することがプロジェクトの目的と理解しました。ただ、UDEを見ていると「エンジニアとしてのあるべき論」になっているような気もします。気持ちはわかりますが。 お手数ですが、テーマの共有をお願いします。

[tomoyuki-nakabayashi]

とりあえず、目を通してくれてありがとう。

ソフトウェアエンジニアとして本業（開発業務）に注力したい」みたいなのがテーマかな思いました。

紆余曲折したんだけど、『新しいテクノロジーを使って、生産的にエンジニアリングしたい』かな。ちょっと他の人の意見も聞かないとだけど。

最終テーマは一朝一夕では解決できないものだが、その一部でも解決するサービスを提供することがプロジェクトの目的と理解しました。

yes.

「エンジニアとしてのあるべき論」になっているような気もします

そういう印象を受けた？当日はそういう話になっていなくて、負のループを断ち切るために、どうすれば勉強する人を増やせるだろうか？という議論が中心だった。

負のループを加速してる部分が、『技術が評価されていない（とエンジニアが感じている）』じゃね？となって、#2 に繋がっていった（実際は行き来してたけど）。

[ghost]

ちょっと他の人の意見も聞かないとだけど。

了解です。ここは認識合わせをしたほうが良いと思います。

勉強する人を増やせるだろうか？という議論が中心だった。

勉強をしないことがUDEなのか疑問に思いました。勉強をしないことによって引き起こされる事象がUDEになるような気がします。

[tomoyuki-nakabayashi]

勉強しないこと、はUDEとしては出てきてないのよ。まあしない人はしない人でしゃーないよね、くらいの扱いだった。あくまで、事象として出てきただけ。（TOC的に正しい書き方になってないから？混乱させているかもしれんが）

勉強する人、しない人に別れることで、技術格差が広がる、というのが問題のとっかかりだった。 勉強した人が、ツールを導入するコストが高くて（例. みんなが使えるようにドキュメント作れと言われたり）、かつ、その技術力が評価されないと、技術力高い人は技術導入が嫌になる。 結果、技術力高い人は会社を去るか、技術を隠すようになって、技術共有が進まないので無限ループしてね？って感じだった。

[ghost]

勉強しないこと、はUDEとしては出てきてないのよ

2 でクラウドとして出ていたので出ていたのかなと思ってました。

勉強する人、しない人に別れることで、技術格差が広がる、というのが問題のとっかかりだった。

これについては私の職場との違いかもしれないです…すみません。 互いの環境について前提条件を共有する必要がありますね。 ただ、TOCのツールを使うならば「技術格差が広がる」ことが悪いことなのかはっきりさせないといけないです。技術格差が広がることによって何に困っているのでしょうか？ 例えば、「ベテランの残業時間が長い」とか「レビュで不具合が漏れている」とか。 TOCではツールを使うステージ毎の情報のみで図を作らないといけないので、ネガティブループありきでアイディアを出そうとするには向かないツールです。（じゃないと根本原因の特定が難しくなり、多くの場合が金と時間で解決すればいいじゃんになってしまうので）

[tomoyuki-nakabayashi]

体調が回復しない…

なるほど。例えば、次のように直すとどう？ちょっと事実じゃなくて、想定が入ってるけど（まあ肌感覚的には間違ってないと思ってるが）。

『古いツールや技術を使い続ける人が多数派で職制も高位なことが多い』、かつ、『そのような人たちは新しいツールや技術の導入に懐疑的であったり、過剰にドキュメントを求めたりする』であれば、『新しいツールや技術を勉強した人がそのツールや技術を導入しようとすると、労力がかかる』

↑、かつ、『技術格差が大きければ大きいほど、技術導入にかかる労力が大きくなる』であれば、『先進的な技術を知っている人ほど、その技術導入に多大な労力がかかるようになる』

結果、面倒くなって会社を辞めるか、頑張って技術導入し続ける気がなくなる。

[tomoyuki-nakabayashi]

『技術格差が大きければ大きいほど、技術導入にかかる労力が大きくなる』

↑はgit知らない人にGitHub持っていこうとすると、まず、gitから説明しないと…的な。 そもそも言葉が通じないから、そっから苦労するとかね。

[tomoyuki-nakabayashi]

あぁ、ダメだな。きれいに自動生成されない…。別の方法を考えよう。

とりあえず、一旦ツリーを整理したけどイマイチ感なんだよなぁ。もう1回練らないとダメ感。