スケールしないプロジェクト
先日Webサービスとシステムインテグレーター(SIer)との業態の違いについて、サカモトさんが以下のようなツイートをしているのを見た。
この手の話、単純にビジネスがスケールしないからSIer等は例え速く開発出来るとなってもこの方式を取らないで、もう答えは出ていると思うんですよね。めちゃくちゃ優秀な人を10万人くらい独占できるならスケールするんですが、そんな事は不可能ですからね。 https://t.co/pIAALTZwKH
— サカモト@エンジニアキャリア論 (@sakamoto_582) March 13, 2023
これはあくまでSIerのシステム開発はスケールしないシステムを作ることについてのツイートなのだけど、ふと国際協力についても言えるかもしれないと思った。コードを書いてたくさんの人に使ってもらうようなWebサービスとは異なり、国際協力プロジェクトでは、課題も地域性も異なっていて、その中で、日々出てくる課題に取り組んで目標を達成しようとする。
SIerでも、国際協力でも教訓や、成功事例を他に応用するなどの取り組みをすることで、より良い結果が出るようにしている。国際協力では複数の案件に携わることによって、知見・経験がたまる人もいるし、専門性の高い人が現場に張り付いて深い理解を得ることもある。だからこのツイートを読んで少しもやもやした。Webサービスのように大きくスケールすることは期待できないが、何か国際協力でも改善できることはないだろうか。もちろん、政策などへの関与はとても大きなインパクトを与えるものだが、もう少し今の状態を改善できないだろうか。
Figmaの成功
ちょっと前に業務フロー少考：ふたつのパラダイムという記事を読んだ。この記事は、Web上でデザインや協業のできるWebサービス、Figmaの躍進について分析して、Figmaの躍進の要素としてFigmaがデザインに関わる裏の業務フローへの取り組みとその改善を挙げている。
裏を返せば、Figma以前はツールとコンテンツが分かれており、それがデザインに於いてもっとも重要である「フィードバックを受けて改善する」という本質的なプロセスを邪魔していた。そしてデザイン業務フローをより本質に近づけるべく4年間模索した創業者たちが辿り着いた結論が、ブラウザの中で完結するデザインツールを作る、という結論だったわけだ。
Figmaが裏の業務フローに取り組んだように、国際協力の裏の業務フローに取り組むことで、もっとこの分野を進められるのではないかと思う。
国際協力の裏の業務フローとは？
じゃあ、具体的にFigmaの何が良かったのか。以下のツイートではFigmaを使うべき理由を4つ挙げている。（詳細は元のツイートを見てください。）
WebデザインのデータをFigma(かXD)で作成した方が良い理由
①デザインの確認が容易
②コードの自動生成
③コミュニケーションの円滑化
④ファイルの管理が容易
デザイナーのみなさん、お願いだから、お願いだからWebサイトのデザインはFigma(かXD)で作ってください…！
— ゆっこ｜Webデザイナー (@yukko_work04) April 1, 2023
下の方にその理由をまとめました↓
イラレやフォトショはグラフィック向きでありWebデザインとしてコーディング前提で作るには不向きです。
コーディング担当の人たちがIllustratorや…
これを見ると、国際協力分野でも同じことが言えるかもしれない。書類作業が煩雑だったり、コミュニケーションの手段が人によって違ったり、過去の経緯をいろんなところから掘り返したりしている。もちろん、毎日まとめられていれば良いのだけど、情報がいろいろなところに散らかっていてそうなっていない。Figmaがやったように裏業務を紐解いて、それに取り組む必要がある。マイクロデータを格納しておしまいならNotionやConfluenceがあれば良い。もちろん、人の入れ替わりの多いプロジェクトであればそういうのも大事だ。
ここまで書いてきて問題を混同していることに気づいた。スケールするのはコンピュータやチェーン展開の店舗などの特性で、スケールするためにはマニュアル、ルール、調達可能なリソースが必要。一方で、Figmaが提供したのは、本来の仕事に集中するという価値で、それは国際協力の分野でも今も求められると思う。文書の素案、レビューのやり取り、定期的なレポートなど一つ一つはそこまで大変でないが、集まると面倒なものがある。それを解決する仕組みが必要だ。
国際協力がどうこう以前に自分の仕事の仕方として、整理というのが苦手なので、自分の仕事の改善として整理を心がけてみたい。この整理についてはまた別に書きます。
