ITごはん

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

ペーパープロトタイピングで成功する5つのポイント

はじめに

10年以上前の話になりますが、 当時所属していたSIerで、周りで出来ると噂の先輩エンジニアと2人で組んで、 提案+要件定義を行うという作業をしたことがありました。

当時はアジャイルだの、UXなんて言葉はなかったのですが、 社内では「HTML紙芝居」と呼ばれていた手法で、 プロトタイピングを行い、スピーディにユーザーとコミュニケーションをとっていました。

この「HTML紙芝居」とは、その先輩エンジニアが紙ベースで、画面のイメージを作り、 その画面イメージについて、ひたすら業界経験の浅い私がHTMLのタグを打っていくというものでした。 (画面遷移のリンクや、本番に近しいデータもベタ打ちで書いていました) 当時、毎週で何十枚、何百枚というHTMLを作成する苦行だったことを覚えています。

この方法は 後続工程(設計・コーディング〜)の段階になっても、 完成品のイメージをしっかりと擦り合わせができていますから、 手戻りも少なくユーザー・開発サイド両方でかなり評判が 良かったため、プロトタイピングの威力を身をもって実感しました。

さてさて、今回はそのようなプロトタイピングの中でも、 HTML紙芝居より更にスピーディで、最近流行りの紙のみで行うペーパープロトタイピングの ポイントについて整理してみます。

ペーパープロトタイピングとは何か

まず、ペーパープロトタイピングですが、 これは、紙に鉛筆書きで、ラフに画面イメージを書くことで、 完成品をイメージするというものです。 主に企画や、上流設計のタイミングで実施されることになります。

【ポイント①】スピードとコミュニケーションを重視する

プロトタイピングは、基本的にスピードを重視して下さい。 1日に数十枚の画面を作るぐらいのスピード感だと考えて下さい。

そして、早めにチームやユーザーと共有することです。 基本的にはペーパープロトタイピングでは、 スクラップ・アンド・ビルドです。 書いては、書き直し、書いては、書き直しを 行うことが、企画のブラッシュアップにつながります。 ですので、はやめにチームやユーザーと コミュニケーションに共有することが重要です。

【ポイント②】細部にこだわらない

例えば、フォントの大まかなサイズ感は決めたとしても、 具体的に何ピクセルかなどについては、ペーパープロトタイピングでは 深入りしません。

ペーパープロトタイピングの位置づけにもよるのですが、 後続作業で仕様書を作成するような場合では、 こういった細部は必要ありません。

もっというと、細部について記載してしまうと、 全体観を掴むという目的を阻害してしまします。 (議論の中で、そういった細部が議論の中心になってしまいます。)

【ポイント③】全体的な流れをしっかりつかむ

時折、一部の画面だけプロトタイピングするようなやり方が見受けられますが、 基本的には、もちろん、ラフなイメージで構いませんので、 全画面や、出来るだけ網羅的にアニメーション・シナリオを作成してください。

逆に、一部の画面では正しいことが、全画面でみたら、正しくないなんてことが 十分起こりえますので、しっかり全部の画面を作成してください。 ここで手を抜くと、プロトタイピングの意味がないぐらいです。

【ポイント④】便利なWebサービスを使わない

プロトタイピング用のWebサービスがいくつかありますので、 そちらをつかっている人も多いと思います。 賛否両論あるかと思いますが、これは使用しないほうがいいです。

一番大きな理由は、ペーパープロトタイピングの スピード感が失われてしまいます。 また、最初から用意されている機能やオブジェクトを、 使用しないような場合は、特にスピードが落ちてしまいます。

また、電子データとして、必要でしたら、 紙に書いて、スキャンしたほうが早いです。

【ポイント⑤】実際に見る画面サイズをベースにする

ペーパープロトタイピングを行うときに、 実際の利用する画面サイズをベースにして下さい。

思いの外、スマートフォンの画面は小さく感じることが多いですし、 大きい画面であれば、目線の動く距離なども、チェックすべき観点です。

終わりに

ペーパープロトタイピングのポイントは、スピーディに、ユーザー・チームメンバーと、 効果的にコミュニケーションをとるために、作成するのが要点です。 この点を抑えると、その有効性を実感できると思います。

ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする

ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする

Monacaでハイブリッドアプリ開発をおすすめする5つの理由

[iOS/Android対応] HTML5 ハイブリッドアプリ開発[実践]入門 (Software Design plus)

[iOS/Android対応] HTML5 ハイブリッドアプリ開発[実践]入門 (Software Design plus)

最近のHTML5アプリがアツい

HTML5アプリは、 当初の注目がFacebookなどの失敗により、一気に意気消沈してしまいましたが、 最近はまた、エンジニアたちの熱い視線を集めています。

背景には、圧倒的にスマートフォンの高機能化により、 過去において課題であった、レスポンスの問題をクリアしたことが挙げられるでしょう。

その中でも、HTML5アプリ開発に、手軽で便利なMonacaを紹介してみようと思います。

https://ja.monaca.io/

さて、Monacaってなんでしょうか、ということですが、 次のような特徴があります。

- Webサイト(ブラウザ)から利用できるHTML5ハイブリッドアプリ専用開発環境
- 実機のテストは、専用デバッガーにより実行可能
- OnsenUI(CSSフレームワーク)やAngularJSベースの開発ができる
- ほかにもローカル環境からホットデプロイできるツールや、ソースコード暗号化やエンタープライズ向け機能もあり
- 3プロジェクトまで無料で利用できる
- 実績も多数

それでは、Monacaの推しポイントを5つみて行きましょう。 ちなみに、私とMonaca開発のアシアル社は何の関係もございません。

1.環境構築がラクちん

いざ、iOSAndroidアプリを開発するとなった場合に、 ハードルになるのが開発環境の構築です。 何個もSDKをインストールして、EclipseなどのIDEをインストールして、、、 そして、開発環境がすんなり動けばいいですが、 なぜか、書籍やネットの情報どおりにやっても、 動かないよ!なんて声は良く聞きます。

安心して下さい。Monacaなら、ブラウザでサイトにアクセスするだけです。

そして、Monacaデバッガーという秘密兵器がありますから、 すぐに実機で試すことができます。 例えば、iOSであれば、お手持ちのiPhoneから、 AppStoreからMonacaデバッガーをインストールして、 自分のMonacaアカウントでログインするだけです。

2.安心の日本語環境と、豊富なサンプル

冒頭でも言いましたが、Monacaは国産です。 ですので、日本語情報完備です。(もちろん、英語もありますよ) また、公認の書籍もあります。

そして、手早く動くものを作りたい、というのはエンジニア共通の願いかと思います。 Moncacaであれば、OnsenUIコンポーネントサイトを訪ねて、 気に入ったUI部品のソースコードをコピペするだけです。

http://components.onsen.io/

3.AngulerJSで安心設計

HTML5アプリを作成する際にまず、頭を悩ますのは、 どういった構成にするかではないでしょうか。 MonacaのOnsenUIはAngularjsに準拠しています。 (なお、OnsenUIはjQuery風に書くことも可能です)

Angularjsは、javascript界隈でもっともアツい フルスタックフレームワークです。

最初は少々、学習コストがかかりますが、 構造的な全部入りフルスタックですから、 慣れれば、かなりのスピード感をもって開発することができます。 また、Angularjsは、ネット上も情報が豊富です。

4.10年後も使える技術で安心

HTML5は、HTML+CSS+JavaScriptで構成されることはご存知だと思います。 これらは、現在のWebサイト・システムの標準技術で、 今も進化しています。これらが今後10年置き換わるということは、考えにくいです。

そして、うれしいことに、AltJSの最右翼であるMonacaはTypeScriptにも、 対応しています。 TypeScriptは、CoffeeScriptなどとは違って、見た目はほとんどJavaScriptの雰囲気で、 静的型付けが導入され、クラスベースのオブジェクト指向言語として、 ストレスフリーに記述することができます。 (個人的にはJavaと同じような感覚で書くことができます。)

今後のJavaScriptの仕様であるECMA Script6の仕様を先取りしていますから、 予習にも役立ちますから、TypeScriptで学んだことは今後も利用価値が高いです。

また、Monacaが廃れたとしても、類似のHTML5ハイブリッドアプリプラットフォームに 移ることは非常に容易に可能です。 Monaca自体がPhoneGapをベースにしていますし、 OnsenUIベースで開発している場合は、IonicFrameworkなんかもほとんど同じです。

5.HTML5アプリでコスト削減

最近のアプリ開発のコストは全体的に増加傾向にあります。 それに対して、HTML5アプリは既存の標準技術をベースにしていますから、 経験的には3〜5割ぐらいのコスト削減が可能です。

さいごにポイントを

以上、Monacaのいいところを挙げてみました。 確かにHTML5アプリはデメリットもあります、 困難な課題もなくはないです。( ただし、いずれも工夫しだいで乗り越えることが可能でしょう)

設計開発のポイントは、ネイテイブアプリの模倣をしないことだと思います。 ネイテイブアプリと同じような動きに、こだわると自ずとしんどい場面に出くわします。 ここは、発送の転換をいて、いくらでもアイデアが落ちているWebサイト・システムを、 参考にデザイン(設計開発)していいけばいいと思います。

ぜひ、Monacaを一度触ってみることをおすすめします〜

システムの信頼性の基礎知識

f:id:HIDEKIT:20150430191441j:plain

信頼性の指標

システムの信頼性とは一言で言えば、 システムが壊れず使えるかの度合いです。 以下の3つの信頼性の指標を覚えましょう。

・MTBF(Mean Time Between Failure:平均故障間隔)とは、
故障が回復してから次に故障するまでの平均時間です。長いほど信頼性が高い。
・MTTR(Mean Time To Repair:平均復旧時間)とは、
故障が発生したときに復旧に要する平均時間です。短いほど信頼性が高い。
・稼働率=MTBF/(MTBF+MTTR)

信頼性を上げるための設計(信頼性設計)

それでは信頼性を上げるためには、どのような設計が有効でしょうか。 例を挙げてその考え方を整理しましょう。

フェールセーフ

障害が発生した際の被害を最小限に抑える設計思想です。 身近な例では、石油ストーブが転倒すると自動的に消火するなどです。 他に、作業範囲に人間が入ったことを検知するセンサが故障したとシステムが判断した場合、 ロボットアームを強制的に停止するといった設計もこのフェールセーフになります。

フォールトアボイダンス

故障が起きないようにするという考え方は、フォールトアボイダンスといいます。 例えば、一部機能の障害によってシステムが停止しないよう、ハードウェアやソフトウェアを十分に検証し、 信頼性の高いものだけでシステムを構成する方法です。

フェールソフト

たとえ、障害がおきても、大きな問題がないようにする方法がフェールソフトといいます。 例えば、クラスタ構成のシステムにおいて、あるサーバが動作しなくなった場合でも、 他のサーバでアプリケーションを引き継いで機能を提供する。

フールプルーフ

利用者は間違うということを前提として、もし間違いが起こってしまっても 問題がおこらないようにする考え方がフールプルーフです。

例えば、電子メールでの返信が必要とされる受付システムの入力画面で、 メールアドレスの入力フィールドを二つ設けて、同一かどうかをチェック機能や、 アプリケーションを間違って終了してもデータを失わないように、 アプリケーション側の機能で編集中のデータのコピーを常に記憶媒体に保存するようなケースです。

発注者・エンジニアが知っておきたい法律知識

これ1冊でわかる 契約書の読み方・つくり方 新版 CD-ROM付

これ1冊でわかる 契約書の読み方・つくり方 新版 CD-ROM付

システム開発に必須の法律論

システム開発ももちろんビジネス活動ですから、 法律知識は必要となってきます。 なかでも重要と思われるのは、以下です。

- 契約法(民法)
- 知的財産権
- 労働者派遣法

契約法(民法

請負、委任といった契約形態や、瑕疵担保、損害賠償などを契約書に定める際に必要な知識となります。 具体的なポイントは以下エントリーを参考にして下さい。

http://hidekit.hatenablog.com/entry/2015/03/31/090000

http://hidekit.hatenablog.com/entry/2015/03/31/223000

知的財産権

イデアや新しく発明された方法などに財産的価値を見出し、 それを守るための権利を知的財産権といいます。

知的財産権のうち、特許庁が定める産業財産権は、以下の4つです。 ・特許権: 特許権者に発明を実施する権利を与え、発明を保護する。 ・実用新案権: 物品の形状等に係る考案を保護する。 ・意匠権: 工業デザインを保護する。 ・商標権:文字、トレードマーク、サービスマーク、商標に関するブランドイメージを保護する。

また、著作権法では「思想又は感情を創作的に表現したものであって、文芸、学術、美術又は音楽の範囲に属するもの」(著作物)を保護対象とします。 上記の著作物に含まれるものは他に文書、絵画、写真、映画、演劇、プログラムなどがありますので、 ソフトウェアの知的財産権は、著作権法により定められています。

労働者派遣法

請負とは、仕事の一部、またはすべてを別の会社に委託することです。 委託先の従業員は、委託先(受託者)の指揮命令のもとで業務に従事します。 休憩時間や勤務日など勤務形態に関するルールは、 発注者ではなく受託者自ら自社の従業員へ指示を行います。 これらの指示を発注者側が行うことは、 請負契約ではなく労働者派遣とみなされます。

【RFP作成の作り方②】RFP作成の事前リサーチ

事例で学ぶ RFP作成術実践マニュアル

事例で学ぶ RFP作成術実践マニュアル

前回はRFP作成の流れをについて説明しました。 今回は、RFPを実際作成する前に行う、 リサーチについて説明します。

RFP作成チームを立ち上げる

システム構想・企画を、さらに具体化するためには、

企画検討チーム≒RFP作成チームの立ち上げを行うと良いでしょう。

そして、RFP作成チームのメンバーは以下のような人が良いでしょう。

- 今回のシステム投資の遂行に責任を持つ人
- 利用部門のキーマン
- システム部門のリーダー
-

このチームがシステム企画の中心になります。 (多くの場合は、企画後の開発・導入においても中心的な役割を果たすことは 有効です)

RFPの事前リサーチの基本

RFP作成チームが立ち上がりましたら、 次に行うことは、RFP作成前の事前のリサーチです。

ここで収集しておきたい情報は以下です。

- 1.対象とするシステム
- 2.対象とする業務知識
- 3.上記を実現するための技術

リサーチの基本はインターネットでしょう。 まずは、上記の項目について、 スピーディに網羅的にリサーチして下さい。

この段階では、粗くてかまいません。

次に、インターネットは情報に偏りや、 信頼性、また深さが足りませんので、 書籍やセミナーや展示会などから、 より情報の精度を高めていって下さい。

社内ヒアリング

次に、リサーチしたことを頭に入れておきながら、 社内ヒアリングを実施します。

基本的には、その開発予定とするシステムの利用部門が 主なターゲットとして、ヒアリングとなります。

上記の事前リサーチを経ずに社内ヒアリングを行う場合は、 注意して下さい。

利用部門の考え方に引っ張られてしまったりするためです。

また、利用部門は新しいシステム導入によってもたらされる、 ビジネスプロセスの変更を嫌うケースも多々見受けられます。

例えば、新システム導入で複数あった帳票をまとめて、 ペーパーレス化を行おうといった際、 これまで使い慣れた帳票が出ない、出せないといった、 改革には抵抗されることが多いです。

RFP作成チームに求められるのは、 こういった問題に対して、 客観的に、かつ、会社や経営の視点から、全体最適なシステムを企画することになります。

リサーチのまとめ

上記の作業の中で、情報や要求を整理しておきます。 この時点で、要求の優先度や、影響度、削減できるコストなどを 目安として整理しておきましょう。

次は、実際にRFPに盛り込む内容について説明します。

抑えておきたいIT・システム開発の基本用語①

読んでわかるIT用語の基礎知識 (プレイブックス)

読んでわかるIT用語の基礎知識 (プレイブックス)

カタカナ言葉にご注意を!

コンサル業をやる中で、個人的には、 日本語として浸透していないような 横文字・カタカナ言葉による説明は 出来るだけ避けるように意識しています。

なぜかというと、まずわかりにくいですし、 相手を選ぶような用語の選択は、 コミュニケーション品質が落ちるからです。 また、ほとんどの場合、すんなり日本語に置き換えることができます。

(その意味で先人が、外来語を輸入し、適切な日本語を当てはめたり、 新しく造語したりした努力には頭が下がる想いです)

一方、カタカナ言葉を乱発することで、 自分の専門性をアピールすることや、 相手を煙に巻くことに使う人も多いで気をつけて下さい。

※ 大したことを言っていないのに、 素人が聞くと、カタカナ言葉でさも、なにか凄いことのように 感じられてしまう。

ただ、コミュニケーションの双方が理解していることであれば、 カタカナ言葉を使いこなせることで、 ユーザーサイド、開発サイドのコミュニケーションギャップを防ぎ、 また、効率的・効果的にコミュニケーションが成立することもあるでしょう。

そんなわけで、システム開発の基本用語の基礎を不適連載で説明していきます。

バズる

英語の「Buzz」という言葉で、うわさ話が立つといった意味があります。 インターネットのソーシャルメディアTwitterFacebook、ブログ)などで、 爆発的に注目をあつめている事柄を指します。 「インターネットで流行っている」ぐらいの意味と考えれば、間違いありません。

また、意図的にバズらせることも、炎上マーケティング、バズマーケティングと呼ぶことがあり、 今や多くの企業が販売促進の手法の一つとして、バズらせようとしています

ペルソナ

ペルソナは元々、仮面という意味をもっていますが、 主にマーケティングにおいて、ターゲットとする顧客の属性を定めたものをいいます。

例えば、ターゲットを「2〜6歳までの子供を持つ、働く女性」など、 具体的にターゲットを決めることで、

マネタイズ

収益化する方法。スマートフォンアプリを例にとれば、 広告で売り上げを立てるとか、課金アイテムで売り上げを立てるとか、 そういった手法をいいます。

ローンチ

Webサービススマートフォンアプリなどを、公開することを指します。 一昔前は、リリースという言い方をしていましたが、 ローンチもよく聞くようになりました。

アジェンダ

会議・打ち合わせにおける議題を指します。 アジェンダを記した紙を1枚用意しておいて、 それを見ながら、会議を進行することで、 議論すべきテーマを忘れることを防いだりします。

アサイン

任命や参画するという意味です。 具体的には、Aさんが○○プロジェクトにアサインされた、みたいな使い方をします。

アジャイル

言葉自体は「俊敏な」といった意味で、素早く、というのとほぼ同じです。 また、システム開発において、素早く企画・製造・テスト・リリースを繰り返す、 ような開発手法をアジャイル開発といい、近年取り入れるプロジェクトが増加傾向にあります。

エビデンス

証拠という意味になりますが、実際は裏付けをする資料といったニュアンスになります。 システム開発においては、テストを実施した結果として、 そのテスト結果を記したテスト仕様書や、システムのアウトプット(表示された画面や、データなど)を エビデンスとして使用したりします。

【RFP作成の作り方①】RFP作成の流れ

RFPとは

RFPとは何かということですが、

まず、RFP(提案依頼書:Request For Proposal)とは何かということですが、 システム開発・委託を予定しているユーザー(発注者)が、 開発依頼先となるベンダー(システム開発会社)を見つけるために作成する、 必要としているシステムの概要や予算、その他条件が記載された文書を指します。

ポイントとしては、

- どんなシステムを (概要、要求)
- いくらで (予算)
- いつまでに (スケジュール)

がコンパクトに整理されていることが重要です。

近年では大手企業や政府系等では、 そシステム部門や、企画部などが中心となって、 RFPを作成することが一般的になってきております。

それでは、今回はRFP作成の大きな流れを説明していきます。 RFPにどんな内容を記載すべきかと言った点は、 次回説明します。

RFP作成のプロセス

それでは、RFP作成はどのようなプロセスで構成されるでしょうか。 システム開発全体の中で位置づけも含めて確認しましょう。

f:id:HIDEKIT:20150427190935p:plain

RFPが作成されるのは、 システム構想・企画フェイズと呼ばれる システム開発の最初のフェイズになります。 さらに、RFP作成は以下のプロセスに分割されると考えて下さい。

1 リサーチ
2 RFP作成
3 提案依頼
4 提案評価

1.リサーチ

まずは、システム構想・企画が行われたところで、 リサーチ(情報収集)を行います。

これは、社内向け、社外向けそれぞれ行われます。 社内向けでは、実際の利用者であるエンドユーザーに向けて、 ヒアリングを行い、要望を吸い上げます。

また、ポイントとしては、現行システムでの感想や改善要望を 各員すると、要望が整理しやすいです。

社外向けでは、 インターネットや各種セミナー・展示会などで 依頼するベンダーの候補や、同業他社の動向や、 また、技術的なトレンドなども可能な範囲で調べておきます。 そして、社内システムではなく、外に向けたBtoCサイトなどでは、 マーケット分析も行います。

また、ベンダー(システム開発会社)に対してRFI(情報提供依頼書:Request For Information)を提示することもあります。 RFIを作成する際は、要求を明確にして、その要求を実現するための技術や、 それに必要な予算等の情報を得られるように、質問形式にします

2.RFP作成

リサーチで収集した情報をもとに、 RFPの作成を行っていきます。 RFPは冒頭の3つの要素を満たすように、 網羅的に記述します。 RFPに盛り込むべき内容、書き方の詳細については 次回、説明します。

3.提案依頼

RFPの作成が終わると、それを 候補となっているベンダーに送付し、提案を依頼します。

送付するベンダーの数については、 経験的には、3〜5ぐらいが適切でしょう。 (もっと言うと、それぐらいの数に絞れるようにリサーチの段階で、 情報収集する必要があります)

多数のベンダーに対して、送付するようなケースがありますが、 多くなればなるほど、提案評価の作業で苦労しますので、 そのことに留意する必要があります。

4.提案評価

提案依頼に対して、ベンダーより提案書を受領し、 プレゼンテーションをしてもらいます。

提案書、プレゼンテーションの内容から、 提案を最終的に評価することになります。

評価に当たっては、提案評価書などを社内向けに作成し、 社内レビューを行うのが一般的です。