levii blog

levii Inc. が運営する公式ブログです

ユーザーの声をちゃんと聞かないと UI/UX リニューアルなんてできないよね

f:id:yoshizawar:20180529142954j:plain

こんにちは。散歩が趣味になりつつあるレヴィの吉澤です。

昨年の 11 月頃から半年程かけて Balus Mega の UI/UX をリニューアルした結果、「すごく良くなりましたね」というポジティブなフィードバックをいただけるようになりました。

なかなか成果が見えずに精神的にも大変だったのですが、改めて振り返ってみると、

作り手のコンセプトを反映したシステムの視点

実際に使うユーザーの視点

をいかに接続するかという、デザイナーとしての本質的な仕事をしていたように思います。

その過程で、ユーザーの声を聞く、ということの難しさや、デザインコンセプトやガイドラインといった「作ってみた」で終わっていたものをどう使えばいいか、が少しずつ分かってきたのでまとめてみました。

デザインコンセプト「ナイスミドルに親切で便利」

リニューアルの取り組みの話の前に、Balus Mega そのものとデザインコンセプトについて紹介します。

Balus Mega は業界特化型の B2B SaaS (いわゆる Vertical SaaS) で、対象となるユーザーの IT リテラシーは必ずしも高いとは限りません。そのため、ウェブアプリケーションに慣れていない人でも使いやすい UI/UX を実現しないと実際の業務では使ってもらえません。

Balus Mega は他社の協力を得て開発しており、様々な視点が入るため、チームで作っているものに対する目線がブレやすいという問題がありました。そのため、抽象度が高いレベルでデザインの理想像や方向性、テイストを共有し、チームで目線を揃えて開発を進めるために、デザインコンセプトを決めています。

クールやスタイリッシュといったかっこいい要素は排して、なるべく分かりやすく使いやすい製品にするために「ナイスミドルに親切で便利」という言葉を選択しています。

f:id:yoshizawar:20180529114920j:plain:w320

ここでは「親切」と「便利」という言葉を次のように定義しています。

  • 親切: ユーザーがメンタルモデルを構築しやすいこと
  • 便利: 業務シナリオをこなすのに効率が良いこと
    • 画面遷移やクリックなどの操作の手間ができるだけ少ない

UI/UX リニューアルのあらまし

Balus Mega は SaaS なので、個々のお客様の課題に合わせたカスタマイズではなく、普遍的・本質的な課題を使いやすい UI/UX で解決する必要があると思っています。

しかし、リニューアル以前、ユーザーからは次のような「分かりにくい」というフィードバックをもらっていました。

  • どこを見ればいいのか分からない
  • どのボタンを押せばいいのか分からない
  • 何の画面にいるのか分からなくなる

このままではよくありません。。

そこで、まずは問題の本質を探るため、フィードバックをくれたユーザーに細かくヒアリングを重ねるところから始めました。その結果をまとめると、次のような感じです。

  • 何が問題の本質かはよく分からない
  • ユーザーもよく分かっていない
  • でも小さな問題はものすごくたくさんある

何か本質的な問題があるのは確かなのですが、これを解決すればいい、というものは誰にも分からないという状況でした。

デザインコンセプトを改めて振り返りつつユーザーのフィードバックを深掘りしていくと、アプリケーションの構造や振る舞いに対するユーザーの認識にズレがあることが分かってきました。

そこで、「メンタルモデルの構築」に課題があるために「操作や見た目に問題があると感じているのではないか」という仮説を立てて、リニューアルに取り組み始めました。

OOUI でメンタルモデルを構造化する

メンタルモデルとは、「人がある情報を得た時に作り上げる心の世界」のことです*1。ユーザーはシステムを使うことでシステムに対するメンタルモデルを構築し、そのメンタルモデルを頼りにシステムを使っていきます。

メンタルモデルに関するさまざまな手法を検討した結果、モデルという観点で Balus Mega と相性が良い OOUI*2 でアプリケーションの概念を整理し、画面構造を見直すことにしました。コンポーネントの責務とコンポーネント間の関係性をリレーショングラフとして定義し、実際の画面と比較することで課題を抽出しました。

Balus Mega のメンタルモデルの一部をリレーショングラフで表すと次のようになります。

f:id:yoshizawar:20180529115348j:plain:w320

Balus Mega では、プロジェクトの配下にアクション、モデル、データというコンポーネントがあり、それぞれに対応する画面がありまし。しかし、メンタルモデルと実際の画面を比較すると、カバーとナビゲーションの表現が良くなく、間違ったメンタルモデルを作りやすいことが分かってきました。

f:id:yoshizawar:20180529125507p:plain
変更前の画面

カバーにはパンくずリストとアクション名が表示され、その下にあるナビゲーションにアクション、モデル (画面ではダイアグラム)、データ (画面ではコンテンツ) のタブがあるため、アクションの配下にアクション、モデル、データが並んでいるように見えてしまっていました。そこで、カバーはプロジェクト名だけに変更し、アクション、モデル、データのタブをその下に移動しました。

f:id:yoshizawar:20180529132509p:plain
変更途中の画面

それに伴ってアクション名やパンくずリストなどの場所をそれぞれのコンポーネントの責務に合うように変更しました。その他にも、メンタルモデルを作りやすいようにいくつかの変更を入れました。

これでユーザーの視点とシステムの視点は接続できたぞ!と思っていたのですが、残念ながら反応はそれほど良くありませんでした。

ガイドラインで一貫性をもたせる

改めてユーザーのフィードバックを注意深く聞いていくと「ボタンの対象が分からない」といった、一見すると細かい問題がいくつも出てきます。

メンタルモデルという抽象度の高い問題を解決したことで安心していた我々ですが、「神は細部に宿る」という言葉もあるように、デザインの細かい部分、「UI の一貫性に問題がある」らしいということが徐々に分かってきました。

UI の細かいコンポーネントは使い回しができるように作ってあったのですが、より抽象度が高いレベルで一貫性を改善するため、UI/UX ガイドラインという形で「解決したい課題に対する表現」を言語化することにしました。

ガイドラインの目的として、

  • チームで UI/UX の理想像を共有する
  • ユーザー視点で議論する場を作る
  • 個別対応ではなく全体最適を目指す
  • デザインに統一感を持たせる

という課題意識は以前から持っていて、このリニューアルをきっかけに整備し始めました。

ガイドラインには、ユーザーに提供する価値から具体的な実装方法までを記述し、なぜそのような UI/UX に意思決定したのかを追えるようにしています。

ガイドラインを生きたものにするため、コンセプトから落としてガイドラインを作るだけではなく、個別の課題からガイドラインを整理していく方法でも進めています。

「ボタンの対象が分からない」という課題を解決するために、ボタンに関するガイドラインを整理し、そのガイドラインに沿ってアプリケーション全体を修正しました。ボタンの言葉と位置、フィードバックがアプリケーション全体で一貫性のあるものになりました。

f:id:yoshizawar:20180529115706p:plainf:id:yoshizawar:20180529115700p:plain
ボタンの比較 (左が変更前、右が変更後)

ガイドラインを整備することで、コンセプトから出発し改善していくプロセスと、個々の課題から出発しアプリケーション全体を改善していくプロセスの両方をチームとしてやっていくための土台ができました。

ガイドラインはいろいろと役には立ったのですが、ユーザーのフィードバックは依然としてネガティブでした。そろそろ辛くなってきます。

コントラストで表現を伝える

流石に我々も困り果てて来ましたが、別の SaaS アプリケーションを具体例として検討することで突破口が見つかりました (始めから気づけよ、という話だとは思いますが)。

BacklogAsana など、良いフィードバックを得られるアプリケーションと Balus Mega の差分を検討した結果、画面構造や UI の一貫性は良くなったものの「表現に問題があってそれがうまく伝わっていない」ことが分かってきました。Balus Mega のデザインはコントラストが低く、コンポーネント間の関係性が視覚的に表現できていなかったのです!

そこで、デザインの原則に立ち戻り、配色とタイポグラフィー、余白を見直し、アプリケーション全体でコントラストを調整しました。

f:id:yoshizawar:20180529115849p:plain
変更後の画面

  • 配色
    • カラーパレットの定義
    • コンポーネント間の関係性に応じた配色設計 (目立たせるもの、同じカテゴリーのもの、など)
  • タイポグラフィ
    • フォントサイズ、ウェイト、カラーのセットをテキストスタイルとして定義
    • テキストの種類とその責務を明確化
    • テキストの種類とテキストスタイルの対応付け
  • 余白
    • コンポーネント間の関係性に応じた余白設計 (関係性が近いもの、遠いもの、など)

各画面でメリハリが出てコンポーネント間の関係性が伝わるようになりました。

これまで、細かく改善しユーザーのフィードバックをもらう、というサイクルを回してきましたが、ここで初めてフィードバックがポジティブになりました。ポジティブなフィードバックをもらったことで改善の方向性が明確になりました。やったー!

ユーザーの声をひたむきに聞いて改善しよう

デザインコンセプトやメンタルモデルなど、いろいろな観点でリニューアルを進めてきましたが、得られた最大の学びは「ユーザーの声をちゃんと聞く」に尽きます。

今回のリニューアルでは OOUI の手法やガイドラインの整備などの施策を行いましたが、これらの施策は、そのままではシステムの作り手の視点を押し付けるだけのものになりかねません。そのため、ユーザーテストなどを使ってユーザーの視点と接続し、ギャップを埋めることが大事になります。なぜなら、常にシステムを作る側とユーザーの視点にはギャップがあり、このギャップが UI/UX の問題として現れるからです。

このギャップを丁寧に埋め続けるためには、結局、「ユーザーの声をちゃんと聞く」という基本的なことを続けるしかないということですね。

そして、「ユーザーの声をちゃんと聞く」ためには

  • できるだけ率直に意見を言い合うために信頼関係を築く
  • 一緒に問題に向き合っていることをユーザーと共有する
  • その場で具体的なフィードバックを貰えるように準備をする

というコミュニケーションの基本もとても大事なことが分かりました。

レヴィでは、ユーザーの声を聞き、改善し、フィードバックをもらうというサイクルをこれからも回し続けていきたいと思います。

*1:メンタルモデルにはさまざまな定義があります。これはこの文脈での定義です。

*2:OOUI (Object-Oriented User Interface) または OOUX (Object-Oriented User Experience)。詳しくは こちら

ライセンス形式変更に伴うご案内

平素よりBALUSをご利用いただき、誠にありがとうございます。

β版を提供しておりましたBALUSの正式版を、2018年4月25日より提供開始することといたしました。

正式版では、システムモデリング機能に加えて、プロセスモデリング機能やデータ管理機能など、プロジェクトを効率的に進めていく上で不可欠な機能が追加されています。

それに伴いまして、名称を「Balus Mega」に変更し、またライセンス形式を変更することとなりました。 ライセンスはグループ単位での付与となり、下記3種類を提供いたします。

  1. トライアル・ライセンス(1ヶ月間のみ無料)
  2. スタンダード・ライセンス(有料)
  3. アカデミック・ライセンス(個別相談)

現在BALUS上に存在しているグループには、自動的にトライアル・ライセンスが付与されます。

1ヶ月間は、無償でフル機能をご利用頂けます。(2018年5月31日まで

引き続き、ご利用頂くには、スタンダード・ライセンスあるいはアカデミック・ライセンスが必要となります。

ライセンスご希望の方は、下記宛先・件名にて、ご連絡頂ければ幸いです。

宛先:contact@levii.co.jp

件名:スタンダード・ライセンス見積依頼 or アカデミック・ライセンス見積依頼

引き続き、レヴィとBalus Megaをよろしくお願いいたします。

株式会社レヴィ

コードを書かない開発合宿に行ってきました @ 湯河原温泉 おんやど恵

f:id:hagifoo:20180311150104p:plain

寒さから花粉へとダメージソースが移り変わったものの、相変わらず鼻炎のケアが欠かせない @hagioo です。

フルタイムのメンバーが 3 人になってから 9 ヶ月経ち、ありがたいことにリリースも間近になってきました。 リリース後、お客様からの改善要望や不具合修正などの対応が増えることが想定される中で、 中長期での機能追加やアーキテクチャの整備なども含めた、より中長期的な視点にたった開発チームとしての意思決定が必要になることは明白です。 しかし、levii は普段ほぼフルリモートで開発をしているため、目の前のタスクを処理していく体制はできているものの、 あまり中長期目線での視点を揃える機会が足りていませんでした。

そこで、目の前の開発の事は一旦置いて、目線を揃える場として湯河原温泉のおんやど恵さんに開発合宿に行ってきました。

湯河原へ

東京駅集合の予定が電車遅延のせいで途中駅からメンバーが合流、という波乱を予感させる幕開けになりました。

f:id:hagifoo:20180311155953j:plain

まずは行きの電車で「時間」「抽象度」の2軸で課題感をマッピングし、合宿でやることと優先順位を考えていきます。 以前はがっつりアジェンダを作り込んでから会議をするスタイルだったのですが、 メンバーの視点を混ぜ合わせて行くほうが課題の精度が高くなるのと、準備をがっつりしても無駄になるケースが多いことから、 その場でアジェンダを作る文化に移行しています。 ここでは言葉に注意して、課題感から逆算して「ある時点でこうなっていたいという状態」と「そこにどう向かうかという行動・戦略」を明確に分けるように注意しました。

f:id:hagifoo:20180310121430j:plain

湯河原に着いてからは 13:00 のチェックイン(会議室)まで、万葉公園を散策したり足湯(独歩の湯)に足を浸しながら色々と話をしました。 普段とは違った環境でリラックスできると、なかなか言いづらいことがいいやすくなるものですね。

独歩の湯は安め*1の値段設定ながら、かなり満足度が高かったです。

f:id:hagifoo:20180311160002p:plain

理想の言語化

一通り話をして昼ごはん*2を食べたら、おんやど恵の会議室にチェックインです。 広さも十分ですし、畳なので休憩時間にごろっとすることもできます。 Wifi はもちろん、ディスプレイ*3につなぐためのケーブル類も充実しており安心感があります。 お水やお湯も用意してあって無くなったら取り替えていただけるのも非常に助かりました。

f:id:hagifoo:20180309141524j:plain

目的が「中長期での目線を揃える」なので、まず最初に「ビジネス」と「チーム」という 2 つの側面から理想を言語化するためのワークをやります。 時間軸を決めて具体的なアクションまで落とし込むかどうかで迷ったのですが、 こういった言語化は今回が初回ということもあり、まずはあまり時間軸にとらわれずに自由に考えることにしました。

理想が実現できている状態をメンバー 1 人ずつ 5 分で付箋 10 枚以上書いていき、それらを共有してから抽象的な意味を考えつつグルーピングして、 最終的に 3 つずつの言葉に落としていきます。 「技術や考え方を生み出している」「関わる人全員がハッピーになる」「会社の名前がついたバス停ができる」など色々な言葉が出てたのが面白かったです。 長いことやっている仲間ということである程度視点が揃っていたおかげか、割とすんなり 3 つにまとまったので、 続いてそれらを会社を表す 1 つの言葉にまとめました*4。 ドット投票の結果「複雑さの中に価値と面白さを見つけよう」という元々の言葉に加えて、 「生物みたいに強い会社」という糸井重里のキャッチコピーみたいな言葉が選ばれました。

f:id:hagifoo:20180309153012j:plain

ここまで多少頭を使ったので早速温泉タイムです。 露天風呂がおしゃれで、完全に外ではないもののちらっと空が見える感じが逆にリラックスできました。 泉質のせいか、お風呂から出てもあたたかさが持続するので、うっかり寝そうになりますが夕食まで我慢してワークを続けます。

風呂上がり後はチームの理想をさらに深掘りしました*5。 3 つの言葉(=理想)それぞれについて、それらが実現できている状態をより具体的に(みんなで〇〇している etc)付箋に書き出していきます*6。 それらをグルーピングすることで、各メンバーがそれぞれの言葉に託していた思いが微妙にずれていることや、 メンバーによって視点に違いがあることが明らかになっていきます。

その後、「ここで出てきた理想が本当に自分たちの大事にしてきたものなのか?これからも大事にしたいものなのか?」をより深く知るために、 ホワイトボードを眺めながら、これまでの行動を具体的に振り返りながら理想を実現出来ている、出来ていないという話をしました。

日頃から「率直に言い合える」環境を作ろうと努力していたつもりだったのですが、 意外とそれが達成出来ていなかったことが分かったりと、この話し合いの時間はチームにとって非常に貴重なものになりました。

f:id:hagifoo:20180309195730j:plain

品質と全体感について

夕食に備えておやつを控えていたこともあり、既にお腹が減りすぎてやばい状態です。 そんな我々の期待に応えて、夕食は質・量ともに申し分なかったです。

f:id:hagifoo:20180311170329j:plain

夕食後は短期と中長期の両方で課題感のある品質について色々と議論をしました。 リリースに向けた短期での「当たり前品質」の担保はもちろんのこと、出てしまった不具合を素早く検知するためのエラートラッキングや そもそも品質を定義するための仕様をどう作っていくか、 それをどういうステークホルダーのために仕様書に落とし込んでメンテナンス可能なプロセスを構築するか、といった中長期での施策の話も色々とできました。

今のフェイズだと短期的に品質を上げるのも非常に大事だと思うのですが、 やはり中長期での視点も揃えておけると今後の活動がスムーズだなと改めて思いました。

ここまでで大分疲れが溜まってきたので、真面目な話は一旦切り上げて Web アプリケーションの発表会?に移しました。 Web アプリ開発初心者に「全体感」を持って開発を進めてもらえるように各メンバーが一から Web アプリケーションを作ってみるという試みです。 普段の開発では既に作り込まれたフレームワークや CI、開発プロセスに乗っからざるを得ないため、あまりゼロベースでそれらを考えることはありませんが、 こういった開発を通じて各メンバーが予め与えられた枠そのものを壊して考えられるようになりつつあることが感じられました。

私自身も DDD はもちろん Progressive Web Application や Typescript + InversifyJS などの新しい技術的な探求も兼ねてアプリケーションを作ってます。

f:id:hagifoo:20180309153631j:plain

フレームワークとプロセス

翌朝は 7 時から再開予定だったものの、朝風呂の誘惑にメンバー全員が負けて朝食後からのスタートになりました。

12:00 退出予定だったので、最後の枠としてこちらの記事を参考にアプリケーションのフレームワークとして直近で整備した方がいいところは無いか、 中長期的に入れるべきことはないかを検討していきました。

qiita.com

「視点を揃える」という目的に注意しつつ、やるやらないという話だけでなく、何故それが必要なのか・我々の理想にどうつながっていくのか、 といった点を議論することにも時間を使うようにしました。

  • ロギングやエラーなどが各メンバーによって何となくで実装されてしまっており全体的な方針が無いため 0 ベースで見直す
  • 依存関係が微妙な箇所があるので DI コンテナ相当のフレームワークを導入して IoC を実現できるようにする

といった直近でのフレームワークの話から、

  • イベントキューを使ってサービスレベルで疎結合化、依存関係の逆転を進める
  • サーキットブレーカーをちゃんと考えて導入する

といった中長期的な話もできました。

levii はアーキテクチャを綺麗に保ち続けることにかなりこだわりがあるので、それを実現するための要素としてのフレームワークについて 参考になる記事を元にメンバー同士の目線を合わせられたのは非常に良かったです。

f:id:hagifoo:20180310095050j:plain

帰りの電車や東京に帰ってからの打ち上げでも、開発プロセスや組織について色々と話をして盛り上がりました。

f:id:hagifoo:20180310140921j:plain

まとめ

あっという間の合宿でしたが全体として非常に学びが多かったです。 開発において設計やコーディングが占める割合は決して低くないですが、コードを書いている側の人間やチームについてみんながちゃんと考える時間を作ることも同じくらい重要ではないかと思います。 普段と違う環境を用意することで中長期の話をしてみたり、言いづらいことを言い合ったりして「チームの目線」を揃えてみるのはいかがでしょうか?

*1:300円/人、タオルは 150円/枚

*2:一二一という豆腐料理屋さんでおいしいお昼をいただきました

*3:2000 円/日

*4:これらの言葉が本当に自分たちの考えを体現しているのか、普段使いしながら確認していく予定です

*5:開発メンバーということもありビジネスの理想が少し抽象的になってしまいました。営業などビジネスサイドの人間も一緒にやるのが良さそうです

*6:7 分で各言葉につき 5 つ以上 = 3 x 5 で 15 以上

ログイン方法を変更します!

複数の BALUS アカウントを使っているんだけど切り替えが面倒、という声にお応えして 2017/05/26 からログイン方法を変更いたします。

概要

従来の BALUS アカウント(これまで Google アカウントを使ってログインしていたもの)に加えて levii ユーザーアカウントを新たに作成します。

1 つの levii ユーザーアカウントには、複数の Google アカウント(将来的には他のプロバイダーのアカウントも追加できるようにする予定)を連携させることができます。 ※1人で複数の levii ユーザーアカウントを所持することも可能です

また、1 つの levii ユーザーアカウントに複数の BALUS アカウントを連携させることができ、自由に切り替えを行うことができます。

f:id:hagifoo:20170511104950p:plain

Levii ユーザーアカウントを経由してログインを行うことで「どの Google アカウントを使っていたっけ?」「間違えて別のアカウントでログインしちゃった、ログアウト面倒だな」といった問題の解決を狙っています。

BALUS にログインするまでのフロー

これまでは BALUS のページを表示した後、右上の「サインイン」をクリックすると Google アカウントの選択画面が表示されログインできました。 これからは右上の「サインイン」をクリックすると levii アカウント管理のログイン画面が表示されます。

f:id:hagifoo:20170511110019p:plain

Google でログイン」をクリックすると Google アカウントを選択する画面になるので、これまで BALUS にログインするために使っていたアカウントを選択して下さい(後から連携する Google アカウントを増やすこともできます)。

既に levii アカウントと連携している場合はそのままログインが成功しますが、まだの場合は以下のサインアップ画面が表示されます。 名前を適切に変更してサインアップして下さい。

f:id:hagifoo:20170511110401p:plain

サインアップに成功すると BALUS に戻り、新規にユーザー登録を行うか、既存の BALUS アカウントでログインするかを選択します。

f:id:hagifoo:20170511110737p:plain

既に BALUS にログインしたことがあれば、「既存アカウントでログイン」を選択して下さい。 既に BALUS アカウントにログイン済みであればそのアカウントが、まだであればアカウント選択画面が表示されるのでアカウントを選択し、ログインして下さい。

これで連携が完了し、次回からは自動的にログインできるようになります。

複数の BALUS アカウントを levii ユーザーアカウントに連携させる

ヘッダー右上のユーザーメニューから「アカウント切り替え/追加」を選択して下さい。 「既存の BALUS アカウントを連携」ボタンをクリックすると連携用のページに遷移するので、BALUS アカウントを変更・選択して連携させて下さい。

ユーザーダッシュボードの UX を改善しました!

今回のリリースでは、ユーザーダッシュボードに関する UX を改善いたしました。 グループやプロジェクトの一覧と詳細が見やすくなったと思います。

1. グループやプロジェクトの一覧が左側に移動しました

ログインして最初に表示されるユーザーダッシュボードで、グループやプロジェクトの一覧が左側に表示されるようになりました。最近更新されたプロジェクトおよびグループが上位数件表示されます。

f:id:yonambu:20170324151356p:plain

Fig.1 ユーザーダッシュボード

また、ユーザーダッシュボードでグループやプロジェクトを選択した際に、これまで新しいページでグループダッシュボードやプロジェクトダッシュボードが開かれていましたが、今回から同一ページで開かれるようになりました。高速化されて、待ち惚け感も薄らぎました。グループやプロジェクトの詳細が中央に表示されるようになって、見やすさもアップです。

f:id:yonambu:20170324151611p:plain

Fig.2 グループダッシュボード

2. 右上の通知リストから通知を既読にすることができるようになりました

各ダッシュボードの右上にある通知マークをクリックすると通知リストが表示されます。ここから通知を既読にすることができるようになりました。

f:id:yonambu:20170324150142p:plain

Fig.3 通知リスト

3. ダイアグラムをグルーピングすることができるようになりました

ダイアグラムの数が多くなってくると、閲覧・編集したいダイアグラムを探すのにも一苦労です。そんなときに便利なのがフォルダ分けですね。できますよ。

プロジェクトダッシュボードのダイアグラム一覧の右上の「カテゴリ」マークをクリックしてください。

f:id:yonambu:20170324152100p:plain

Fig.4 カテゴリを作る

カテゴリが新規に作成されます。ダイアグラムの名前の前にある円マークをドラッグ&ドロップしてカテゴリの中に入れることができます。

f:id:yonambu:20170324152154p:plain

Fig.5 カテゴリ

こうして、ダイアグラムを整理整頓することができます。

f:id:yonambu:20170324152343p:plain

Fig.6 カテゴリの中のダイアグラム

その他、いろいろと細かいところが改善されています。

これからも、痒いところにも手が届く、使いやすいツールを目指していきます。要望お待ちしております。引き続き、よろしくお願いいたします。

2016年11月13日(日) システムモデリングのワークショップを開催しました!

クリスマスまで、あと1ヶ月と少し

バルス大学工学部の宇宙開発研究会の新入生であるみなさんは、チームに分かれてCANSATを開発することになりました。

CanSatの打ち上げ予定日は12月24日...

そう、クリスマス・イブの日です

みなさんは、リア充らしい甘酸っぱいミッションと、非リア充らしいドス黒いミッションのどちらを選びますか?

f:id:yonambu:20161124012007j:plain

ワークショップに参加した面々は,次のようなミッションを提案しました。

  • CanSatがハート型のパラシュートを開きながら降下してきて、彼女にキャッチしてもらい、好きな相手に告白する。OKなら指輪を出して、NGなら悲しい音楽を流す。
  • CanSatがイチャイチャしているカップルを全力で照らしつけてメタルコアの絶叫を聞かせ、それに全力で盛り上がる非リア充の声でオーナーに報告とする。
  • CanSatリア充カップルを追い回し、雰囲気に合わないイルミネーションを点灯して雰囲気を台無しにして、非リア充に知らせる。
  • CanSatからローバーを放出して、雪にメッセージを投影する。

ミッションが個性的であるだけでなく、 CanSatとしての機能をきちんと定義したものであり、参加者の理解度は非常に高いものでした。

参加者は4グループに別れて、クリスマスイブの日に「好きな相手に告白する」というリア充ミッションと「イチャつくカップルを盛り下げる」という非リア充ミッションを担うCanSat(模擬衛星)を題材に、要求分析を行いました。

3時間という短い時間でしたが、どの班もきちんと階層化された質の高い要求図を作ってくれました。

事後のアンケートでは

「これからの衛星開発やミッションを行う上で確実に役立つと感じました。有意義な時間をありがとうございます。」

「各個人で考えたり、グループで発表したりなど他人の意見も聞くことができたので非常によかった」

「いままでPowerPointVisioをつかってシステムツリーを作成していて大変だったので、便利なものを知れてよかった。今後の活動でぜひ利用したいし、大学に持ち帰って普及させたい。」

という声が聞かれ、参加者の満足度も高い様子でした。

本ワークショップは、東京工業大学大岡山キャンパスにて、宇宙工学講座「複雑化するシステムに挑む~モデルベースなシステムズエンジニアリングの基礎~」(主催:一般社団法人日本機械学会、共催:NPO法人 大学宇宙工学コンソーシアム(UNISEC)、協力:株式会社レヴィ)として開催されました。

弊社も全面協力のイベントということで、ワークショップのモデレータを南部(弊社CEO、大阪府立大学助教)と三浦(共同創業者、鳥取大学助教)が務め、各グループのファシリテータを五十嵐、木村、萩原、吉澤(共同創業者)が務めました。

14名の参加があり、教室を熱気で溢れさせました。超小型衛星開発に関心のある13名の大学生に加え、1名の社会人(企業にお勤めの方)、2名の大学生スタッフ、4名のスタートアップ起業家(株式会社レヴィ)という多様なメンバーが、熱心に議論を行いました。

また、本講座開催に当たっては、会場や物品の手配等、東京工業大学の坂本啓准教授に多大なるご協力を頂きました。 この場を借りて御礼申し上げます。

今後とも同種の参加者が手を動かす形式の講座を開催していきたく思います。

f:id:yonambu:20161122141047p:plain

「南部助教による講演の様子」

f:id:yonambu:20161122141105p:plain

「南部助教(左)と三浦助教(右)」

f:id:yonambu:20161122141112p:plain

「ワークショップの説明」

f:id:yonambu:20161122141120p:plain

「ワークショップの説明を聞く参加者」

f:id:yonambu:20161122141133p:plain

「要求図の説明をする南部助教

f:id:yonambu:20161122141225p:plain

CANSATの振舞を考える参加者」

f:id:yonambu:20161122141232p:plain

CANSATの要求の洗い出し」

f:id:yonambu:20161122141239p:plain

「モデルを説明する参加者」

f:id:yonambu:20161122141245p:plain

「モデルを講評する南部助教

f:id:yonambu:20161122141252p:plain

「モデルを講評する三浦助教

ダイアグラム編集の UX を改善しました!2

前回に引き続き、いくつかダイアグラムの閲覧・編集に関する UX を改善いたしました。 今回はダイアグラムの閲覧性を向上させる改善と、ワークショップで実際にユーザーの動きを観察した結果入れた改善が含まれています。 また、ノードやリンクを選択した際に周囲をハイライト表示する機能が使えなくなっていたため修正しました。

1. 選択したノードと周囲のノードとの関係を見やすくしました

ダイアグラムを閲覧する際に「特定のノードを見ようとすると周囲が見えなくなる」「引いて全体を見ようとすると注目したい部分が見づらい」といった意見をいただくことがありました。 特に、ダイアグラムが詳細になり、遠くのノードとリンクを持つようなノードが増えてくると上記の問題が顕著になってくるため、 その対策としてノードの詳細画面に「現在選択中のノードから 1 つのリンクで繋がったノードを表示するビュー」を追加しました。 リンクの向きに応じて周囲のノードに番号が振られ、リストと対応付けて確認できるようになっています。

f:id:hagifoo:20161119224350p:plain

実は BALUS が同じノードを複数のダイアグラムに存在させられるのをご存知でしょうか? (同じプロジェクトの別のダイアグラムに Ctrl+C/Ctrl+V でノードをコピーしてみて下さい!)

そういったノードを作ると、今見ているのと別のダイアグラムでそのノードがどういう関係を持っているのかをさっと確認したい、という要望が出てきます。 この機能はその辺りもしっかりフォローしているので、是非お試しください!

2. ノードの後ろに隠れたリンクを編集しやすくしました

リンクの前にノードを置いてしまうとリンクを曲げるための手がかりが見えなくなってしまう、という問題の対策として、 選択中のリンクはノードよりさらに全面に表示するようにしました。

f:id:hagifoo:20161119224819p:plain:w300

3. 同じリンクを複数作る場合の操作性を上げました

BALUS はリンクも作成しやす過ぎるため、既にリンクが存在しているノードに対して間違ってもう一回リンクを作ってしまうという誤操作が度々発生します。 リンクが重なってしまうと誤操作した事自体に気づかないという問題への対策として、同じ両端の組み合わせを持つリンクが作られた場合は、既に存在しているリンクに重ならないように微妙に曲げて配置するようにしました。

1 本目

f:id:hagifoo:20161119225251p:plain:w300

2 本目

f:id:hagifoo:20161119225254p:plain:w300

3 本目

f:id:hagifoo:20161119225256p:plain:w300

20 本目

f:id:hagifoo:20161119225456p:plain:w300

作り過ぎにはご注意下さい!