こんにちは、エンジニアのづやです。
LIGではRuby開発者であり、当社の技術顧問を務める、まつもとゆきひろさんによる社内勉強会を開催してエンジニアのスキルアップに取り組んでいます。
第7回は以下の3本立てです。
- 【気になる技術ニュース】Twitterの動向
- 【ケーススタディ】お客さまからの無茶振りへの対応
- LIGエンジニアたちのお悩み
LIGの社内アンケートをもとに、まつもとさんはこれらの問題をどうとらえているのか、どう対処すべきかを具体的に伺いました。
|
人物紹介：まつもとゆきひろプログラミング言語Rubyの生みの親であり、一般財団法人Rubyアソシエーション理事長。株式会社ZOZOやLinkers株式会社など複数社で技術顧問などを務めている。オープンソース、エンジニアのコミュニティ形成などを通じて、国内外のエンジニアの能力向上やモチベーションアップなどに貢献している。 |
|---|
目次
【気になる技術ニュース】なに考えてるの？Twitter
2022年10月のイーロン・マスクによる買収以降、従業員の大量解雇や、一部サービスの有料化など、Twitterでは次々と大きな変化が起きています。
Twitterが何を考えているのか、どこを目指しているのか、疑問に思う方は多いでしょう。外から私が現状を見ていて、こういった事態になっている理由は3つあります。
「言論の自由」に対する姿勢が不明確
一つ目は、Twitterの言論の自由に対する姿勢が不明確であるという点です。
イーロンは度々「言論の自由」という言葉を使いますが、一切の制限なく自由な発言を許すと、さまざまな問題が起きます。Twitterはそれを経験してきたからこそ、攻撃的な発言を非表示にするなどの対策をしてきたはずです。
ところがイーロンは、おそらく自身のツイートが削除された経験も影響して、トランプ前大統領のような人でも、言論の自由を認めるべきだと考えているようです。
一方ではっきりとは言いませんが、自分を批判する人には言論の自由を認めたくないことがうかがえます。ここで生じた矛盾が、Twitterのポリシーのブレに現れているのだと思います。
「メガアプリ」を目指している
二つ目は、Twitterは「メガアプリ」を目指しているという点です。
「メガアプリ」とはコミュニケーション、ショッピング、ペイメントなど、あらゆる機能を搭載したアプリのことです。Twitterは「X」という会社との合併により、会社としては消滅しました。イーロンはTwitterをXのメガアプリにおける、ソーシャルを担うアプリにしようとしているようです。
関連：会社としての「ツイッター」が消滅、“スーパーアプリ”の実現にイーロン・マスクが動き出す | WIRED.jp
ユーザーへの考察が足りていない
三つ目は、ユーザーの気持ちに対する考察が足りていない、という点です。
以前のTwitterは、自らの機能を拡張するのではなく、サードパーティアプリを許容することで、それらと共存共栄してきました。
ですがそもそもAPIの利用は無料。ユーザーはTwitterにアクセスしているのに、目にするのはあくまでサードパーティアプリの画面でした。インフラや通信のコストもすべてTwitter負担です。縁の下の力持ちなのに儲からず、報われなかったのです。
そこでTwitterは方針を転換し、サードパーティのAPI利用を有料化しました。課金しなかったアプリは消えていき、私を含めて多くのユーザーの不興を買いました。
そこからしかお金を取れる場所がなかったかというと、そうではないと思います。
たとえばTwitterのアナリティクス機能は、広報活動でTwitterを利用している企業にとっては必須です。そのため有料化しても使い続けてくれるでしょう。ほかにもいきなりAPIを有料化せずとも、Twitter Blueに課金すればサードパーティアプリを利用できるようにする、といった方法もあったはずです。
結局、ユーザーがどの機能にならお金を払ってもいいと思っているのか、どのサードパーティアプリは残してほしいと思っているのか、きちんと理解できていないのだと思います。
コストの負担構造を上手に設計しなければ、みんなTwitterから離れていってしまう。Twitterは誕生から約17年が経ちますが、このドタバタぶりを見ていると、息の長いサービスをつくるのは本当に難しいと感じますね。
【ケーススタディ】まつもとゆきひろなら、こんなときどうする？
ここからはLIGで実際にあった事例から対処方法、考え方をご紹介していきます。
こちらが損をする取引を求められたら「No Deal」
LIG社内でアンケートでは、実際にあった困りごととして次のような事例があがってきました。
- ウォーターフォールとアジャイルのいいとこ取りを求められた
- 見積り金額から半値以下にしてほしいと言われた
- 「エラーでなければいいんだから、早くやれ」と言われた
私が決裁権限を持つ立場だったら、こういった無茶振りをするお客さまとの契約は打ち切ります。
『7つの習慣』という本では、持続可能な取引とは両者に利益が出る「Win-Win」の関係に基づくものであるとしています。逆にどちらかが損をする取引には持続性がないため「No Deal」、つまり取引をやめるべきだとしています。私も同意見です。
「これまで取引をしてきたお客様なので、断れない」という声も聞こえてきそうですが、相手に損を押しつける人は、それを繰り返す傾向があります。「今回はこっちが損をしたが、次回はその分得になる取引を提案してくれるはず」と期待してしまいがちですが、残念ながら相手は損を押しつけたことなんて覚えていません。
たとえば上記の「見積金額から半値以下にしてほしいと言われた」というケースでは、半値にすればこちらにほとんど利益がない、または損をすることは相手もわかっているはず。「次回予算が取れたら上乗せするから」と言ってきたとしても、そんな機会はまず訪れません。むしろ「今回も前回と同じ金額でお願い」と言ってくる可能性は高いでしょう。
「ウォーターフォールとアジャイルのいいとこ取りを求められた」というケースについては、そもそもそんな便利な手法は存在しません。あったらみんな使っていますから（笑）。
上記3つのケースでは、取引相手はこちらから搾取しようとしています。そんな企業はお客さまではありません。そういった取引に直面してしまった場合には、「相手に道理をわかってもらう」か「断って関係を断ち切る」かしかありません。
ただし私の経験からすると、道理をわかってもらおうと思っても、話をきちんと聞いてくれるお客さまはごくわずかです。その場合は「今回はとりあえず受けて、次回は断ろう」ではなく、直ちに依頼を断り、相手との関係を断ち切りましょう。
無茶振りを防ぐためには事前の社内調整が必須
相手が損をする取引を押しつけてくるのを防ぐためには、また無茶振りをされたときにすぐに断れるようにするためには、プロジェクトが始まる前の社内調整が大事です。
とくに営業との関係です。営業の社員はお客さまの言いなりになってしまいがちです。そのため開発の許可なく無理な要望を受け入れて開発を苦しめたり、開発が取引を断ろうとした際に反対したりすることがあります。そうなると社内対立に発展してしまいかねません。
そうならないためには、プロジェクト開始前のチームを編成の際に「営業は開発の味方になる」「無茶な取引は断る」という意識を、チーム全体でしっかり共有しておくことが必要です。
エンジニアたちのリアルな悩みごと
ここからはLIGエンジニアのみなさんが開発において抱えている悩みについて、私なりの考えをお話しします。
「パフォーマンス」「可読性」「保守性」どれを優先すべきか
「パフォーマンス、可読性、保守性がぶつかったとき、どれを優先すればいいのか」という議論はネット上でもよく見かけますが、これらはそもそも対立するものではないと考えます。
可読性について
開発において、解決すべき問題が複雑になればなるほど、それを解決するためのソースコードも複雑になる傾向があります。そのため難題に対しては可読性が低くなることはある種仕方のないことなのです。
そういう場合には「この論文を参照してください」「次のようなアルゴリズムになっています」などとコメントを書いておきましょう。後々ほかの人がデバックすることになった際に役に立つはずです。
保守性について
たまに「納品まで時間がないので、可読性は低いがとりあえず書く」という人がいますが、私はそれは少しズレていると思います。
というのも、読みにくいコードにすれば早く書けるというわけではないからです。
もちろん時間がないために、リファクタリングの余地がある状態でコードを書いてしまうことはあると思います。ですがそれは工夫が可能というだけで、コードの読みやすさには直接関係しません。
さらに人がつくったソフトウェアは、大体何かしらのバグが入ってしまうため、デバックが必要になります。ですが読みにくいコードはデバックもしにくい。そのため急いでいるからと可読性の低いコードを書くと、デバックに時間がかかって結果的に生産性が下がるおそれがあるんです。
凝った表現でなくていいので、読みやすいコードを書くほうがトータルの効率は良く、締切に間に合う可能性は高まると思います。
パフォーマンスについて
時間がないためパフォーマンスは後回しにするという状況は当然ありますし、私はそれでいいと思います。
そもそもボトルネックではない部分をいくら工夫しても、あまり意味がありません。
たとえばある関数をより難しいアルゴリズムに変更したところ、パフォーマンスが10倍になったとします。一見するとすごいのですが、アプリケーション全体ではその関数が消費される時間が1%に過ぎない場合、全体のパフォーマンスは0.9%しか改善していません。せっかく工夫しても、誤差程度しか効果がないのです。それにボトルネックになると予測して対応したのに、そこはボトルネックにはならないというケースも多い。
そのため工夫のない実装でいいのでまずアプリケーションをつくり、ボトルネックが明確になってからそこを直すほうが良いと思います。
「コメントがなくても理解できるコードこそ美しい」は真実か
適切な関数名や変数名が付いていて、コードを見ただけで何をやっているのかわかる、というのはたしかに理想的です。
一方でコメントが書いてあった方がいいこともあります。
私は「未来の自分や同僚がこのコードを見たときに、一目ではわかるかどうか」を考え、わからないと思えばコメントを残しています。
かなり主観的な基準でブレも発生しやすいのですが、それくらい曖昧なルールの方がいいと思います。「関数は必ずコメントを付けて説明すること」など、ガチガチの基準を設けてしまうと、コメントの量が増えて大事なコメントを見落としかねないからです。
ちなみに私が考える「美しいコード」は、本質に集中できるコードです。
プログラミングには特定の課題解決やアプリ開発などの目的があり、それを達成することだけに集中できればいいのですが、どうしてもそれ以外のコードも書く必要があります。それをできるだけ少なくし、本質的な部分の割合が高いコード、意図が直接プログラムに表現されているコードは読みやすく、美しいと思います。「実行可能な疑似コード」が存在するなら、それがベストですね。
アーキテクチャはどう勉強すればいいのか
最近「モノリスvsマイクロサービス」という議論が盛り上がっています。こういったトピックスをどう学べばいいかというと、やはりやってみることだと思います。
たとえばRubyのアプリケーションを書いていると、モデルが膨れ上がり複雑化することがあります。全体を分割すればメンテナンスしやすくなりますが、必ずどこかに複雑さは残る。徹底したマイクロサービス化が本当に有効かどうかは、やってみなければわからないのです。
一つのデザインパターンでうまくいくと、ほかの案件でもできるだけそれを適用したくなりますが、極端はよくない。とくに「モノリスvsマイクロサービス」など、議論が行ったり来たりしたり、新しいパターンが生まれたりするなど、議論が揺れているものは、どちらか一方に決めて突き進むのはおすすめしません。
どのアーキテクチャにするか迷ったときは、自分でやって痛い目にあいながら学ぶ、または痛い目にあった人から話を聞いて学ぶ、どちらかを行ってから選択しましょう。今はインターネット上に経験談があふれているので、それらを読むだけでも失敗の可能性はイメージできると思いますよ。
まとめ
今回はLIGエンジニアが直面したトラブル、抱えている悩みに対し、まつもとさんからさまざまなアドバイスをいただきましたが、似たような経験をしている企業、現場は少なくないと思います。
今後も多くのエンジニアの参考になるような情報をお届けしていきますので、次回のまつもとゆきひろ勉強会レポートにもご期待ください！
