ネクスト・オフショア | ベトナムのオフショア開発総合情報ポータル

2020-01-16

人工知能とは│歴史

最近、人工知能（以下AIという）という言葉はテレビやインターネットによくみられていますが、詳しく知らない方が多いと思います。そこで、今回は人工知能とは│歴史について紹介します。人工知能に関心を持たれる方は、この記事を読んでいただけばと思います。

人工知能とは：

人工知能は英語でArtificial Intelligenceで、この略称で「AI」と呼ばれています。
人工知能（AI）とは、人間と同様の知能であり、機械の形で表される行動、知覚、思考として定義されている。簡単に言えば、周囲の環境を認識し、行動を分析し、目標を達成することを最大化する可能性があるデバイスは、人工知能があるデバイスと見なされます。

人工知能（AI）の歴史とは？

私たちの生活の中で人工知能が搭載されている機会は多くなっていることが実感できると思います。
それでも、「人工知能のニュースをよく耳にはするけど、あまりピンと来ない」という人がほとんどではないでしょうか。そこで、人工知能について歴史から理解していきたいと思います。

以下の図はAIの歴史段階を占めています。

(出典）松尾豊「人工知能は人間を超えるか」（KADOKAWA）p.61

第一次AIブーム　推論・探索の時代（1950年代後半～1960年代）

第一次ブームは、1960年代に起こった「推論と探索」に関するブームです。推論と探索というのはあるルールとゴールが決められているゲームの中で、コンピュータがなるべくゴールにたどりつけるように選択肢を選んでいくものです。推論と探索には迷路を解く際にしらみつぶしに選択肢を探索してゴールにたどり着く方法や、チェスなどの対戦ゲームにおいてなるべく自分が有利になるように選択肢を選んでいく方法などがあります。

このブームの中で、一見知的に見える問題をコンピュータが次々と解いていき世間を驚かせました。しかしよく考えてみると、解いている問題はすべて明確なルールが定義されているモノでした。
しかし、実際に現実にある問題については、その複雑な計算を処理する術がなく、解くことができませんでした。コンピュータの性能の限界が見えたことから、1970年代に一回目の冬の時代に突入していきます。

第二次AIブーム　知識をいれると賢くなる（1980年代）

第2次AIブームで盛り上がりを見せた「知識表現」に関して：エキスパートシステムです。
第一次ブームでは高度な計算はできましたが、現実にある複雑な問題の解決が難しかったんです。そこで革新的な「エキスパートシステム」は、膨大な専門知識の入ったソフトウェアで，専門家のように問題解決を行うことができるものです。第一次ブームと比較してコンピューターの小型化・性能が高まっており、ある程度はこれらの試みは成功しましたが、知識を教え込む作業が非常に煩雑であること、例外処理や矛盾したルールに柔軟に対応することが出来ません。

しかし、ここでも問題がありました。コンピュータには「常識」がないという問題です。ここで一つ例を挙げると、“熱を下げるには”という質問に対して、「解熱剤を飲ませる」または「殺す」と答えたそうです。確かに死ぬと体温は下がりますが…。そもそも前提として命を守るということがありますよね。

ただ、コンピュータにはそういった「常識」がないために、このような答えを出してしまうのです。結局、このような問題に直面し、第二次ブームは収束しました。

第三次AIブーム　機械学習・深層学習技術の発展（現在）

この第三次ブームが起こった大きな要因として、ディープラーニング(深層学習)という技術の発展、ビックデータの普及などが挙げられます。実は、ディープラーニングなどは、第二次AIブームの時代から研究されていましたが、実用化するためにはコンピュータの性能が追い付いていませんでした。

しかし、2000年代に入り、コンピューターの小型化・性能向上に加えインターネットの普及、クラウドでの膨大なデータ管理が容易となったことで実現可能なレベルとなり、第三次AIブームが沸き起こりました。

この技術により、画像や映像から情報を抽出したり、音楽や文字の生成などが可能となっています。ディープラーニングがこれからの人工知能の発展に大きく関わってくることは間違いないでしょう。
… Read more

2020-01-21

AIの基本的な特徴や種類について

ニュースなどのメディアで人工知能の話を聞く機会が増えています。AIが将棋や囲碁、チェスなどの分野でプロプレーヤーと勝負したり、自動車の自動運転を可能にしたりする話題が注目を集めてきました。ただ、ほとんどの人が「AIという単語は知っているけど詳しい内容までは知らない」と感じている方が多いでしょう。そこで、この記事では AIの基本的な特徴や種類について一緒に学んでいきましょう。

人工知能とは

AIは「Artificial Intelligence（アーティフィシャルインテリジェンス）」の略です。それぞれを日本語に訳すとArtificialは「人工的な」Intelligenceは「知能」という意味合いです。AIはそれらを組み合わせ人工知能と訳したものです。

AIの特徴

AIは自分で学習し、認識・理解ができます。この認識や理解といった学習力を用いれば、問題の解決だけでなく予測などの立案といった人間の知的活動を行うことが得意です。
一方、AIを備えたコンピュータは、状況に応じて人間のような判断と対応を適切に行うことができます。つまりAIは、自ら状況判断ができるということです。

身の回りのAI技術

実際に、すでに身の回りには多くのAI技術が活用されています。例えば、毎日利用しているフェイスブックは、AIの自動音声認識や画像認識の導入が進められています。

また、AIによる株取引の自動化も進んでいます。最も適切なタイミングでの買い注文や売り注文を、AIが膨大なデータから自動的に予測します。人間は、「もっと儲けたい」「損をしたくない」といった感情から冷静な判断ができない場合がありますが、AIならデータに基づいた客観的な判断を行うことが可能です。

人工知能の種類

AI（人工知能）と一括りにいっても、実はその機能や使用目的によって、種類が分けられます。人工知能にどのような種類があるのか、確認していきましょう。

特化型人工知能（GAI）と汎用人工知能（AGI）

特化型人工知能（GAI)　とは？

GAIの正式名称はGrowing Artificial Intelligenceといい、特化型人工知能と和訳されます。
特化型AIとは、限定された領域の課題に特化して自動的に学習、処理を行うシステムを指します。例えば、画像認識や音声認識といった技術やコンピュータ将棋やチェス、自動運転自動車、医療診断といったAI技術が該当します。

汎用人工知能（AGI）とは？

AGIの正式名称はArtificial General Intelligenceといい、汎用人工知能と和訳されます。
汎用型AIは、特定の課題だけに対応するのではなく、人間と同じようにさまざまな課題を処理可能なシステムを指します。

特化型人工知能は事前に決められたことしかできないのに対し、汎用人工知能は、想定外の出来事が起こった場合でも、人間であればこれまでの経験に基づいて総合的に判断を行い、問題を解決できます。

この「汎用人工知能」は、私たちが小さい頃に憧れた鉄腕アトムやドラえもんのようなものです。汎用人工知能が完成した時、AIが人間の脳を超えるという時代が到来します。

弱い人工知能・強い人工知能

また、特化型人工知能（AGI）と汎用人工知能（GAI）の分類の他に、弱い人工知能と強い人工知能にも分けられます。

弱い人工知能とは、ある枠の範囲で考えることは可能だが、意識・思考を持たないAIとしています。
つまり、人間の知性の一部分のみを代替し、特定のタスクだけを処理するAIが弱いAIです

一方で、… Read more

2019-12-25

オフショア開発とは？オフショアの問題を解説

昨今、オフショア開発は経営のトレンドの一つをよく言われます。では、オフショアは何でしょうか？または、オフショアを利用する際、どんな問題が起きるのでしょうか？これらの悩みごとを調べてみましょう！

オフショア開発とは？

オフショア開発はシステムの開発や応用管理業務を海外に委託・発注することです。

安価な人材の雇用でコストパフォーマンスを削減可能が一つの大きなメリットですが、オフショアサービスを使用するときには次の点を三つ注意する必要があります。

1. 遠隔での作業

管理者は開発チームから遠く離れている場所にいることが多いので、プロセスや仕事の進度を直接に指導しにくいかもしれません。

この問題に対応は両方のコミュニケーションが具体の明確なレポートを通し、Whereby、Zoom、Google Hangoutなどのオンライン通話ソフトウェアを積極的に使用することです。

2. アイディアと資料の共有

上で書いたの通りは、オフショア開発は海外の人材を採用します。そのため、お互いに直接の発想共有は難しく、ビデオコールを使っても不安定な通信やビデオでは、言い表しにくいことによって、情報をちゃんと伝えられない恐れがあります。

この問題を避けるために、開発用の資料は詳細で明確な方が両側は開発している機能を汲み取りやすく、期待通りに効果を得ることができます。

3. 言語問題

オフショアサービスを使用するとき、コミュニケーションは最も大切な難しい問題です。言語と文化差異を理由として双方同士の勘違いが生じられます。

この問題を解決するためには、情報交換のための直接会議が行う必要があります。さらに、プロジェクトにおいて、コミュニケーター/ ブリッジSEの役割は、双方が情報を結びつけるために非常に重要であり、プロジェクトが、元のアイデア通りに実行されることを保証します。

まとめ

オフショア開発を利用する際、顧客は遠隔での管理や言語問題などを直面しかねないとはいえ、最適な解決をすればこのサービスのメリットを享受できます。緊密な進展状況のレポート管理や、高品質な開発チームとコミュニケーター/ ブリッジSEチームを有する企業との連携などがございます。 … Read more

2020-01-07

ブリッジSEとは｜役割と必要なスキル

「ブリッジSE」とは、「ブリッジシステムエンジニア」、「ブリッジエンジニア」や「BrSE」などとも呼ばれる比較的新しい職種のため、耳馴染みのない方も多いことでしょう。それもそのはず、近年急増しているオフショア開発とともに、ブリッジSEの需要が増加しつつあります。では、具体的にブリッジSEとは｜役割と必要なスキルについて調べましょう。

ブリッジSEとは

「ブリッジSE」とは、国際化の流れの中で誕生したSEです。他国と協働するIT関係のプロジェクトにおいて、自社の代表として取引先の他国企業との間に立ち、橋渡し役を担うSE（システムエンジニア）です。

相手国の人材と結成するプロジェクトチームは、話す・聞くに用いる自然言語が異なるグローバルなチームで構成されます。

このようなグローバルな環境下では、チームとしての生産性向上・品質確保を担保するため、自然言語の壁を排して情報の橋渡しを行う人材が必要となります。このような役割を担う人材がブリッジSEなのです。

ブリッジSEの役割

「ブリッジSE」は、開発中、発注者と開発チームの方向性が合致するよう常に調整し、現場をうまく回して開発プロジェクトを成功させるという重要な役割を担います。

一般的なSEと比べると、ビジネス分析、交渉、市場特性を加味したコミュニケーションが重視され、かつ実践的な異言語間コミュニケーションの運用経験が重要視されるポジションです。

ブリッジSEに必要なスキル

「ブリッジSE」は、現在、海外の方と協働しシステム開発を行っていくという方法で、主に規模の大きいIT企業で活躍している方が多いようです。技術的な内容はもちろんのこと、語学や、その国に応じたコミュニケーションのマナーやルールなど、ITの知識と語学の知識の両方が要求されます。

ブリッジSEに必要とされるスキルは、次のとおりです。

案件に関するIT/技術知識

プロジェクトにかかわるSEとして、第一に案件で必要とされるITや技術関係の知識は必須です。ブリッジSE本人がプロジェクトの技術的内容を理解せずには、言語も文化も異なる人材との適切なコミュニケーションと伝達はできません。

チームをまとめるコミュニケーション能力

プロジェクトマネージャーやリーダーでなくても、ブリッジSEにはクライエントの意見を調整の上でまとめ、開発チームに伝達するという役目があります。

ブリッジSEとしての職責を果たすには、自国のチームをまとめ、さらに相手国のチームの信頼を勝ち取るだけの高いコミュニケーション能力が求められます。

両国の商習慣や文化に対する理解

オフショア開発を採用する際は海外の人材を雇うことので、言語の違いはもちろん、文化も異なります。文化のみではなく、ビジネスに大きな影響を与えるのが商習慣の違いです。

両国間の習慣やルールの違いに起因するトラブルを避けられるよう、ブリッジSEは両国の商習慣や国民性までも熟知する必要があります。

交渉できるレベルの高い語学力

プロジェクトの進行中、万が一問題が発生した場合は、外国語を駆使しながら相手国のメンバーが理解しやすい言い回しや方法で説明し、理解を得る必要があります。

このため、ブリッジSEには、外国語による最低限のコミュニケーション能力のみでなく、相手に分かりやすくかつ説得までできるレベルの語学力が求められるのです。

まとめ

プロジェクトをスムーズに実行するためには、プロジェクトのすべてのメンバーが互いにうまく協力する必要があります。両側の橋渡し役として、ブリッジSEはプロジェクトの成功を促進する責任を担っています。または、ブリッジSEの仕事を上手く行うために必要なスキルを身につける必要があります。

… Read more

2020-01-17

要件定義とは？｜要求定義との違い、進め方とコツ

前回の記事に要件定義の基本的な情報について述べました。今度は混同されやすい要求定義との違いや、実際に要件定義を進めていく上でのコツに関するインフォーメーションを紹介します。この記事に、要件定義とは？｜要求定義との違い、進め方とコツについて読みましょう。

要件定義と要求定義の違い

● 要求定義とは？

要求定義とは、「プロジェクトで○○がしたい」「この機能がほしい」というクライアントの希望を確認する作業です。クライアント側の担当者が複数人いる場合は、特に必要となります。

● 要件定義と要求定義の違い

要求定義は「○○がしたい」というクライアントの希望で、その要求をまとめて「○○の機能が必要」など具体的なシステムの仕様書を作成するのが要件定義です。

例えば、クライアント担当者が2人いた場合、両者の希望を確認したところ、二つの異なっている要求が出てしまうケースがあります。この場合、要求に乖離があり、どちらも満足のいくものになるとは限りません。そのため、要求を確認してまとめ、最終的に要件定義にする内容を決める作業が要求定義です。

要件定義の進め方とコツ

要件定義は、繰り返し修正を行いながら作成していきます。どのように進めていけば良いのでしょうか。

● クライアントの要求をヒアリング

ヒアリングは、クライアントから、ただ求めている機能を聞くだけではありません。「現状、どのような不満があるのか」「どんな作業で時間がかかっているのか」など、質問を通してクライアントの潜在的な要求を掘り起こしましょう。メールでヒアリングシートを送付して返信してもらうだけの簡易的なヒアリングでは、要求を完全に網羅することはできません。打ち合わせをして、議事録とヒアリングシートを作成し、クライアントと共有しながら認識を合わせていく必要があります。

● 要件定義書の作成

クライアントと共有したヒアリングシートを基に、要件定義書を作成します。ヒアリング情報を体系的に分析・整理していき、定義に矛盾がないようにします。要件定義書を作成する際、クライアントの要求すべてを盛り込んでもクライアントが満足してくれる良いシステムが作れるとは限りません。クライアントが実際には何を求めていて、本当に必要な機能は何なのかを分析し、要件定義書にまとめていきます。

要件定義書は簡単に作成できるものではありません。プロジェクトの根幹となる資料であり、この定義を間違えればプロジェクト全体の方向性が変わることになります。「ヒアリング」「要件定義」「共有」「修正」を繰り返して、要件定義書を完成させていきましょう。

要件定義はプロジェクト成功の鍵

プロジェクトを進めていくと、設計時やプログラム実装時、そしてリリース前など、さまざまなタイミングで問題が発生します。その際に、どのように要件を定義していたのかを振り返って確認するための資料が要件定義書です。

しっかりと練り込まれた要件定義があれば、問題が起きて振り返る際やプロジェクトに新たなメンバーがアサインされたときにも、すぐに全体を理解できる重要なツールになります。

終わりの言葉

プロジェクトに対する要件定義は身体に対する背骨と同じ意味です。プロジェクトを始める際には、プロジェクト全体を良い方向に導くために、しっかりと要件定義を作成するように心掛けましょう。
… Read more

2020-02-05

自動運転技術のレベルについて

多くの方は「自動運転」という言葉を聞いたら、ドライバーが何もしなくても目的地まで辿り着くようなクルマをイメージがついているでしょう。そのようなに理想的な「自動運転車」を実用化されるのはまだまだ先のことです。実は、自動運転技術は米運輸省道路交通安全局（NHTSA）が「自動運転化レベル」としてレベル0～レベル5までの6段階に区分しており、レベル5では制限なく全ての運転操作が自動化されますが、現在日本で販売されているのはレベル2までのクルマです。今回は自動運転技術のレベルについて詳しく説明したいと思います。

自動運転技術は以下のようにレベル0～レベル5までの6段階に区分されています。

レベル0：運転自動化なし

レベル1：運転支援

レベル2：部分運転自動化

レベル3：条件付き運転自動化

レベル4：高度運転自動化

レベル5：完全運転自動化

レベル0

レベル0は自動運転技術のないクルマです。加減速やハンドル操作を含めた全ての操作をドライバーの判断で行います。現在の車のほとんどがレベル0です。

レベル1

衝突被害軽減ブレーキ（自動ブレーキ）やオートクルーズコントロールのように加減速を支援するか、または車線維持のようにハンドル操作を支援するクルマです。

例えば、車線から外れると検知し修正するシステムや、先行車との距離を一定保つために加減速をコントロールする「クルーズ・コントロール」など、最近の新車に多く搭載されている運転支援システムが当てはまります。

レベル2

レベル2になると、「ハンドル操作」と「加減速」の操作が連動して運転をサポートしてくれ、現在の公道最高水準となります。ドライバーは常にハンドルを握り、運転の責任は全てドライバーにあります。そのため、レベル2までは「自動運転車」ではなく、「運転支援車」と呼ばれています。

例えば、渋滞時に走行レーンを走りながら先行車の動きに追従するため、前の車が止まればそれによって停車し、再び前の車が動き出せば再度発進するシステムとなります。

レベル3

レベル3になると、走行場所等が決められた条件下で、全ての運転操作をクルマの自動運転システムに任せることが可能となります。ただし、システムが自動運転を継続できなくなった場合、ドライバーはシステムからの要求に応えて、いつでも運転に戻れる状態でなければなりません。

例えば、高速道路などで交通状況を認知し、運転に関わる全ての操作を自動で行います。これによってドライバーは運転しなくてもよくなりますが、緊急時や自動運転の作動が困難になったときは代わりに運転しなければいけないため、運転席には座っていなくてはいけません。

レベル4

レベル3のように特定の場所で全ての運転操作をクルマの自動運転システムに任せることが可能となります。そのため、自動運転が作動しているときはドライバーの運転操作は必要ありません。

現在、ラストマイル（主に中山間部等において、公共交通の最終地点と自宅等最終目的地を結ぶための移動システムのことで、自動運転車の活用が期待されている）等の社会実験が行われていますが、それらの実験用車両はレベル4を想定したものが多くあります。

レベル5

さらにレベル5になると理想の「自動運転車」と言える、条件なく常に全ての運転操作をクルマの自動運転システムに任せることが可能になります。いつでもどこでも自動運転されるため、もはやハンドルもアクセルも必要なくなります。そのため、従来の車のスタイルから全く異なる内装のアレンジが可能で、車というよりも「動く小さなリビング」と呼んでもいいでしょう。

上述したように、「レベル2」までは、主にドライバーの運転をサポートする技術であり、万一事故を起こした際の責任はドライバー側にあります。

しかし、「レベル3」以上は基本的にドライバーが操作を行う必要がないので、事故が発生するとき、誰が責任を取るかという解決するべき課題はたくさん残っており、実現するにはまだ相応の時間がかかると考えられています。

まとめ

理想の「自動運転車」が成立したら、ユーザーの利便性や快適性の向上ではなく、交通事故の大幅な低減といった期待が寄せられています。ただ実用化と伴う課題も出てきています。そのため、実用化に向けては、新たに法制度を作ったりインフラを整えたりといった国家規模の取り組みの必要があるではないかと思います。
… Read more

2020-01-21

外部設計と内部設計

システム開発における設計は、「外部設計」と「内部設計」の二つに大別できます。基本的にシステム設計では、最初に要件定義を行い、次に外部設計を行います。外部設計を基にして内部設計を行ったあと、内部設計を基にしてプログラミングを行います。今回は、外部設計と内部設計、それぞれについてご紹介します。

外部設計とは？

外部設計は、実際にシステムの仕様を決定する段階です。要件定義で決定したシステムの機能要件や非機能要件、制約条件、外部とのやり取りなどをより具体的な仕様にすることで、実際にプログラム可能な形にします。ここでは、外部設計の主な項目を三つに分けて解説します。

● 方式設計

方式設計では、システムの実装方針やプラットフォームの方針を設計します。システムがどのようなハードウェアで合成されるか、ハードウェアやソフトウェアの機能や構造をどうするか、プラットフォームは何か、開発言語をどうするかなどを決定します。アプリケーション全体の構造もここで設計されるため、アーキテクチャ設計とも呼ばれています。

● 機能設計

機能設計では、システムをモジュール単位で分割し、各モジュールや使用するデータベースの設計を行います。具体的には、データの入出力、データベース同士のデータの受渡し、ユーザーによる操作などです。

また、画面のレイアウト、操作方法、帳票類の書式など、システムの使いやすさやユーザー満足度につながるインターフェース部分の仕様を決めるのも機能設計の役割です。

● その他の設計

その他の設計では、クライアントに求められている機能やセキュリティや運用規定など、業務として運用するために必要な部分を決定します。

外部設計では、「外部設計書」「画面仕様書」「インターフェース仕様書」などが成形されます。これらの内容は、クライアントに確認して合意を取ることが必要です。

内部設計とは？

内部設計では、外部設計の結果を実際にプログラミングできるように、システム内部に特化した詳細な設計を行います。ここでは、内部設計の主な項目を三つに分けて解説します。

● 機能分割

機能分割では、プログラミングやシステムのメンテナンスをしやすくするために、機能をモジュールごとに分け取り、各モジュールの機能を明確化します。また、機能間でデータが処理される際の流れ（データフロー）を設計します。データが処分される流れを明確にすることで、設計バグを洗い出せます。

● 物理データ設計

物理データ設計では、ユーザーには見えないシステム内部で使用するファイルやデータのやり取りに関する部分の設計を行います。

● 入出力の詳細設計

入出力の詳細設計では、外部設計で決めたインターフェースをプログラミングでどのように実装し、表現するかをさらに細かく設計します。例えば、エラー処理や初期値・デフォルト値の定義、入力データのチェック方法、表示するメッセージなどについても検討します。

内部設計では、「機能仕様書」「データフロー図」「データベース物理設計書」などが作成されます。内容はプログラミング作業を行うメンバーに共有されますが、内部設計でクライアントとの調整を行うことはほとんどありません。

まとめ

外部設計と内部設計はシステム開発における設計の二つの大きな部分です。システム設計の流れには外部設計か内部設計かをきちんと作成できないと製品の品質を確保できるはずがないでしょうか。
… Read more

2020-02-25

SFAの導入と運用に伴う注意点

以前で紹介したことを踏まえれば、SFAは営業部門だけでなく、全社的な基幹システムとして通用するものだということがおわかりいただけるでしょう。しかし、実際に導入するとなると、意外なところでつまずくことも少なくありません。続いては、 SFAの導入と運用に伴う注意点について考えてみましょう。

「使って当然」という環境を作る

SFAを導入したのはいいけれど、現場になかなか定着しない…というのは、よくある悩みです。SFAは活用してこそ真価を発揮するものですから、日常的に使うようにしなくてはなりません。

ではどうするか？…その方法はいくつかありますが、ひとつは上長のプッシュです。経営陣から指示を出したり、SFAベースでのワークフローに移行したりすれば、否応なくSFAを使うように誘導できるでしょう。その意味では、現場のマネージャーはもちろん、経営トップが積極的に導入に関わることが重要です。また、SFAを積極的に使いこなすメンバーに何らかのインセンティブを与えるという方法も考えられます。

しかし、本質的に必要なのは、SFAの活用にどのようなメリットがあるのか、それによってチームメンバーにどのような利益が生まれるのか、さらには顧客にどのような価値を提供できるのかということを、現場にしっかり理解させることでしょう。そうすれば、「これだけメリットが多いSFAなのだから、使うのは当然だ」という状況が自然と生まれます。

スモールスタートを切るのも良い方法

SFAの導入による変化は、営業現場でのワークフローだけにとどまりません。個人プレーからチームプレーへの移行、顧客第一主義という発想への転換など、企業に大きな変革をもたらす可能性を秘めています。それだけに、全社的に一気に移行するというのは、なかなか難しいことです。そんなときは、6～7名程度のチーム単位でスモールスタートを切り、その効果を見るというやり方も有効です。

新たにSFAを導入するとなると、運用や活用について予測できない障害が発生することもあるでしょう。定着するまでに、困難に直面することもあるかもしれません。ですから、まずは最小単位での導入として、様子を見るのです。これなら、障害や不具合が発生しても、全社的な問題に至ることはありません。その上で導入範囲を広げていけば、社内全体にスムーズに普及させることができるはずです。

まとめ

SFAの導入と運用前、注意すべきことがご存知した方が良いでしょうか。次は、最後のSFAに関する記事にSFAツールを選ぶポイントについて読みましょう。
… Read more

2020-01-06

オフショア開発の見積もり

オフショアサービスの最も大きなメリットは雇用の低いコストです。海外の会社へプロジェクトを委託するのは国内で開発するよりもコストを抑えられます。では、オフショア開発の事前にどんなオフショア開発の見積もりをしましょうか。

見積もりに記載されるコストの内訳

設計費用

設計費用は、開発プロジェクトの目的となるシステムや成果物について、ブリッジSEやプロジェクトマネージャー（PM）がクライアントと充分に相談し、設計書を創作するための費用です。また、設計書の内容を現地の言語へ翻訳するための費用なども含まれます。

管理費用

管理費用は、実際の開発をブリッジSEやPMが管理していくための費用です。また、定期的な報告や、急な仕様変更・トラブル発生時の対応などにかかる費用について含まれることもあります。

人件費

エンジニアの人件費相場が安ければ安いほど、コストメリットは大きくなります。反面、日本人エンジニアの人件費とあまり変わらなければ、むしろ翻訳料といった諸経費の分、オフショア開発をすると損になる場合も考えられるでしょう。

見積もりでは、人件費は必要なエンジニアの単価と、開発にかかる工数（人数・期間）によって計算されます。

その他の費用

写真やイラストなど素材購入費や、サーバー管理費、適切なコミュニケーションを維持するための通信費用など、他にも様々なコストが発生できます。

見積もり額を抑える方法

オフショア開発ではエンジニアの数を考慮する

エンジニアの数が多い大規模案件ほど、オフショア開発でコストを抑えられます。とはいえ、エンジニアが多くなれば全体管理も難しくなるため、リスクに備えることも考えなければなりません。

諸経費を自社でカバー

例えば、自社に現地人と充分にコミュニケーションできる人材がいたり、開発に必要な画像素材などを自社で提供したりできれば、人件費以外のコストを削減することができます。

ラボ型開発でリスクに具える

仕様変更が発生した時、改正費用が追加で発生する可能性もあります。そこで、一定期間、現地に専属の開発チームを設けるラボ型開発を活用することも有効です。

ですが、開発時間が延長すれば総額も高くなるため、せっかくのエンジニアを無駄に遊ばせないよう工夫が大切です。

まとめ

オフショア開発のメリットや目的を考える上で、見積もりを正しく取って検討することが欠かせません。

しかし、見積もり額の安さやコストメリットだけを追いかけて、開発品質を劣化させたりリスクを抱えたりすれば本末転倒です。

適当な会社を選択できるために、見積もり額に基づいて、事前にきりっと点検し、多角的に考えていくことが大切です。
… Read more

2020-03-04

コロナウイルスの背景におけるテレワークの問題

新型コロナウイルス対策のため、多くの企業でテレワーク・自宅勤務化が急ピッチで進められている。終わりが見えないコロナ騒動を受け、突然の「一斉総テレワーク化」に徐々に舵を切り出したようにも見える、日本の企業社会。浮かび上がる問題点や解決策はどこにあるのか。日本テレワーク学会会長や政府の推進委員会を歴任し、多くの企業の導入例を分析してきた東京工業大学環境・社会理工学院の比嘉邦彦教授にコロナウイルスの背景におけるテレワークの問題について聞いた。

「テレワーク自体にセキュリティリスク無い」

テレワークで企業側が特に神経をとがらすのがセキュリティ問題だ。ただ、比嘉教授は「実は、これまでテレワーク化が進んでいない企業ほど、セキュリティ問題が上位に浮上するもの。テレワークそのものがセキュリティのリスクを増大させることはあり得ない。そうした企業は普段からリスクが存在している可能性があり、（テレワーク実施時に）それが顕在化するだけ」と指摘する。

例えば、比嘉教授が挙げるのが社内データのアクセス権の対象・範囲などに代表されるセキュリティの「レベル」だ。「セキュリティにも階層があって、（誰が）どこまでアクセスできるかなど何段階にも分けなくてはいけないが、テレワークが進んでいない企業ほどそれをやっていない。怖がって、セキュリティ対象でないようなレベルの物に対してもパスワードをガチガチに固めてしまう傾向にある」。

それでもあり得る、情報漏えいの盲点

過度にセキュリティを保護してしまったテレワークのシステムは、在宅業務を確実にやりづらくする可能性を孕む。同時に比嘉教授が危惧するのが、「自社のシステムが使いづらいと感じた従業員が、個人で勝手に仕事のデータのやりとりを“工夫”し始めた際の情報漏えいリスク」だ。

「テレワークで（データのやりとりなどが円滑に）できない状況を、個々人が勝手な判断で『できる』ようにするケースも出てくるのではないか。例えばネット上で無制限に会社の機密データのやりとりをし始めたら、ハッカーに狙われる可能性もある」（比嘉教授）。これらの背景にあるのは、社員に対する教育の甘さやシステムの不備など、あくまで平時にも存在していたセキュリティリスクだという。

現場の従業員だけでなく、彼らをマネジメントする管理職側も戸惑う可能性が高い、と比嘉教授は推測する。「彼らの多くは『テレ（＝遠隔）マネジメント』をやってきていないはず。急に部下が目の前から消えてしまったマネジャーに対するサポートを企業側は考えるべきだ」。対面ではできていたコミュニケーションが、文字だとできなくなる上司も少なくないためで、こうした地味なマネジメントの工夫もテレワークには必要になりそうだ。

「耐え忍ぶ」より次につながる「評価」を

SNS上ではテレワーク体制の不備に対する不満や批判など、さまざまな議論が既に発生している今回の騒動。比嘉教授は「（今回の緊急）テレワークを企業も従業員も“耐え忍ぶ”のでなく、むしろ『実際にできたこと』『できなかったこと』を明らかにし、その原因について分析してほしい」と提言する。「今回、各企業が分析したテレワークの問題点を国がまとめ、ノウハウとして共有するといった試みがあれば、今後の推進に弾みをつけるチャンスになる」

テレワークの「コスパの良さ」ちゃんと評価を

むしろ今回、テレワークの『効能』が明らかになりそうな事例として比嘉教授が挙げるのが、「コスト面の評価」だ。従来、多くの企業でテレワークは一部の従業員にとどまっていた。「もともとテレワークは（職場の一部分だけの運用のため）コストに見合わない物だったと思うが、（今回の騒動で）全従業員が参加すれば、相当なオフィス縮小などのコストカットにつながるだろう。そういったテレワークの（ポジティブな）コスト評価もできるかもしれない」。

多くの企業で、雪崩のように広がっているテレワーク化の動き。「日本は何かのきっかけで『一斉にやるぞ』となると、右向け右でみんなが動く国。それが正しい『右向け右』になるよう、今回のテレワーク実施の分析結果は1社ごとでなく、全体で共有すべきだ」（比嘉教授）。
… Read more