ポエムに呼応するポエム、またはわたしのFictions

いつのタイミングでか、どうやら世の中のエンジニアは技術同人誌というのを執筆しているらしいというのを知った。Twitterのタイムラインでもサークル当選の話題で盛り上がっている。はて、それは一体どういうものかと先日技術書典5に行ってみた。フロントエンドとUI関連の本はないものかとサークルを周り、Web Componentsの冊子を手に取ると「ひろみつ氏にはこっちの方が合ってると思う、とりあえず読んでみて」とサークル主に勧められた。目次に目を通すと「スペシャリストとジェネラリスト」「真のユーザーファースト」など気になる言葉が並んでいた。

「こっちもください」

特に中身を深く読む必要もなく、目次買いした。Fictionsという、エンジニア達が書いた、よりよいプロダクトづくり/開発のための本だった。How toは書かれていない。けれど、不確実性の高いものづくりに向かう上で、折れずに向かってゆくマインドセットのヒントになりそうな本だった。帰り道の電車のなかで夢中で読んだ。

技術書典で買ったエンジニア勢のエモいポエム本読み終わった。プロダクトデザインに関する想いから、組織の話まで。たいへんよかった。感想はあとでブログにでもかく。 #まいにち積み本消化部 pic.twitter.com/pKZHNc18rS
— ⛩ひろみつ⛩ (@hiromitsuuuuu) 2018年10月10日

ここでは気になった同テーマに対してわたしが思ったことを書いておく。ポエムに呼応するポエムの真似ごとのようなものである。

スペシャリストとジェネラリスト

デザインとエンジニアリングの双方を仕事にしたいという指向性のなかで、スペシャリストとジェネラリストどちらになるのか向き合った内容だった。結果として、学び続け移動し続ければどこかにたどり着いてそこが正解になるのではないかと締めくくられていた。

わたしもずっと「技術とデザインを繋ぎたい」とフロントエンドのエンジニアリングとUI設計の狭間で生きている。志した新人の頃は「ジェネラリスト」になるのだと意気込んでいたが、領域を越境するにつれ個々の領域の浅さに不安感を感じ、スペシャリストとジェネラリスト問題がでてきた。けれどわたしの網羅領域と同じひとはどれだけいるのか考えたら、それが専門性とも言えそうだと思って両方手放さずにここまでやってきている。（だけどここ１年くらいはコードがかけていない）

エンジニアリングとデザインに限っていえば、ふたつの領域は地続きであると信じている。きっとプロダクト設計のスペシャリストにわたしはなりたいのだ。最近、デザインエンジニアとか、プロダクトマネージャーとか、過去にはあまり聞かなかった言葉を耳にするようになった。本を読んで、きっと好きに駆け回っていたら、名前がついたりどこか近いところにたどり着けるのかもしれないと思えた。

詐欺師症候群

コンピューターサイエンスのバックグラウンドがないことに対する劣等感から、自己肯定感がなく、求める状態と現実の大きなギャップが原動力となるという話だった。

まるで自分のことかと思った。自分には芸術工学の修士はある。けれど、学んだ領域の広さと、プロダクトのプロトタイプ発表で卒業したからか、学術的なバックグランドの裏付けをもって深く研究していないのではないかという後ろめたさを感じている。もうひとつは、プロダクトコードやプロダクトUI設計の打席数だ。分野を越境しすぎたせいで同じ年数の実務者に比べて、自分のアウトプットは少なく精度が低いのではないかと思い込んでいる。

まわりのコミュニティの知り合いや同僚はなぜか肯定してくれる。ありがたいことだ、否定しては認めてくれている方々に失礼だと思いつつも、自分はもしかすると周りが思っているよりもずっとレベルが低い詐欺師なんじゃないかと不安が掠める。

同じく、このギャップがわたしの原動力になっている。「自分ができると信じている、自信満々だね」と同期は言う。いつか本物になれると信じて、努力を繰り返す。

真のユーザーファースト

プロダクト開発をするなかで、営業からエンジニアまで様々な専門性・立場の人間の意見をいかに理解し、プロダクトの前進に繋がる判断下せるか、どう正しく意思決定を下すかという問いだった。

ユーザーの利益になると考えられた発言のなかには、承認欲求が混在しているものもあるという視点は頷けるものがあった。最近Twitterでみた『「人間中心設計」が、「欲望中心設計」になってしまっている』というのにも繋がるところがある。ステークホルダーのために妥協しなければならないこともあるが、それを続けているとどんどん自分たち都合の機能が増え、ユーザーの利益になる攻めの開発ができなくなってしまう。

いくら越境していても、どこかの判断軸が強くなってしまう。正しいとは何か。大局的な判断をするにはどうすればいいのだろう、わたしも興味がある。

分割統治リニューアル

UIデザインを一新することで、サービスは成功するのかという話。ユーザーの一人としての視点から見れば「リニューアルしてほしい」と思ったことは一度もないと。フルリニューアルは開発現場の改悪や負債を生み、負荷のかかったエンジニアが磨耗してゆく。分割統治し、きめ細かなリニューアルをしていこうという提案。

これはto Bとto CのUIでちょっと変わってくるかもしれないと思った。to B (or in B)では、道具であるシステムの改善によって効率化されて成功（ここでいう成功は、時間の余剰を産んだり業務のミスを減らすことなどである）に繋がることもあると思う。一方、to Cではコンテンツや売り物が主役のサービスである限り、店の内装や棚だけをいくら綺麗にしたところでお客様に届けるのは難しい。商品企画と売り方を一緒に考えないといけないと思っている。フルリニューアルで得られる価値とはどれくらいなのだろう。

リニューアルが成功に繋がるかどうかは置いておいて、改善の粒度は分割統治された方が良さそうだと思う。プロダクトバックログの側面からみても、UIリニューアルに全力を注いでしまうと新機能開発が止まってしまう。ずっと連絡をよこさないで、ある日突然サポートされるより、きめ細かくケアされた方が心持ちが良いのではないか。

デザイナーのように考え、エンジニアとして実行する

プロダクト開発のために、デザイン/エンジニアリングお互いの視点を持って「なぜこのデザインなのか」を考え専門のやりかたで進めようという話。

たまに思うのだが、なぜデザインが上流で、エンジニアリングが下流なのだろう。というか上流、下流という言葉が苦手だ。川下に流れるにつれ、Whyが薄まり作業になっていく。向かう課題は同じはずだ。エンジニアは扱う情報をモデル化し、システムで効率的に扱えるように、デザイナーはその概念をユーザーが理解しやすいように整理して画面に表現するのではないのか。お互いは対等に話せる立場なのではないのか。だからこそ、わたしが設計する際には背景からゾーニング・要素の意図を伝えたいと思っている。

おわりに

触発されてついエモ散らかしてしまった。人を選ぶ本だとは思うけれど、忙しい開発や苦しい時に読み返したくなる本になっていると思った。３人共同で書いた本のようだが、どれを誰が書いたかわからないようになっており、人や役割に紐づかない純粋な文章として読めてよかった。どこかの現場で同じように考えているエンジニアがいるんだなぁ、意識の高い詐欺師にならないように自分も頑張るか、と思った。技術書典お疲れ様でした。

本書が気になった方たちへ。こちらで電子版を買えるみたいです（AmazonにKindle版もあるすごい）。