マエカワの備忘録的な何か

思い立ったが吉日

ソフトウェア工学 其の六 20171130

面接について

 やる気を見せても、そのようにみられないことが多々。注意せよ。自分自身についてのプレゼン能力が面接の場では試される。面接=プレゼンテーションだ。

課題の講評

 「通信して、いい感じに儲けるシステム」の考案について、講評がありました。その中で出てきた話をいくつか。

機能だけではいけないとあれだけ言ったのに…

 どうやら、「こんな機能があります!!すごいでしょう!!便利でしょう!!儲けるでしょう!!」というレポートが結構あったようです。セキュリティコースの方にその傾向がみられたようですが。
 この課題では、現在ある問題はいったい何なのか。そして、その問題はどのような性質を持っているのか。これを踏まえたうえで、最も解決策に近いものを提案する必要がありました。「アルゴリズム」だけでなく、人間の感性・感情に基づいて。また、「みんなが使っているものを使いたがる」という人間の性質から、ネットワーク外部性に繋げて行くことも可能かもしれません。

ヒット商品はクレイジー

 ヒット商品は発表された当初は受け入れられず、クレイジーだと思われることがあるようです。しかし、クレイジーであるというのは、「今はまだない概念」であるということ。技術や人の考え方が変わってきたときに受け入れられ、認められ、ヒット商品になる(ならないものも当然あります)。
 何年か前の回答で、「バーチャル彼氏を育成していくサービス」というものがあったらしい。今でこそ、スマホアプリなどでその種のサービスは提供されているが、課題が出された当初はなかなかクレイジーだったそうです。

かゆいところに手を届ける

 新しい製品を作るとき、何を一番に考えなければならないか。それは、「ユーザーの心」。これにダイブしていくのが重要になってくる。表面に見えているものではなく、ユーザーが持っている「もうちょっとこうならないかなぁ…」的な表に出ない声に耳を傾け、製品を作っていく。これこそが、「見えないものを見る」ということにつながる。

システム開発について

 システムを買う側の企業を「ユーザ企業」、システムを作る側の企業を「SIerソフトハウス」と呼ぶ。今回扱った、システム開発の手順(途中まで)を以下に列挙していく。

  1. ユーザー企業がRFPを作成、提出
  2. 要求開発

とりあえず、この回で進んだのはここまで。

RFP(提案依頼書)

 ユーザ企業が最初に提出するもの。中身は

  • システム概要(予算が入札時の駆け引きで重要になる)
  • 手続き
  • 提案していただきたい事項
  • 開発の条件(作業時間、勤務場所など)
  • 保証要件
  • 契約事項(瑕疵担保契約期間が重要)
  • 添付資料

などなど。企業の採用情報に、「勤務地:○○、他」と書かれていたら、常駐を疑うようにするべし。
 この項目の中で、特にネックになってくる事項は「予算」と「瑕疵担保契約期間」。少し説明を書き足します。

予算

 言わずもがな、とても重要。ユーザ企業は複数企業に対して「こんなもの作ってくれませんか??」と呼びかける。考慮すべきなのは、その予算がシステム開発にかかるコストとして妥当なのか、自社は儲けるのか、他社はどのような動きを見せるのかなどなど。お金はいつだって大事。

瑕疵担保契約期間

 簡単に言えば、作ったものに対してユーザ企業が訴えを起こせる期間。電化製品を買ったときの保証期間みたいな感じ。依頼を受ける企業側からしてみれば、この期間は短くしたい。

多重下請け構造

 日本では、この仕組みでシステムを開発しているところが多い。ユーザ企業が200万でシステムを依頼したときの流れの一例を書いてみる。

  1. 1次受け(プライムともいう)が依頼を受ける
  2. 1次受けは150万で依頼を2次受けに投げる
  3. 2次受けは100万で依頼を3次受けに流す
  4. n次受けがn+1次受けに依頼を回す

このように、下へ下へと依頼を回していく。これが多重下請け構造
 こうなってしまっては、全体の進捗を把握することができない。伝言ゲームのようにめんどくさい手続きを経て、ようやくプライムに情報が共有されることになる。このラグは、仕様変更の際に殺人鬼と化す。仕様変更が即座に末端に反映されないので、反映されていない期間にやった作業がすべて水の泡に。現場は火の車と化す。
 さらに、1次受け、2次受けくらいまではコードを書かないことがあるらしい。ただ依頼を横投げして、50万円ゲット。
 コンサルタント会社がユーザ企業とプライムの間に介入するという変則パターンについても説明を受けた。コンサルタント会社の仕事は、「提案すること」。実際に作ることはまずない*1。また、ユーザー企業は多くの場合、専門の知識を持っていない*2。なので、構造上絶対にありえないシステムだったり、わけのわからないシステム仕様書が採用されてしまうらしい。現場は瞬く間に炎上。SEがブラックだといわれている一つの要因だ。
 就職先を決める際も、この構造についてしっかり理解することが重要だ。最初にどこの位置にいる企業に入るのか。これによって、その後が変わってくる。プライムとn次受けでは、とんでもない単位で生涯年収が変わってくるのだから。
 ただし、今時安定している会社はない。どこに入っても大変だろう。しかし、その中でも恵まれた職場環境に身を置くためには、スキルが必要になってくる。

要求開発

 RFPが提出されたら、要求開発のフェーズに入っていく。詳しい話は次回なのだが、この「要求開発」において最も重要なのが、「何(what)が欲しいのかを決める」ということ。手段(how)は決めない。これは簡単そうに見えて、とても難しい。なぜなら、まだこの世に存在していないシステムについて話をしているから。存在していないものに何が必要なのか見極めるためには、スキルが必要になる。「見えないものを見るスキル」が。第1回目の課題とつながった。


*1:もちろん、そうでないところもあります。

*2:もちろん、そうでないところもあります。