2017-12-29

2017年の振り返り、そして 2018年へ

JET STREAM を聞きながらブログを書いています。

今年は人生の中で忘れられない年になりました。

新しい家族

春をすぎる頃に二人目が生まれ、生活が180度変わりました。そんななか会社やチームメンバーにも支えられ、奥さんが体力的に一番厳しい時期をサポートすることが出来ました。( 自分は出来たと思ってるだけで、直接評価を聞くのは怖いです^^; )

大仕事を終えた奥さんには感謝しかありません。

退職、フリーランス

前職はとても素晴らしい環境でした。できればもう一つか二つ、新しいプロダクトを作りたいという気持ちもありました。ただ 2016年に起きた熊本地震以降、熊本の両親、家族を大切にしたいという気持ちが強くなり、家族を連れて帰郷する決心をしました。

引っ越しはこれからですが、前職のプロダクトのお手伝いをさせてもらいながら、熊本での新しい生活の準備をしています。

個人開発

Android アプリ黎明期に、カメラアプリを作って公開していましたが、その手の仕事につくこともなく、Google Play での公開も終え、5年ほど仕事一筋な生活を送っておりました。

今年はフリーランスになるということで、触る機会がなかった Vue と React で Webアプリケーションを作ってみました。

PlantUML Editor

plantuml-editor.kkeisuke.com

これは Qiita やブログにも記事を書いていますが、仕事や個人開発で大活躍しています。

初めての Vue でしたが、公式サイトが充実していて、楽しんで構築ができました。Vuex も学習コストが低く、もっと早く使いたかったなと。直近では CodeMirror を導入したり、2018年も開発を続けて行きます。

Utility

utility.kkeisuke.com

二つ目は SQL や JSON をフォーマットするアプリです。これは React、MobX という構成で、UI には Semantic UI React を採用しています。仕事で API の吐き出す JSON や、SQL のログを漁ることが多いので、こちらも自分専用アプリになってます。

Semantic UI React はもはや HTML ではない感じで、input タグでアプリケーションを作るという苦行も後数年かなと希望が持てました。

PlantUML Editor、Utility 共に Netlify で運用しています。プランが寛大すぎて、大変素晴らしいです。

GitHub Pages からカスタムドメインで HTTPS 対応したくて Netlify に引っ越した際に検討した内容 · GitHub

その他

qiita.com

Qiita にも5件ほど記事を書いたり、ブログも2件ほど書きました。

来年も時間を作ってアウトプットしていきたいです。（寝かしつけを引き受けてくれている奥さんに感謝です。）

2018年

2017年は家族や将来のことを考えに考えた1年でした。また、改めてプロダクトを作ることが自分のやりたいことだと実感した1年でもありました。2013年から4年かけて立ち上げから運用まで行ったプロダクトも第一線を譲り、また新しい目標を探してもがいてみようかと思います。できればもっともっとユーザーの近くでプロダクトを作っていきたいなと考えています。

2017-08-07

PlantUML Editor の要求/要件定義

PlantUML

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

Nice online UML editor! Credit @kkeisuke https://t.co/26agRRy0o8 https://t.co/P0oCEVwtQe
— PlantUML (@PlantUML) 2017年8月1日

概要

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

背景

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

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

未経験者が手軽に PlantUML を試せる環境がない
- 各エディターのプラグインの場合 Java, Graphviz のインストールが障壁
各種情報共有サービスが利用できない。あるいは Crowi、GitLab などの運用もままならない場合
- 小規模、社内規定、予算都合 etc

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

コンセプト

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

対象ユーザー

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

ユースケース

PlantUML Editor ユースケース図

競合

atom：plantuml-viewer など
vscode：PlantUML - Visual Studio Marketplace など
Online Plant UML Editor
PlantText

機能要求

テンプレートを準備する
- 新規作成をできるだけ簡単にする
チートシート機能
- note や direction など
画面サイズを超える UML にも対応
- 拡大縮小
- 画像スクロール（縦横）
出力は SVG と PNG に対応
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年には宮崎から地元の熊本へ拠点を移し活動予定です。(退職理由は引っ越しです。)
少しでも興味をもって頂けましたら、ご連絡いただけると幸いです。
宜しくお願い致します。

2017-02-19

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

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

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

参考スライド

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

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

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

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

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

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

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

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

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