Toolsの杜- 弥生株式会社の自動仕訳エンジンを支えるフロントエンド～「ダサいは、バグだ！」を標榜してUXを徹底的に追求する～

弥生株式会社
開発本部システム開発部
シニアテクニカルリーダー黒木進矢
シニアエンジニア澤村嘉孝
© 2018 Yayoi Co., Ltd. All rights reserved.Confidential
弥生株式会社の自動仕訳エンジンを
支えるフロントエンド
～「ダサいは、バグだ！」を標榜してUXを徹底的に追求する～
2018年07月10日

© 2018 Yayoi Co., Ltd. All rights reserved.1 Confidential
くろきしんや
 黒木進矢
 1994年4月入社
• 弥生歴25年目
 今はPMですが、ベースはエンジニア
• C++とSTLが大好き
 趣味
• オンロードバイクでツーリング＆サーキッ
ト走行
– 愛車はYAMAHA MT-09
• 料理の撮影
– 毎日毎食撮影してmiilへ投稿
– 今日で連続投稿2,236日（6年ちょい）
スピーカーの自己紹介①

スピーカーの自己紹介②
さわむらよしたか
 澤村嘉孝
 2011年から弥生で作業
 弥生ではずっとクラウドアプリのプロジェクト
• フロント寄り
 趣味
• ゲームを買うこと
– クリアすることはまれ
• ホラー映画を見ること
– 赤い方

1. プロローグ
2. 弥生の開発プロセス
 パッケージからクラウドへの進出
 .NET開発時の開発体制・方針について
3. Wijmo（ウィジモ）開発
4. まとめ
本日のアジェンダ

 弥生会計などの業務ソフトを開発・販売しています
弥生株式会社のご紹介

主力商品は弥生会計

クラウドアプリも作ってます
クライアント: HTML5 / サーバー: C# (Azure)
クライアント: HTML5 / サーバー: Ruby on Rails (AWS)

 取り組みが評価されて、パートナーオブザイヤー 2017
受賞しました！
Azureプラットフォームへの取り組み

弥生株式会社 30年の歴史

 MBOで独立するとき、社内公募で決まりました
 いまだに「弥生会計株式会社」と間違えられます
「弥生」という会社名の由来

カンファレンスに出展してショックを受けた一言
スーツを着たSEが
オフショアで作っている
会社だと思っていた

 スーツ着用は客先訪問時のみ
スーツ着用と思われていますが
取締役
開発本部長
CS本部長

 秋葉原UDX 21Fを借り切って作っています
ほとんど自社開発です！

パッケージからクラウドへの進出

 当時の世相
 民主党が308議席を獲得し、政権交代を果たしました
 「草食系（男子）」が流行語になりました
 TVアニメ「けいおん！」が大ヒット
 村上春樹の「1Q84」が大ベストセラー
 クラウドプロバイダーの状況
 三強が出揃い、徐々に普及が始まりました
• Amazon Web Services
• Google App Engine
• Microsoft Windows Azure
クラウドアプリの開発は2009年から

 2009年当時、RDBが使えたのはAzureだけでした
 Visual Studioとの親和性の高さもポイントでした
 高度なデバッグ機能が利用可能です
 社内に.NET技術者が多く慣れていました
 需要の季節変動に柔軟に対応できます
 確定申告時期（2月中旬～3月中旬）は負荷が急激に高まります
 スケールの変動にはクラウドがピッタリ！
Azureを選定した理由

弥生初のクラウドアプリ
クライアントは
Silverlight
で作られていました

 当時はRIAが盛り上がっていました
 Microsoft Silverlight
 Adobe Flash
 2010年4月、AppleがiOSでFlash非対応を表明して以来、
風向きがHTML5へ変わりました
 2014年1月、HTML5の確定申告アプリをリリースしました
 コントロールにWijmo 3を採用！
RIAからHTML5へ

弥生の開発プロセス

 よくあるソフトハウス的な作りで弥生会計を作りました
 リードエンジニア達が基盤部分やライブラリを作る
 他のメンバー達が末端の機能を一気に量産する
 その実態は...
 エンジニア個人のスキルに頼った開発
 ドキュメントはあまり存在しない
 とにかく叩いてバグを出す
弥生は小さなソフトハウスでした
結果、何が起きたか

 リードエンジニア達が独立して辞めるなどして、
プログラム全体像を知るものが減っていきました
 ドキュメントがあまりないため、どう動くのが正しいのか
が不明確になり、アプリの仕様変更や機能追加が困難にな
りました
 ソースコードは荒れていき、スパゲッティ状態やクローン
コードだらけのプログラムとなり、違法建築状態に陥りま
した
 エンジニアを追加したくても、教育に時間がかかり、
開発をスケールアップしづらくなりました
プログラムのブラックボックス化

 日付→文字列変換関数（弥生給与）
違法建築の残念な例
メソッド名処理内容
StrToDate() 日付形式の文字列を日付のシリアル値にする
StrToDate2()
StrToDate()の修正の影響範囲を限定するため、
StrToDate()をコピーして必要箇所を修正
StrToDate3()
StrToDate2()の機能拡張（影響範囲の限定）
StrToDate2()が正常に動作するように
文字列を加工してStrToDate2()を呼び出す
StrToDate4()
StrToDate3()の機能拡張（影響範囲の限定）
文字列中の空白を詰めてStrToDate3()を呼ぶ

 体系的なテストを行うための材料がないため、
品質保証が勘と経験に頼るしかありませんでした
 一定期間テストして、バグが減ったらリリースOK
といった品質保証しかできませんでした
 修正の影響範囲が読めないため、
不安を解消するため大人数でのテストをするしかなく、
工数と費用を圧迫しました
 やがて「テストができない」という理由で、
プログラムの修正に及び腰となり、
開発が硬直化していきました
品質が安定しない

 どんなに優秀な人が作っても、障害が潜伏しやすい状態に
なってしまいました
 「これで世の中に出していいの？」という判断ができなく
なってしまいました
 ユーザーからのクレームが続き、社内の雰囲気が悪くなり
ました
 会社の業績も停滞気味になりました
大ピンチ

モノづくりについて一から見直しました
困難に立ち向かう職人技
 ドキュメントがない
 スパゲッティ状態で影響範囲が分からない
ソースコード
 旧式のツールを使用するための技術と経験
 自分しかその業務を担当していないのでド
キュメント化の必要を感じない
 ミスしないように業務の流れを完全に把握
ロープを板にする努力
 ドキュメント化
 知恵の共有
 ツールの採用
 プロセスの整備
 教育の充実

U字型プロセスの導入
要求
要件定義(FS)
（基本設計）
外部（内部）
設計
実装
(内部設計）
部分統合
全統合
MR候補ビ
ルド
システムテ
スト設計
システムテ
スト実施
統合テス
ト実施
結合テス
ト実施
単体
テスト
結合テスト
設計
統合テスト
設計
レビュー
レビュー
レビュー
レビュー
レビュー
Bugfix
レビュー
Bugfix
レビュー
制限事項
Bugfix
成果物に対する
レビューを徹底し
影響のある成果物は
すべて変更する
実装プロセステストプロセスレビュープロセス
αフェーズ
イテレーション開発
③問題点・リスクを見つけたら都度改善する
②
開
発
期
間
中
は
計
測
・
監
視
①プロジェクト開始時に品質確保の計画をする

U字型プロセスの導入
Before
 明確な開発プロセスはなかった
です
 モノづくりは完全に個人任せで
した
 品質が個人の能力に依存
After
 部品(Unit)単位で確かなものを作り
まっとうな部品を積み上げるよう
にしました
 上流工程から課題を見つけてつぶ
して無駄な手戻りを減らすように
しました
 開発作業のリズムを作りやすくな
り、品質も安定していきました
 前半の要件定義とFSでは、ざっく
りと作ります
 後半の外部設計以降では、決めた
ものをカッチリキッチリ作ります

 要件定義とユースケースを元に、統合テストスクリプトを
作成して、作りたかったものの漏れがないようにしました
 外部設計を元に、結合テストスクリプトを作成して、
機能を網羅的にテストするようにしました
 開発者以外もアプリの仕様を把握できるようになりました
 マニュアル作成担当者
 コールセンター
 マーケティング
設計書とテストスクリプトを整備

 コードレベルの自動単体テストを導入して、部品単位での
品質確保に努めました
 アプリのUIテストも導入して、帳票印刷テストやシナリオ
テストなどを繰り返し実行できるようにしました
 テストを書くには手間や工数がかかりますが、品質の後退
（デグレード）をすばやく検出できます
テスト自動化

 決められたことを決められたとおりに運用されているか監
視・指導しています
 期日超過したタスクがないか？
 進捗情報が正しく登録されているか？
 品質をモニタリングして、問題を早期に検出しています
 設計書へのレビュー指摘が多すぎないか？
 重度の障害が多発していないか？
QAによる品質管理

 プロジェクトチームにマーケティングとコールセンターの
メンバーを加えて、部門横断で製品開発できるようになり
ました
開発だけでなく、会社組織も変えた
PMO（QA含む）
PM
エンジニアテストエンジニア
テストスタッフ
レビュアー
コール
センター
マーケティング
開発本部だけでなく、モノづくり
に関わる全ての部署がチームに参
画して、リリース後の責任を持つ
クオリティ
リーダー
テクニカル
リーダー

 かっちりとした品質の製品を、安定して作り出せるように
なりました
 上流工程で潜在的な障害・課題を検出するようにしたので
全体的な手戻りが削減されました
 製品リリース後に発覚する障害数の減少
 残業時間の軽減
 休日出勤の軽減
上流工程での品質確保
めでたしめでたし！
となればいいんですが...

 機能は要求を満たしているし、品質も安定している
 しかし実際に使われると、問い合わせが殺到
 コールセンター業務が回らなくなったケースがあります
ダサいUXで問い合わせが殺到

 迷った末に電話をかけたくなるUXでした
 不要な選択肢の提示
 必須入力の多さ
 不適切な案内手順
ライセンス認証機能

 次のバージョンで大幅にUXを見直しました
UXを大幅に見直し

 王道とレアケースを分離
 大多数のユーザーに最短ステップで「オンラインでライセ
ンス認証」していただけるUIフローに変更
インターネット接続有無は
システム的に検知できるので
このステップ自体が不要
入力項目も一画面に詰め込む
のではなく、必要なものを必
要なタイミングで表示する

 レアケースに相当するユーザーに対してはUIを特化
 問い合わせの絶対数を削減する工夫をしました
個別の事象に対して
自己解決を促す画面を用意
最終的にどうしても必要な場合のみ
電話の手段を提示

 電話認証の利用率が6.8%から2.3%に減少
 コール数を大きく削減できました
その結果
 UXの重要さを再認識した大きな転換点でした
 弥生は「ダサいは、バグだ！」をかかげて
UX改善に取り組んでいます
要件通りに作っても、
障害がなくても、
使いにくければ意味がない！

チームで使う
 メンバー間での成果物のクオリティを統一しましょう
1. 個々のメンバーがスタイルを設定する必要を無くす
 画面毎でスタイル設定に迷わされない
2. Wijmoコントロールの初期値を予め設定する
 基本的な用途においてはそのまま使用可能に
3. 設定可能なプロパティを絞る
 不要な設定に惑わされない
成果物の統一感が
締まった印象を与えます

見た目を統一する
 画面間でのスタイルの違いを無くしましょう
 WijmoにはCSSとテーマが用意されています
 コントロール毎のスタイルを1から用意する必要がありません

Wijmoコントロールを使う
 通常はcshtmlからヘルパーを使用します
cshtml
Wijmo.InputNumber
YayoiInputNumber
@Html.InputNumber(“name”, “value”, options)
(function(){
new YayoiInputNumber(“#name”, {
value: “value”
})
})();
export class YayoiInputNumber
extends wijmo.InputNumber {

Wijmoコントロールの初期値を設定する
 コントロールをそのまま使用可能にします
 Wijmoの既定値とアプリケーションが求める既定値は同じではありません
• 既定値を設定するJavaScriptのラッパーを用意
InputNumber controlTemplate
max
min
rightToLeft
showSppinner
controlTemplate ： Classの追加など
max
min
rightToLeft
showSppinner ： false
useCalc ：追加したプロパティ
YayoiInputNumber

設定可能なプロパティを絞る
 Wijmoに用意されたすべてのプロパティを使用するわけではありません
 不要なプロパティで開発者を惑わせないようにします
• cshtmlで使用するラッパーを用意
InputNumber
controlTemplate
max
min
useCalc
@Html.InputNumber
YayoiInputNumber controlTemplate ： Classの追加など
max
min
rightToLeft
showSppinner ： false
useCalc ：追加したプロパティ

コントロールのカスタマイズ
Wijmo（ウィジモ）開発

コントロールをカスタマイズする
 実装を簡易にしたり、必要な機能を追加します
1. 複数のコントロールを1つのコントロールとして使用
2. コントロールに存在しない機能を追加
3. 複数のコントロールを使用して新しいコントロールを作成

コントロールをまとめる
 複数のコントロールで1つの機能を実現します
 複数のコントロール間で処理が連携
 決まった処理が存在する場合に、各実装者で処理がずれることを防止
 期間選択コントロール
 カレンダー表示時の表示状態を画面から切り替え
 選択状態で日付の入力値を制御
期間選択コントロール
ComboBox InputDate InputDate
連携する処理

コントロールに機能を追加する
 Wijmoのコントロールに機能を追加します
 アプリケーションの要件に対応
 Wijmoに存在しない機能を追加
 数値入力コントロール
 日付入力のカレンダーのように電卓を表示
 計算結果をコントロールに反映
数値入力コントロール
InputDate Calculator表示

新しいコントロールの作成
 Wijmoのコントロールで新しいコントロールを作成します
 アプリケーションの要件に対応
 Wijmoに存在しないコントロールを作成
 科目選択コントロール
 カテゴリ選択でのジャンプ機能を持つコンボボックス
科目選択コントロール
科目選択リスト
ListBox
ListBox
ComboBox 表示

まとめ

 クラウドアプリとデスクトップアプリの融合が
今後ますます進むでしょう
 Webのフロントエンドの技術が、
Desktopでも使われる場面が増えるでしょう
 つまり、Webのフロントエンドの技術者の重要性が
今後ますます増していくでしょう
まとめ

 開発者ブログやってます！
 http://tech.yayoi-kk.co.jp/
 月1～2回のペースで勉強会「もくテク」を開催中！
 https://mokuteku.connpass.com/
もっと話を聞いてみたい方は...

 会場でお気軽にお声がけください
もっと話を聞いてみたい方は...

Toolsの杜- 弥生株式会社の自動仕訳エンジンを支えるフロントエンド～「ダサいは、バグだ！」を標榜してUXを徹底的に追求する～

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (14)

Ähnlich wie Toolsの杜- 弥生株式会社の自動仕訳エンジンを支えるフロントエンド～「ダサいは、バグだ！」を標榜してUXを徹底的に追求する～

Ähnlich wie Toolsの杜- 弥生株式会社の自動仕訳エンジンを支えるフロントエンド～「ダサいは、バグだ！」を標榜してUXを徹底的に追求する～ (20)

Mehr von Developer Solutions事業部メシウス株式会社（旧グレープシティ株式会社）

Mehr von Developer Solutions事業部メシウス株式会社（旧グレープシティ株式会社） (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)