今までWEBサービス・アプリの開発に関わり、(ちょっとだけの)成功と多くの失敗を繰り返して中で反省点や気がついたことを自戒を込めて書き記しておこうと思います。私の経験した狭い範囲の中での話ではありますが。不定期に加筆・修正していくかもしれません。
オッサンだけで決めている
これはカジュアルなコミュニケーション系のサービスやアプリに関して言えることです。専門家向け・マニア向け・アダルト系のサービスは除きます。
この令和の時代になっても、オッサンだけの会議で意思決定してコミュニケーション系のサービスを開発している会社をいくつか見てきました。そしてほぼ例外なく撃沈してます。
一般論として、女性ユーザーが集まると放っておいても男性ユーザーは勝手に集まります。逆はありません。オッサン同士であれこれ決めて女性ユーザーの関心を惹きつけるのは至難の業です。
私の数少ない経験を振り返ってみても、成功したサービスでは女性社員たちに大きな裁量が与えられて伸び伸びと企画・運営していました。もちんろんセンスのある優秀な女性達でした。
日本の会社組織だと、そんな優秀な女性達もいつのまにか結婚などで退職してゆき、気がつくと意思決定するのがオッサンだけになっていた、というのは割りとよくある話かもしれません。
大盛り幕の内弁当
手当たり次第に機能を盛り込めばいいサービスが出来ると思ってるケース。お金だけは持ってる企業が初めてWEBサービス・アプリを開発する場合に多いような気がします。あるいは、初めて企画を任された人が陥りがちな罠でもあります。
しかも大抵の場合、独自アイデアではなく他所のサービスでみかけた機能をあれもこれもと手当たり次第に仕様書に詰め込んできます。核となるアイデアに自信が無いからかもしれません。
本当にプッシュしたいオリジナルのアイデアがあるならば、まずはそれを全面に出し、それを引き立てるための最低限の機能に絞って実装し早期リリース(公開)して、あとはユーザーの反応をみながら慎重に追加していくのがベストだと思います。
機能を大盛りにした場合、開発する側は、毎日少しずつ機能が増えていくのでゆっくり覚えられていいのですが、使う側のユーザーが一度にそれを見せられたら、まず覚えきれません。本当にプッシュしたい機能に辿り着く前に離脱されてしまうことになります。特にカジュアル向けサービスでは。
また、最初はシンプルな機能で開始したサービスが年月を重ねるうちに機能が肥大化するケースも多々あります。機能を追加しないと現行ユーザーが満足しなくなるし、かといって追加して複雑化すると上記の理由で新規ユーザーの参入が減るというジレンマを抱えるなかで、各社は慎重にバランスの舵取りをしたり、追加した機能をライトユーザーからは見えないところに置くなどの工夫をしたりしていることと思います。
エンジニア目線で語るなら、過去に最悪だった経験は、開発が進行しスケジュールが伸びているにも関わらずクライアントが新しい機能追加(それも他社のパクリ)を次々と捻じ込んできて、営業がそれを認めてしまい、ゴール地点がどこなのか見えなくなってチームのモチベーションが下がるところまで下がってしまったケースでした。
エンジニアがプロジェクトマネージャーも兼任する
これはよく言われていることだと思います。私もPMを兼任して失敗したことがあるし、兼任したPMの下で働くエンジニアの立場で失敗するのを見たこともあります。
エンジニアとして自分のミクロ的な仕事に時間が経つのも忘れて没頭する時と、マクロ的な視点で全体を俯瞰しないといけない時は脳を完全に別モードにしないといけなく、短時間の間に何度も切り替えることが求められます。
それが得意な人だったらいいのですが、私は2,3人くらいのチームでも限界でした。優秀な人なら5人くらいのチームまでは大丈夫かもしれません。超優秀でスーパーマンのような人なら大人数でももしかしたら・・(私はみたことありませんが)。
流行最先端の技術が絶対正義だと思っている
人工知能やVRのような最先端の製品開発に最新の技術を導入するのは当然のことです。ここで言及するのはそうではない、ごく普通のごく平凡な業務システムやECサイト等についてです。
そのような、枯れた技術で十分に開発可能なものにまで、何が何でも最新の開発環境や言語を導入しようとするIT業者や意識高い系のエンジニアが少なからず存在します。
するとどうなるかというと、その業者やエンジニアが辞めてしまうとメンテできる人がいなくなります。その技術を扱える業者/エンジニアを新たに雇うと通常の倍以上のコストが掛かります。やがてシステムはメンテされないまま放置されるか、枯れた技術で作り直すことになる運命を迎えます。
それと似たようなケースとして、大手のソーシャルゲームアプリ会社の末端で働いていたようなエンジニアが独立したり転職先でPMになったりした時に、ソーシャルゲーム開発の知識しか無いものだから、普通の業務システムをそれで作ってしまうケースがありました。適材適所を見誤った例で、上記ど同じ運命が待っています。
・・・・・・・
会社や組織にエンジニアが集まると、最先端の技術を試したがる、意識が高くて優秀な者が一定数は出てきます。それはとても健全なことです。
そんな彼らに枯れた技術を押しつけても満足しないし、かといって前述したような平凡な業務システムを最先端の開発環境で作らせたとしても、やはり完全には満足できないので、遅かれ早かれ高給の職場活躍できる場を求めて去って行くでしょう。
一番いいのは最先端の製品を開発できる仕事を創出することなのですが、会社にそれが出来ない場合、本人の意思を尊重して放出してあげるのが社会全体にとってもいいことなのかもしれません…。(無責任な意見かもしれませんが)
頭のいい人目線で作ってしまう
これは頭のいい人が陥りがちな罠です（私のことでは無いですよ）。
使う側も自分と同じくらい頭がいいことを前提に設計してしまい、使う側がついていけなくなるケースです。
少し大袈裟に表現するなら、カジュアル向けサービスは小学校高学年でも使えるものを目指して設計して、やっと成人の一般ユーザーが気軽に使ってくれるものが出来上がるのではないかと思います。
また、初めて画面設計する人がやりがちなのは、長文の説明をいたるところに書き込むパターンです。基本的にユーザーは説明文があっても読みません。ユーザーが10人いたら1人でも読んでくれたらラッキーで、説明無しでもある程度は直感的に操作できないと、そこで多くのユーザーが離脱します。
多重下請け
これもよく言われていることですが、一エンジニアとしての経験から書かせていただこうと思います。
以前、日本人なら誰もが知っている大手通信会社のアプリに下請けエンジニアとして関わっていた時のことです。その時、自分が最低でも4次下請けだということは把握していましたが、実際に何次請けだったかはわかりません。2つ上の担当者までとは直接やりとりをすることが出来ました。
ある時、与えられた仕様書を見て、「この仕様はちょっとまずいのでは?」と疑問に思うことがあり、その2つ上の人に「こうした方がよくないでしょうか?」と掛け合ったのですが、あっさりと「上の人に提案する権限は無いですねえ・・」と言われ、私も「そんなものですよねえ・・」となりました。以降は疑問点があっても気にとめず仕様書通りに忠実に作ることに専念しました。
多重下請けは中抜きの問題ばかりがクローズアップされていますが、開発現場からのフィードバックが閉ざされていることも日本のソフトウェア業を停滞させてる一因ではないかと思いました。（全てがそうではないと思いますが）
過去の成功体験・失敗体験が忘れられない
私も気がついたら20年近くIT業界にいたわけですが、10年前、5年前の経験が通用しなくなってることを痛感することばかりです。
ですので、この記事で書いたことが100%正しいとは自分でも思っていません(笑)
こんな考え方もありますよ程度に受け取っていただければ幸いです。
