1. 最後に

1.1. 柔軟な開発手法の選択

エクメルンの開発では以下のように開発手法は柔軟に変更しました。特に大きな問題はなく開発できました。

ローンチまではウォーターフォール型
MVP、今回のケースの期間では急激な市場の変化は考えられない、要件変更もなさそう、骨組み部分はきっちりと作り込みたい、といった背景から、詳細なドキュメントは省きつつもきっちりと設計を行い、かつ粒度大き目のガントチャートでクリティカルパスをコントロールしながら開発しました。
ローンチ後はスクラム型営業活動、社内からの反応、サポート問い合わせから少しずつ改善するスタイルに適したスクラムに変更しました。

1.2. プロジェクトと自己実現の歯車をあわせる

各メンバーでプロジェクトを通じ成し遂げたいこと (○○をやってみたい、○○の技術を習得したい、○○を導入してみたい) を事前に話し合い、できるだけチャレンジできるようにしました。効果は以下の通りです。

個として成長できた
仕事自体が自分へのご褒美となり終始モチベーション高く仕事をすることができた
アウトプットへのこだわりが高まった→ ギリギリまで「もうちょっと、もうちょっと」のプロフェッショナルな精神が生まれました。
他メンバーから刺激を受けることで向上心が生まれた→ 他メンバーから「○○をマスターした」と聞くと自然に「自分も負けていられない」となりました。

1.3. 分報の導入

Slackで試験的に分報を導入してみました。各々自分専用の公開チャンネルを作り、限りなくTwitterに近い、ノルマなし、仕事・プライベートのつぶやきなんでもござれのゆるふわ運用で6ヶ月ほど経ちましたが、いい感じにワークしています。効果は以下の通りです。

詰まったところを誰かが助けてくれる
解決しなくとも一人で悩まなくても良いという安心感
他メンバーから刺激を受け、向上心が生まれる
つぶやくことで自分の頭の中を整理できる (一人壁打ち)
作業ログとして残せる→ 実際に「この時間帯に○○の作業をしていたらつじつまあうよね」「この時何してたっけ？」といったケースがありました。
作業の見える化で自律心が芽生える
特定の相手にメンションするほどでもない内容を書き置きできる
くだらないことで盛り上がったり嫌なことも愚痴ってストレス発散できる

1.4. ドキュメント管理ルール

あとあと悪い意味で枯れていくことが多いドキュメントの管理には以下のルールを設け、今のところうまくワークしています。

ドキュメントはすべて一つの場所に集約する→ 集約化によって検索性を高め、情報の重複化を防ぎました。新規メンバーの導入コストや引き継ぎコストを抑える効果もあります。
定期的にクリーニングを行う (要不要の判断がつかないドキュメントは思い切って断捨離)
→ できるだけ有益なドキュメントのみとしておかないと、不要なドキュメントの更新や、必要なドキュメントの作成・更新の放置が行われだし、最終的に保守性の低下や属人化につながります。

1.5. プロジェクトは学びの場

エクメルンの開発メンバーは開発のみならず、製販一体となってものづくりを行いました。具体的には、問い合わせのサポート業務を行ったり、エクメルンを認知させるための活動を行ってきました。デベロッパーとして技術力を高めることは当然してきましたが、このプロジェクトを通じて、エクメルンを使われるサービスに育てるために、類似サービスに目を向けたり、どのように商品説明をすればサービスを使ってくれるだろう？とビジネスサイド目線からも物事を考えるようになりました。

お客さまからの問い合わせ一つにしても、「この人はどういった立場で、何を思い、何を知りたいのだろう？」このように考える事ができます。「仕様です」ではお客さまの納得は得られないのです。

技術力 x ○○力の掛け算が、デベロッパーとしての価値になるのだと思います。あなたがデベロッパーであれば、ものを作るだけではなく他の仕事にも目を向けてみて下さい。そこにはきっと学びがあります。

CoffeeBreak
ドキュメント断捨離のポイントは「その情報は何のための情報なのか？」ということに絞りました。あるあるとしては、設計・開発フェーズには各機能の整合性を取ったり頭の整理に必要だったが、実装後は不要、といったケースが多くみられました。また、粒度の細かい情報は不要となるケースが多いです。

最後に