スタートアップ企業に共通する、給与、人事、評価に関する9つの考え方

良いか悪いかは別。
でも、経験上、たしかにそうだね・・と言える

スタートアップ企業に共通する、給与、人事、評価に関する9つの考え方
http://blog.tinect.jp/?p=17660

９つは以下のとおり（以下太字は上記サイトより引用）

1.定期昇給しない。
2.給与を高めにして、人を集める。
3.差が大きくつくことを前提とした給与制度である。
4.副業歓迎
5.能力、スキルは評価の対象とならない。
6.同質性が低ければ低いほどよい、と思っている。
7.管理しない。フィードバックする。
8.成果を出すことと、きっちり失敗することは等価である
9.出戻り歓迎


とくに

　「5.能力、スキルは評価の対象とならない。」と
　「6.同質性が低ければ低いほどよい、と思っている。」と
　「8.成果を出すことと、きっちり失敗することは等価である」が

当たり前に感じない人は、ベンチャーに向かないと思う。
（ベンチャーに数社勤めた経験から言うと）

請負契約・準委任契約・派遣の契約の違いまとめ

ちょっといろいろと説明しなきゃいけないことがあるので、まとめておく。

＜＜契約の違い＞＞

請負契約：仕事の完成に対して対価を支払う契約（民法６３２条）
準委任契約：法律行為でない行為をすることを相手に委託する契約（民法６５６条）
→委任契約：法律行為をすることを相手に委託する契約（民法643条）
【参考文献　ここ】

派遣契約：派遣労働者が派遣元事業主に雇用されながら、
　　　　　派遣先から指揮命令を受けて労働に従事する
【参考文献　ここ


＜＜具体的に＞＞
A社がB社に以下の契約をして、B社の社員の管理者X,デジタル土方YがA社にいって働く場合

請負契約：
　　B社は、何時間働いても、成果物を出して、検収を受けないとお金がもらえない（建前上）
　　A社はB社のX氏に依頼すべきで、直接A社の担当者がYを使うことはできない（建前上）
　　　→Yを直接指示すると偽装請負（偽装派遣）となるここ参照
　　法律上、直接使ってはいけないのだから、A社担当者がY氏を残業させて、うつ病になっても
　　　「A社の責任は」法律上曖昧である（建前上？実務でもそう？）→B社はもちろん責任ある。
　　瑕疵担保責任があるので、B社の責めによるバグがあったら、
　　　B社の誰かは、ただで直さないといけない（建前上）

準委任契約：
　　B社のX,Y氏は、働いた時間分、お金をもらえる（原則、建前上）
B社のX,Y氏の責めによる重過失でないバグがあっても、バグ修正のお金はもらえる（原則、建前上）
　　前述の偽装請負の例の場合、ここでは、請負でも委任でも、偽装請負は成り立つように読める。

派遣：
　　B社のX,Y氏は、働いた時間分、お金をもらえる（実務上も）
　　B社のX,Y氏の責めによるバグがあってもバグ修正のお金はもらえる（実務上も？）
　　A社の担当者は、X,Yそれぞれに指示を出すのが前提になっている

＜＜何が問題になるのか？＞＞
・請負契約でシステムが出来なかったとき
　請負契約の場合、「支払わない」「検収が挙がるまでお金は払えない」といわれても、
　反論できない。

・偽装派遣で、A社が労働基準法を守らず、人とは思えない残業や精神的苦痛を与えて、つぶれたとき
　A社を訴えることが出来るか、損害賠償とれるかどうか微妙。
　→たぶん、B社を訴えても、B社はつぶれて損害賠償は払えない
　→派遣の場合、A社は「時間外労働については」、法律は守らないとまずい。
　（人として扱わず、寝かせないで、脅迫、威嚇して拷問のように仕事をさせるとまずい）
　　→全ての法律が当然適用されるのでなく、派遣元に適用されるもの、グレーなものがある。


＜＜ちなみに＞＞
・SES契約は、本来は準委任契約。
・特定派遣と一般派遣の違い（上記例の場合B社とX,Yとの関係）
　一般派遣：（いわゆる登録型派遣）派遣期間だけ契約する（A社で解雇されたら、お仕事なくなる）
　特定派遣：（いわゆる常用型派遣）派遣元と常用契約（A社で解雇されたらB社に戻って仕事する）
　→派遣元（例の場合B社）が満たすべき要件は違う（そもそも特定は届出、一般は許可）
　くわしくは、ここに表がある。
　 資産－負債＞2,000万円、現預金の額＞1,500万円の条件から、中小ソフトハウスでは
　一般は厳しいが、移行期間は３年（の猶予）があるものの、特定労働者派遣は
　改正派遣法で廃止されたので、今後は一般にするしかなくなってくる。

デジタル土方さんは根絶へ向けての「要件の自動抽出技術」の今ここ

前に書いたＫＢＳＥの話は、実は、「要求の自動抽出がどれだけ現実化しているか」を語っているのだが、それ、わかりにくいので、コメントしておく。

---

■システム開発は、３つの自動抽出ができると、ほぼ完成する

その前に、「要件の自動抽出技術」が完成すると、どういうことが起こるのかについてすこし。

システム開発は、以下の３つの自動抽出ができると、ほぼ完成する

　　・（要求～設計）「要件の自動抽出」により、
　　　　　顧客から対話型ないしは自然文で要求っぽいことを入力してもらうと、
　　　　　要求から機能要件、非機能要件を抽出し、
　　　　　あらかじめ登録してあるサービスを検索し、利用すべきサービスと手順を設計書として出力し
　　　　　結合テスト、総合テストを自動生成する

　　・（設計～実装）「設計書からプログラムを自動生成」
　　　　　上述の設計書をもとに、プログラムとドキュメント、単体テストを自動生成する

　　・（テスト）「テスト自動実行」
　　　　　上述の単体テスト、結合テスト、総合テストを自動実行する。

この３つの自動抽出が完成すると、デジタル土方さんは必要なくなる。
偽装請負の問題や、ブラック企業の問題、メンタルの問題は一切なくなる。
なんたって、その対象である、デジタル土方さんがいなくなるのだから・・・

そして、「テスト自動実行」は、なんとかＵＮＩＴとか、いろんなテスト自動実行ツールで
実用化の段階に入っている。

「設計書からプログラムを自動生成」は、いわゆる超高速開発であり、GeneXusや、
富士通のInterdevelop Designer
などがそれに当たる。つまり、実用化の段階に入っている。

しかし、現状、「要件の自動抽出」ができていない。そこで、ユーザーから要求を聞いて、それを設計書に起こすまでが、人間の仕事として存在する。
　このうち、ユーザーからのヒアリングは上流の会社が、設計書の記入と、超高速開発、自動テストの運用と設定が、デジタル土方さんの仕事となっている。

　つまり、現在、「要件の自動抽出」ができていないので、デジタル土方さんは、必要である。逆に言うと、「要件の自動抽出」ができれば、デジタル土方さんは必要なくなる。

---

■要件の自動抽出の３つの要素技術

さらに、要求の自動抽出は、以下の３つの要素技術でできる。

１．顧客から対話型ないしは自然文で要求っぽいことを入力してもらうと、
　　要求から機能要件、非機能要件を抽出する

２．機能要件から業務ワークフローを割り出し、
　　既存のサービスから、ワークフローにあったサービスが存在するかどうかを検索し、
　　存在した場合は、順番にそのサービスをならべ、設計書を出し、
　　存在しない場合、どのようなサービスを作成すればよいかサービス仕様書を出力する

３．業務ワークフローが存在し、
　　それを満たす既存のサービスが複数存在する（＝機能要件は満たす）ときに、
　　非機能要件から、最適なサービスを抽出する

このうち、前回のＫＢＳＥ


論文とかが通るかどうか、判断＆アドバイスしてくれるかもしれないソフト？
http://blog.goo.ne.jp/xmldtp/e/bf2dcaa49c0b76fab8972186c0d7fa7c


の石川先生「機能・品質の多様性を扱う適応的サービス合成」の発表は
上記３を説明している
　つまり、非機能要件を評価関数にして、
　ジェネリックアルゴリズムを使って、サービスの組み合わせを決めていく
　ことにより実現する

また、コグニティの河野さんの「BrainPlots/CogStructureのご紹介」は、
上記１を説明している
　このツールは、文章をチェックし、足りない部分などをアドバイスし、
　要約して抽出する。

　で、質問として出てきた、D-CASEの回答にあるように、
　いま、ゴール指向とのマッピングをおこなっている。

ゴール指向とのマッピングが行えれば、このソフトで、
　ゴールを挙げてもらえるような、アドバイスをする
　ゴールをまとめて出力する
ことはできそうということになる。

　非機能ゴールに関しては、すでに、Lamsweerdeのゴールカテゴリ、
　NFR、（ゴールじゃないけど）非機能要求グレードなどで、
　なにを挙げればよいかが分かっている。

　機能ゴールは、最終的に必要な出力内容の定義（＝トップゴール）となる。
　（業務内容によって異なる）

よって、あと、必要なのは、上記の２になる。

---

■ゴールから要件の割り出し

　のこりの２については、萌芽的な研究しかないが、方向性はわかりかけている。
　（ここの論文の
「刺激―反応ゴール」あたりをロリポおじさんなみのテキトーさで解釈すると）

つまり、以下の手順で行う

　　（あ）まず、トップゴールをゴールとします
　　（い）ゴールに対応するプロセスが１つ以上あると仮定して、
　　（う）そのプロセスが必要とする入力を指定してください
　　　　入力から出力が作れれば、仮定したプロセスは実現できることになります。
　　（え）上記（う）の入力値が、他システムから与えられるか、誰かが手入力する
　　　　というのでなければ、その入力値をゴールとして（い）に戻ってください
　　（お）最終的に、他システムまたは手入力をもとに、最終的に必要な出力内容
　　　　が得られるプロセスがわかります＝業務要件とサービスがでてきます。

例：酒屋倉庫問題

　　　・手元にお酒が届いている→入力値：注文したお酒＆送付先情報（プロセス：配送）
　　　・注文したお酒→入力値：注文したお酒のの種類と数＆倉庫のお酒（プロセス：出庫）
　　　・注文したお酒の種類と数→入力値：顧客からの手入力（プロセス：受注）
　　　・送付先情報→入力値：顧客からの手入力（プロセス：受注）
　　　・倉庫のお酒→入力値：発注したお酒の種類と数＆発注先のお酒（プロセス：入庫）
　　　・発注したお酒の種類と数→入力値：発注者の手入力（プロセス：発注）
　　　・発注先のお酒→他システム（発注先にある）

　よって業務プロセスは
　　　発注→入庫→受注→出庫→配送

---

■全部できると・・・

そうすると、以下の手順で、要求抽出は自動化できそうである

・ゴールを挙げてもらいます（サポートするツールで）
　　最終的な出力内容と
　　非機能要件を

・最終的な出力内容をもとに、既存のサービスを検索して、上記手法によって
　業務プロセスを導き出し、該当サービスがあればそれを抽出、なければ、
　どのようなサービスを出せばよいか出力する

・業務プロセスが決まれば、非機能要件を満たす、最適なプロセスを
　遺伝的ありごリズムを使って抽出する

で、これができると、ユーザーが要求を入れさえすれば、設計、プログラム、テストが
自動的に行われ、システムができることになる。デジタル土方はいらない。

---

■開発で残れる人

このような状況になっても、要求を出すために、上流の会社はのこる
まだないサービスをつくるため＆自動生成を起動するため、
富士通系だとFSA
のメンバーは残れるかもしれない。都筑さんはのこるだろう。
（両毛さんは、ＦＣＡに入ってる）

でも、それ以外はいらなくなってくるかもしれない。
富士通以外でも、似たようなもんになるだろうから、多くのデジタル土方は
いらなくなる・・・転職したほうがいいかも。
会社は別事業を考えたほうがいい？

たとえば、

　　秋葉原にあるなら、
　　女子社員を４８人集めて、ＡＢＣ４８とか作って、
　　バブルのころは良かったけど、最近ぱっとしないテレビ局に
　　「うちの名前の会社名の前に、”オールナイト”とつけた冠番組を深夜に行う」等と提案し
　　コンテンツビジネスで儲ける・・

とか・・・（冗談ですよ　＾＾；）