失注した案件を振り返る (マネジメント編)

先日個人的に受注 & 失注 した案件で得た教訓を記憶が新しい内にまとめる.
本記事はマネジメント編.

この記事ではこんなことを書いている.

  • チーム内外へのコミュニケーションはこんなことを気を付けたよ
  • こうするべき, あぁするべき ってことを経験談から紹介

技術的な内容は極力排除したけど, チーム開発スピードアップに必要そうな箇所については補足してある.

いつも通り厳密性を排除してゆるく, ふわっと.
概要は次の通り.

対象読者

対象読者は直近の私の状況に近い人を想定.

  • マネジメント経験がないエンジニア/デザイナ
  • 「取引しない」というカードを切りたい人

本案件着手前の自分がターゲット.

Overview

本記事の概要を箇条書きで紹介.

  • マネジメントについて
    • チーム内
      • 実装
        • 事前に大まかな実装をしてレールを敷こう
        • メンバ参画前に可能な限り仕組み化しよう
      • コミュニケーション
        • 伝えたい情報を可能な限り具体的な言葉にして先出ししよう
    • チーム外 (お客さん)
      • 誠実な対応を心がける
      • mtg 内容は記録に残そう
      • 取引しない, という選択肢を持とう
    • 自分
      • 忙しさに潰れる前にメンバに頼ろう
      • 違和感への気付きを大切にしよう
  • よかったこと
    • vagrant で provisioning スクリプトを作成することでメンバの環境構築作業負担軽減
    • 取引しない, というカードが切れた
  • 反省点
    • メンバに対して
      • 実装のレールを引くのが遅れて手戻りを増やしてしまった
      • 〆切が近付くにつれ, メンバへの slack 文言がキツくなってしまった
    • 自分に対して
      • 受注の時点で「友人」「お客さん」の線引を明確にして契約書を作成するべきだった
  • まとめ
    • 一番伝えたかったことは 「取引しない」 選択もアリだよってこと
    • この案件直後に『カイゼン・ジャーニー』読んだよ
    • 次回はもっと上手くチーム開発ができるように頑張る

記事をなるべく短くするために適宜省略しながら各項目について紹介する.

マネジメントの定義はこうした

まずマネジメントの定義について.
解釈の幅が広すぎる management って単語を私はこう定義した.

  • 自分の考えを劣化少なく相手に伝えるための手段

management って単語を見聞きすると「管理」って漢字を当てはめたくたる.
多くの場合「control したい」ってニュアンスで使われるよね.

私は人もプロジェクトも control したいわけじゃない.
頭の中で考えていることを適切に相手に伝えたいだけだ.
だから management は情報伝達の手段だと定義した.

この定義は自分も関係者も気分良く働くための土台となる.
そう, 私は気分良く働きたいんだ.
開発メンバにも気分良く働いて欲しい.

誰かに命令されてやりたくもない作業を嫌々やるんじゃない.
我々も, お客さんも, ある課題を解決してビジネスを前進させるために目の前の作業をするんだ.
こんな気持でゴリゴリ開発できるように.
こんな気持で新しい技術に触れることができるように.

お客さん & メンバ を支配してやろう, って気持ちがあると自ずと言葉や態度に出ちゃう.
上流工程に関わる人やリーダー経験のある人, 社内の予算を管理する人なら思い当たる点があるのでは.

気分良く働きたいって気持ちが根本にあるから, 私にとって management って言葉を自分なりに再定義するのは最重要事項だった.

受注 ~ 失注 の概要

案件概要はこんな感じ.

  • この案件を一言でいうと?
    • 知人からの HP 改修依頼
  • 依頼主は?
    • 知人
      • 映像制作系40代前半女性社長
  • 依頼のきっかけは ?
    • 数年前に知人が法人化したんだけど, そのときに簡単なコーポレートサイトを作ったのがキッカケ
  • 今回の依頼で実現したいことは? (知人, 私 各視点で紹介)
    • 知人視点
      • HP内で Youtube 非公開動画を知人の知人(つまりこの女性社長の知人)にポートフォリオとして公開したい
        • 現状は非公開, 限定公開の状態で Youtube にポートフォリオを置いている
      • HP の動画一覧ページにはパスワードを掛けたい
        • パスワードを知ってる人だけが HP 内で動画を見れるようにしたい
        • このパスワードは自分で自由に変更したい
      • HP に表示する動画に独自のコメントを付けて表示したい
      • 納期は2019年内ならいつでもいいよ
    • たきもと視点
      • Youtube の API 叩かなきゃ
        • 公開状態を問わず動画取得する方法ってあるのかね?
        • OAuth 的な認証突破する必要があるのでは?
      • アプリケーション側で特定ページに Basic 認証かけなきゃ
        • .htaccess を利用した Basic 認証は知人自身でパスワード設定できないから却下
      • 管理画面作らなきゃ
        • 動画 公開/非公開 コントロール
        • 動画一覧ページパスワード コントロール
  • 失注の決め手
    • リリース後も無償での仕様変更を幾度も求められたこと
    • 喧嘩腰のメールに耐えられなくなったこと

案件概要については以上.

チーム内のマネジメント

チーム内マネジメントについての所感は次の点に分けて紹介.

  • メンバ構成
  • 実装
  • コミュニケーション

以下, 詳細.

メンバ構成

今回のメンバはこんな感じ.

メンバ PC エディタ 経歴 筆者との関係
たきもと mac Vim 元 半導体エンジニア, 現 WEB エンジニア この記事を書いている人
友人 A win Sublime Text 元 SE, 元 営業, 現 一人社長 大学院時代の同期
友人 B mac Atom プログラミング実務未経験 学部時代の同期

メンバは3人.

開発マシン OS は win, mac 混在してた.
改行コードが問題にならないように git の設定について repository の readme に事前にまとめて共有した.

エディタはバラバラ.
.editorconfig でコーディングスタイルはそれなりに統一可能.
ただ, 採用している linter に差があったから最終的に細かい書き方が気になっちゃった.

経歴は表の通り.
私 & 友人A が開発~運用までの知見があった.
友人B は完全に未経験.

私とメンバの関係は友人.
友人A, B は互いに直接の面識はない.
住んでいる場所も 東京(私), 茨城(友人A), 栃木(友人B) って具合に離れているし.
slack のアイコンと文章の雰囲気から人柄を察してもらうスタイルで参画~リリースまで過ごした.

実装

ここでは実装について.
もっとこうすれば良かった, って内容.

イチからプロダクトを作るときは dir. 構成やデータへのアクセスパターン, sass構造(FLOCSS 等)に拘らず好き勝手に作れちゃう.
だからこそ, 期待する実装パターンがあるならメンバ参画前に実装しておくべき.
そうすれば新規参画者は既存コードに倣って開発を進めることができる.
これだけで混乱が減るし, 各々の開発スピードが上がる.

私はこれができなかった.
上記の点を押さえて早めに動けばよかったと後悔している.

あと, なるべく開発に専念できる環境を整えておくことも大切.
私は vagrant 起動時に読み込む shell script を用意してメンバによる環境構築の手間を削減した.

コミュニケーション

チームメンバとのコミュニケーションは次の2点を意識した.

  • 具体的な言葉を使う
  • 先出しする

日頃意識しないけど, 主語(or 目的語) & 動詞 を使えばそれだけで考えが伝わりやすい.

  • e.g.) Repository class (の xxx method ) を使って欲しい

メンバとのコミュニケーション時に主語, 動詞は省略しちゃダメ.
じゃないと, 高確率で認識齟齬が起きる.
今回の開発ではこの点を意識したからか, メンバとの間に大きな認識齟齬は起きていない.

情報の先出しはメンバにも私にもメリットがある.
たとえばこんなメリット.

  • メンバ
    • 心の準備ができる
    • 「突然そんなこと言われても…」 っていう心理的負担が減る
    • 情報共有漏れ防止
    • 調査・モック作成等で手伝ってもらえる
      • (コレは友人Aがとても優秀だったから)

たとえば友人Aへの情報の先出しはこんな形で返ってきた ↓

  • 不明点を調査し, 結果をまとめて教えてくれる
  • モック作成をしてくれる
  • 気を利かせた実装をしてくれる
  • 顧客との折衝をする上でのアドバイスをくれる
  • etc…

これらは自分の時間の節約にも, プロジェクト前進にも繋がる.
ここで出した例は友人Aが優秀だからこそかもしれないけど, 私は本当に助けられた.
情報の先出しって大切.

チーム外 (顧客) のマネジメント

お客さんとのマネジメントについての所感は次の通り.

  • 誠実な対応って大切
  • mtg 内容を記録に残すのって大切
  • 取引しない, というカードを切って後悔を未然に防ぐ

1, 2 点目については省略.
ここでは3点目について.

取引しない, というカードを切って後悔を未然に防ぐ

先述の通り, 本案件は失注した.
ここで 「取引しないって選択もアリ」 という教訓を得たので紹介したい.

プロダクト完成後, 本番環境へデプロイし, 稼働費用を頂戴することなく最終的にこちらからお断りした.
理由は喧嘩腰の仕様変更要望への対応に私が疲れたから.

お断りした際, 本番環境は改修前の状態に全てロールバックした.
メンバへは然るべき稼働費用を支払った.

私はフリーランスになって以来, 厳しい決断をするときに次の点を判断基準の一つにしている.

  • 目先にお金を得る代わりに失うものは何か
  • 目先のお金を失う代わりに得るものは何か

今回「取引しない」というカードを切ることで失ったものはこれ

  • 受注->納品 で得るはずだった利益
  • メンバへの稼働費用

失ったのはお金だけだね.
逆に, 得たもの・守れたもの・削減できたものはこれ

  • 喧嘩腰のメールに耐える時間削減
  • 開発メンバへの顧客像を共有する際の心苦しさ
  • 次のような印象・前例を作らずに済んだ
    • 「無理を言えば事前の取り決めを破っても開発してくれる」という印象
    • 「喧嘩腰のメール・skype を送れば要望が通る」 という印象
    • 「私の記憶では~ xxx」 という記憶頼りの仕様変更

お金は大切.
でも, 私は目先のお金よりも 人としての誠実さ や ビジネスパートナーとしての信頼関係 の方がもっと大切.

大切なものがある, または, お客さんに対して誠実な対応を心掛けている自負がある.
その場合は「取引しない」というカードを切ろう.
このカードを切ると一時的に後悔するかもしれない. 得るはずだったお金を失うしね.
でも, 大切なモノを失って一生後悔するよりは何倍もマシだ.
日々誠実な対応を心掛けている自負があるのなら, このカードを切ることは然程難しくない.

自分のマネジメント

開発期間中の自分自身のマネジメントについて.
私は心の平穏を保つため, または, 頭の中身を常に整理しておくためにこんなことを実践したよって話.
概要は次の通り.

  • 落ち込まないためにルールを作る
  • ランニング・筋トレで頭の中身を空にする

落ち込まないためにルールを作る

まずは落ち込まないためのルールについて.

今回の案件は元々知人だった人がお客さんになった事例.
立場が変わっただけで態度や言葉遣いが豹変するのを目の当たりにして驚いた事例.

案件終盤は落ち込んでいる時間が長かったが, 次のルールを取り入れて随分気持ちが楽になった.

  • ここまでは自分の責任, ここからは相手の責任 という線引をする

チーム・部署単位ではこの考え方は不要.
ビジネスを前進させるための協力関係が崩壊するから.

でも, お客さんや取引先に対しては明確な線引が必要.

先述した内容と重複するけど, 誠実な対応をしている自負があるのなら相手の責任まで背負い込む必要はない.
心身を削って取り組むべきことは他に山程あるはずだ.

中~大規模の会社では営業部隊やカスタマー対応部隊がいるはず.
今回の一件で身に沁みたけど, 彼らが日々これほどタフなやり取りをしている事を考えると頭が上がらない.

ランニング・筋トレで頭の中身を空にする

次に頭の中身を空にすることについて.

頭を空っぽにできるものなら何でもいい.
ゲームでもドライブでもちょっとした散歩でも.
私の場合はランニングと筋トレだ.

経験則だけど, 一時的に仕事から離れて体を動かした方が目先の問題が片付きやすい.
頭の回転効率が向上する気がする.

もし頭の中がいっぱいになり, 目の前のたかだか 1, 2行の文章すら読めなくなったら運動靴を履いてランニングに出掛けよう.
もしくは上着を脱いで簡単なストレッチ・筋トレを開始しよう.
PCの前に戻ってくる頃には頭の中身が空っぽになり, 目の前の問題が瞬く間に解決するだろう.

私は体育会系じゃないけど, この脳筋な気分転換方法をいたく気に入っている.

よかったこと

ここまでざーっと案件概要について振り返ってきた.
ここでは本案件を通してよかったことを紹介.
概要は次の通り.

  • 実装面
    • vagrant で provisioning スクリプトを作成することでメンバの環境構築負担軽減
    • gitLab Boards でチケットをカンバン方式で管理
      • チケット単位の実装を実現
    • チケット単位のレビューによる src 品質の担保
  • マネジメント面
    • 議事録を残すことで「言った」「言わない」問題を回避

以下, 詳細.

実装面

実装面でよかったことはコレ.
ちょっと技術の話が含まれるけどご容赦を.

  • vagrant で provisioning スクリプトを作成することでメンバの環境構築負担軽減
  • gitLab Boards でチケットをカンバン方式で管理
    • チケット単位の実装を実現
  • チケット単位のレビューによる src 品質の担保

2, 3 点目は多くの現場で行われているから省略.
1点目について簡単に紹介.

メンバ数に関わらず環境構築は工数が嵩む.
たとえばこんな状況に陥りがち.

  • ホストマシン OS が異なる場合, 改行コード問題, 文字化け問題, etc.. が爆誕
  • 環境によって動いたりエラーになったりする問題が爆誕
  • 経験が浅いと LAMP 環境を自力で構築できないから開発が進まない

この辺の問題を避けるために shell script をゴリゴリ書いた.
Vagrantfile に shell script を記述したファイルを指定することで $ vagrant up 時に provisioning が実行される.
(私は明示的に --provision スイッチを付ける方が好き)

shell script の処理内容はこんな感じ.

  • apache
    • virtual host 設定
    • ssl 設定
  • mysql
    • migration & seeding
  • php
    • laravel プロジェクト作成
    • composer install
  • node.js
    • npm install
  • その他
    • log ファイル出力

ディレクトリ構成はこんな感じ

$ tree -L 2 provision/

provision/
├── apache
│   ├── apache.sh
│   └── ssl
├── common.sh // ディレクトリ path など共通変数を定義
├── database
│   ├── database.sh
│   └── mysql
├── laravel
│   └── laravel.sh
├── log
└── setup.sh // 処理の本流. 他の shell script を呼び出して実行

あとは git commit message 先頭にチケットID を付けるための shell script や, larave の cahce clear 系コマンドをまとめた shell script を書いたりした.
commit message については以前記事にまとめたのでご参考までに.

マネジメント面

マネジメント面でよかったことはコレ.

  • 議事録を残すことで「言った」「言わない」問題を回避

世の中のお客さん全てが次のような行動を取ってくれるわけではない.

  • 送信したメールをキチンと読む
  • 説明資料にキチンと目を通す
  • MTG した議事録にキチンと目を通す

今回の案件をお断りした決め手になったのは次の2点だ.

  • メールによる罵詈雑言
  • 記憶ベースの「言った」「言わない」問題に発展させたリリース後の仕様変更要求

私は MTG 内容, 相談・決定事項等は全て議事録として残している.
これはメンバに対してもお客さんに対しても.
結果として言った言わない問題に毅然とした態度で対応できたんだけど, それはこの議事録のお陰だ.

残念ながら, 世の中には議論や要求を「言った」「言わない」問題に発展させたがる人がいる.
火のないところに煙を立てたがる人, と言ってもいい.
こういったケースには議事録が有効だ.
そう, 確かに有効なんだけど… 非生産的かつ消耗するよね, このやり取り.

私は世の中が良くなったり, 困っている誰かの問題を解決するために能力を活かしたい.
時代や国を超えて尊敬される価値 (努力, 誠実, 愛, 勤勉, 愛 など) を私も大切だと思っているし, 手放すべきではないと思う.
だからこそ, 議論をするでもなく, 妥協点を探るでもなく, 罵詈雑言と相手を貶めるような手段で要求を押し通そうとする人にいつまでも付き合うつもりはない.

議事録は有効だけど, あなたが考える正義に反するお客さんとの取引はしない方がいい.
さもなければお金よりも大切な何かを失うことになる.

反省点

山ほど心当たりがある反省点から次のものを紹介.

  • メンバに対して
  • 自分に対して

以下, 詳細.

メンバに対して

メンバに対する反省点は次の通り.

  • 実装のレールを引くのが遅れて手戻りを増やしてしまった
  • もしかしたら黙って我慢してお金を受け取るべきだったかもしれない

ここでは2点目について.

元営業職の友人Aには逐一 罵詈雑言問題 を含めてお客さんとのやり取りについて相談していた.
その中で次のようなアドバイスを slack で貰った. (本文そのまま掲載)

まぁ深追いしなくては良いと思うけど、成果物は出てるから代金は受け取った方が良いと思うよ。
受け身でも良いので。
向こうから振込依頼があった場合にはプライドで拒否せんようw

我々の仕事は納品して初めて対価が得られる.
今回は友人Aが言うところの プライド と 対価 を天秤に掛けた上で対価を放棄した.

ビジネス視点では対価を得て, その中から私を含めたメンバの稼働費用を支払うのが正解だと思う.
もしかしたら, 私が大切にする価値やプライドを捨てて対価を得るのが正解だったのかもしれない.
けど, 確信はない. 私のちっぽけなプライドが邪魔しているのかもしれない.

今回の決断に後悔はないけど, 将来もこのままでいいかは疑問.

  • もし, 自費で賄えないほどメンバが増えても価値観を大切にするか?
  • もし, もっと大規模案件だったら悪印象を与えてでも価値観を大切にするか?
  • もし, 顧客との折衝まで依頼されても価値観を大切にするか?

この辺はもう少し自問自答が必要かも.

自分に対して

この記事全てが反省文のようなものだから 自分に対して というのは妙だけど…
自分に対する反省点は次の通り.

  • 受注の時点で「友人」「お客さん」の線引を明確にして厳密な契約書を作成するべきだった
  • 先方を敵だと認識してしまった

1点目は言葉通りなので省略.
ここでは2点目について.

最終的に「取引しない」カードを切ったことに後悔はない.
メールでの罵詈雑言や強引なコミュニケーションへの落胆も一旦脇に置いておこう.
そんなことよりも, 自身のプロジェクトで私が落ち込み先方を敵だと認識した点はもう少しどうにかならなかっただろうか.

国や人種を問わず, もっと多くの人といい仕事がしたい.
相手の正義を理解しつつ, 自分の正義も伝えて前進したい.
そのためにはもっと人間の機微に聡くなる必要がありそう.

ここが自分の弱点.

まとめ

記事が長くなったね.
今回一番伝えたかったことはこれ.

  • 取引しない選択もアリ

ところで, この失注案件がキッカケで次の本を読み始めた.

  • 『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』

超満員の田園都市線で毎朝押し潰されながら kindle で読んでいる.
今回の経験とこの本からの得た学びを次に活かすために.
次回のチーム開発の際(それが個人的なモノでも, コミット先の企業のモノでも)今回よりももっと上手く走り切りたい.

今回は以上.

スポンサーリンク
336 x 280 – レクタングル(大)
336 x 280 – レクタングル(大)
  • このエントリーをはてなブックマークに追加

この記事が気に入ったら
いいね!しよう

スポンサーリンク
336 x 280 – レクタングル(大)
トップへ戻る
Secured By miniOrange