業界・会社をもっと知る

開発を特定分野に特化した方が専門性の点で強いのではないですか？: 当社は各業種の上位に位置する一流顧客の戦略的な大規模システムの開発を中心に請け負っています。企業の安定性の面から言うと、特定分野に特化することはリスクを伴います。過去の歴史において、重化学工業、鉄鋼、造船など当時の繁栄業種に特化したソフトウェアハウスもありましたが、その業界が不況になると経営が苦境に立たされるケースも数多くありました。ソフトウェアハウスの技術力はソフトウェア技術と業務知識のいわば掛け算で決まると言えます。ソフトウェア工学の特性から言えば、ソフトウェアは抽象概念であり、業種が異なっていても他業種で培ったソフトウェア構築に関わるノウハウ等のシステム上での実現性は高いといえます。さらに新しい業務知識の理解が必要となる場合は、過去に開発したシステムの業務に関す蓄積ノウハウの利用に加えて、素早い吸収に努めています。

なぜマンパワーリース（技術者の派遣）を否定しているのですか？: ソフトウェア開発市場において、現在、技術者の派遣（マンパワーリース）を行っている企業はグレーなものも含めると約7割と考えています。当社のような一括請負のシステムインテグレーションは約1～2割です。マンパワーリースに対し、当社が否定的である主な理由は以下の通りです。

1.IT企業の今後について
現在のIT企業（ソフトウェアでシステムを開発する会社）は永年に亘り派遣中心の役務契約で事業を進めてきたため、システムの開発を失敗しても時間比例型の売上が保証されているため、品質およびコストに関するソフトウェア工学(技術)が全く進んでいないのが現状です。
当社では永年に亘り、品質とコストに関する技術の蓄積に常に務め競争力のあるソフトウェアの提供に努めております。

2.社員評価と人材育成
派遣の場合、社員は常駐先で顧客から直接業務指示を受けるとともに、顧客による評価を受けることになります。派遣元企業では、社員の仕事ぶりを把握できないため、適正な能力評価ができず、各自の能力特性および希望を見極めた上での人材育成も図りにくいという重大な問題があると考えます。

どこの会社でも能力主義と言っています。他社と何が違うのですか？: 当社では「組織の中にあって個人が能力を如何に発揮し、それをどのように評価するか」という、能力評価の極めて根本的な課題を会社設立のテーマの一つと考え、真正面から取り組んできました。その結果、ジャステックは社員の評価を年功序列ではなく能力主義で行うべきと考え、なおかつ、上司による一方的な評価ではなく、上司と本人のみならず同じ部署で働く同僚を交えて、評価のみならず、評価規準の改訂までも含めて議論を行うべきとの結論に達し、そのコンセンサスが社内にできて今に至ります。

具体的には「能力がある人にはたくさん払う」とすることが当社の能力主義の原理原則であり、さらに、能力評価の基準作り、年間の個人目標の設定、ならびに実際の評価の実施に際しては部署単位で全社員が参加するオープンな能力評価システムを導入しております。言わば「みんなで作って、みんなで客観的に測り、納得性を高める」ということです。

これに対し、昨今の能力主義の多くは、それまでの年功序列から脱皮しようとしても、ソフトウェア成果物に対する価値を規定する論理（当社では定量管理と呼ぶ）が全く確立していません。最近、能力主義を採用しているという会社の能力判断基準を見るに、主観的な用語の羅列が多く、どのような裏付があって作成されているのかわかりません。

一分野一社を原則とする営業政策では会社の発展や仕事の幅に限界はありませんか？: 一分野一社の原則は、あくまで相当量の仕事発注と、その継続性を前提とした考え方です。従って、当社の拡大、顧客事情などにより、その前提が叶わなくなった場合は、同一分野内の複数顧客と取引関係を築くこともありえますので、特に限界はないと考えています。

経営参加の方法と具体例は？: 日々の仕事の小さな事柄から、全社で取り組む必要のある問題に至るまで、その解決を誰かに委ねるのではなく当事者意識を持って考え、行動することが「経営参加」の本質と言えます。自分たちの会社は自分たちで創り、改善していくという気持ちが、個人、会社双方の発展につながるのです。代表的な例として予算提案制度などが挙げられます。

高利益を維持している理由は？: いくつかの理由が考えられますが主なものを挙げると以下の通りです。

○取引先が一流のクライアント
○幅広い業種の開発で培った技術力
○技術に精通した強力な営業体制
○顧客との直接取引
○採算が見込めない案件は受注しないという強い営業姿勢を貫くと同時に、採算が見込めない案件であるということを受注前に予見
○独自の生産管理およびそれを支える定量管理モデルにより工学的に開発を管理（見積、進捗、原価などを管理）
○オープンな能力主義に基づく給与体制
○購買部門による協力会社の一元管理

開発の期間・開発チームの人数はどのくらいですか？: 開発規模により差がありますが、短期では半年程度。長期では複数年にわたるものがあります。開発チームの人数は小規模なもので5～10名程度。大規模なものになると100名以上になります。開発管理技術で勝負する当社には、同業他社に比べて開発規模が大きくかつ開発期間が長い案件を多く手掛けているという特徴があります。

ソフトウェア開発における「見積」はどのように行うのですか？: 開発着手前に、これまで蓄積した開発ノウハウを基に、独自の生産管理技術方式を用いて、開発規模および生産性を予測し、これを開発するに必要な品質を考慮した価値を売値とし、開発期間（納期）を合わせて工程別に契約金額を提示し、顧客の合意を得て契約をします。

開発が計画通りに行われているかどうかについては、実際の開発規模・生産性などについてのデータを収集分析し、見積通りに開発が履行されるよう管理します。開発プロセスを定量的に管理する当社の独自技術は、同業他社に対し圧倒的な競争優位性を持っているものと自負しております。また、その技術を業界標準とすべく、顧客に積極的なPRを推進しています。当該技術が的を射たものであることは、開発プロセスの成熟度を測る枠組みとして現在世界標準と言われているCMMIにおいて、その最高水準であるレベル5を日本で初めて達成していることでもお解り頂けると思います。

ソフトウェア開発に自分が向いてなかったらと思うと不安です。 「SE35歳定年説」というのも聞いたことがあります。: 当社は、技術者が自ら設立した企業であり、技術者の限界打破が設立来の大きなテーマになっています。一般に限界説には以下の背景があるものと考えられます。

○受注分野の成長性がなくかつ狭い。
→売上、給与が伸びない。
○下請け会社でプログラミングなどの下流工程しか受注できない。
→技術力が育たない。
○技術以外で活躍できるポストがない。
→親会社、取引先企業からの出向、転籍者が管理、営業、総務などのポストを占め、社員の職種転換ができない。

当社はこうした背景を踏まえ以下のことを実践しています。
○業務は上流工程をタレント中心（コンサルタント、ストラテジスト等々の名称が現状のところ業界で使われていますが、当社ではソフトウェア工学に関する技術の知識に留まらず、創造性を発揮する能力も具備する技術者をタレントと呼んでいます）が手掛け、一般的な技術者が以降の工程をフォローすること。
○技術者が技術以外のポストにつくことを容認すること。

社内の雰囲気はどうですか？: オープンでフランクな人間関係が挙げられます。お互い役職名でなく名前で呼びあう習慣があります。間違った場合には本気で愛情を持って指導（注意）してくれる同僚、先輩、上司がいます。若いからといって軽々しく扱われることはありません。意欲が高い人には、どんどん仕事を任せます。20代後半で開発チームのリーダを、30代で課長や部長を担っている人もいます。全国から当社の理念に賛同した人が集まっています。個々人をみればおとなしめの人からとんがった人までバラエティー豊かです。共通しているのは、自分達の会社、仕事に誇りを持ち、自立した生き方を志向しているということです。

良いソフトウェアを開発するためには所謂上意下達ではなく、世代、立場、利害を超えて、お互いの人格、主張を尊重し、是々非々な論議を行う必要があります。そうした企業文化がそのまま社内の雰囲気を作り出しています。仕事の結果はもちろん重要ですが、一方では、「自分でやりたいことを宣言し、挑戦する姿勢」を良しとします。周りは協力と応援をおしみません。皆さんの所属ゼミ、研究室の雰囲気と共通する部分も多々あると思います。
※是々非々：いいことをいいとし、悪いことを悪いとする、公平無私な主義

ソフトウェア開発の方式について教えてください。

ソフトウェア開発には「一括請負方式」と「派遣方式」の二つの方式があります。下表に、それぞれの方式の特徴を示します。

	一括請負方式	派遣方式
価格根拠	開発の生産性を反映させた生産物単価と規模の見積により、価格を決定する価格＝生産物単価×見積生産量	顧客要求に基づき、当該技能を有する技術者の単価および稼働時間により、価格を決定する価格＝時間単価×稼働時間×人数
コスト意識	見積ミス、技術力不足によるコスト増は、ソフトウェアハウスがリスクを負う生産物単価が一定の下での時間増 → 利益減	技術力不足によるコスト増は、顧客がリスクを負う時間増 → 売上・利益共に増
指揮命令	開発要員に対する指揮命令権はソフトウェアハウスにあるチームリーダ → メンバ	開発要員に対する指揮命令権は顧客にある顧客担当者 → 派遣社員
完成責任	ソフトウェアハウスが責任を負う	顧客が責任を負う
損害賠償	ソフトウェアハウスが責任を負う契約金額を上限とすることが一般的	顧客が完成責任を負うため、発生しない
瑕疵担保	ソフトウェアハウスが責任を負う	顧客が完成責任を負うため、発生しない
著作権	著作権はソフトウェアハウスが所有し必要に応じて、顧客に対し、改変権・使用権の譲渡または使用権の許諾を行う	著作権は顧客が所有する
特許権	特許権はソフトウェアハウスが所有し、一定期間独占的に実施する権利を有する	特許権は顧客が所有する
顧客	開発を全面的に委託することができるため、システムに対するニーズを詰めるなどの企画業務に集中できる	技術者の管理に時間をとられる
経営者	少なくとも取締役の中に、ソフトウェア工学に関し創造力のある人材が必要	役務提供会社の経営者が、知識集約型への脱皮を図るのは無理
技術者	担当する開発工程の幅が広い。上位技術者からの技術トランスファーが可能	担当する開発工程の幅が狭い。社員、チーム間の技術トランスファーがしづらい

【派遣】
自社社員を派遣先企業の業務担当者による指示命令を受けて就労させることを派遣と言い、派遣会社は厚生労働大臣へ届出をする必要があります。なお、就業場所が顧客の施設内であったとしても、自社の上司の指示命令で働いている場合は、「常駐」と言い「派遣」とは異なります。

【瑕疵担保】
法律用語で「瑕疵」とは仕事の目的物の欠陥のこと、「担保」とは債務の履行の確保を行うために債権者に提供されるもののことを指します。つまり、一括請負方式における「瑕疵」とは、生産物（設計書やプログラム）のバグ（不具合）のことを指すため、瑕疵があった場合には、ソフトウェアハウス側が責任を持って修正し完成させること、ならびに瑕疵により顧客が被った損害を賠償することが、瑕疵を担保することにあたります。