2016年 Schoo Advent Calendar の24日目の記事です。
おはようございます。こんにちは。こんばんは。Schooでパートナーリレーションユニットで広報業務をやっているdoyanishiと申します。
私は2012年にSchooに入社するまで全くエンジニア・Webデザイナーという職種の方と関わりがなかったんですね。入社からこれまででエンジニアのみなさんと一緒にお仕事をしてきた中で印象深いケースのご紹介と、そこから得られた教訓を、これからエンジニアと働く非エンジニアの皆様が同じ失敗をしてしまわないために書いてみたいと思います。
##Case01：ワイヤーフレームに色がない！と言ってしまう
お分かりいただけるでしょうか……。マジで今思えばありえない話なのですが、インターネットサービスに関わったことがなかった自分にとって、ワイヤーフレームの意味がわかりませんでした。雑誌でいえば手書きの台割に写真がない、色がないとクレームをつけているのと同じです。当然デザイナーにムッとされたことを覚えています。
「ワイヤーフレームに色がない」というのは極端な例としてひとつ目にご紹介しましたが、これで伝えたかったのは「今作られているもの、そして開発フローの意味」について理解することが必要だということです。実際に開発を進めていく中では、試行錯誤の繰り返しをしていくことになります。その意味を理解することは不用意な折衝を避けることにも繋がります。
教訓「開発フローとアウトプットへの理解は大事」
##Case02：勝手にスケジュールを決めてしまう
仕様とスケジュールは綱引きです。であるにも関わらず、リリーススケジュールをディレクター側で勝手に決めてきてしまう。これはあるまじき行為です。特にディレクターは売上を負っていたり、クライアントとの交渉の中でスケジュールを先に決めてしまうということをやりがちです。仕様が決まってもないのに開発者不在でスケジュールを決めてきてしまうのはやめましょう。（開発チームのみなさん、すみません、反省しています）
これを回避するために最近では「プロジェクトの目的・理想像・上記を成し遂げるためにやりたいこと」を簡単でもいいので社内の情報共有ツールであるConfluenceにまとめてもらうようにしています。それを持ってプロジェクトが立ち上がる前に開発ユニットマネジャーに頭出しをする。そうすると、ディレクターだけでは想定出来てなかった課題に気づかせてくれるだけでなく、つくりたいプロダクト、サービスのイメージを双方で具体化することができるという実感を持つことが出来ました。まだまだご迷惑を掛けてしまうこともありますが、インターネットサービスを進めていくうえで開発者と協働で作っていくとう感覚をチームの皆に体感してもらうということは一定功を奏し始めているのではないかと思っています。
教訓「スケジュールが変われば仕様も変わる。両方勝手に決めない」
##Case03：説明待ちになってしまう、技術的にわからないことをわかろうとしない
これは、デザイナー・エンジニアとディレクターなどの非エンジニア双方が努力するべき事項です。「餅は餅屋」はいい言葉だと思うのですが、やはり相互の理解がないことには同じような問題が一度ならず何度も発生してしまうんですね。ちゃんと質問して分かるまで説明してもらうことは、アウトプットされるもののイメージをすりあわせて品質を向上させるためにも必要なことなんだなというのを実感しています。
教訓「恥を忍んで質問する。お互いに理解をする姿勢が重要」
##Case04：「◯◯ってできますか？」と聞いてしまう。
これもよくやってしまうことでした。特にエンジニアの皆さんとのコミュニケーションで発生しがちだなと思います。「技術的に可能かどうか？」と「どうやってやるかどうか」はかなり違うんですね。エンジニアの皆さんは「できるかどうか」と聞かれれば「できる」と答えてくれます。
でも、これは実は不毛な質問なんですね。深まってない。「できる（ただし、この仕様とスケジュールでは無理）」と言ってくれているのですが、この（）の中の部分を本当はすり合わせしていかないとダメなんですね。
ディレクターがストーリーや成し遂げたい指標などの理想像を描いたうえで、どのようにやるかについてエンジニア・デザイナーと双方ができることを持ち寄ってサービスを作っていかなければチームで価値を生み出すことは出来ないなと最近強く思っています。
教訓「ディレクターは、あるべき像を描かくことから逃げない」
##Case05：差し込みタスクを軽視してしまっている
どうしても急に修正が必要なことがあったり、re:dashにデータの取得をお願いしなければならなかったりと「差し込みタスク」が発生してしまうことがあります。弊社の開発チームは1スプリントを2週間でプロジェクトをタスクに砕いて仕事を進めています。差し込みタスクが発生する際には開発マネジャーとスクラムマスターと調整をする必要があります。スプリント内での調整を経ずにぬるっと依頼しないこと。
教訓「差し込みタスクは、ぬるっとお願いしない」
##☆自分が参考にした本
一緒に働きませんか
いまSchooではエンジニア・デザイナー・セールスと幅広く仲間を探しています！
Bizサイドと開発の風通しの良さは本当に誇りに思っています。