PlantUML Editor の要求/要件定義

細々と作っていた PlantUML Editor ですが、公式アカウント?から「Nice」を頂いたので、改めて要求や要件などを必要最低限まとめておきたいと思います

概要

PlantUML Editor はブラウザ上で PlantUML を試すことができるWebアプリです

背景

  • esaKibelaDocBase などの情報共有サービスや、Crowi、GitLab など PlantUML 対応が充実してきている
  • エディターについても atomvscode の PlantUML プラグインが普及している
  • フロントエンド分野でも DDD の機運が高まりつつあり(国内)、今後も UML の需要が維持もしくは向上することが見込める

一方、課題も見えてきている

  • 未経験者が手軽に PlantUML を試せる環境がない
  • 各種情報共有サービスが利用できない。あるいは Crowi、GitLab などの運用もままならない場合
    • 小規模、社内規定、予算都合 etc

技術的な要因等は Qiita にまとめています。
vue-cli (vuex) で PlantUML エディターを作ってみた - Qiita

コンセプト

  • 未経験者、初心者が手軽に PlantUML を試せること
  • 各種情報共有サービス等に移行しやすいこと
  • 小規模、個人の場合は継続して利用できること
  • PlantUML の良さを広めることに寄与できること
    • 上司、チームメンバー etc

対象ユーザー

  • PlantUML 未経験者、初心者
  • 各種情報共有サービス等の導入を検討している人
  • 個人アプリ制作などで PlantUML を利用したい人
  • これから PlantUML を社内で広めていきたい人

ユースケース

PlantUML Editor ユースケース図

競合

機能要求

  • テンプレートを準備する
    • 新規作成をできるだけ簡単にする
  • チートシート機能
    • note や direction など
  • 画面サイズを超える UML にも対応
    • 拡大縮小
    • 画像スクロール(縦横)
  • 出力は SVGPNG に対応
  • UML の出力はキーバインドとボタンを用意する
    • 最初はボタン。慣れてきたらキーバインドと使い分ける
    • リアルタイム処理は PlantUML サーバーへの負荷が怖いので避ける
  • 保存機能(履歴機能)
    • 継続利用するため。オリジナルのテンプレートとしても使える
  • SVG, PNG のダウンロードに対応
    • Excel 添付などしやすいようにする
  • Gist 投稿機能
    • secret 対応し共有しやすくする

非機能要求

個人アプリなので、運用に費用や労力を掛けることができない。できる範囲で運用を行う

  • 永続化
    • localStorage, indexedDB
    • DBサーバーなどは用意しない
  • アプリケーションサーバ
    • GitHub Pages で運用する。リポジトリGitHub に準備するので、デプロイも効率化される
    • HTTPS 対応するため Netlify で運用する。GitHub 連携機能があるので、デプロイも効率化される
  • PlantUML サーバー
    • PaaS の無料範囲内で運用する。今回は Heroku を採用する

テスト

これから準備していく

  • 複雑な業務ロジック等がないため、単体テストより E2E テストを整備していく
  • UML図(画像)の比較も行いたい

最後に

2017年8月末で6年勤めた現職を退職し、個人事業主になります。
2018年には宮崎から地元の熊本へ拠点を移し活動予定です。(退職理由は引っ越しです。)
少しでも興味をもって頂けましたら、ご連絡いただけると幸いです。
宜しくお願い致します。

PM するときに必ず見返すスライド、ブログ記事

今(2017/02/19)はBtoBで5名~10名程度(時期変動)のプロジェクトマネージャー兼プロダクトマネージャー兼SE,PG,雑用 etc 的なポジションで仕事をしています。折に触れてよく見返すスライド、ブログ記事があるのでまとめておきます。(人におすすめするときに毎回探さなくて良いように)

  • 2017/03/05 参考記事を追加しました。
  • 2017/03/17 参考スライドを追加しました。

参考スライド

開発組織のマネジメント // Speaker Deck

以下、メモ (感想とか、日々の反省とか)

  • 全体最適
    • ステークホルダーからの短期的な意見に対して、中長期的な目線を必ず入れること。また、説明し説得すること。
    • ともすると自チームの利益だけ考えすぎだが、もっと広範囲で有益であればやる。誰かがやらないといけないことは自分たちでやる。(自分たちが標準になる。結果さえ出せばそれが標準になりうる。)
  • 自己組織化チーム
    • アサイン権限がなくとも、ステークホルダーを自チームに引きずりこむこと。
    • なんでも自分たちでやってみる。企画、カスタマーサポート、営業。(それでも専門家がチームにいてくれるにこしたことはないけれど。リソース的にも辛いので。)
    • 人の出入りが多い場合もそれを想定したプロジェクト運営を日頃から行う。ナレッジを残し共有する工夫をチームでやり続けること。逆に思い切ってやらないことを決めてリソースを捻出する

開発組織マネジメントのコツ // Speaker Deck

以下、メモ (感想とか、日々の反省とか)

  • 問題発見
  • 対メンバー
    • メンバー同士だけで議論できるように持っていく。うまくいっているときは口を出さない。
  • コントロールできる対象をマネジメントする
    • 文化は結果であり、コントロールできない。日々の小さな意思決定を少しづつ変えていく。
  • 心理的安全性と責任
    • 無関心領域にいる人をどう引き上げればよいか。。。
  • 期待値調整 (フレーミング)
    • チーム内もそうだけど、ステークホルダーとの期待値調整も難しい。でもやらないと確実に失敗する。
  • 信頼を勝ち取る
    • 実績、結果を出さないと得られないけれど。。。
  • 指示待ちが得
    • 反面教師。待っててもいいマネージャーだと思われてる。
    • 逆に一挙手一投足ほうれんそうする人。これも反面教師。
  • 良いプロダクトと良いチーム
    • 「君のチーム、社内では技術力ある方だけど結果出てないよね」と遠回しに言われたこともある。

不確実さとうまく付きあうサービス開発 // Speaker Deck

以下、メモ (感想とか、日々の反省とか)

  • ユーザーを知る
    • 行動、価値観、文脈(背景)
  • チームで発想する
  • サービスのリリースはスタート
    • という期待値をステークホルダーと事前に合意しておくこと。スタートだと思ってるのがエンジニアだけだと灰になってしまう。
    • 営業組織に影響力がある場合(BtoB)、まずそこにファンになってもらえないと、ユーザーまで届かない。(売れない以前に売ってもらえない。)
    • 営業組織への営業力が必要。
  • コンパス
    • ユーザー(課題)、価値、体験、機能
  • 確かめながら作る
    • フィードバックが多すぎて納期に間に合わなかったらどうしようという不安との戦い
    • 「売れない、売ってもらえない」「ユーザーにガッカリされる」よりは納期が多少遅れて非難されるほうがマシ。(と腹をくくる。程度やケースの問題でもあるが。)

Qiitaの作り方 〜Incrementsのチーム開発とプロダクトマネージメント〜

参考記事

seleck.cc

  • 書いてある通りにやる。

blog.kentarok.org

  • 書いてある通りにやる。

techlife.cookpad.com

ozyozyo.hatenablog.com

  • 今どの段階か説明したり、俯瞰的にみて現在置を確認したり

blog.kentarok.org

  • 戒め

blog.yamotty.com

  • 売上は全てを癒す
    • 戒めその2

yappy727.hatenablog.com

  • 2017/03/05 追記
  • 身につけるべきスキル一覧
  • 全然足りて無くて凹みます。また、プロダクトマネージャーの必要性、重要性が分かる資料。(専任が必要)

yappy727.hatenablog.com

  • 2017/03/05 追記
  • 各フェーズ毎の解説