専修大学ネットワーク情報学部2年生の応用演習（コンテンツデザイン）の資料です。後半の方には、産技大での講義資料も追加してあります。上平崇仁作成。
KJ法の手順
専修大学ネットワーク情報学部2年生の応用演習（コンテンツデザイン）の資料です。後半の方には、産技大での講義資料も追加してあります。上平崇仁作成。
サービスデザインツールの目的と活用法
こんにちは。サービスデザイナーの佐藤 史です。 サービスデザインには、さまざまな専門的メソッドが存在します。サービスデザインの普及に伴って最近ではさまざまな書籍が発行されたりセミナーが開催され、皆さんが所属されている企業や団体の中でも実際にサービスデザインの手法を試みられたり、ツールを活用される機会も多くなっているのではないでしょうか。 しかし同時に、ツールを使うこと自体が目的化してしまったり、本来の意義を踏まえずにやり方の部分だけを表層的に真似してしまったりすることで、やってみたはいいけど効果や成果を実感できなかった、というようなケースも見受けられるようになってきました。 どんなに優れた手法・ツールであっても、使う局面や目的を間違えると、期待した成果は得られません。 そこで、本稿では、コンセントが普段関わっている多くのプロジェクトの中で、よく使われていて、かつ専門性の高い手法・ツールにつ
デザイナーのための自分サービス開発のススメ/ web service development tips for designers
2017/4/26 『渋谷開催！デザイナーLT＆交流会（BASE×ノハナ×マネーフォワード×みんなのウェディング）』 https://mwed.connpass.com/event/54099/ 発表資料
登場人物を分類し、振る舞いを分解して、機能を考える（企画職の人に教えてもらったこと） - $shibayu36->blog;
本職の企画の人が優れた機能案を出してくる理由がわからなくて、どうやってやってるんですかと雑談した。新たな発見があったので、雑なメモだけ残しておく。*1 その人の企画の流れ 企画の流れは、以下の3ステップで行っているらしい。 1. 登場人物を分類する 2. 登場人物ごとの振る舞いを分解する 3. 様々な振る舞いを照らし合わせて、機能・UIを絞り込んでいく 「1. 登場人物を分類する」は、機能に関わる人物をツリー構造に分類していき、分類をした結果から、その機能を使うメインターゲットを決めるフェーズらしい。 例えば、ブログユーザーをブログの作者と読者に、さらに作者を毎日更新する人とそうでない人に、みたいにどんどん分解していく。すると、機能のメインターゲットが浮かんでくる。 「2. 登場人物ごとの振る舞いを分解する」では、メインターゲットを中心に、どのような振る舞いをするかを考えるフェーズらしい。
Node.js(Express)とthree.jsで一通りウェブサイトつくって公開した記録(初心者向け) - Qiita
この記事はThree.js Advent Calendar 2016の10日目の記事です。 はじめに この記事は「初心者がThree.jsとか使ってなんとか簡単なウェブサイト作って公開した」記録です。なので内容は教科書レベルだと思います。 「Three.jsでとりあえず球体浮かべてみたけどその後何しようか自分でもわからない」「ExpressでHello Worldしてみたけどそれから何したらいいのか」という人の参考になれば光栄です。 Three.js Advent Calendarの記事の割にThree.jsに関係ないことが半分くらい占めそうです、すみません。 環境 さくらVPS (Apache 2.2.15) Node.js v6.5.0 Express v4.13.4 three.js r81 ちなみにローカルはWin10です。エディタはAtom、ターミナルはCmder、転送ツールはW
iOSエンジニアが考えるBtoBサービス開発の面白さ - Qiita
トレタ Advent Calendar 2016の12日目です。 はじめに 最近スタートアップでもBtoBサービスが盛り上がってきましたね。BtoB、BtoCと書くと読むのがちょっとつらいので以下、toB・toCと呼ぶことにします。 タイトルにはざっくりtoBと書いていますが、主にSaaS型toBサービスの話になります。また、toBサービスも意外と面白いんだよーという話であって、どちらが良くてどちらが悪いという話ではありません。僕もやっぱりtoCが面白そうだなって思うことは多々あります。友達が使ってくれてたりしたら最高ですよね。（誰かtoCの面白さについて書いてくれると嬉しいです） 面白いところ お客さんが一方向➡️ toCの悩みでよく聞くのが、ユーザーと広告主さんの両方を見なければいけないということです。使い勝手を考えると広告は無い方が良いですし、とはいえマネタイズを考えると載せないわけ
サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ（前編） - デジタル世代のものづくり - 岸田崇志のブログ
こんにちは！ 株式会社LITALICO CTOの岸田崇志です。 記念すべき『LITALICO Engineers Advent Calendar 2016』1日目の記事となります！ LITALICOでは現在『教育×テクノロジー』での可能性を広げるべく、チャレンジを広げています。 今回は、サービスを組み立てる話をしたいと思います。 1.はじめに タイプ別にみる失敗パターン 2.基本を理解しよう！ AARRR - Pirate Metrics（海賊モデル） 3. サービスのコンセプトを設計しよう リーンキャンバスを知る リーンキャンバスについて リーンキャンバスの使い方 （おまけ）KPIを設定しよう まとめ 5.次回は… 1.はじめに サービスを立ち上げの現場では戸惑うことが多いと思います。 特に初めての場合ははなおさらです。 サービスの企画を初めてやるときに、 どうやっていいかわからない。
最小限にこだわるサービス開発の試み - クックパッド開発者ブログ
こんにちは、検索事業部の原田です。クックパッドでプロダクトマネージャーとして検索領域を中心にサービス開発に携わっています。 サービス開発を成功に近づけるためのフレームワークやプロセスについては、書籍等で多くの知見が紹介されています。こちらのブログでもクックパッドの例についてご紹介をしてきました。 クックパッドで大事にしているサービス開発の取り組みのひとつに「仮説をスピーディーに最小限の形で確かめる」というものがあります。言うは易しなのですが、そもそも取り組むべき最小限の形とは？ それをどうやって見つけるのか？ やっとの思いで何かを見つけられたとして、その後最小限にこだわり判断し続けるには？ と、大変な困難が伴うと感じています。 今回は、サービス開発プロセスの中でも特に、どのように取り組むべき最小限の形を見つけ、最小限にこだわり続けながら開発を進めるのかについて、私が気をつけていること（気を
仮説検証とサンプルサイズの基礎 - クックパッド開発者ブログ
パートナーアライアンス部 森田です。有料会員の獲得施策や、それに関わるサービス内動線の最適化を担当しています。 記事の対象 仮説検証を通じて何かを改善をしたいと思っている人 仮説検証の際に「どれくらいのデータを集めたら良いか」分からない人 はじめに 仮説検証とは「仮説を立て、それを証明するためのデータを集め、真偽を確かめること」です。今回は仮説検証を行う際の手順と、その検証に必要なサンプルサイズの考え方を説明します。サンプルサイズの話のみ関心があるかたは、前半を飛ばし「サンプルサイズの決め方」を読んでください。 目次 記事の対象 はじめに 目次 仮説検証のつくりかた 1. 仮説をたてる 2. 施策/KPIを考える 3. 仮説検証後のアクションを決める 4. 対象を決める 5. サンプルサイズを計算する サンプルサイズの決め方 答えを先に サンプルサイズを決める二つの要素 「二つの平均値」と
インターンシップ「サービス開発演習」の舞台裏 - クックパッド開発者ブログ
こんにちは、投稿開発部副部長の勝間(@ryo_katsuma)です。 普段はクックパッドのレシピ投稿周辺のサービス開発を行う部署のマネジメントやエンジニアリングを担当しています。 さて、クックパッドでは、8月10日から先日9月2日まで技術インターンシップを開催していました。 講義全体のまとめについては、先日公開されましたこちらの記事を参照ください。 クックパッド サマーインターンシップ2016の資料を公開します Service Development at Cookpad 2016 summer internship 今回は、私が担当した4日目の講義「サービス開発」について、どのような狙いを持って設計したか、また参加学生の皆さんがどのような反応だったかなど、舞台裏についてご紹介いたします。 昨年の振り返りと課題 技術インターンシップにおいて、サービス開発の講義は昨年度も私が担当しました。
新サービス立ち上げ時の重要指標のデザイン - クックパッド開発者ブログ
こんにちは、株式会社ビットジャーニーに出向中の出口 (@dex1t) です。ビットジャーニーでは、社内情報共有ツール Kibela*1のサービス設計やプロダクトマネジメントに責任を持ちつつ、エンジニアとして開発全般に携わっています。 今回は、新サービスの立ち上げ時にどのような考えで重要指標*2を設計し、それを実際の開発のなかでどう使っていくかという話をします。 なぜ検証をするのか そもそもなぜ新サービス立ち上げ時に、重要指標や検証といった考えが必要になるのでしょうか。それを考えるにあたって、クックパッド的なサービス開発の流れを改めて整理してみます。 企画と検証は表裏一体 サービス開発といえば、企画・開発・検証をぐるぐる回すというのが一般的だと思います。指標は検証段階で活用する道具です。企画で考えたことを確かめるのが検証段階であり、企画と検証は表裏一体です。 したがって、指標の設計をするにあ
IT専門家に即役立つ極上アイデア発想法
現代は過去の延長でものごとを判断したり行動していては、思うように成果を出せない。求められるのは従来の秩序を壊す「イノベーション」だ。本稿ではイノベーションを実現する極上のアイデア発想法を厳選紹介する。 ［第24回］社会心理学者シーナ・アイエンガーが教えてくれた、「選ばないことを選ぶ」理由 人生はいわば選択の連続と言える。しかしいいのか悪いのか、情報過多の現代にあって、最大の満足を得ようとする人は、時として選択不全すなわち「選ばないことを選ぶ」場合が多々ある。これは製品を売る人々にとって深刻な事態だ。ここでは行動経済学の観点から「選んでもらう」ための発想術について考えたい。 2016.08.04 ［第23回］行動経済学が教えてくれる、売れない商品を上手に売る方法 売れない商品を売れるようにしたい。ビジネスに携わる人ならば誰しもこのように思っているに違いない。最も大切なのはニーズに合致した商品
ペロリ流 開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流 開発要件のまとめ方 開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。 今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？ パワポ ですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。 ちなみに、ペロリはカオスを楽しめる人を求めていますw 開発要件のまとめ方って色々あって難しい 私が学生の時に所属していた ベンチャー企業 では、数十MBもある パワポ に画面イメ
pelletkachels | blog over bedrijven en feitjes en de pelletkachel
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
2人で楽しくサービスやアプリを作る話
YAP(achimon)C::Asia Hachioji 2016mid in Shinagawa Talk 7/3 10:00- スライド資料です 子供のころは、秘密基地作ってる最中が一番楽しかったりしました。小さいサービスやアプリを2人で作るときに、企画・設計・開発を「2人で」楽しく進められるように、いくつかのサービスで行ってきた具体的な事例をベースに、簡単にできる方法を話します。 - アイスブレイク - ものづくりのフローを楽しく - ものづくりのフロー - ブレストの基本 - ホワイトボードの基本的な使い方 - スケジュール調整の基本 - イメージをすり合わせて一緒に形にしていく - リード・ファーストフォロワーを2人で使い分ける - アドホックペルソナと簡易シナリオ - リアルの時間を楽しく過ごす - メッセージやりとり - 開発合宿
アイデア出しのWEBアプリ - アイデア生産工場
アイデア出しに困っている人のアイデア生産ツールです。 アイデアを出したい単語を入力してみてください。
エンジニアが0からのサービス開発で学んだこと - クックパッド開発者ブログ
こんにちは、買物情報事業部の三浦です。 私たちのチームでは１つのプロダクトの開発が佳境を迎えています。 私は普段エンジニアとしてチームに所属していますが、今回はプロダクトオーナーとして開発に携わっています。そこで単に実装者としてだけでなく、初期のコンセプト立てやユーザーインタビューなどのプロセスを経て学べたことをご紹介します。 価値を見つけるところからスタート 普段のチームでの開発はディレクターが開発を伴わない価値検証を行った上で仕様を考えます。それを基に立てられたissueをエンジニアは引き継いで実装を進めています。issueに記載された施策の背景やユーザーストーリーから、ユーザーの利用シーンをイメージして開発します。 今回はその価値となるものを探す作業からディレクターと共に行いました。まずはユーザーインタビューを実施し、計10名以上の方からお話を聞きました。 課題をよりリアルに感じた
Web サービスは機能の多さで勝負してはならない - ボクココ
ども、@kimihom です。 近年はいろいろなサービスがあるが、サービス開発者の中で勘違いしやすいのが 「機能は多ければ多いほどいい」「他社サービスがこんなことやってるからウチもやらないと」「お客さんがこんなこと言ってるから実現しないと」 といった考え方だ。自分たちのサービスにその機能は本当に必要なのかを考えず、ただ闇雲に機能を追加していく。その行く先にあるのは「複雑で、誰も使いたがらないシステム」である。理解するのに、慣れるのに何日間もかかるようなシステムを誰が喜んで使いたいだろうか？残念ながら、今の日本のサービスはそんなのばっかりだ。 なぜこのような考え方が生まれるのか 機能を闇雲に追加していくことのメリットは、「自分が何も考えなくてもいい」ということだ。他社のを参考に、ユーザーの意見を参考に言われるがままにパクって作ればいいだけなのだから。多少は自分たちのサービスっぽくカラーを添え
企業をデザインシフトさせる方法と今後のデザイン戦略 | tsublog
少し前に、Schooさんで「 企業をデザインシフトさせる方法と今後のデザイン戦略 」という内容でお話させていただきました。 「 デザイナーの能力を生かせない日本企業の仕組み 」という日経の記事を読んで、共感する事も多く、企業導入の参考事例の一つとして、Schooで話したスライドをシェアしておきます。 デザイン・シンキングは、製品開発する上で有用な手段になりうる一方で、日本の企業ではまだまだ理解してもらえない事の方が多く、デザインというワードを使っているため「その言葉はよく聞くけどデザイナーさんのテクニックの一つでしょ」という現場の方が多いです。 スライドでも触れてますが、多くの現場ではデザイン・シンキング以前の問題が多く、いきなり導入を試みたり、ステークホルダーに提案すると、そのギャップに打ちのめされる事が多いと思います。 一方で、デザイナーが一定以上の品質を目指す場合、技術力が高い人でも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンセプトのつくりかた - アイデアをかたちにする技術
