見出し画像

デザインとプログラミングを一人で終わらせる社長の話

親愛なる皆さま、お変わりありませんか。アーキビジョンの澤谷です。

「プログラミングとデザイン、両方できるんですよ」と話すとびっくりされますが、プログラマー時代に「デザイナーに向いていた」と気づくきっかけがあったことが転換点でした。両方ができる人間を目指していたわけでは全くなかったです。


CUIからGUIへ。そしてGUIの「G」は取れた

私がプログラマーとしてIT業界に入ったころは、インターネットどころかマウスもない時代です。アプリはキーボードだけで操作するCUI(Character User Interface)ほぼ一択。その後、マウスが普及し、Windowsが発売され、人とコンピューターの対話手段がGUI(Graphical User Interface)になりました。

1997年、Microsoftが「Ask Dr.GUI」という開発者向けコラムを連載し始め、GUIに注目が集まりました。しかし、当時でもGUIについて考えている人は日本では本当に少なかった。皆「グーイ」と発音していましたが、「UI」に短縮されたのはだいぶ後のこと。「G」が取れた時期はよく覚えてませんが、Graphicalが当たり前になったからですよね。

そんな昔話はこの辺で。今日はなぜ私たちがエンジニアリングに強いかをお伝えするために、スマホアプリ開発のエピソードを語らせてください。

22年前。右側の黒っぽいのはスマホではなくPalmというPDA。ブラウン管モニター…。
21年前。アナログですがやっていることは全く変わってないですね。
同じく21年前。Figmaが欲しかった(笑)

危ないプロジェクト!?参画の経緯

ある日、仲良しのクライアントFさんがぐったりした様子でオフィスに来ました。聞いてみると、進行中のプロジェクトで開発ベンダーの成果が思わしくないとのこと。Fさんは誰もが使いこなせる社内システムを目指していたけど、このままでは何も変わらないと嘆いてました。

困っているFさんを見過ごすことはできず、私たちは手始めにベンダーが作った試作版アプリをレビューすることに。その後、UI/UXデザイナーとして本格参画し、開発も引き受けることになったというのが経緯です。なお、同社のバックオフィス業務改善にUI/UXデザイナーが初参画したプロジェクトとのことです。

「X」を高めて働き方も顧客満足度も改革

クライアント社内で活用されるエンタープライズアプリのプロジェクトでした。さまざまな申請業務をUIデザインの力で効率化。UX、CX、EXを向上させ、その成果を業務効率改善、顧客満足度向上、働き方改革の事例として社内に浸透させていき、さらなるDX化を推し進めていくのが目標。

開発対象はWebアプリとスマホアプリの2つ。Webアプリはパートナーに開発してもらいましたが、スマホアプリは、ネイティブで組めるパートナーが見つからず、私たち、というか私が1人で開発することになりました。スマホアプリ側は、ざっとこんな要件です。

  • ADEP(Apple Developer Enterprise Program)契約

  • Enterprise(In-House)配布チャネル

  • MDMあり

  • Xamarin.Formsでクロスプラットフォーム開発

  • まずはiPhone、追ってAndroid対応

  • Webアプリホストではなくネイティブコードで一から書く

  • UI/UXデザインしっかりやる

  • SSO認証対応

  • プッシュ通知対応

  • APNs (Apple Push Notification Service)プロバイダーはAWS SNS

  • 外部基幹システムとAPI連携

  • レポートをPDFへエクスポート

  • 操作ログ蓄積

知っている人が見れば、まずまずハードルの高い要件だとお判りいただけるかと思います。Xamarinは学習コストが高いと言われますが、MSカルチャーで育った私にとっては神のようなプラットフォーム。大好きなC#で書けるなんて楽しみしかないですし、昔より見栄えするUIも作れるようにもなりました(ここはもっと頑張って欲しい…)。

これ以上の詳細は割愛しますが、1点だけ。ADEPは現在では、ほぼ契約不可能なライセンス(悪意を持ったアプリを作ろうと思えば作れてしまう契約)と言われてますので、そのライセンスを用いた開発環境の整備や設定、デプロイまでのフローを確立する検証に少し時間がかかりました。それ以外は、一般的なネイティブアプリのそれと同じ。大きなトラブルなく予定通りにリリースできました。

知ってしまえばADEPはものすごく楽です。審査がないし、どんなアプリも自由に作れてiPhoneにインストールできちゃいますからね。ただ本当に悪意あるプログラム作れちゃうので、実質契約できなくなったのは正しい判断だと思います。

当時、発売されたばかりのM1 MacBook Airではビルドがうまくいかず、急遽Intel Macに切り替えて開発。その後、M1でもビルドできるようになりましたが、疑心暗鬼で何度もバイナリーを比較してました。

デザインの力が認められた瞬間

最初のラフプロトタイプの段階で、関係者からこんな声が上がっていました(当時の議事録から抜粋)。

  • 感動。素晴らしい。

  • 他の社内システムとの落差に耐えられなくなりそう。

  • 短期間でこのデザイン改善。信じられない。

  • すっきりして分かりやすい。早く使いたい。

「Fさんの心配が一つ解決された」と私たちもほっと一息。Fさん以外はデザイナーの参画に懐疑的だったので、そこにデザイナーを押し込んだFさんの心労は察して余りあります。失敗が許されなかったプロジェクトだったんだなと。

このプロトタイプのおかげで、関係者に安堵が広がり、着々と事が進んでいくことになります。ユーザーテストをしっかりと行える予算と期間、そして様々な部署から多数の関係者がテスター参加してくれたため(恐れ多い肩書きの方も…)、初見から従業員がスムーズに使いこなせるアプリに仕上がったというわけです。

ユーザーテストの様子。予備知識を与えずにタスクをこなしてもらうのがポイントです。私たちがニーズが高いと仮説立てて用意した機能にまったく気づいてもらえずショック、ということが見つかるフェーズでもあります。

結果、問い合わせがほぼゼロ件になった

現場に投入され、一部従業員を対象に3カ月の運用テストが行われました。結果、使い方に関する問い合わせが減少どころかゼロ件になるという驚きの成果に。私たちも「さすがにそれはないだろう」と疑い、クライアントのPMに確認したところ、実際には2件問い合わせがあったけど、使い方に関する話ではなく「こう進めて良いんですよね」という確認の問い合わせだったとのこと。

Webアプリのデザイン変遷(澤谷の手書きラフ以降、UIデザイナーが担当。意図的にぼかしています。)
スマホアプリはデザインとコーディング同時進行(澤谷担当。意図的にぼかしています。)。Android対応は今フェーズのスコープ外ではありながらも、今後の後戻りリスクを摘み取っておくためにプラットフォーム固有箇所以外は動作確認したり。

苦労話

たっぷりとしたいところですが、ほとんどなかったんです。

というのも、Fさんのデザインリテラシーがもともと高く、社内のステークホルダーに対してデザイン改革を推し進める合意が取れている状態だったからです。関係者の皆さまが一心同体となりタイムリーに付き添ってくれ、本当にFさんに感謝しかないプロジェクトでした。そんなプロジェクト、現実にはほとんどないので(笑)。

ダブルスキルホルダーになると何が起こるか

プログラミングとデザインの両方ができると、こういうことが起こります。

  • Figmaから始まらない。デザインは手書きレベルで完結。

  • デザインとコーディングを開発環境上で同時に進められる。

  • 最新のガイドラインを最初からきっちり守って組んでいける(スムーズに審査パスできる)。

  • 文言からメッセージまで、初めからUXライティングできる。

  • 自分で動かしてみて良くないと感じたUI/UXを抜本的に変えてしまえる。

  • 社内デザイナーのフィードバックをその場で反映できる。

  • リリース直前までUXを高めるためのマイクロインタラクションなどの組み込みに時間を割ける。

  • プロトタイプではなく、最新ビルドをTest Flightなどで配って、実機でのフィードバックをいち早くクライアントから集められる(Androidで機種固有の問題が発覚するのもこのフェーズが多い)。

  • デザイナーとプログラマーが同一人物なので、コミュニケーションが不要で仕上がりが早い。

  • デザイン、システム設計どちらで問題が起きても、早期に発見して問題を摘み取っていけるので、初版からおのずと品質が高くなる。

やはり大きいのは、いきなりコーディングに入ってしまえることですね。プログラマーの方なら分かると思いますが、UI/UXデザイナーが画面デザインしながらコーディングできたら、はじめから一定の使いやすさを達成したアプリになることは想像つきますよね。この一連の作業が一人で完結できてしまうのは楽です。UIを修正したときの実装への影響が正確に見通せるため、リリース直前まで最高の成果物を目指していけます。

ただ、楽しめるかどうかはクライアントの要求レベルやアプリの規模によります。今回のスマホアプリは、特定ユーザー向けに機能セットが絞られた小規模なアプリだったので、クリエイティブな時間を楽しめましたが、中規模・大規模なら、私のような化石プログラマーよりも、現役プログラマーのほうがはるかに優秀なはずです。今回のように、よほどのことがない限り、私がコーディングすることは滅多にありません。

それと「Figmaから始まらない」といいましたが、これも要件次第です。スピード重視の場合、デザイン成果物は省いていいとなるケースがありますが、後出しで「やっぱり検収で必要だった」となることも。そうなるとアプリは完成しているのに後からFigmaでデザインを起こす、という逆再生作業が発生します。両方できてしまうゆえにスプリントが早く、クライアントも触って試せる成果物が出てきてるから大丈夫、というムードに陥ることがあります。なので、この要件は毎回しつこいほど確認しますね。

目指せるなら、その価値は無限大!?

私が最初に覚えた言語はCOBOLでした。決まった記法で手続きをひたすら書いていく単調さ。プログラミングの世界に幻滅して、早くも転職が頭をよぎっていた私をC言語の世界に引きずり込んでくれた当時の上司には、いまでも感謝しています。

ポインター、オブジェクト指向、マルチスレッド、コンポーネント、トランザクション、分散処理、マルチコア並列処理、グラフィックスなどなど。コアな実装技術を磨くために5日分の着替えをもって、土曜に一瞬帰宅して洗濯してまた出社ということをいったい何年繰り返したことか。もう二度としたくない体験ですが、そのおかげですね。プログラミング言語が母国語のように身に沁みついているのは。

目指してなれるか分からないし、得する保証もないですが、企業の開発チームやデザインチームとすぐに信頼関係を築けるのは間違いないです。両方の言語で会話できますからね。滅多にないですが、両者の間に入ってアイスブレイカーの役割を果たすときは通訳者のような体験になります。

Highlightは、こういうスキルセットを持った私が責任を持って主治医を務めますので、要件や制約、さまざまな事情を踏まえた診断が可能ということをお伝えしたくて書きました。

お悩みがありましたら、ぜひ気軽に相談してください!


お問い合わせはこちらから(ヒアリングからお見積りまで無料です)。


この記事が気に入ったらサポートをしてみませんか?