「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か？｜moutend
結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。
なぜ営業組織と開発組織の仲は悪くなるのか？を考えて体制構築したらBizDevの重要さがわかった話｜井原 真吾
前提として、私は営業組織でも開発組織でも働いた経験があります。 営業組織で学んだこと私は新卒でリクルートに入社し、キャリアの最初は「カーセンサー」という中古車メディア（当時からWEBが中心）の広告営業でした。 新規顧客開拓では都内の中古車店にひたすら飛び込む中で辛い経験も味わいながらも、噂に聞いていたリクルートの営業部隊を現場で体感できたのは非常に学びが多かったです。 私が働いていた当時、大規模な顧客向けシステムのリプレイスがありました。当時はシステムのことなど何もわからず、営業の立場として聞いたときには、「なんでこれまで慣れてきた画面を変えるんだ！」と思いましたし、リリース後にバグがあると「なんでこんな品質のものを開発部隊は当たり前に提供するんだ！」と激怒していたものです。「せっかく俺たちが（売上を）作っているのに・・・」と飲みながら話すことがよくありました。 何よりも、今動いているシス
小さなゲーム開発についての小さな電子冊子を作ったよ - ABAの日誌
小さなゲームを開発することの楽しさや、その作り方について、今までブログに色々書いてきた。 それらの内容を「小さなゲーム開発の楽しみ」という、小さな電子冊子としてまとめた。 楽しさを色々な側面から伝えるべく、以下の内容を盛り込んだ。 小さなゲームとは何か、そしてその制作がなぜ楽しいのかを探る ゲーム開発におけるターゲットデバイスや開発環境の選び方 ゲームの核となるアイデアの考案や、制約を活かしたアイデアの生み出し方 プレイヤーが感じる適切な難しさの設定方法 ゲームをより魅力的にするための「ジューシー」なエフェクトや音の追加方法 自作のライブラリ・エンジンの制作や、絵や音の自動生成方法 コンピュータがゲームを一から開発する可能性についての考察 小さなゲーム開発に興味がある方、またはすで開発している方にとって、なるべく有益な情報を含んだつもりだ。自分の興味に従って書いたため、散発的で多様な内容で
はじめに · 小さなゲーム開発の楽しみ
小さなゲーム開発の楽しみ はじめに ゲーム開発は、自分の創造性を存分に活かせる場だ。特に、手軽に作成してすぐに楽しめる小さなゲームを題材とすれば、その魅力をすぐに体験できる。この記事では、小さなゲームを制作する楽しさを探ってみたい。 「小さなゲームを作ること、それ自身が楽しいのだ」の章では、小さなゲームとは何か、小さなゲームを作るのはなぜ楽しいのかを述べる。小さなゲーム開発は大きなゲームを作るための訓練というだけではなく、小さなゲームならではの楽しさがあるのだ。 小さなゲームを作ろうとした時、どのようなプログラミング言語やゲームエンジンを使って作れば良いかは、最初に悩むポイントだ。「ターゲットデバイスと開発環境、何向けに何で作ろうか」の章で、それらに関する情報を集めた。 ゲームの核となるアイデアの考案は、小さなゲーム制作の鍵だ。「小さなゲームのアイデアって、どうやって思いつくの」の章で、そ
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
銀行の基幹系システムはなぜ複雑なのか？｜つっちーさん
おはよう人類。 インフラストラクチャーという言葉は、元々ラテン語に語源があり、inferus(下部の)という言葉とstructura(構造体)という二つの言葉を合成した言葉で、言葉の意味としても、社会構造の中で上部構造である政治基盤に対応する経済基盤としての使い方(主にマルクス経済学で用いられる)と、道路や橋だけででなく教育機関など公共性の高い社会基盤の意味で用いられる。特に、後者の意味が強いのだが、インフラストラクチャーの供給源というのは国や公共的な組織だけにとどまらず、電力会社や鉄道会社、金融機関のように私有なのだが、その性質上インフラストラクチャーとして扱われるものも多い。 こういった企業を(広い意味で)インフラ業と呼ぶことも多いのだが、その公共性の高さから私有にもかかわらず、その運営には様々な規制が加えられていることが多い。設立に免許や認可が必要で、運営に関しても一般の企業とは異な
売れるアプリにするコツ100個書きます(吐血) - Crieit
はじめに 脱サラして、個人開発アプリだけで生活している、あたか絵師です。 Crieitアドベントカレンダー10日目として、売れるアプリにするためのコツを100個吐き出します。 僕は、個人開発アプリで月6桁の売上を出す感じですが 「売れてるな〜！！」 って感じるのは、1万円/月を超えるぐらいのアプリなので 「売れるアプリ」＝「コンスタントに1万円/月ぐらい売り上げるアプリ」 と考えて下さい。 何となく書いていたら ・ASO ・CS ・UX ・企画 ・マーケティング ・運用 に分かれる気がしたので、その分類でいきますよ！ 普段もたまに役立つことをつぶやいている可能性があるので、twitterフォローもどうぞ🐔 👉👉 https://twitter.com/atagon 👈👈 noteとzennの記事も気になったらどうぞ 📱 食えるアプリにするための細かい工夫 (Zenn) 📱 売
120年ぶり民法改正へ、システム開発費「高騰」のリスク
約120年ぶりに債権法を抜本的に見直した改正民法の施行が、約4カ月後の2020年4月1日に迫っている。改正によりIT業界で新たな火種となりそうなのが、ITベンダーが納品した情報システムに対して、ユーザー企業が無償改修や賠償を請求できる期間が実質的に延長される点だ。大手ITベンダーや業界団体は対応に乗り出しているが、システム開発費が「高騰」するリスクをはらんでいる。 改正民法は2017年に国会で成立した。売買やサービスなどの「契約」に関するルールを定めた債権法を約120年ぶりに抜本的に見直す。建築業界と並んで大きな影響を受けるのがIT業界だ。ITベンダーとユーザー企業それぞれで対応が必要になる。 最長10年間、ユーザー企業は無償対応の請求が可能に ユーザー企業とITベンダーが交わすシステム開発の契約形態は大きく2つある。ITベンダーが成果物に対する完成義務を負う「請負」と、ユーザー企業が設計
なぜシステム会社の見積りが「ボッタクリ」に見えるのかを、きちんと説明する。
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開） ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
アプリ開発を発注する時に準備したい10のこと - architecture_database
随分と久しぶりの更新になってしまいました。 最近アプリ開発をしているのですが、開発よりも大きな範囲で意見を求められることが多いので、参考となればと思ってまとめてみました。 自分の考えたサービス企画が無事に社内で承認を得た。さぁ開発会社に見積り取って発注するぞ！そんな状況の人にぜひ目を通して欲しい10の情報をまとめました。 依頼する前にあなたが考えること 1.アプリをリリースして1年間のストーリーを書く 開発会社によってはあなたの企画したサービスに対して親身に相談に乗ってくれるかもしれませんが、残念ながら開発会社の本業はアプリの開発なので、過度な期待はやめましょう。 一方、あなた自身もいきなりサービス全体を完璧に想像できないでしょう。そこで開発会社とサービスのイメージを共有するためにも、リリース後1年間のストーリーを描きましょう。 いきなり「ストーリーを書け」と言われても難しいと思うので、「
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。 船底の穴からの浸水を必死でかき出しながら、どうにか進んで行く。そういう航海だ。 船のどこにどれだけ浸水箇所があるのかは分からない。 ある穴を塞ごうと船底に板を打ち付けたら、 それによって別の場所に新しい穴を空けてしまったりする。 船の構造はあまりに複雑で、膨大な部品の間にどんな依存関係や相互作用があるのか、 誰も完全には把握していない。 それは、はるか昔に組み立てられた太古の船で、 構造把握の手掛かりは、代々伝わる不十分で不正確な古文書だけなのだ。 新任の船員は、出た水に対してとにかく手当たり次第に対処した。 どんな物でも使い、徹夜で穴を塞いで回った。 ひたすら大きな声で号令を出し、 いかに早く穴を塞ぐかが、船員の間で競われた。 何人もの船員が過労と心労で倒れ、 航跡には水葬者が点々と残された。 船員たちが経験を積
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳