以前よりご要望の多かった請求書、見積書、納品書の「明細行数」と「備考欄」の文字数制限を緩和いたしました。
新しい仕様は下記の通りです。
この仕様変更により帳票が二枚になる場合がありますが、郵送料金とFAX料金はお値段据え置きでご利用いただけます。
明細行数が多くなりますと、セルの行間が短くなったり自動的に改ページが入ったりしますので、どのような表示になるかは事前にPDFダウンロード等でご確認をいただければと思います。
こんにちは、ブログ担当のトヨシです。今日は2014年7月に追加された会計ソフト「freee」との連携方法を紹介します。
freeeと連携することで、Misocaの売上データが簡単にfreeeに登録できるようになり、さらに作業効率がアップします。
Misocaの請求書をfreeeの売上としてボタンひとつで登録ができます。
それぞれのアカウントが必要になります。まだ登録がお済みでない場合は下記リンクからご登録ください。両サービスとも登録は無料です。
上記の事前準備が終わると、Misocaの請求書の詳細画面に[freeeに送る]というボタンが表示されるようになります。
ボタンを押して「freeeへの請求書情報登録が完了しました」と表示されれば送信完了です
いかがでしたでしょうか。Misocaで作った売上データがワンクリックで記帳できるのはとても便利ですね。他にも請求書のデータを弥生形式でダウンロードすることや、MFクラウド確定申告、MFクラウド会計連携機能（マネーフォワード）との連携も可能です。ぜひお試しください。
2014年8月9日（土）～2014年8月17日（日）まで、Misoca（スタンドファーム株式会社）は夏季休業とさせていただきます。
ご不便をおかけしますが、何卒ご理解いただきますようお願い致します。
スタンドファームではクラウドで請求書を管理できる「Misoca」というサービスを2年前から提供しています。
今日はMisocaの機能を強化していく過程がどのように行われているのか過去から現在までの開発プロセスの進化をご紹介したいと思います。
まずはカウボーイ期から。
Misocaはスタンドファーム創業者である豊吉(@toyoshi)と松本(@Dominion525)の2人によって作られました。
そこにアルバイトとしてプログラマーを数名を雇うことになりました。そのため2人だけで共有していればよかった情報をチームとしても共有する必要が出てきました。
しかし、当時はチームとして活動する意識が低く、今までの2人だけで作業をしていた環境を引きずるようになってしまいました。この頃はまだ受託開発が主な業務内容であったため、チームとして活動する必要性が低かったこともあります。
個々のプログラマーに対して、豊吉と松本のどちらかが指示を出し、プログラマーがSubversion+Redmineを使いながら進捗を報告する、という流れで開発が進んでいました。
プログラマーからすると、指示をもらってレビューをしてもらうのは常に豊吉、松本のどちらかでした。この時期の問題点は2点です。
チーム全体として情報交換をする場が設けられていないため、他のメンバーの作業をよく知らないまま開発が行われていました。少しでもメンバー間のコミュニケーションを促進しようとChatWorkを導入したり工夫を試みましたが劇的な改善にまでは至りませんでした。
それでも、まだせいぜい数名のチームのため大きな問題には至りませんでした。
そんな状況ですが、ツールは常に新しいものを取り入れようという意欲はありました。
問題があるのはわかっているが、どう改善したらよいのかわからない。もがきながら開発してる時期でした。
スタンドファームは2013年9月に資金調達を行いました。それまでは受託開発を主な収益源としていましたが、これを期にMisocaの開発を本格化させて行くことになります。
その結果、新たにWebマーケティング担当やプログラマーがチームに参画しました。
さすがに従来の豊吉、松本が直接指示〜レビューするプロセスのままでは限界が見え始めています。
そこで改善案として出されたのが、「週一で開発ミーティングをやってみよう」というものでした。
開発ミーティングの内容は以下の通りです。
発表会とはスクラムなどで言う、スプリントプランニングから着想を得ていますが目的が異なります。
スプリントプランニングはチームの作業をプロダクトオーナーが成果として受け入れるかどうか、という会ですが、
この時のスタンドファームでいう「発表会」とは単にお互いの成果を共有をしましょう、ということが重視されていました。
既にふりかえりというイベントがスタンドファーム内で行われていました。
しかしふりかえりといっても開発プロセスについて改善を考えるものではなかったため新たに設けました。
それまではMisocaのロードマップがチームに対して語られることはありませんでした。チームとしての形になっていなかったため話すことの必要性も感じていませんでした。
それはよくない、ということで、豊吉、松本に直近で予定している機能追加について話してもらう場をつくることにしました。
以上のことを、毎週、月曜日に実施しました。
それまでは個々のことだけしか見れなかった環境であったのを、チームとして取り組む意識を根付かせる時期だったと思います。
しかし、ミーティングを開催するものの、個別の議論に深入りしすぎて予定の時間をオーバーするなどして、開発の時間を圧迫する事態に。そこでまずはミーティングの時間を計測して記録を取るようにし始めました。ダラダラと時間を消費することを好まないメンバーばかりであったため時間についての意識は常に全員が持っていました。
開発ミーティングをすることでチームとしての一体感が生まれてきました。次に望まれたのが、より詳細なタスクの管理と見える化でした。
Misocaでは機能の追加を重視して開発されていたため、細かい使い勝手の改善が放置されがちでした。
この時期にパートタイムのアルバイトとしてプログラマーが2名増員されました。フルタイムでは働けないため大きな機能の開発は任せられません。そこで、後回しにしていた細かいタスクをしてもらうことになりました。
そのために、タスク管理には「機能追加」と「機能改善」を分けて管理する必要が出てきました。
当時は、Pivotal Trackerで開発タスクを管理していましたが適切に運用されているとは言い難い状況でした。みんなでタスクを共有している、という意識が欠如していました。
そこで考えだされたのが、スタンドファーム版(社内ではコクボ式とも呼ばれる)タスクかんばんです。デジタルなツールに頼るよりもまずはアナログなホワイトボードを持ってきて、フリーフォーマットでやってみよう、という話になりました。
「機能追加」と「機能改善」の境界を上下で分けて付箋を貼ってタスクの見える化をするようになりました。
メンバーのTwitterアイコンを印刷したマグネットを作成して担当している付箋(タスク)に貼るようにしました。
このスタンドファーム版タスクかんばんによってタスクを管理して、開発ミーティングなどを進めることにより、お互いの状況の把握がより容易になりました。
自分以外のタスクも含めてチームとしての取り組むべきものだと意識付けに取り組んだ時期でした。
しかし、同時に次の課題へと直面しました。
スタンドファームは名古屋の会社です。オフィスも名古屋にあります。
名古屋だけではなく岐阜や東京で働くメンバーもいます。
それに加えて、2014年に入ってから、スタンドファームではリモート勤務が自然と取り入られるようになったため、普段はオフィスに来ているメンバーも自宅で仕事をする日も増えてきました。
リモートメンバーとオフィスメンバーの垣根をなくすために、Googleハングアウトで常時会話ができるようにしました。高解像度カメラと広角カメラの2種類を用意して、指向性のあるマイクも導入しました。2種類のカメラを使い分けることで、的確にリモートメンバーへ映したいものを映せるようになりました。
開発ミーティングにも可能な限り、リモートの人に参加してもらうようになり、コードレビューや発表会もハングアウトの画面共有を使って全メンバーで行うようになりました。しかし、頑張ってカメラで映してもどうにも伝わりにくいものがありました。それがアナログなホワイトボードを使ったタスクかんばんです。
タスクかんばんの致命的な問題は次の2点です。
それまでは、「まずはオフィスメンバー内だけでの意識改革をやろう」と行ってきたのが、リモートメンバーを含めてチームとしての一体感を出す方向へと舵を切り始めました。
(Webカメラを使ってタスクかんばんをハングアウト経由で共有するなど試してみましたが、コストに見合うほどの効果はありませんでした)
そこで決断したのが、
です。
タスクの管理はTrelloに集約することにしました。ふりかえりもKPTを付箋に書くことをやめました。
さらにアナログ偏重のため、Trelloの更新が怠りがちだったのを改善するため、朝会時に進行中のすべてのカードのステータスの更新を全メンバーの前でやるようになりました。個人の特徴が大きく出るアナログ的な良さが失われたのは確かですが、それ以上にリモートメンバーを含めて、全員がチームとしての一体感を出せる選択をしました。
今も毎日、試行錯誤しながら「チームのパフォーマンスを最大化する」ための改善を日々取り組んでいます。
今見えている課題としては以下の2点です。
見積については、自社サービス開発であるが故に後回しにされてきました。見積をするためのコストと得られるメリットのバランスを見ながら取り組んでいきたいと思っています。
コードレビュー・仕掛中Pull Requestについては、やはりまだメンバー個々で黙々と頑張る文化が残っているために協調作業が難しくなりがちになってしまいます。チームメンバーの殆どがフルタイムではなくパートタイムでの勤務のため、致し方ないところはあるのですが、今後取り組んでいくべき課題だと認識しています。
開発ミーティングの一部として「発表会」があります。発表会は今では「豊松会」と呼ばれています。その経緯についてご紹介します。
元々、発表会の目的は「自分がやった成果をみんなの前でアピールしよう」という趣旨でした。
それが会を重ねるごとに「(主に)豊吉、松本からのフィードバックを受ける会」に変わってきました。
「発表する」と必然的に「フィードバックを受ける」ことになります。そのフィードバックを受けることにチームとして価値を感じたためです。そして、豊吉、松本はMisocaの責任者であるため機能や仕様を決めるのは必然的に2人の同意が必要です。
2人とも自分が関知しない仕様になることを望みません。
その2人からのフィードバックを重視する(2人が揃っていないと意味がない)という意味で豊吉と松本の頭文字をとって「豊松会」と呼ばれるようになりました。
(開発ミーティングを企画した者としては、発表会を切り口にフィードバックをもらう流れをつくりたかったため、予定通りの展開です)
通常、スクラムなどでいうバックログにはReadyな状態になっているバックログ・アイテムが入ると思います(要件から受入基準までしっかり練られている)。
スタンドファームではバックログ・アイテムがReadyかどうかは重視されません。これは、新機能の追加をどういった仕組み(UIや表示項目など)で実現するのか最初から決められないためです。
ふんわりした要件からサンプル設計・実装と豊松会によるフィードバックを繰り返しながら細部をつめていきます。なので、スタンドファームでは明確なイテレーションの単位がないとも言えます。
豊吉、松本が常にチームと近い距離感にいるため最初からバシッと決めるよりも、細かくフィードバックを受けて細部を詰めていく方向へ流れています。要件を出す人と開発するチームの距離が精神的にも物理的にも近いからこそできることですね。
タスクかんばんは運用開始してから数ヶ月で終了することになりました。
果たしてタスクかんばんは必要なツールだったのでしょうか？
いろいろな視点があると思いますが、私たちは必要だったと考えます。チームのタスク管理を本気でやろうと思った時、まずはアナログでやったことに大きな意味がありました。
アナログであるが故に物理的にもオフィスの一部になるわけでその存在を否が応でも自分たちのことだと意識することができたと思います。またメンバーそれぞれの身体性を視認できることもアナログの大きなアドバンテージです。
デジタルとアナログのどちらがよいか、という優劣の問題ではなく、これは選択の問題です。
チームのアクティビティはTrelloとGitHubのPullRequest一覧を見ればすべてわかるようになっています。Qiita:Teamは最近になって取り入れられたのですが、日報を書くという習慣が定着することで想像していた以上にチーム間の結びつきがよくなった気がします。日報といっても各自の裁量で書かれているため緩い内容ですが、ゆるふわな空気で組織の文化をつくるのに役立っています。
Pivotal Trackerはとてもよくできた優秀なツールでしたが、ツールの持つプロセスの制約が強すぎて使いこなせませんでした。
小久保 祐介 (こくぼ ゆうすけ)
株式会社ファントムタイプ代表取締役
2013年12月よりMisoca開発者としてチームに参画。プログラマーとしてMisocaの機能開発を行いつつ、本記事でご紹介したような開発プロセスの改善にも取り組んでいます。株式会社ファントムタイプはスタートアップ企業の成長を応援する会社です。
いつもMisocaをご利用いただきありがとうございます。
この度、Misocaからクラウド会計ソフト「freee」に請求書情報を送る機能を追加、公開いたしましたので、お知らせいたします。
Misoca上で作成した請求書の情報をfreeeに送信することで、freeeの取引（収入）として取り込むことができる機能です。
通常ですと手作業で入力していた作業が、ボタン一つで完了します。
※2014年6月18日現在 freeeに事業所を複数登録している場合も連携する事業所の選択はできません。次回アップデート（6月30日を予定）にて選択できるよう対応予定です。
ビジネステンプレート
経理の教科書
人気記事
便利な見積項目リスト
最新記事
カテゴリ
