ITごはん

ITを活用したい人、ITで何か作りたい人、そんなITでごはんを食べる人のためのブログ

幼児向けアプリ「どうぶつなあに」をリリースしました。

立ち上げに参画している新会社より、 第一弾 幼児向けアプリ「どうぶつなあに」をリリースしました。

f:id:HIDEKIT:20150425123629j:plain

人気の動物を題材にした、クイズ形式の知育アプリです。
クイズに答えて、リアルな動物の動きと鳴き声をお楽しみ下さい。
動物たちの簡単なトリビア(おもしろ豆知識)も学ぶことができます。
操作は簡単、広告表示も無いので小さなお子様でも安心して、すぐにお遊び頂けます。

子供向けにとらわれないリアルな描写と音声(鳴き声)に こだわったアプリになります。 ぜひ、手にとって触ってみて下さい。

また、感想やアドバイスについて頂けたら、幸いです。 (キッツい感想、大歓迎です!!)

iPhone https://itunes.apple.com/jp/app/doubutsunaani/id956804277?l=en&mt=8

Android https://play.google.com/store/apps/details?id=com.anyware.animal

あと、新会社は「株式会社エニウェア」といいます。よろしくお願いします。 http://anyware-inc.com/

RFP作成の4つのメリット

はじめに

最近では、システム開発に先立って、 RFP(提案依頼書:Request For Proposal)を作成することが多くなりました。 RFPをうけとったベンダーはこれをもとに、提案書を作成することとなります。

ただし、RFPの作成は相応の労力が発生します。 RFPを作成せずとも、ベンダーの営業を呼び出して、 口頭で要件を伝えることでも、提案書を作成して持ってきてくれるでしょう。

それではRFPを作成するメリットとはなんでしょうか? 今回はそのメリットを考えてみたいと思います。

メリット1.社内におけるシステム投資の方針を明確にし、合意を形成する

これから始まるであろう、システム開発プロジェクトの成功は、 システム部門・担当者だけの力でなし得るものではありません。 実際の利用部門であるエンドユーザーや、経営者の強いコミットメントがあって、 初めて成功の確率が上がってきます。

RFPを作成するタイミングで、関係者に十分ヒアリングや、 プロジェクト協力の根回しをすることで、 スムースにプロジェクトの協力体制を構築できるでしょう。

メリット2.ベンダーの提案のレベルを上げる

RFPによって、要求が明確されていることによって、 一般にベンダーの提案のレベルが1段上がります。

これは身近な例でも分かりやすいのですが、 「何か美味しいお菓子買ってきて」と依頼するよりも、 「ミスドのクリーム系のドーナツを何か買ってきて」と依頼する方が、 あなたの要求に近いもの、満足できるものが得られる可能性が高まるのと同じです。

(もちろん、あなたがミスドのクリーム系のドーナツが好物だとしてですが。。。)

また、私はRFPには予算について明示的に記載することを推奨しているのですが、 予算が明示されることで、ベンダーは全体的にバランスのとれた提案が可能になります。

単純に顧客管理を一元化したいとしても、一元化したデータは、だれが、いつ、どこで登録や参照されるか、 こういったことを盛り込むことで、より適切な提案を望めるはずです。

メリット3.後続の要件定義フェイズの負担・リスクを軽減する

RFPが詳細に書けていれば、書けているほど、 後続のベンダーとともに行うであろう、要件定義フェイズが 楽になります。

RFPの時点で、ある程度要求が整理されているわけですから、 要件定義ではそれをベースにより、効率的・効果的に進めることができるでしょう。

メリット4.ベンダーを適切に評価できる

RFPを提示し、それをもとにした提案書を受け取ることで、 ベンダーの提案力や技術力を評価することが容易になります。

RFPでの要求の一覧と、提案書の提案の一覧を並べることで、 要求が実現できるか、事前に把握することができるでしょう。

もし、自社の望むことを本当に叶えてくれるベンダーであれば、 RFP記載の業務要求から、より適切で具体的な提案が帰ってくるはずです。

例えば、大手だからとか、有名だからといっても、 ベンダーの得意分野は様々ですから、 あくまで、開始しようとしているプロジェクトにマッチした ベンダーを見つけることが成功の近道であるのは、間違いありません。

 さいごに

RFP作成のメリットについて考えてみました。 以上のようにRFP作成には多数のメリットがあるとおもいます。

それではRFP作成のデメリットは何でしょうか? やはり、一つには労力・コストがかかることです。 しっかりしたRFPの作成には、しっかりと社内ヒアリング等の 計画をたて、関係者に時間をとってもらい、計画的に行う必要があります。 また、システム投資になれていない中小・中堅企業の場合は、

いざ、実際RFPを作成しようにも、細かい項目として何を書けばいいか 分からないという会社も多いです。 こういった場合は、外部のコンサルタント会社などを利用するのも十兆です。

(弊社もRFP作成支援は多数実績がございます)

90分で学べるRFPの作り方

90分で学べるRFPの作り方

JavaとJavaScriptの違いを分かりやすく説明する方法

エンジニアの面談をしていると、 「Javaは経験あるので、JavaScriptも大丈夫です」 なんて言われると困惑してしまうことがあります。

知っている人は知っているのですが、 JavaJavaScriptはともにオブジェクト指向言語ですが、 全然違います。

今回は、初心者や非IT系のかたにJavaJavaScriptの違いを簡単に説明する方法 を考えてみたいと思います。

JavaJavaScript

- インドとインドネシアくらい違う
- オーストラリアとオーストリアくらい違う
- メロンとメロンパンくらい違う
- ハムとハムスターくらい違う
- 宮崎県と宮城県くらい違う
- 酒井若菜と酒井彩名くらい違う
- 水野真紀と水野美紀くらい違う
- 陣内孝則と陣内智則くらい違う
- 森高千里と森下千里くらい違う
- 高橋克典と高橋克実くらい違う
- 峰竜太と竜雷太くらい違う
- 麻生久美子と麻木久仁子くらい違う
- 加藤あいと阿藤快くらい違う
- 鈴木亜美と鈴木えみくらい違う
- ASKAと泰葉くらい違う
- 矢田亜希子と和田アキ子くらい違う
- 稲垣潤一(歌手) と 稲川淳二(怖い話の人)くらい違う
- ピケティ(経済学者)とチャパティ(インド料理)くらい違う
- ピカタ(イタリア料理)とピタパ(PiTaPa。関西の鉄道系ICカード)くらい違う
- そうめんとひやむぎくらい違う
- アルジェリアとナイジェリアくらい違う
- 華氏と摂氏(20℃=68°F)くらい違う
- グラニュー糖とブランニューデイくらい違う
- ひつまぶしとひまつぶしくらい違う

さて、冗談はこれくらいにして、

JavaJavaScriptの違いを整理しておきます。 前者がJavaで、後者がJavaScriptです。

- クラスベースオブジェクト指向 vs プロトタイプベースオブジェクト指向
- 静的型付け言語 vs 動的型付け言語
- コンパイル必要 vs コンパイル不要(インタープリタ方式)
- 最初は サン・マイクロシステムズ社が開発 vs ネットスケープ社が開発

以前は、サーバーサイド言語(Webサーバで動作する)としてJavaが、 クライアントサイド言語(Webブラウザで動作する)として、JavaScriptが、 主に使用されているという役割的な違いがあったのですが、 JavaScriptがその活躍の場を広げ、サーバーサイドでも使用されますし、 スマホアプリ開発などでも利用されるようになりました。

【システム開発】システムを評価する6つの観点

最近はめっきり春めいて、過ごしやすくなってきましたね。

今回は弊社にも問い合わせ依頼の多い システム評価についてのエントリーです。

システム評価の観点を理解しておくことは、

 出来上がったシステムを評価する、
 構想しているシステムの要件・仕様を検討する

といった場合に非常に便利です。 それでは、システム評価に「つかえる」6つの観点を紹介します。

機能性

システムは当たり前かもしれませんが、 目的を持って開発され、運用されます。 機能性とは、そのシステムの目的を達成するために、 必要な機能を実装している度合いといえます。

例えば、顧客管理システムを開発したとします。 その顧客管理システムは、 顧客名簿より、名前での検索はできます。 ただし、顧客の出身地、年齢などは検索できません。 (それらの情報は保持はしています)

このような場合、顧客の出身地、年齢などを検索できる他のシステムと 比べて、機能性は低いということになります。

また、正確性もこの中に含まれます。 操作マニュアルなどにもとづいて、操作を行った際に、 正しく(不具合なく)、出力家かを返してくれるかも、 機能性の一部です。

信頼性

信頼性とは、システムが障害などでサービスを停止することなく、 正しく動作し続ける程度を示します。 また、障害が起きた際に、素早く修理し、サービスの提供を再開できるかも、 信頼性の一部となります。

また、一部が障害が起きても、システム全体が止まること無く、 その一部以外は正しく動作できることも重要です。(障害許容性)

具体的には、平均故障間隔や、平均修理時間稼働率(総稼働時間に対して、正しく稼働している割合) といった指標により、信頼性は図られることとなります。

使用性

使用性は一言でいって、「使いやすさ」となります。 単純にWeb画面が使いやすいとか、 その操作を習得するのが容易であるとか、 また、インストール(導入)が容易であることも、 使用性の要素となります。

また、近年ではスマホアプリや一般消費者向けのWebサイトなどでは、 ユーザーインターフェース(UI)や、 ユーザーエクスピリエンス(UX)といって、 ユーザーが直感的に、気持ちよく使いこなすことができる、 画面や操作の設計を行いましょうというトレンドが強くなっています。

使用性は、機能性や信頼性などの指標と違って、パッと見で分かります、 スマホアプリや一般消費者向けのWebサイトでは、 ユーザーはその短い時間で、そのシステムを使うか使うかどうか判断します。 そのことはつまり、他社との競争の際に、使用性が差別化要因となることになります。

効率性

効率性とは、そのシステムが目的を達成するために、 使用する資源量の効率をいいます。

たとえば、ある操作をして、その結果の反応が表示されるまでの時間(時間効率性)や、 ある機能を実行した際のCPUやメモリの消費量が、 少なければ少ないほど、効率が良いということになります。

保守性

システムは、開発に要する時間よりも、実際に使用される(運用される)時間の方が、 大幅に長いです。 この使用される期間において、保守(メンテナンス)がおこなわれるわけですが、 その保守のしやすさが保守性です。

例えば、何か不具合がユーザーから報告されたとします。 その場合、どこに原因があるか突き詰めないといけませんが、 その原因を発見しやすさや、 システムを修正や改良する際の、変更のしやすさが 保守性になります。

移植性

システムが開発される際は、そのシステムが正しく動く特定の環境が想定されます。 環境とは、そのシステムがWindowsで動くのか、スマホで動くのか、 日本語で動くのか、利用される場所はどこかといった、ものです。 移植性は、その当初予定の特定の環境を変更する際に、対応のしやすさを表します。

例をあげると、これまでWindows7で動いていたシステムが、 Windows8が登場し、Windows8でも動くようにするために、 変更を行う際の対応のしやすさが、移植性です。

これは開発の際に意識されにくいですが、 会社が継続的にそのシステムを利用・発展させていこうという想いがある場合は、 特に意識しなければいけません。 (移植性は捨てて、開発コストを抑えるという判断もあるかと思います)

さいごに

実は上記で挙げた項目はソフトウェア品質特性として、 よく知られているものになります。

より各項目の詳細は、以下のWikipediaが参考になるでしょう。

http://ja.wikipedia.org/wiki/ISO_9126

また、大企業では、より専門的にはシステム監査といって、 第三者(システム監査人)が、上記のような観点から、多方面から分析・評価することも行われます。

ソフトウェア品質特性は、知識としてだけでなく、 冒頭で述べたシステム構想・企画や、 仕様の抜け漏れをチェックする際にも、非常に使える観点ですので、 是非、利用してみて下さい。

アイデアの作り方の基本

はじめに

今や、アイデアを出すことが求められるのは、 限られた職業の仕事ではなくってきましたね。

一方、「私はアイデアマンではないから」と、 アイデア出しに拒絶反応を見せる人も多いです。

今回は効率よくアイデアを出す方法を考えてみたいと思います。

イデアの作り方

そもそも、アイデアってどうやって作るんでしょうね。 まずは古典的名著である J・W・ヤングの「アイデアのつくり方」から、 そのエッセンスを学んでみましょう。

J・W・ヤングは、アイデアを次のように断言します。

**アイデアとは既存の要素の新しい組み合わせ以外の何ものでもない。**

その上で、アイデアの作り方として、以下のプロセスが必要だと説きます。

1 データ集め
2 データの咀嚼
3 データの組み合わせ
4 発見の瞬間
5 アイデアのチェック

以上のことから、分かる重要なことはイデアはゼロから生み出すものではない ということではないでしょうか。 そして、この基本をベースにすれば誰でもアイデアは生み出すことが出来ます。

また、よくゼロベース思考なんて言葉も言葉もありますが、 この言葉の本来の意味は、既存のやり方にとらわれないようにしようという意味で、 データもない状態でアイデアを練り直そうということではないので、 注意しましょう。

ブレストの基本

次に、集団におけるアイデア出しの手法として、ブレインストーミングがあります。 略して、ブレストとよく言われていますね。

ブレストとは、集団でアイデアを出し合うことによって相互のやりとりの中で生まれる連鎖反応や 発想の誘発を期待するアプローチです。

ただし、ブレストは以下のようなルールがあります。 皆さんブレストとやろうと言いながら、このルールを忘れてしまい、 効果が半減してしまうこともよく見られますね。

- 批判しない: 他人の発言を批判しない、批判すると発言できなくなります
- 自由奔放: 自由に恐れずアイデアを出していきましょう
- 質より量: とにかく、多くのアイデアを出すことが重要です
- 連想と結合: 他人の意見を聞いてそれに乗っかって、アイデアを追加・改良していくのがブレストの醍醐味です

オズボーンのチェックリスト

オズボーンのチェックリストは、 既存のモノ・サービスを見ながら、また 思いついたアイデアを更に発展させるために、 非常に有効なアプローチです。

以下のチェックリストを順番にみていって、 アイデアの生み出しや改良を行ってみてください。

・他に使い道がないか?
・他に似たものをさがしてみたら?
・変えてみたら?
・拡大したら?
・縮小したら?
・置き換えたら?
・配置や並びを換えてみたら?
・逆にしたら?
・組み合わせてみたら?

そして、さらにオズボーンのチェックリストを発展させた、 SCAMPER(スキャンパー)法というものがあります。 これも以下のチェックリストをもとに、 アイデアの生み出しや改良を行っていきます。

- 入れ替えたら?
- 統合したら?
- 応用したら?
- 修正したら?
- 使い道を変えたら?
- 取り除いたら?
- 並び替えたら?逆にしたら?

ネットを活用

そして、アイデアは既存のものの組み合わせと考えた時、 インターネットは素材の宝庫です。

なかでもおすすめなのは、 Google画像検索です。

Google画像検索を行うと、多数の画像が一覧として出てきます。

画像は、文字に比べて、情報量が多く、インスピレーションが生まれやすいです。 ずらずらと並んだ画像ををもとに、 上記のチェックリストなども活用しつつ、 アイデア出しことで、1時間で数十のアイデアを出すことも容易です。

エレベーターピッチでアイデアをチェックする

いいアイデアが生まれたら、 今度はアイデアを評価してみましょう。

他人に評価をお願いするのも重要ですが、 以下の様なエレベーターピッチのテンプレートを用いて、 アイデアを評価してみましょう。

※ エレベーターピッチとは、シリコンバレーの起業家の間で一般的になっている 30秒などの短い時間で自分のアイデアのエッセンスを、投資家に伝えるプレゼン手法です。 (エレベーターで投資家に偶然会った際に、30秒で投資家を口説き落とすための方法というのが由来で、エレベーターピッチと呼ばれます)

以下の[]の中身を埋めていきます。

- [課題解決]したい
- [対象]向けの
- [アイデア・商品名]というプロダクト・サービスは、
- [カテゴリ]です。

これは

- [重要なメリット]ができ、
- [代替手段・競合]とは違って、
- [決定的な特徴]が備わっています。

[]が上手く、埋めることができれば、 そのアイデアは、実現に向けたステップに進むことが出来るでしょう。

一応、例を揚げてみます。 例えば、以下の様な形となります。

- [家族に栄養がある料理を提供]したい
- [時間がない働くお母さん]向けの
- [食材すぐ来る!]というサービスは、
- [食材配達サービス]です。

これは

- [配達されるカット済み食材やレシピによって、美味しい料理の調理時間が大幅に短縮]ができ、
- [定期配達である類似サービスB]とは違って、
- [電話一本で1時間以内に配達できるサービス]が備わっています。

さいごに

言うまでも無いですが、 現代社会のあらゆるものは 先人たちのアイデアの実現した結果といえるのではないでしょうか。 そう考えると、先人たちのアイデアには本当に感嘆させられますよね。

個人的にはアイデア出しはエキサイティングで、楽しいプロセスだと思います。 ぜひ、基本を抑えて、沢山アイデアを出してみてください。

【メンタルヘルス】ITエンジニアにおすすめ5つのストレス解消法

個人的にはITエンジニアは、他の職種・業界の方に比べて、 非常にストレスを抱えている人が多いように思います。

会社でもメンタルヘルス等と言って、対策はしていますが、 以下の様なストレスを誰しもが、 大なり小なり抱えているのでは思います。

- 長時間労働
- 人間関係(上司、同僚、部下)
- 顧客の無理な要求
- 多数の無駄な会議・打ち合わせ
- 納期や品質、コストに対するプレッシャー

また、以下のデータを見てもストレスフルな現状が浮き彫りになりますね。 http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=001324

社会人になると、 自分なりのストレス解消法を確立しないと、 誰しもが早晩、体調不調等やうつ症状の危険性がありますので、 ストレス解消法を見つけることは、 個人的には必須スキルだと思います。

というわけで、だれでも出来るストレス解消法を 紹介していきたいと思います。 個人的には効果があるのではと思います。

また、ストレス解消のために 「没頭できる趣味を持つといいよ」なんて、 言われても、趣味は急に持てるもんでもないし、 困ってしまいますよね。

そんな中で今回は、誰でも取り入れやすい、ストレス解消法を紹介します。

①銭湯・温泉・健康ランド

入浴は、かの昔からストレス解消方法の定番です。 近所にある銭湯・温泉・健康ランドに、 騙されたと思って是非いってください。

体の疲れも取れ、心の疲れも洗い流せます。 また、しっかり入浴・サウナに入ったあとの、 ビールはたまりませんね。

もし、外に行く暇がない場合は、 家で入浴剤なんかを入れて、温泉気分で じっくり入ってみてください。

②ウォーキング・ジョギング

運動嫌いな人も多いかもしれませんが、 ウォーキング・ジョギングも手軽にストレス解消できます。

短い距離、時間で、特にスピードは意識せず、 20〜60分ぐらい、運動するとだいぶ頭の中がすっきりするのが、 自分でも分かります。

ポイントは無理せずにやることが大事です。

③マッサージ・ストレッチ

少し時間があったら、30分や1時間でもいいので、 マッサージを受けにいくのはいかがでしょうか。

ITエンジニアは長時間労働で、腰や肩、首が 気づかない内にカチカチに凝っていて、そんな体の不調が、 心の不調に影響していることもあります。

マッサージを受けたあとは、気分が爽快になることでしょう。 私もマッサージを受けるのは好きですが、 やはり、体と心は繋がっていると、改めて思います。

④映画館・博物館

これは家を出て、映画館・博物館に行ってみてください。 家にいると、ストレスを抱えている状況では、 ついつい仕事のことを考えたりしてしまします。 映画館や、博物館に行くと、 もう観ること以外できませんから、 数時間を頭の切り替えができることはストレス解消に効果があります。

また、泣きたい気分なんてときは、 泣きたくなるような映画を見に行くのもいいでしょう。 涙をながすことが、ストレス解消に効果があることは、 科学的にも証明されています。

自己啓発書

次に、自己啓発書ですが、 これは一つ読み方があるんですが、 実行しなきゃという、気持ちで読むわけではなくて、

出来なくていいや、という気持ちで、 あくまで、心のサプリメントとして読むんですね。 これは心の健康を回復するのは効果があります。

おすすめの本を挙げておきますね。

・会社・仕事・人間関係で「もうダメだ!」と思ったとき読む本

会社・仕事・人間関係で「もうダメだ!」と思ったとき読む本

会社・仕事・人間関係で「もうダメだ!」と思ったとき読む本

・道は開ける

道は開ける 新装版

道は開ける 新装版

さいごに

どんなに頑張っていても、 ストレスが原因で体調を崩してしまったら、 元も子もありません。

そして、 2週間以上、気分が優れないような状態が続いた場合は、 気軽に精神科を受診してみましょう。

ちなみに、私の一番のストレス解消法は”お酒”です。 定番ですね。それでは。

【システム開発】発注者が信頼できるエンジニアを見極める5つの質問

コミュニケーションできる信頼できるエンジニアを探す

まず、エンジニアでない方が、エンジニアの技術力を測ることは非常に難しいです。

ですが、それは逆を言うと、技術力があるエンジニアであれば、 エンジニアの技術力を測ることは、割りと容易です。 その場合は、技術用語をベースに知識や経験を、質疑応答すればよいです。

※ なお、技術力のないエンジニアの場合ですと、 「わぁ、俺より凄い!」 だけで終わってしまいますので、この点は注意です。

もし、内部に技術がわかる人間がいないが、 エンジニアの技術力を測りつつ、 発注、業務委託を行いたいということであれば、 外部のエンジニアやITコンサルなどに依頼して、 同席してもらうことをおすすめします。

しかし、ITプロジェクトの失敗要因が、 技術だけということは稀です。

マネジメントや、目的・予算の失敗もありますが、 根本的にはコミュニケーションの失敗といった 問題が潜めています。

コミュニケーションの失敗から、 ユーザーとエンジニア(システム開発会社)の間で 信頼感が醸成されず、足並みが合わなくなり、 失敗するケースが多くあるように思います。

このようなケースを避けるため、 信頼できるエンジニアであるか見分ける質問のコツを紹介します。

見極める質問集

①一人で◯◯システムを開発するとき、自信を持って出来る範囲はどこまででしょうか。

エンジニアだけではありませんが、 自分の能力のアピールとして、 所属した会社や、参画してきたプロジェクトの規模やネームバリューなどで、 語る人がいます。

この質問は、その組織の功績ではなく、 本人がどこまでできるか、また自信があるか、を聞く質問になります。

②得意なプログラム言語は何ですか?その言語のメリットとデメリットを、ビジネス上の観点から教えて下さい。

この質問は、技術の選定を単純な自分の趣味趣向の問題ではなく、 プロジェクト成功の問題として認識しているかを、問う質問になります。

③顧客とコミュニケーションする際に、気をつけている点、失敗した点はなんですか。

エンジニアは対顧客と、対エンジニア(チーム)において、 コミュニケーションの仕方を変える必要があります。 ユーザーに技術用語を羅列するエンジニアをよく見かけますが、 このような態度はコミュニケーションの失敗でよくあるケースです。

また、失敗した点は、失敗として認識している事柄であれば、 それを改善しようと、どうしているかも併せて尋ねてみてください。

④過去に炎上したプロジェクトを経験していると思いますが、

そのプロジェクトで事態の収集に努めたときに、気をつけた点、苦労した点はなんですか。

開発プロジェクトはしんどい場面が必ずあります。 その際の粘り強さや、 そういった際に前向きに行動できるかを確認します。

⑤一緒に仕事をすることになった場合に、当方に望むことはなんですか。

プロジェクトの成功には、スキルや経験も当然大切ですが、 成功に向けた情熱や意志が不可欠です。

この質問は、一緒にプロジェクトを開始する際に、 同じ方向を向いているかの確認となります。

信頼できるエンジニアであれば、成功に向けて必要な事柄を要求してくるでしょう。

おわりに

上記は質問パターンを挙げていますが、 どう回答すれば正解というものもありません。

しかし、信頼できるエンジニアであれば、 上記の質問に対して真摯に向き合った経験がきっとあります。

そのため、きっとあなたが納得できるような回答をしてくれるでしょう。

ぜひ、面談の際のスパイスとして使ってみてください。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (36件) を見る