こんにちは。
株式会社Photoructionでwebエンジニアをしている土岐（とき）です。
Photoruction Advent Calendar 2021の19日目の記事になります。
目次
１、はじめに
２、受託開発の頃に大事としていたこと
３、自社開発で大事にしていること
４、これからやっていく上で大事にしていきたいこと
はじめに
まずは軽く私の自己紹介から。
IT業界に入る前は異業種の仕事を色々していましたが、ちょうどブロガーという仕事が生まれた頃でしょうか。私はブログの中身を見て楽しむよりサイトのデザインを見て惹かれていき、そのうち自分で作ってみたいと思うようになりました。まだHTMLやCSSすら知らなかったど素人ながらもググってwordpressテーマを作り、更にそこからVPSサーバでLAMP環境をググって構築しドメインを借りて公開をおよそ２ヶ月半程度でやってみた事がIT業界に入ったきっかけでした。
１社目はmovabletype、DoやLumen、wordpress、laravel、その他javaやandroidアプリなど、主にphpがメインであるものの割となんでもいろんな案件を受託しちゃう１０人程度の小さい規模のシステム開発会社で、PMやデザイナーはおらず全員エンジニアで構成された会社でした。
そこで私は初めてデスマーチというのを体験しました。おおよそ４〜５ヶ月間常駐先に缶詰になりながらjavaでできた巨大なレガシーシステムを読み解いていき、設計書やフロー図・シーケンス図などに落とし込むのが仕事でした。何日も泊まり込みというのはザラで家に帰っても寝る時間ぐらいしかいなかったので、残業時間だけで月150時間位はいってました。そして残業代はどんなにしても一律3万円までという会社でしたので中々のブラックだったな...と勉強になりましたね（泣）
２社目はwordpressをメインの受託会社。自社商品の仮装マシンも売りにしており、割と誰もが聞いたことがあるような結構大手な会社から受注し、そのサイトの開発から保守まで受け持つ、なかなかやり手なベンチャーでした。
１社目とは異なりPMやデザイナー、シニアエンジニアなどが揃っており、基本１案件を一人で行うものの、何かあった時は頼れる先輩エンジニアがいたことは心強かったですし、色々と教えて頂けたのは本当にありがたく私の財産になりました。
受託開発の頃に大事としていたこと
いろんな案件をこなしてきましたが、やはり受託の場合は「納期までに実装して納品する」事が第一です。
ミッションをクリアするために主に３つの事を気をつけていました。
１、コミュニケーションのルールを決めておく
よくあるのが実装・テストフェーズに入った後などPMや顧客とのやりとりで
「こんな機能作ってって前に言ったよね？」
「聞いてません。提出した設計書を確認時にそちらからもOKを頂きましたよね？」
みたいな「これは言った、言わない」問題。いわゆるコミュニケーションの不足による仕様の認識がズレることです。まぁよくあることですね。
実際、依頼側が言い忘れていた場合もあるし、受注側が忘れていた場合もあります。また実装したものを触ってみて細かいところまで考慮漏れだった事もありますし、依頼側の要望が途中から変わってくることもあります。
そういう時はムキになってこちらは悪くない！と言い張る争いをしても案件は終わらないし、相手と気まずい嫌な空気が生まれてしまうだけ。そんな不毛なやりとりが大の大人でも現場でよく起こったりします。
そこで私はキックオフや割と最初の段階で相手といろいろ取り決める際に以下のことを提案します。
- 基本やりとりはslackで。口頭だと聞き漏らすことや忘れることもあるので必ず文章化して残したい。
- 画面名や機能などの名称を統一・共有しておく。こうすることで、コミュニケーションを取る際に双方の認識が合致しスムーズにやりとりできるため
- チームの全員の認識が一致するために、最新の確かな仕様をいつでも誰でも振り返って確認できるようにして欲しい。そのため仕様書の更新をその都度して頂きたい（口頭やslackだけでは不確かだったり二転三転するため）
こういうことを最初に取り決めておくことで、なるべくコミュニケーションコストを下げお互いにとってイラつかないようにするのが双方にとってスムーズだと学びました。
2、まずは30%でもいいのでなる早で作る
じっくりと丁寧なものを期限ギリギリに提出するよりも、完成度が30%でもいいのでプロトタイプを早めに提出してそれに対しフィードバックをもらう。
そしてまたそのフィードバックに対しサクッと作る。
そういうサイクルを繰り返す。
上記の１でも少し書いたのですが、実装したものを触ってみて細かいところまで仕様を決めていくというのはよくあります。
というのも要件が固まり仕様を決めても、細かいところまでは決めていない・気づかない事はよくあります。（完璧な仕様書というのは最初から作れないもんです。人間だもの）
そのためざっくりでもいいのでまずは動くものを提出し触ってもらうことで、依頼側と開発側、双方の認識が噛み合ってきます。
口頭や文章だけではうまく伝わらない事もあっても、実際のものを通して認識をすり合わせる事で完成度を高める事ができるので、なるだけ早く形にするのは大事だと知りました。
早いは正義！
3、早い段階で別チームに知らせる
大きい規模のシステム開発など、別の会社やチームと組んで一つのシステムを作る時、自分達の領域だけでは解決できない機能があります。（例えばスコープ外の機能と連携しないと表示できない部分とか、webとモバイルでデータを受け渡さないといけない部分が出てきたりなど）
そういう時に大事なのは、何か疑問が出てきたらすぐに別チームのエンジニアと早めに情報を共有することでした。
なぜなら別チームにもそれぞれスケジュールや優先順位があるからです。
別チームと連携しないと進めない問題が出てきた時に、できるだけ早い段階で共有しておかないと別チームが切羽詰まってきます。そして別チームが遅れることで、こちらもそれに合わせて対応が遅れてきたりと...まぁ全体的に遅れてくるので、やはり連絡・共有は早いことに越したことはありません。
早いは正義！！（２回目）
自社開発で大事にしていること
さて。そんな受託の頃とはうってかわって、このPhotoructionではなかなか他では味わえないような面白いメンバーで構成されています。
まずこのPhotoructionは「建築業界をスマートにする」というミッションで立ち上がった会社なので、建築業界出身の方とIT業界出身の方がおおよそ半々。
そのうちシステムの開発部にはエンジニア（web,IOS,android）、デザイナー、PMチーム（プロマネ）、QA、CREチームと構成されていますが、PMは全員が建築出身の方で構成されています。
受託の時は「納期までに納品する」ことが第一になっていたのですが、ここでは「ユーザに価値のあるものを届ける」ことが第一になってきます。
とはいえ、はじめは「ユーザに価値のあるものを届ける」と言っても具体的にどういう姿勢でやっていけばいいのか慣れませんでした。
今までは決められた仕様を期限までに作るやり方に慣れていたため、仕様が二転三転するのに困惑しましたし、仕様を決める時からエンジニアも参加できるのですが、エンジニアは現場の空気感や使っているユーザのことはあまりわかってる人はいません。
そのためエンジニアが加わるとどうしても「どう作るか」な目線で決めたがります。これはシステム的にまたはデータの観点からベストなやり方で作ろうとするからです。
ですがユーザのニーズからかけ離れたものを作ってしまったら本末転倒です。
そのため建築業界出身の方と一緒にうまく協力していく必要があります。
受託の時とは違って1人では良いものは絶対に作れません。「みんなで作っていく」ということが受託との１番の違いだという事を教えて頂きました。
これからやっていく上で大事にしていきたいこと
「できない理由」を探すのではなく「どうしたらできるか」といったスタンスで
仕様を決める際、ユーザの要望に向けてあれもこれもやろうかといろいろ案が出てくるのですが、どうしても期限を考えると現実的に実装できる機能を絞り、この機能は「リリースまでにできるか・できないか」というスタンスになりがちです。
ですが本来私たちのミッションは「ユーザに価値のあるものを届ける」こと。
時間の許す限り、よりユーザにとっていいものを作るのが大事になってきます。
そのためエンジニアとしては設計や実装において「できない理由」を探すのではなく「どうしたらできるか」といったスタンスで取り組むのが大事なのではないか。と私は思っています。
なかなか大変であろう機能をお願いされた時、「他の案でカバーできないか」「別のやり方（簡単な機能）でいいか」などとすぐに返すのではなく、まずはどうしたら実現可能かを考えユーザの求めるものに寄り添う姿勢でやっていくこと。
限りある時間の中でいかにクオリティの高いものを作れるか、そこがエンジニアとしての腕の見せ所になってくるのではないかと思います。
一緒に作っていくチームメンバーとのコミュニケーションにおいて
どうしてもエンジニアという仕事をやってると細かい所まで目が行くようになります。
具体的に言えば設計だと
- 求められている機能の確認
- 既存仕様とそのコードの確認
- 機能を追加する事によって生じる影響範囲の確認
実装だと
- 求められている機能を作って動くようにする
- 書いたことでクリティカルなバグが発生していないか
- 他の機能にも影響がないか
- 書いた処理が他の処理と被ってる部分がないか、コードをもっとスマートに省略できないか
テストだと
- 想定外のバグがないか
- そもそもこちらの認識の抜け漏れがないか
……などなど。
システムを細かいところまで確認し作り上げるのがエンジニアの仕事なので「細部まで厳しくチェックする目」を持つようになり、それを要件やコードだけでなく色んな部分に向けるようになってきます。
でもそれは決して「人の至らなさ」に対して向けるべきではないはず。
一緒に案件をやってるメンバーはあくまで「良いものを作りたい」という同じ目的の下集まってる同士であり仲間です。
加えて人間なのでどうしてもコミュニケーション不足による認識の齟齬や勘違い、言葉足らず・逆に一言多い、積んできた知識・経験の差などというのは必ず発生します。
そもそもITと建築というバックグラウンドが違う人間同士のコミュニケーションなのでそういう事が起きて当たり前です。
そのため人の発言に対し重箱の隅をつつくような揚げ足を取ったり、間違った知識や認識に対して人間性を否定するかのような批判をする、といったことは絶対にあってはいけない事です。
ちなみにPhotoructionにはそんな人は誰一人いません。それはPhotoructionの理念の一つに「敬意尊尚」というのがあるのですが、これは心理的安全性の高い組織を作るために「互いをリスペクトし、立場に関わらず相手の意見に耳を傾け、建設的な議論をすること」を良しとしてる風潮です。これによりチーム内のやりとりはフランクな空気でとても仕事がしやすくなっています。
今、Photoructionはいろんな機能が密結合しており開発するたびにバグが多数出てきてしまっているのが現状です。
そのため自分達が書いたコードや成果物には「性悪説」な目を向けて。
ですがチームメンバーには「性善説」な目を向けて、これからもやっていきたいと考えています。
最後まで読んでいただきありがとうございました。他の記事もぜひご覧ください！
株式会社フォトラクションでは一緒に働く仲間を募集しています
