#大規模なUI改修
Text
2023年の振り返り
色々やることがあるので書かなくても良いかなと思ったけど、やっぱり書いておこうと思った。
人間の意識って不思議なもので、なにか自分の中で常識のアップデートが起きると、さも昔からそうだったかのように思い込んでしまう（GPT4から1年経ってないなんて信じられない）。良く言えばそれは過去に囚われず動けるということではあるけど、悪い面としては何も前進していないように感じたり、過度に固定的なものとして扱ってしまう。意識というメタソフトウェアに意図的に組み込まれた不具合。
そういった不具合を補正するために記録があり、記録を理解可能なものにするために、叙述がある。
まあこれはそんなに大したものではないけれど、なんとなくトピック別でまとめていく。
LLM : 大規模言語モデル
2023年の年明けは、何と言っても LLM だった。元々 GPT3の頃から一部の人が注目していたことを観測していたが、強化学習を施しチャットというUI を与えられてプロダクトとしても爆発的なヒットとなった ChatGPT のリリースが2022年11月、そして GPT4のリリースが2023年3月。
もともと機械学習周りは改めて勉強したいと思っていたので、Coursera の Machine Learning コースと Deep Learning コースを履修してみた。言語モデルだけでなく、CNN等画像を扱うための手法も学べた。その後、OpenAI の論文をいくつか読んだり。直接に手を動かして新しいモデルを開発するといったところまでは難しいが、重要なアイディアを理解することができ、収穫になった。
LLM のインパクトはここで書くまでもないだろう。自分でも API を使っていくつかプロトタイプを作ってみたのだが、汎用的なものは作っているうちに「あー、これ自分がやらなくてもプロバイダー側が作るやつだ」と気づいて作るのをやめた。具体的には、OpenAI の GPTs のようにプロンプトをカスタマイズして名前をつけて保存できるチャットボットや、GitHub Copilot in the CLI のようにコンソール上でやりたいことを自然言語で打つとサジェストしてくれる君などだ。どちらのプロダクトも今は便利に使っている。
逆に、Wantedly のドメイン（自然言語のアノテーション付き GraphQL API を最大限活用）を使って作ったプロトタイプは結構面白さを感じたし、デモの評判も良かった。自分のことを自分で説明するのはエネルギーが要る。聞かれて答える方が脳のニューラルネットワークを励起させることがたやすい。いきなり飛躍するが、日本で LLM を使って業務効率や生産効率を上げるのであれば、ドメインに浸潤するような、プロセス全体から変えていくようなソリューションの方が面白いかなと思っている。
ともあれ、LLM はこれからも確実に世界を変えていく。今後が楽しみなのは間違いない。
Developers Summit で話した
上記と並行して、2月には Developers Summit 2023 で Wantedly の人として話した（スライド）。ソフトウェアアーキテクチャを組織構造と一緒に価値に接続するというテーマ。
ソフトウェアアーキテクチャの問題は、いま目の前にあるチームの形との不一致がペインになって現場の声として現れることが多い。しかし経験上、そういうボトムアップな課題感を、そのままアーキテクチャに落とし込んで大きく変更する戦略は上手くいかないことが多い。
これはソフトウェア設計の概念を借りると依存関係の矢印が間違っている設計だと言える。営利企業である以上（あるいはサービスの価値を上げたい以上）、組織構造も “それ” に緩やかに依存して下支えするように設計されている。ソフトウェアアーキテクチャも“それ” に緩やかに依存するべきだ。しかし、目の前にある組織構造に依存してソフトウェアアーキテクチャを設計してしまう。そして組織の変化でアーキテクチャがまた適合しなくなる。
何を変数にして何を定数とするかを考えよう。
この辺りの話が 「Accelerate」 に加えて「チーム・トポロジー」が出たことでようやく共通の言葉で話せるようになったなと感じる。こういう Wantedly のシステムにおける学びを世の文脈の中に置くことは意味あることだと思ってお話させていただいた。
技術の進化
同じ時期、いまあるソフトウェアシステムを叙述によって理解可能にするという観点から、10年間の技術の進化（直接見たのは7年間だが）をまとめたのだが、これは学びがあった。
ある技術 A を導入していたから可能になった技術 B がある。ここまではある程度の人が認識できるのだが、それが A→B→Cのような多段になっていたり、複合的な要因だったりすると案外と認識できていない部分があったりする。あるいは認識できていても、技術を投資として見たときに、蓄積的な効果がどの程度あって、それに要するリードタイムがどのくらいなのか、といったこと。それを踏まえて考えられる戦略的なソフトウェアの技術投資とは、ということ。
この図はそういうことを考える良い機会になった。
https://docs.wantedly.dev/introduction/technical-overview より
加えて言うと、この図には入らなかったけど明らかに重要な、並行して変化する外部構造が二つある。せっかくなので書いておく。
一つは会社における事業とサービスの展開。・・・まあこれは結構自明ではあるのだが、あるサービスを展開する際に行ったある技術的なチャレンジが副産物を生み出した、といったことを陽に認識することができた。流れの早い IT スタートアップにおいて、技術の研究開発チームのようなものを独立して作るよりは基本的に走りながらやる方が上手くいく。ただしそのためのチャレンジマネジメントは必要で、これはテックリードの役割だと思う。
もう一つは会社の外のこと。こうやってタイムラインを見ると、明らかに2010年頃からのスマートフォンと社会的な普及が多くの影響を及ぼしている。Web アプリとユーザーインターフェイスおよびそのデプロイの仕方が分化し、同時にユーザーの期待値が変化し、それを解決するための技術が出てきて、オープンに使えるようになって、、、と言ったことをタイムラインと一緒に見ていくと面白い。マクロな構造が変わったとき、実は同じ問題意識を持っている人というのが同時多発的にいて、その中で技術が生まれて収斂していく。
昨今の生成 AI の盛り上がりで AI を動かす GPU を生産する NVIDIA の株が爆上がりしている。これなどは明確なハードウェアの生産量やコストの形を取るのでまだ一見分かりやすいが、オープンソースソフトウェアなどはもっと非金銭的な動機（たとえば鍵となる技術やビジョン）に導かれていることがむしろ普通で、実際に触ってみて中に入って理解する必要がある。そうやってドライバーを見極めつつ、自社の問題との一致を見出して、取り入れるタイミングを見計らう。取り入れたら、自社に適用するためのさまざまなプラクティスなど広義の意味での「技術」を組織の内部に蓄積していく。
こういったこともテックリードがいれば一定担保できるが、この通り様々な技術領域やレイヤーを超えて技術の進化は作用するので、適切に全体像を掴むのは案外難しい。そこを最適化するにはより上位の役割が必要になる。
そういえば、WIRED の創刊編集長が書いた「テクニウム」はこういった広い範囲でのテクノロジー・マネジメントを行う上で非常に示唆の多い本だった。去年の「技術と創造の設計」に続いて技術それ自体の捉え方を扱った本としておすすめしたい。
Wantedly の振り返り
上記のようなお仕事も8月いっぱいで終了している。
Wantedly では本当に優秀なエンジニア、そしてデザイナーと働くことができた。
ジュニアエンジニアとしては DHH の言うところの Preventing messes / Making great software を地でいく経験ができた（もれなくSaving money も付いてきたが笑）。同期にもとても恵まれた。
3年目には当時、新卒2年目だった @izumin5210 と @qnighy をメンバーにバックエンドチームを持ち、大規模なシステム設計を経験した。この2人がいたことで自分はソフトウェア設計からアーキテクチャ設計に明確に重心を移すことができたと思うし、どんなに複雑に見えるシステムも真因を明らかにして適切な処置を施すことで対処可能であるという確信を持った。
4年目には3つの(今でいうところの)ストリーム・アラインド・チームをまとめるリーダー of リーダーになり KPI を持って1つのプロダクトを伸ばすということができた。プロダクト作りとプロダクトマネジメントの違いをここで学べたと思う。
その後は必要性もあり全社の技術戦略やアーキテクチャをマネジメントを行ったがこれもこの記事に書いたように多くの学びがあった。
ここには挙げなかった人、直接一緒のチームで働かなかった人も含めて学んだことが多い。そしてもちろん、こういった組織を作り上げた CTO の @kawasy にはとても感謝している。
以上に加えて、教えるということにも多くの学びがあった。特に技術フェローになってからの1年は現開発執行役員の @nory_kaname がそれを組織的に実行するのを横で見ていたが、組織設計とピープルマネジメントについては最後の2年が最も学びが深かったと思う。
初期パラメーターが高い人だけ選び続けてもそれは何かを生み出しているかというと疑問があるし、マクロに考えれば、最終的に良いソフトウェアエンジニアをきちんと育てて増やすということに尽きる。
この点では、自分は大学時代から既に恵まれていた。研究室の先生は何か新しいことをやったらそれが役に立つかの判断よりも先に「それ、面白いね」と言う。そういう中で色々な面白い���フトウェアを作る人がいて、そういう人が時々すごいソフトウェアを作っていた。
企業レベル、つまり資本主義の世界でも技術を育める文化を持つ会社が、きちんと技術を事業的な価値に変えてかつ資本的にも還元して拡大再生産していくことが必要だというのが1エンジニアとしての意見だ。
SANU に入社した
さて、9月からは SANU という会社でソフトウェアエンジニアとして働いている。
リリース当初に申し込んでずっとユーザーだったのだが7月にユーザー向けのイベントに行ったことがきっかけで、代表の Gen さんやファウンダーの Hilo さんとお話しして非常に面白かったので入ることにした。
自分にとっては、前職の経験はありつつも普通にソフトウェア開発の方法論を難易度を上げて適用するのはちょっと面白味がないなと正直感じていた。そういう意味では、SANU には自分が働いたことのないような人たちがたくさんいる。
サービス運営の中でも、アプリの開発をするファンクションも必要なのだが、リアルなオペレーションがあり、建築があり、不動産としての運営があり、それが総合的なユーザー体験と収支に紐づく。
こういう世界において、例えばチームトポロジーの方法論でストリーム・アラインド・チームを作ると言ってもどう適用するかは全く自明ではない。ただそれでも入ってみてきちんと観察をすると、オンラインでのフィードバックがめちゃくちゃサービス運営に活きていて、改善につながっている。
ここにデータの活用、そして継続的デリバリー、プロセスをシフトレフトさせて作り手の発想を入れるといったエッセンスのレベルでは加える価値があるのも明らかで、むしろリアルなお客さんがいること、現実に受けるサービスの一定割合はそういったものであることを考えれば、サービス開発の本丸では？とさえ思う時がある。
・・・と SANU に入ってからの発見と驚きはもっと伝えたい気持ちがあるのだが、普通に記事がもう1つ出来てしまいそうので、一旦このあたりで。あ、もし気になる人がいれば喜んで話すので直接声をかけてね。
0 notes
Text
Subject: 年収30%の紹介手数料 不要。月々の単価への上乗せなし！
人事採用ご責任者様
いつもお世話になっております。
株式会社ワークタンクの関戸と申します。
①SESの場合
エンジニアの所属会社を直接ご紹介します。
単金に上乗せはいたしません。
②エンジニアを採用する場合
年収３０％の紹介手数料は不要です。
【今すぐ採用予定あり 】
【または近日中の予定あり】
の方はすぐ、ご対応いたします。
案件情報がありましたら、メールしてください。
すぐに候補者を返信いたします。
案件情報を頂く際は、
★開発言語
★ご連絡先携帯番号
ご提示頂きますようお願い致します。
申し訳ございませませんが、
ZOOMやWeb会議は制限があるため行っておりません。
=====================================
mailto:[email protected] まで
株式会社ワークタンク
担当:関戸 （せきど）
TEL : 03-5324-2815
○電話 平日月～金８：３０～１８：００まで
それ以外の時間は、お手数ですがメールでご連絡下さい。
ご返信いたします。
・゜゜・:.。..。.:・゜・゜゜・:.。..。.:・゜・゜゜・:.。..。.:・
【今週の登録者】
☆33才 JAVA開発経験
☆37才 C#開発経験
☆37才 VB開発経験
他にもJAVA .net C++ Linux Oracle サーバー構築 ネットワーク等のエンジニア
が登録しておりますので、何なりとお申し付けください。
////////////////////////////////////////////////////////////////////////
ID 035
性別 男性
出身地 岐阜県
現住所 東京都
年齢 33
最終学歴 専門学校卒
勤務先の業種 ソフトウェア・情報処理
現勤務先の従業員規模 100～299名
現在の年収 500 ～ 550 万円
現在の勤務状況 求職中
経験職種・経験年数 プログラマー(Web・モバイル関連)
J2EE/J2SE 5年
PHP 4年
C/C++ 5年
データベース設計・構築
Microsoft Access 3年
Webサーバー設計・構築
Linux 4年
語学関連のキャリア 検定資格
TOEFL 450～500点
会話能力
所有資格
希望雇用形態 契約社員
委託社員
希望職種 プログラマー(Web・モバイル関連)
希望の勤務地 東京23区
横浜・川崎
愛知県
職務経歴
業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語
ソフトウェア・情報系
BtoBWebサイトリニューアル 業務系(ＷＥＢ系)
[ ＥＣ：その他システム ] 100人以下
基本設計
詳細設計
システム運用管理/保守
OS：
Linux
PHP
《担当業務》 (フロント側)
・BtoBWebサイトのリニューアルに伴い、主に画面の新デザイン当て込みと既存機能の移行になります。
(新規会員登録画面、イベント見積り画面、店舗登録画面、新着表示出し等) ・結合テスト
AWSクラウド環境の基盤リソースの設計構築・運用
≪担当業務≫
・業務利用アプリの改修のための設計構築・運用
・業務利用ツールの環境整備と運用
・GitHubでのソースの構成管理
≪コメント≫
・業務利用アプリのセキュリティー面の改修に必要な知識が深まった。
・業務用ツールを使った新たな仕組みの導入にあたっての他チームとの調整や環境整備についての経験を積むことができた。
////////////////////////////////////////////////////////////////////////
ID 053
性別 男性
出身地 埼玉県
現住所 東京都
年齢 37
最終学歴 専門学校卒
勤務先の業種 ソフトウェア・情報処理
現勤務先の従業員規模 100～299名
現在の年収 400 ～ 450 万円
現在の勤務状況 求職中
経験職種・経験年数 プログラマー(Web・モバイル関連)
J2EE/J2SE 4年
JavaScript 5年
C# 5年
データベース設計・構築
MySQL 4年
語学関連のキャリア 検定資格
TOEIC 501～600点
会話能力
所有資格
希望雇用形態 正社員
委託社員
希望職種 プログラマー(Web・モバイル関連)
希望の勤務地 埼玉県
千葉県
東京23区
東京都下
横浜・川崎
神奈川県下
職務経歴
業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語
ソフトウェア・情報系
フロントエンドの開発 業務系(ＷＥＢ系)
[ 広告出版：その他システム ] 100人以下
基本設計
詳細設計
サーバ設計/構築
OS：
Linux
仮想ソフト：
Vmware
Xen
Hyper-v
PHP
■フロントエンド
HTML5, CSS3, Sass：
レスポンシブWebサイトコーディング
JavaScript(jQuery)：
簡易UIの実装
（モーダル、タブ・ドロップダウンメニュー、文字数チェッカー、スライドショー、
ページ内スクロール、ソート機能、Ajax）
■サーバーサイド（PHP）
・Dockerによる仮想環境の構築
・MySQL：テーブル操作、レコードに対するコマンド処理（select, insert, update, delete）
・PHP：簡易アプリケーション作成によるCRUD処理の実装、バリデーション実装
・セキュリティ対策：CSRF対策、セッションを利用したエスケープ処理の実装
・Laravel：MVCフレームワーク概念理解、
・テスト：PHPUnitによる単体テスト
■チーム開発
・Pull Requestベースのチーム開発入門
・Redmineを使用したタスク管理
////////////////////////////////////////////////////////////////////////
ID 376
性別 男性
出身地 兵庫県
現住所 東京都
年齢 37
最終学歴 専門学校卒
勤務先の業種 ソフトウェア・情報処理
現勤務先の従業員規模 100～299名
現在の年収 500 ～ 550 万円
現在の勤務状況 求職中
経験職種・経験年数 プログラマー(UNIX系)
アセンブラ 4年
C/C++ 5年
プログラマー(Web・モバイル関連)
VB.NET 3年
ファームウェア開発
ファームウェア開発 6年
語学関連のキャリア 検定資格
TOEFL 601～650点
会話能力
所有資格
希望雇用形態 正社員
契約社員
希望職種 ファームウェア開発
希望の勤務地 東京23区
東京都下
横浜・川崎
神奈川県下
京都府
大阪府
職務経歴
業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語
ソフトウェア・情報系
無線装置の保守系機能開発 インフラ(基盤)系
[ ネットワーク ] 100人以下
基本設計
詳細設計
プログラミング
無線装置の保守系機能開発
無線装置開発の保守系機能の詳細設計、製造、単体試験を実施
C言語
【OS】VxWorks
マイコンの調査、仕様確認、設計書作成
マイコンメーカー提供環境による製造および試験
C言語
【OS】Linux
2023.12.5 From: Worktank [email protected]
0 notes
Text
Webフロントエンドのリリース戦略
Webフロントエンドのリリースをどうするのか
前置き
Web開発に分業化が進み、Webフロントエンドの開発は独自に行われることが多くなった。
しかし、Webフロントエンドのリソースの配信はサーバサイドが絡むことも多く、Webフロントエンドに取って最適な方法が取られているとはいえない場合も多い。
ここでは、主にiOS, Androidアプリなどのリリース方法を参考にWebフロントエンドのリソースの配信（リリース）をどうするかを書く。
Webフロントエンド特有の事情
iOS, Androidアプリの場合、リリースに関しては事実上プラットフォームから指定されているため選択肢が少ない。
しかし、Webフロントエンドの場合、事実上URLで指定できる場所にさえおければリリース処理が終わることが多く、自由度が高い。
前提
ここで言う「Webフロントエンド」とは、「Webアプリケーション」と言われるようなそれなりにコード量の多いものを想定している。
Webフロントエンドのリリース戦略とは
以下のようなリリース戦略を提案する。
developへmerge時にフロントエンドチームへリリース
平日17時にdevelopを開発チームリリース
平日10時にdevelopをmainへmerge
平日14時から1時間ごとにmainを段階リリース
平日17時にmainを全体へリリースする
上記の「平日」は祝日を考慮し、休日の前日は除外する方が良い。
（Google Calendar APIから取得するとメンテナンスコストが低くて良い）
もし課金サービスであるなら、段階リリースは非課金ユーザに対して行うことが望ましい。
（Sentry等でエラー監視を行う場合、段階リリース対象のユーザのエラーに注意すること）
時間はあくまでも参考なので、主な業務時間に合わせて調整する。
（上記は主にtoBの場合を想定している）
もし、各段階で障害が発覚した場合、develop -> mainの順で修正し、リリースを行い直す。
コンセプト
重要なのは以下の点。
リリースは自動であること
ただし、障害発生時の対応のため、手動でリリーする方法も確保すること
段階的にリリースされること
上記の例の場合、以下の順番でリリースされる
主な開発者（問題があった場合自分で修正できる者）
開発者全体（エラーがあっても対処できる者）
段階リリース対象者
全ユーザ
リリース段階に社内の非開発者を対象とすることは推奨しない
（ユーザサポート等でユーザと環境が違った場合に支障が出やすいため）
まとめ
主にWebフロントエンドを対象としたリリース戦略を書いた。
上記はリリース戦略はWebフロントエンドに限らないが、Webフロントエンドの場合リリースにあたりDB等の状態を考慮する必要が低いためリリース戦略の自由度が高い。
過去、実際に上記のリリースフローで運用したが、考慮事項が少なくドキュメントも少なかった。
3 notes
·
View notes
Link
ＴＥＤにて
ピーター・ワインストック: 手術の安全性を高める本物のような3Dシミュレーター
（詳しくご覧になりたい場合は上記リンクからどうぞ）
緊急ケア医師であるピーター・ワインストックが、危険な手術を事前にリハーサルなどの練習をするために手術チームがハリウッドの特殊エフェクトや３Dプリンティング技術を使って、まるで、本物のような患者の複製を作る様子を紹介します。
「数時間前に出力しつつ２度（模擬）手術を行い、リアルに切るのは１度だけ。」このトークで手術の未来を垣間見ましょう。 （模型ですが刺激的な映像の部分があります）
このシュミレーターが実現した後、私がボストン小児病院のICUで家族に話す説明の内容はすっかり変わりました！！
こんな会話を想像してみてください。「私たちは、ICUで頻繁にこの病気の症例を処置します。お子さんに行うような手術を数多くした。それだけでなく「あなたのお子さんの手術」に慣れているんです。２時間前に10回も手術したので、これからの本番にも万全の準備ができていますよ」と！！
これから手術を受ける皆様、いかがでしょうか？
新たな治療技術があり、それが、医師や看護師の手に渡れば、子ども、大人、あらゆる年齢の患者たちの治療アウトカムを改善し、疼痛や苦しみ。手術室で過ごす時間。そして、麻酔時間を減らし、治療は最高の効果を生み、治療をすれば、その分だけ患者は良くなる。
それに加えて副作用がなく、あらゆる場所で処置できる。そんなものがあったらどうでしょう。ボストン小児病院のICUで働く救急医にするとこれはゲームチェンジャーです。
その技術とは、まるで本番のような手術のリハーサルです。本番のようなリハーサルが。治療シミュレーションを通じて行われます。
症例を通して、この奮闘の様子をご紹介し、この技術が医療の質を高めるだけでなく、医療にとって必須だという理由をご説明しましょう。これは生まれたての女の子です。私たちは、生まれて最初の日を「生後０日目」と言いますが、この子が生まれるとすぐ全身状態が悪化しているのに気づきました。心拍が早まり血圧���下がり、赤ちゃんの呼吸はとても速く、その理由は胸部レントゲンに表れていました。
これはベビーグラムと言う新生児の全身のレントゲン撮影です。上方は、心臓と肺があるべきところです。下方には腹部が見えますが、ここには腸があるべき場所です。透明な部分が赤ちゃんの胸部、向かって右側へ侵入しているのが見えると思いますが、これらは間違った場所にある腸です。それが、肺を圧迫し、この哀れな赤ちゃんの呼吸を困難にしていました。
これを解決するためには、この子をすぐに手術室へ運び、腹部に腸を戻し肺の圧迫を解決し、再び呼吸できるようにすることが必要です。でも、彼女が手術室へ入る前に一旦私たちのICUへ連れてこられます。私は外科手術チームと働いています。その子を取り囲み、人工心肺装置につなぎ
そして、まず麻酔をかけ首にごく小さな切開を加え、そこから大血管へカテーテルを通し、この大血管はボールペンの芯ほどの太さです。そして、血液を体内からとり出し 機械を通して血液に酸素が加えられそれが体内に戻されます。この子の命を救い手術室へ安全に運びます。
でも問題があります。
こうした疾患。先天性横隔膜ヘルニアというのは横隔膜に空いた穴から内臓が胸腔内に脱出するのですが稀だということです。世界で最高の技術を持つ外科医でも完全に手技が熟練するために必要な数の手術の機会に恵まれるのは困難です。この症例は稀なのです。稀少な症例をどうやってありふれたものにできるでしょう？
もうひとつの問題は、現行の医療制度で臨床訓練を20年やってきましたが、現行のトレーニングモデルは、徒弟（技術見習い）制度といい数世紀の間使われてきたものですが、手術を一度だか数回見学した後その手術を実地で行います。
次には、次世代の医師に教えるというものです。このモデルでは言うまでもなく、私たちは治療すべき患者を練習台にしています。これは、基本人権上、問題です。もっとましなアプローチがあるはずです。医学の世界は高い危険を伴うのに、本番に備え練習をしない最後の業界と言えるかもしれません。
革新的な治療シミュレーションを使ったより良い方法をご紹介したいと思います。
まず、私たちはこのような方法を何十年も使ってきた危険を伴う業務を行う他の業界を訪ねました。
原子力発電所です。ここでは、想定外の事態が起こった際の訓練をシナリオに基づいて定期的に行います。
私たちに身近な航空業界では、私たちは安心して飛行機に乗れますが、それもパイロットやクルーがこのようなシミュレーターで訓練を積み緊急事態のシナリオで経験を重ね、万が一そんなことが起こったとしても、最悪の事態に備えているという安心感があるからです。
実際、航空業界は、飛行機の胴体丸ごとをシミュレーション環境にしてしまいました。チームの息が合うことが、重要だったからです。これは脱出ドリルシミュレーターで、もし、その「極めて稀な事態」が起こるようなことがあっても彼らは即座に対応する準備ができています。
そして、いろいろな面で衝撃的だったのが文字通り大きなお金が関わるスポーツ業界です。
野球チームの選手たちの練習風景を想像してください。これは素晴らしく進んだトレーニングモデルだと思います。彼らは、まず春季キャンプへ出かけます。春季キャンプへ行き野球におけるシミュレーターのようなものです。実際の球場ではなくシミュレーションでプレシーズンマッチの練習をします。
シーズン中にフィールドでゲーム開始の前にまず何をすると思いますか？バッティングケージで何時間もバッティング練習をして様々なボールを打ち、筋肉がほぐれるまで十分に練習して本番に備えます。
ここからが最も興味深い部分です。スポーツ観戦をする方なら見たことがあるでしょう。打者がバッターボックスに入り、ピッチャーも投球準備ができました。投球の直前には打者は何をするでしょう？ボックスから踏み出しまずスイングします。必ずその順番です。
私たちがどのようにこんな訓練の場を医学の世界で作っているのかをお話しします。
ボストン小児病院で私たちは患者を治療する前のバッティングケージを作っています。最近の例でお話しすると頭部が大きくなり続ける４歳児の症例ですが、その結果。神経系などの発達に遅れが起こります。これを引き起こしていたのは水頭症と呼ばれる疾患です。
神経外科学を簡単に説明すると、まず脳がありそれを包む頭蓋骨があります。脳と頭蓋骨の間にあるのは、脳脊髄液。あるいは、髄液と呼ばれ衝撃を吸収します。あなたの頭の中では脳脊髄液が脳を包み、脳と頭蓋の間を満たしています。脳のある部位で生産され、それが回流しそれが再吸収されます。
この見事な流れは私たち皆に起こります。しかし、不幸にも交通渋滞のようにこの流れが滞ってしまう子どもがいて滞留した髄液が、脳を圧迫し脳の成長を阻害します。その結果、子どもは神経系発達指標に後れを生じます。これは非常に厄介な小児の疾患で手術で治療します。
従来の手術法は、頭蓋骨の１部を切り取り、この液体を排出しそこに排出管を取り付けて、さらに、排出された髄液が体内に戻るようにします。大手術ですが、良いニュースは神経外科技術の向上でこの手術では侵襲の低いアプローチが可能になっています。
小さなピンホールを作ってカメラを挿入し、脳の深層部まで導いて小さな穴を被膜に開け髄液を排出します。まるでシンクが排水するように、突然、脳は圧力から解放され本来の大きさに戻ります。私たちはその子を穴１つで治療した訳です。
しかし、問題があります。水頭症は比較的珍しい疾患でこの内視鏡を正しい場所に持っていくトレーニングはありませんでした。でも、外科医たちは創造性を駆使し、彼らはトレーニングモデルを選びました。これが今のトレーニングモデルで。
本当ですよ。この赤ピーマンはハリウッドの特殊効果ではなく本物の赤ピーマンです。医師はこの中に内視鏡を差し込み「種除去手術」をするのです。
この内視鏡と小さなピンセットを使い種を取り出します。原始的な方法ですが、これが手術の技を身につけるための方法です。それから医師たちは徒弟制度に戻り、多くの手術例を見て学び、手術し、それをまた教え、患者と出会うチャンスを待つだけです。
しかし、もっと良い方法があります。
私たちは、子どもをモデルに複製を作り、外科医や手術チームがあらゆる重要な場面のリハーサルをできるようにしました。これをご覧ください。私のチーム。シミュレーター・プログラム。SIMエンジニアリング部門で素晴らしいスタッフで構成されています。
彼らは、機械工学技術者、イラストレーターたち、CTスキャンやMRIから得た１次データをデジタル情報化し、アニメーションにして子供の臓器の通りの配置に組み立て、手術の必要に応じて体表のスキャンが行われ重ねられます。そのデジタルデータを取り、この最先端の３D印刷デバイスでアウトプットし、子どもの臓器をミクロンレベルまで本物そっくりに印刷することができます。
このように、この子の頭蓋は手術の数時間前に印刷されます。
これを実現する手助けをしてくれたのは、西海岸は、カリフォルニア州。ハリウッドの友人たち。彼らは現実を再現する技術に長けている技術者たちです。私たちにとって大きな跳躍ではありませんでした。この分野に踏み込んでいくと自分たちは映画製作と同じことをやっているのだとわかりました。
映画を作っているんです。ちょっと違うのは、俳優たちではなく、本物の医者や看護師が出演することです。これらはカリフォルニア州ハリウッドのFractured FX社の友人たちによる画像です。エミー賞を受賞した特殊効果技術の会社。ジャスティン・ラレイとチームでこれは患者ではありませんよ。
彼らの優れた仕事を見て、彼らと協力し、互いの専門を融合させるため彼らをボストン小児病院へ招いたり、我々がハリウッドへ赴いたりしてシミュレーター開発のため意見を交換しました。
これからお見せするのはこの子の複製です。髪の一本一本まで再現されています。これも同じ子の複製です。気分悪くなられたら申し訳ありませんが、これは手術をする予定の子供を再現しシミュレートしたものです。これが先ほどの被膜でこの子の脳の中にあります。
今からお見せするのは、本物の患者とシミュレーションです。小さな内視鏡カメラが入っていくのがここに見えますね。この被膜に小さな穴を開け液体が出るようにします。ここでどちらが本物でしょう？なんていうクイズを出すつもりはありません。右がシミュレーターです。
外科医たちは、トレーニング環境を用意しこうした手術を何度でも練習できます。慣れて安心できるまで。そうした練習を経た後でのみ、子どもを手術室へ運びます。それだけでなく、ここでの重要なステップは技術そのものだけでなく、その技術を担当チームとの連携にうまく組み込むことです。
F1の例を見てみましょう。
テクニシャンがタイヤを交換しています。この車で何度も繰り返し作業し、それは即座にチーム・トレーニングに採り入れられ、チームが一丸となってタイヤ交換を行い車をレーストラックに送り出します。
私たちは医療にそれを取り入れました。これは手術のシミュレーションです。お話ししたシミュレーターをボストン小児病院の手術室に持ち込み、当院の手術チームが本物の手術の前にシミュレーション手術をしています。
２度の手術を行いますが切るのは１度だけ。
本当に驚きです。この次のステップが重要なのですが、チームは部屋から出るとすぐに振り返りを行います。リーンやシックスシグマと同じテクニックを使い、彼らを集め何がうまくいったか。そして、もっと大切なことですが、何がうまくいかなかったか。どうやってそれを修正するかを話します。
そして、手術室に戻り繰り返すのです。最も必要な時にバッティング練習ができるんです。
さあこの症例に戻りましょう。同じ子ですがボストン小児病院で、この子がどんなケアを受けるかをご説明しましょう。この子は午前３時に生まれました。午前２時には私たちチームは集まり、スキャンや画像からデータを得た臓器を複製し、いわゆるバーチャル・ベッドサイド環境を作り出しました。
シミュレーテッド・ベッドサイドを数時間後にはこの子を実際に手術するチームにその手順を行ってもらいます。ごらんください。複製にメスを入れているところです。赤ちゃんはまだ生まれていません。
どうですか？
私がボストン小児病院のICUで家族に話す説明の内容はすっかり変わりました。
こんな会話を想像してみてください「私たちは、ICUで頻繁にこの病気の症例を処置します。お子さんに行うような手術を数多くした。それだけでなく「あなたのお子さんの手術」に慣れているんです。２時間前に、10回も手術したので、これからの本番にも万全の準備ができていますよ」
この新しい医療技術とは、本番に備えて練習ができる極めてリアルなリハーサルです。
ありがとうございました。
しかし、日本では生物学や先端医療、iPS細胞などの再生医療以外は現状維持の方がいいかもしれません。
なお、ビックデータは教育や医療に限定してなら、多少は有効かもしれません。それ以外は、日本の場合、プライバシーの侵害です。
通信の秘匿性とプライバシーの侵害対策として、匿名化処理の強化と強力な暗号化は絶対必要です！
さらに、オープンデータは、特定のデータが、一切の著作権、特許などの制御メカニズムの制限なしで、全ての人が
望むように再利用・再配布できるような形で、商用・非商用問わず、二次利用の形で入手できるべきであるというもの。
主な種類では、地図、遺伝子、さまざまな化合物、数学の数式や自然科学の数式、医療のデータやバイオテクノロジー
サイエンスや生物などのテキスト以外の素材が考えられます。
こういう新産業でイノベーションが起きるとゲーム理論でいうところのプラスサムになるから既存の産業との
戦争に発展しないため共存関係を構築できるメリットがあります。デフレスパイラルも予防できる？人間の限界を超えてることが前提だけど
しかし、独占禁止法を軽視してるわけではありません��で、既存産業の戦争を避けるため新産業だけの限定で限界を超えてください！
（個人的なアイデア）
宇宙空間にも活用できれば、月面や宇宙空間のロボットを自宅からゲームのように操作するだけで賃金がもらえるような、一神教での労働の概念が変わるかもしれません。
日本では、医療関係は、法律で個人情報の秘匿を義務化されてますが•••
国内法人大手NTTドコモは、本人の許可なく無断でスマートフォンの通信データを警察機関に横流しをしてる！
GAFAのように対策しない違法な法人？まさか、他にも？独占禁止法や法律を強化する？デフレスパイラル予防。このような国内大企業、中堅法人も危険。傲慢。
日本国憲法に違反しているので、アメリカのカリフォルニアやヨーロッパのGDPRのようにデータ削除の権利行使。
他に、再分配するデータ配当金を構築してからでないと基本的人権侵害になるため集団訴訟を国民は起こすべきだ。
税の公平性は、よく言われるが、時代が変わり一極集中しやすく不公平が生じてるなら産業別に税率を上昇させてバランスよくすればいい？
特に、IT産業などは、独占化しやすいから別枠で高税率にして、ベーシックインカム用に再分配システム構築できないなら独占禁止法強化。
自動的にディープフェイクをリアルタイムの別レイヤーで、防犯カメラの人物に重ね録画していくことで、写る本人の許諾が無いと外せないようなアルゴリズムを強力に防犯カメラの機能を追加していく。
防犯カメラのデータを所有者の意図しない所で警察機関他に無断悪用されない抑止力にもなります。
防犯カメラのデータを所有者の意図しない所で警察機関他に無断悪用されない抑止力にもなります。
防犯カメラのデータを所有者の意図しない所で警察機関他に無断悪用されない抑止力にもなります。
マイケルサンデルは、メリトクラシー（能力主義）の陳腐さを警告しいさめています
サミット警備時、死者数が微小なのにテロ対策と称し厳戒態勢！
経済活動を制限した時に、警視庁職権濫用してたが、死者数が甚大な新型コロナに予算増やした？
警察権力悪用！
庶民弱者に圧力やめさせないの？
オリンピック前にも圧力あったから予算削除しろ傲慢警察！
さらに・・・
勝手に警察が拡大解釈してしまうと・・・
こんな恐ろしいことが・・・
日本の警察は、2020年3月から防犯カメラやSNSの画像を顔認証システムで本人の許可なく照合していた！
憲法に完全違反！即刻停止措置をみんなで要求せよ。
日本の警察の悪用が酷いので、EUに合わせてストーカーアルゴリズムを規制しろ！
２０２１年に、EU、警察への初のAI規制案！公共空間の顔認証「原則禁止」
EUのAI規制は、リスクを四段階に分類制限！
前提として、公人、有名人、俳優、著名人は知名度と言う概念での優越的地位の乱用を防止するため徹底追跡可能にしておくこと。
禁止項目は、行動や人格的特性に基づき警察や政府が弱者個人の信頼性をスコア化や法執行を目的とする公共空間での顔認識を含む生体認証。
人間の行動、意思決定、または意見を有害な方向へ操るために設計されたAIシステム（ダークパターン設計のUIなど）も禁止対象にしている。
禁止対象の根拠は「人工知能が、特別に有害な新たな操作的、中毒的、社会統制的、および、無差別な監視プラクティスを生みかねないことは、一般に認知されるべきことである」
「これらのプラクティスは、人間の尊厳、自由、民主主義、法の支配、そして、基本的人権の尊重を重視する基準と矛盾しており、禁止されるべきである」
具体的には、人とやり取りをする目的で使用されるAIシステム（ボイスAI、チャットボットなど）
さらには、画像、オーディオ、または動画コンテンツを生成または操作する目的で使用されるAIシステム（ディープフェイク）について「透明性確保のための調和的な規定」を提案している。
高リスク項目は、法人の採用活動での利用など違反は刑事罰の罰金を売上高にかける。
など。他、多数で警察の規制を強化しています。
人間自体を、追跡すると基本的人権からプライバシーの侵害やセキュリティ上の問題から絶対に不可能です！！
これは、基本的人権がないと権力者が悪逆非道の限りを尽くしてしまうことは、先の第二次大戦で白日の元にさらされたのは、記憶に新しいことです。
マンハッタン計画、ヒットラーのテクノロジー、拷問、奴隷や人体実験など、権力者の思うままに任せるとこうなるという真の男女平等弱肉強食の究極が白日の元にさらされ、戦争の負の遺産に。
基本的人権がないがしろにされたことを教訓に、人権に対して厳しく権力者を監視したり、カントの思想などを源流にした国際連合を創設します。他にもあります。
参考として、フランスの哲学者であり啓蒙思想家のモンテスキュー。
法の原理として、三権分立論を提唱。フランス革命（立憲君主制とは異なり王様は処刑されました）の理念やアメリカ独立の思想に大きな影響を与え、現代においても、言葉の定義を決めつつも、再解釈されながら議論されています。
また、ジョン・ロックの「統治二論」を基礎において修正を加え、権力分立、法の規範、奴隷制度の廃止や市民的自由の保持などの提案もしています。現代では権力分立のアイデアは「トリレンマ」「ゲーム理論の均衡状態」に似ています。概念を数値化できるかもしれません。
権限が分離されていても、各権力を実行する人間が、同一人物であれば権力分立は意味をなさない。
そのため、権力の分離の一つの要素として兼職の禁止が挙げられるが、その他、法律上、日本ではどうなのか？権力者を縛るための日本国憲法側には書いてない。
モンテスキューの「法の精神」からのバランス上、法律側なのか不明。
立法と行政の関係においては、アメリカ型の限定的な独裁である大統領制において、相互の抑制均衡を重視し、厳格な分立をとるのに対し、イギリス、日本などの議院内閣制は、相互の協働関係を重んじるため、ゆるい権力分立にとどまる。
アメリカ型の限定的な独裁である大統領制は、立法権と行政権を厳格に独立させるもので、行政権をつかさどる大統領選挙と立法権をつかさどる議員選挙を、別々に選出する政治制度となっている。
通常の「プロトコル」の定義は、独占禁止法の優越的地位の乱用、基本的人権の尊重に深く関わってきます。
通信に特化した通信プロトコルとは違います。言葉に特化した言葉プロトコル。またの名を、言論の自由ともいわれますがこれとも異なります。
基本的人権がないと科学者やエンジニア（ここでは、サイエンスプロトコルと定義します）はどうなるかは、歴史が証明している！独占独裁君主に口封じに形を変えつつ処刑される！確実に！これでも人権に無関係といえますか？だから、マスメディアも含めた権力者を厳しくファクトチェックし説明責任、透明性を高めて監視しないといけない。
今回、未知のウイルス。新型コロナウイルス2020では、様々な概念が重なり合うため、均衡点を決断できるのは、人間の倫理観が最も重要！人間の概念を数値化できないストーカー人工知能では、不可能！と判明した。
複数概念をざっくりと瞬時に数値化できるのは、人間の倫理観だ。
そして、サンデルやマルクスガブリエルも言うように、哲学の善悪を判別し、格差原理、功利主義も考慮した善性側に相対的にでかい影響力を持たせるため、弱者側の視点で、XAI(説明可能なAI)、インターネット、マスメディアができるだけ透明な議論をしてコンピューターのアルゴリズムをファクトチェックする必要があります。
＜おすすめサイト＞
Game On | Oculus Quest Content Preview
アレックス・キップマン：HoloLensホログラム時代の未来にあるもの
キャサリン・モーア：外科の過去、現在とロボットのある未来
ニコライ・ベグ：極めて危険な一瞬を回避できる手術器具
フランツ・フロイデンタール: 手術せずに心臓疾患を治す方法
ナディーン・ハッシャシュ＝ハラーム: 拡張現実が変える手術の未来
＜提供＞
東京都北区神谷の高橋クリーニングプレゼント
独自サービス展開中！服の高橋クリーニング店は職人による手仕上げ。お手頃50ですよ。往復送料、曲Song購入可。詳細は、今すぐ電話。東京都内限定。北部、東部、渋谷区周囲。地元周辺区もＯＫです
東京都北区神谷のハイブリッドな直送ウェブサービス（Hybrid Synergy Service）高橋クリーニングFacebook版
#ピーター#ワインストック#手術#3D#Printer#プリンター#外科#ロボット#医者#エフェクト#メーカー#HoloLens#AR#VR#生命#人工#知能#F1#臓器#血管#赤ん坊#胎児#NHK#zero#ニュース#発見#discover#discovery
1 note
·
View note
Link
スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートアップだから」という発言はよく聞かれますし、私も使ってしまうことはありますが、基本的にはダサい物言いだと言えます。 テストコードは書いたほうが速い 実は、テストコードが書けるスキルがある場合、ある程度のサイズのサービスを作る上ではテストを書いたほうが開発速度は速くなります。 また、うまくテストコードが書ければ変化にも強くなります。サービスは複雑になる宿命があり、ある変更がどこに影響が及ぶかは完全に把握しきれるものではありません。そんなときにテストコードはあなたの身を守ってくれるのです。バグによってサービスが停止してしまうリスクを減らし、安心して素早く機能追加や機能の変更をおこなえるのです。サービスは作って終わりでありません。素早く進化させていくためにもテストコードは必要なのです。 本番に出してからバグに気づいてあたふたするよりも、テストコードで気づいたほうが早く、顧客へのダメージも少なくなります。動作確認のためにテストコードを書いてみましょう。動作確認の為に手元で動かすようなことをしている場合、それをテストコードにしてしまえばいいのです。よく言われる格言に「時間がないからテストコードが書けないのではない。テストコードを書かないから時間がなくなるのだ」というものがあります。 変化に強いことの重要性 現代においてサービスは変更させ続ける必要があります。何故ならば世界も以前にもまして高速に変化し続けているからです。世界の変化に合わせてサービスを変化させつづけないと生き残れません。一番わかり易い例としてはサービス規模で、1000人の顧客に最適なシステムと、100万人に最適なシステムは大きく異なります。また、料金計算が関わるようなシステムで、消費税率の変更に追随できなかったらサービスを終了せざるを得ません。もちろん顧客のニーズも刻一刻と変わります。 そして、意外に思うかも知れませんが、サービスの変更頻度が多いほど、逆にシステムは安定することが明らかになっています。現代において、数多くのメジャーサービスは見た目はさほど変わらないかも知れませんが、裏側では一日に何度もシステムを変更(Deploy)しています。「動いているシステムは触るな」は過去の言葉になりました。 自転車のメタファー テストコードを書けるかどうかは自転車に乗れるかどうかに似ています。覚えていないかも知れませんが、皆さんは自転車に乗れるようになるまで苦労をしたはずです。しかし、一度自転車に乗れるようになってからは、足で走るよりもずっと速い速度で移動できるようになりました。そして、一度身につけてしまえば、全然難しいものではなくなります。 テストを書かないほうが速いように思えてしまうのは、それは自転車に乗れない人が自転車に乗ったときの景色を知らず、そこに想像が及んでいないようなものだと言えます。 もちろん、テストコードは銀の弾丸ではなく、バグを完全になくせる手法ではありません。コードの品質を上げる手段であって、QAなどを完全に無くせるものではない、ということは留意する必要があります。 テストを書けないとコードを書いてはいけないのか さて、ここまで書いてきたことは、散々色々なところで既に聞いたり目にしてきたことでしょう。聞き飽きたお説教にも感じているかも知れません。 では、テストコードが書けないと、サービスを作ってはいけないのでしょうか。 もちろんそんなことはありません。次のゴールが近くにあるときに、自転車を乗れるようになるまで練習するよりも、今走っていったほうが速いではないか、というのは間違いなく正しい。 良く見かける漫画ベルセルクの主人公ガッツの「何十年も修行して達人になるのを待ってから戦場に出るつもりか？」「だったら、今手持ちのコマでやりくりするしかねェだろ」というセリフは圧倒的に正しいのです。 ソフトウェア開発は初期投資が少なく始められ、多くの人に開かれているという良い特徴があります。どんな業界であれ、参入障壁が高く前提のコンテキストを多く要求する分野は新しい血が入りにくくなり、先細ります。ソフトウェア開発は今後も多くの人に開かれているべきで、参入障壁を高くすべきではありません。 だから「テストコードが書けないとサービスを作るべきではない」というような意見があっても無視して作り出してしまいましょう。結局走り出したやつが偉いのです。そして、有力な事業のアイデアがあってコードも完璧に書ける、そんな人はいません(たまにいます)。できる範囲で進めていくしか無いのです。だから、私のこんなエントリーも「知ったことか」と一蹴してくれてかまいません。未熟なコードでも勝てることがある。そこに痛快さがあるのです。 ただし、己の未熟さを認め、手持ちのコマを増やす努力をしたほうが成功率は上がるはずです。テストコードもその一つです。 テストを書かなくても良いとき テストを書かなくてもいいときもあります。書き捨てやプロトタイプなど捨てる前提で作る場合や、テストを書かなくてもいいほど単純なものである場合です。単純なものとは、捨ててすぐに作り直せるくらいのもの、とも言えます。そういう意味でDisposableである、ということが一つの指標となるでしょう。 しかし、捨てるつもりだったものが捨てられず、単純なつもりだったものが複雑化してしまうことは、残念なほどによく起こります。テストを書かなくて良いかどうかを見極めるためには、実はテストを書けるのと同じくらいのスキルが必要かも知れません。 テスト書きすぎ問題 逆にテスト書きすぎ問題、というのもあります。教条主義に陥ってしまったり、テストを書くことが目的化しすぎて過剰になっている、そういうことも起き得ます。 ただ、テストを書くのが好きなエンジニア、というのはいます。テストコードについて考えるのが好きで、テストコードを書くのが目的になっているくらいの人です。テストコードについてのプラクティスを周りに教えてくれたりもします。 そういう人は貴重な存在で大事にすべきです。時にはやりすぎに感じるかも知れませんが、彼らの自主性に任せ、良い結果を期待すると良いでしょう。 とは言え、変化の足かせになるようなテストを書いてしまっているのであれば明らかにやりすぎです。よく言われることですが、例えば、UIのボタンの位置を少し動かしただけで、大量のテストがコケて修正に時間がかかる、プライベートメソッドのテストがリファクタリングの妨げになる、と言った状況は嬉しくないでしょう。 また、エンジニアが「身を守る」ためにガチガチにテストコードを書いてしまうケースもあります。その結果、ちょっとした変更でもリードタイムが嵩んで、変化を阻害する状況が発生します。これは理不尽で唐突な仕様変更を立て続けに行なっていないか、その結果、本番でエンバグした場合に、エンジニアだけを責めていないか、など、コミュニケーションを見直す必要があるでしょう。 結局、テストコードを書くことがペイするか、サービスのためになっているか、という観点を忘れてはいけません。ただ、この辺りは、テストを書けるようになってから心配すればいい話です。テストコードが過剰であるよりも不足を恐れたほうが良いということです。 あるサービスの初期コードはひどかったし、テストコードなんて無かったと聞いたけど あのスタートアップの創業期のコードはひどかった、当然テストコードなんて当然無かった、という話は多く聞かれます。半ば神話や武勇伝のようになっているものもあります。昔のFacebookに関するエピソードが書かれた、Evan Priestley氏のエントリーなど私は大好きです。社内のWikiに「関数は使うな。遅い」と書かれていた、という下りは最高です。 There was a "PHP Best Practices" wiki which basically said "don't use functions, they're slow" (the intent here was good, but the message was not clear). しかし、だから自分たちもテストコードを書かなくて良い、という話ではありません。 多くのスタートアップは創業期に凄腕のエンジニアを雇えるわけではありません。むしろアイデアを考えだした人と、その周辺にいた人で作り始めることが多いでしょう。その上で、彼らなりに良いコードを書こうと努力したけど結果として拙いコードになってしまった、ということでしょう。意図して質を落とそうとしたわけでは決して無いはずです。 技術の進化と業界の当たり前水準の向上 それに、時代は変わり、Web開発関連の技術や業界も進化しました。ノウハウも共有されて良い意味で枯れてきました。それこそ大昔はソースコード管理すらおぼつかない会社が多かったのですが、今やどこも当たり前のようにGitHubを使っています。 テストコードも格段に書きやすくなりました。近年の新しい言語、フレームワークやライブラリは標準でテストが書きやすいように設計され、そのためのユーティリティも整備されています。また、CI/CDサービスがSaaSで誰でもすぐに使いやすい形で提供されているなんて10年前には考えられなかったことです。モニタリングも同様です。 CI/CDを整えることはリリースの安定性とサイクルの高速化に繋がります。また、リリース後のサービスの健全性を測るためにモニタリングも欠かせません。最近よく聞かれるようになったオブザーバビリティは自分たちの本番システムに対する特有の継続的テスト項目とも言えるでしょう。 それらを整備してトライアンドエラーの速度を上げ、改善サイクルを回していくことが昔に比べて劇的にやりやすくなりました。その分、その水準が当たり前となり、現代のサービス運営では当然のように求められるようになっています。 コードやサービスの品質や健全性に投資しないで、サービスが成功する確率は昔に比べて低くなっていると言えるでしょう。 サービスを立ち上げられる特殊能力 しかし、上記のFacebookは、上記のエピソードの2007年時点で既に十分に成功していたSNSだったはずですが、それでもなおひどいコードだらけだったというのは、すごく良い話だと思います。ひどいコードだったかも知れないが、それでもちゃんと立ち上がった。もちろん、昔の話で牧歌的な時代だったというのもあるとは思います。 やはり0→1のコードを書くのが得意なエンジニアというのはいます。そういうエンジニアが書くコードには質の違いがあります。迷わずコードを書き進めた、一筆書きのような勢いを感じられます。そういう勢いは立ち上げ段階では本当に大切です。私にはそういうコードは書けませんが、それもあって、そういうコードを読み解くのは好物だったりします。 そういう質の違いもあって、0→1のエンジニアが書くコードはメンテナンス性が乏しい、などと言われることがあります。実際そういったコードを書く人もいるのでしょう。しかし、私は運良くそういったコードに余り苦しめられたと感じたことはありません。本当にレベルの高い、業界を代表するエンジニアのコードを業務で読ませてもらえたからでしょう。例えば、Natureの初代CTOのmashさん、二代目CTOのtypesterさん、はてなCTOのmotemenさんなどです。 もちろん、彼等の書いたコードには、自分の流儀とは違う最初は読み解けないコードもありましたが、それらを読み解けるようになったことは自分の糧にもなりました。また、そういった立ち上げに成功したコードを引き継いで、整備し拡大する1→10くらいのフェーズが私の得意分野となりました。つまりキャリアにも結びついているので感謝しています。 mashさんは「あまりテストを書きたくない」とは言うものの、必要最低限のテストは書いてましたし、むしろそこを最低限にとどめる勘所に優れていると感じます。また、テストを楽に書くための仕組みを作ってモジュール化するところなどは、いかにもハッカーらしい振る舞いと言えます。 1の仕事をした人をリスペクトしたいと思っています。 そういう特性のある人は常識を打ち破る力を持っています。先程私はテストコードを書くことは自転車に乗るようなものだ、と書きました。つまり、自転車に乗れなくても、マラソンランナーより速く走り、自転車以上の速度を出せれば問題ないのです。djbを見よ。ソフトウェアはそれくらい「てこ」を効かせられるものですし、そういう常識を打ち破る新しい異能をこれからも見てみたいとも思います。 とは言え常人に真似できるものではないので、多くの場合は普通に地道にやるのが良いでしょう。 コードを減らすこととノーコード ここまで読んできて、コードを増やすとテストを書いたりメンテナンスしたりしないといけないのだからコードは少ないに越したことはない、ということに気づいたかも知れません。それは真理です。同じ価値を同じコストで提供できるのであればコードは少ない方が良いのです。 だからこそ近年は自分たちのコアとなる部分のコード以外はクラウドやSaaSを活用することが当たり前になってきました。 ペーパープロトタイピングなどもそうですが、コードを書かないでトライアルアンドエラーを回せるのであればそれに越したことはありませんし、その方法を模索するのが良いでしょう。 そしてノーコード、ローコードがやってきました。人間は欲深い生き物なので、コードを書かないでサービスを作りたいと考えるのは自然なことです。プログラミング言語やさらにはテストコードみたいなめんどくさいスキルを事前に身につける必要がなく、前提知識少なく始められる点で、これらのツールは間違いなく優れています。 VisiCalcを起源とする表計算ソフトが最も優れたノーコードツールである、という状況が40年続いています。流石にそろそろ次のフェーズに移りたいところですし、その流れがきています。人間は欲深い生き物ですし、そして、願ったことは大体成し遂げてきました。 しかし、ノーコードもまた銀の弾丸ではありません。ノーコードツールを現状積極的に使っているわけではないので想像になりますが、ノーコード活用においてもイテレーションの回し方が重要になるでしょう。結局ノーコードであれローコードであれ、変化に強い必要があり、システム開発と同様の難しさを抱えることになります。 つまり、システムを世界の変化に合わせて進化させていきつつも、既存の顧客の体験を損ねるようなバグを生まないようにする安定させる必要があるのです。 そのためのアプローチとしてQAの重要性が増すでしょう。QAの高速化や自動化が以前にも増して求められるようになるのではないでしょうか。 また、ノーコード・ローコードで作ったシステムがある程度複雑化してきたら、設定(コード)を吐き出して、その後はコード管理するアプローチも考えられるでしょう。最初はノーコードツールのGUIで素早くサービスを立ち上げて、しばらくしたらコード化するというわけです。 ちなみにノーコードがもっと成熟して普及したとしても、コードを書く仕事は減らないでしょう。世界はまだまだソフトウェア化される必要がありますし、人間が思いつく雑多でノイズまみれのアイデアを完全にコード無しで解決できるようになるのはまだまだ先になるはずです。 コードの力が世界にはまだ必要です。 質とスピード かなり脱線しましたが、テストコードの話でした。上のFacebookのエントリ内でも書かれてますし、twadaさんのそのものズバリの「質とスピード」という発表も有名になりましたが、結局、質とスピードは両立してしまうことが知られるようになりました。 チームのレベルに質とスピードが依存する。短期的には質とスピードでトレードオフにはなるが、そこは余あまり調整が効かないし、そこで無理に調整しようとすると、質を落とし続けるスパイラルにはまってしまう。結局、地道にチームのレベルを上げていくことが大事だということです。 手持ちの札で最善を尽くしつつも、持ち札を増やす努力も怠らないようにしたいものです。なまくらで戦って勝てるならそれに越したこともないですが、木こりの寓話の通り、ちゃんとノコギリを研ぐ時間を作った方が良いでしょう。もちろん必要以上にピカピカに研ぐ必要は無いとも思いますが。 しかし、このエントリー結構時間を使って書いたのですが、改めてtwadaさんのスライドを見ると「全部書いてあるな…」という気持ちになっています。 ここまでお読み頂きありがとうございました。 採用情報 ということで、私の所属しているNature株式会社ではエンジニアを募集しています。 バックエンドに関してはテストコードはそれなりに書かれていると思いますが、今後はコードの肥大や、チームの人数が増えてきた場合のコード分割等が課題になりそうです。 また、組込み開発のテストを充実させる活動も社内ではしています。 興味があれば、採用応募してくださると嬉しいです。まずはカジュアルに話を聞いてみたいということであれば、Twitter @songmu まで気軽にDMしてください。お待ちしています！ https://nature.global/careers/
0 notes
Text
テン3
10/20
ヤフーのニュースで能年玲奈さんと橋本愛さんの共演を知る。
ああ、最高だ。写真とコメントを見た瞬間に胸が熱くなった。
あまちゃんの2人はもうね、個人的には誰も勝てないんだよな...。思い入れが強すぎるので。。
あー、これは映画を見に行くかな。。
麺欲果てしなかったのでひさしぶりに行くうどん屋へ。
待ちがほとんどなくて入れたのでラッキー。
チャンポンうどんがとろとろでめちゃうま。
妻が食べてた冷たいうどんも細麺に変更してもらっていてこれまためちゃうま。
やっぱ、おいしいので近いうちにまた来よう。
眠たかったけれどがんばって買い物へ行く。
帰ってきてからも眠気がすごかったがテニスボールで足のマッサージをしたら激痛で目が覚めた。
マッサージもできて、眠気も取れるという一石二鳥。
もっとピンポイントでくるであろう鍼治療を一度体験してみたいがビビっている。
SUITS 2の最終回を見る。楽しみました。
結局、夜中まで起きていた。すごい。
10/21
アマプラでぼーっと内村さまぁ～ずを見る。
ぼーっと、見れていいね。
ただ、動画を長時間見るならいまのネット環境では弱すぎるなー。
止まっていた作業をちょっとがんばってみる。
ピッチベンドというものをひたすらいじる。あー、疲れた。
もっといい感じにグリッサンドをしたいんだけどな～。
いろいろとしながらキッチンからテレビを見て食事をする。これはこれで新鮮。
カウンターがある家だとまた違った感覚なんだろうなあ。その食事方法も楽しそう。
ラジオを聴きながら作業したり片付けたりした。
あっと、思ってその後、鶏ガラでプースーを取る。さて、とうだろうか。
10/22
起きてからぼーっとタモリ倶楽部を見る。
こうやってタモリ倶楽部、内村さまぁ～ずを見ているときが充実していて幸せだな～。
ラジオを聴きながら昼に晩御飯の準備。
今度は魚介のダシ。昨日の鶏ガラダシと合わせて鍋にする。
おいしい味噌鍋を作るんだ...。
なんだか、料理の味をいまのところから2段階くらい引き上げたいんだよな。
そのためになにが必要なのか探っているところ。
移動しながら宮下草薙のラジオを聴く。
最新回で草薙さんがアイスひとつにレジ袋を購入してしまって、炎上するんじゃないかと不安がっているのを宮下さんが「生きづらいな」とポツリと言っているのがよかったな～。
お2人のラジオは和む。聴けるわーみたいな。お風呂みたいなラジオ。ほわ～っとする。
ゆったりと過ごしつつも嫌な～文章書きをする。
どうにかならないものか。
10/23
引き続き疲れるような文章を書き続ける。
だいたいUIが悪くて文章を書くのも嫌になる。
おかげで疲れた。疲れた。
アメトーーク‼のもっと売れたい芸人を見たあとにスペシャルを見たら当たり前だけど、番組の中のリズム、流れが全然違った。
もっと売れたい芸人は何回か1回入れてくるチャレンジの部分だと思うからしかたない。
売れてる芸人さんたちの技量が改めてわかった。
10/24
秋晴れという澄んだ青空の天気だったのでサイクリングを兼ねて中央図書館まで行く。
特に目的の本があったわけじゃないけど、結果的にオードリーのラジオ本と宮下草薙の本を借りた！
棚が移動中だったので書架にあったのが少なかったな～。
図書館のあとに有名ラーメン屋でつけそばを食べる。
おいしいけれど、自分の食べるスピードが遅くてつけ汁が冷めちゃう。。
つけ汁に漬かっているチャーシューがおいしかったな～。
黒豚なんだろうなあ。黒豚好きだな～。
お腹がいっぱいになったところゆるゆると帰る。
普段、夜に通らない街を歩いてみたら新鮮だった。
一応、おしゃれとされている街だからおしゃれっぽく見えた。
買い物に迷いに迷って結局、スーパーへ行く。
チートデイを作るためのジュースやお菓子を購入。
帰って、こたつに入り、ジュースと柿の種と借りてきたオードリーのラジオ本を読む。最高か。最高だ。
読み進めていくとめちゃくちゃおもしろい。
新米リスナーだから過去を遡れるのはありがたい。
10/25
日曜日も快晴。
重い腰をあげてギターをメンテナンスに行く。
今里筋線のことはいつも忘れてるし、名前のことも忘れているくらい地味だけど、乗ってギター屋へ向かった。
しかし、今里筋線は深い。もぐらってこういう気持ちなのかなというくらいに。
調べたら大阪メトロの1日乗車券ってバスも有効なんですね。
というか、バスが90分いないなら2回目の乗車が無料なことに驚いた。
乗り換えにも往復にも使えるらしい。
普段、大阪市バスなんて使わないから知らなかった～。
これをもって有効に使えることがあるかな。検討してみよう。
ギターを修理に出すと、メーカーのことを教えてくれた。
いまはもうないメーカーらしい。うーむ。
メンテナンスしていない割に状態は悪くないとのことでよかった。
気さくな職人をお願いした。こうなるとメンテナンス明けが楽しみ。
ギターがメインのアルバムを作るぞ～。
地下鉄を乗り継いでかつてよく行ったとんかつ屋へ。
小規模チェーンなんだけど、めちゃくちゃクオリティー高いんだよね。
おいしすぎて腹パンでした。また来ます。
これまたひさしぶりの長堀鶴見緑地線に乗ったんだけど、利用者にしたら割と便利な路線なのかも。
しかし車両内が狭い。
今里筋線も同じシステムなんだよね、たしか。
その後に、これまた少しひさしぶりな喫茶店へ。
本などを読みいい感じに過ごして帰る。
帰ってきてからたった2ヶ月でもさもさになった髪の毛を切る。
髪が伸びるスピードが早すぎる。
セルフもいいんだけど、人の髪も切りたい。
ボブカットしかできないけれど。
〆
Ueda Takayasuさん主催レーベルのコンピレーションアルバムに参加させていただくことになりました。
こういった機会がなかったのでありがたい限りです。
10月28日にBandcampでのリリースです。
どうぞよろしくお願いいたします。
0 notes
Text
Adobe XDとBootstrapで作業を効率化 第2回: UIキットをデザインシステムLiteのデザインガイドに落とし込む - Adobe Blog
前回の記事では、デザインシステムを構成する2つのガイドライン、そして2つのキーワード、最後に「デザインシステムLite」のコンセプトを紹介しました。
本記事は、デザインシステムLiteの具体的なサンプルを紹介しつつ、最初の構築ステップとして、UIキットをデザインガイドに落とし込む手順を紹介します。
デザインシステムLiteに必要な要素
デザインシステムLiteは、制作するサイトに見合った規模のシステムとして構築するのがポイントです。そのためには、デザインに本当に必要な要素だけを扱うようにします。
今年12月に開催されたAdobe Max Japan 2019のサイトは、デザインシステムLiteのコンセプトを取り入れて制作されています。このサイトは、CSSフレームワークのBootstrapを使用することを前提にデザインされました。ですが、Bootstrapを使用するからといって、フレームワークの機能の全てを網羅するガイドラインを作成する必要はありません。デザインシステムLiteは、本当に必要な要素のみを扱えばいいのです。
どのプロジェクトにも必要な要素は「カラーパレット」「タイポグラフィ」「ボタン」です。この3つの要素だけ抑えておけば、全てのサイトで応用が効く基本のガイドラインができます。そして、デザインで3回以上使用するデザイン要素があれば、それらも共通化してガイドラインに組み込みます。
Adobe Max Japan 2019のWebサイト
デザインガイドの例
具体的な例として、Adobe Max Japan 2019のサイトのために作成されたデザインガイドを紹介しましょう。このデザインガイドにも、もちろん基本の3要素は定義されています。
最低限必要な3つの要素
まず、カラーパレットは「Primary」「Success」といったBootstrapのカラーパレットのデザイントークンを踏まえてつくられています。グレースケールのカラーパターンも同様です。セッションのカテゴリーを表すためのカラーはこのサイト固有の要件であるため、独自に用意したカラーパレットが追加されています。
Bootstrapのカラーパレットの定義に揃えてつくられている
次は、タイポグラフィです。これはこのサイト専用に新規に用意されたガイドラインです。デスクトップ用とモバイル用それぞれに見出しや段落のタグに応じたフォントサイズと行間の設定が数値で記載されています。
タイポグラフィはデスクトップ、モバイルのサイズを指定している
最後に、ボタンのデザインガイドです。カラーパレットの場合と同様に、Bootstrapのボタンの仕様がベースになっています。Bootstrapのボタンはホバーやフォーカス時に背景色が暗くなるデザインですが、このガイドでは透過度が変わるようになっています。他にも、ボタンの角を丸くするなど手が加えられています。
ボタンの基本構成はBootstrapに揃えて、ホバーなどは独自に設定している
その他の要素
今回作成されたデザインガイドには、グリッドもBootstrapのグリッドを元にしたものが定義されています。グリッドに沿ったレイアウトであれば、HTMLやCSSで構築する際のスピード向上が期待できます。
Bootstrapのグリッド合わせて配置されている
その他にも、フォームやロゴなど、Adobe Max Japan 2019のサイトのデザインガイドには全部で8つの項目が記載されています。アドビのSpectrumなどと比べるとかなり限定的で心もとなく見えるかもしれませんが、これだけでも十分にデザインガイドとして機能します。
カラーパレット
タイポグラフィ
ボタン
フォーム
ロゴ
ヘッダー・フッター
ブロック（グリッド/間隔）
アイコン
デザインシステムLiteのデザインガイドをつくるメリット
本当に必要な要素だけのデザインガイドが持つメリットを改めてここで確認しておきましょう。まずはサイト制作に関連するメリットです。
カラーパターンやコンポーネントが俯瞰しやすくなります。そのためデザインの見直しも効率的に行えます。
開発側はページデザインを眺めてコンポーネントの重要度を見定める必要がなくなります。デザインガイドには重要なものしか掲載されていないためです。
見通しの良いガイドラインを共有することで、「ここのパーツが足りない」などの開発側からの要望への対応が容易になります。
また、クライアントとのコミュニケーションにも役立ちます。
中間成果物としてクライアントに提出する資料になります。デザインに疎い方にも説明しやすい資料として使えます。
「ここを目立たせたいから赤にしてくれ」といった思い付きの指示に対し、カラーパレットやコンポーネントを見せることで、そのサイトに適切な「目立たせる方法」を提案できます。
例えば、2つの色を引き立てあう配色に補色があります。赤と緑や青と黄色などがその組み合わせの例です。このような配色をデザインシステムLiteのカラーパレットに用意しておけば、「目立たせたい」という要望に対して論理的に提案することが可能です。
���ザインガイドをAdobe XDで作成する
それでは、具体的にデザインシステムLiteのデザインガイドを作成する手順を紹介しましょう。
メジャーなフレームワークであるBootstrapには多くの「UIキット」が存在します。UIキットは、ボタンやフォームといったUIがまとまったデザイン集です。既存のUIキットを利用することで、必要な手間を省いてデザインガイドを効率的に作成することができます。
Adobe XDを使うと、Photoshop、Illustrator、Sketchといった別アプリケーションのファイルを読み込めるため、入手可能なUIキットの殆どの利用することが可能です。今回はIllustratorで作成されたBootstrapのUIキットを使用する手順を紹介します。XDの「ローカルコンピューターから開く」メニューからaiファイルを選択すると、ダウンロードしたUIキットをXDのドキュメントとして編集できるようになります。
使用したAiファイル Bootstrap 4 GUI – Vector File on Behance
上の画像は、IllustratorのUIキットを読み込んだXDの画面のキャプチャーです。デザインが崩れることなく表示されています。この状態からコンポーネントを作成し、ステートを定義して、カラーパレットの抽出とデザイントークンの設定を行います。
ボタンコンポーネントを作成する
まずはXDのコンポーネント機能を利用して、デザイン要素のコンポーネントを作成していきます。繰り返し使われる要素をコンポーネントにしておくと、まとめて修正することができるためデザイン作業が効率的になります。また、デザインガイドのコンポーネントを修正したら、それを他のドキュメントに同期することが可能であるため、変更管理も容易です。XDのコンポーネントは、デザインシステム構築にAdobe XDを使用する大きな理由のひとつと言えるでしょう。
カンバス上の要素をコンポーネント化するには、要素を選択してから右クリックして、「コンポーネントにする」を選択します。もしくは、ショートカットキーを使うこともできます。Windowsは[control + K]、Macは[command + K]です。
早速ボタンをコンポーネント化してみましょう。背景になる図形と文字を選択してから、コンポーネント化の操作を行います。
ボタンの背景と文字を選択して、コンポーネント化する
ボタンをコンポーネントに変換する際、文字の書式が中央揃えになっていなければ、中央揃えにしておくと、後で文字数が変わった時に文字の位置を修正する必要がなくなります。
文字揃えの違いによるボタンの文字数を変えた場合の変化
コンポーネント化すると、画面左側にあるアセットパネルのコンポーネント欄に追加されます。アセットパネルが表示されていない場合は、画面左端の下から3番目のアイコンをクリックします。
この操作により作成されたオリジナルのコンポーネントは、マスターコンポーネントと呼ばれます。アセットパネルからマスターコンポーネントをドラッグして、アートボード上にコンポーネントの複製を配置できます。複製されたコンポーネントはインスタンスと呼ばれます。アートボード上のコンポーネントをコピーしてインスタンスを配置することもできます。デザインを行う際には、インスタンスを利用して画面を構築していきます。
コンポーネントをドラッグして画面に配置できる
ボタンのラベルや横幅など、インスタンスに固有の属性を変更する場合は、そのままインスタンスを修正します。一方、全てのインスタンスの属性を変えたい、例えば背景色を青から赤に変更したいといった場合には、マスターコンポーネントを修正します。
マスターコンポーネントを修正するには、インスタンスを右クリックして「マスターコンポーネントを編集」をクリックしましょう。マスターコンポーネントが編集可能な状態で表示されます。
コンポーネントをまとめて編集したい場合は、マスターコンポーネントを修正する
ボタンコンポーネントにステートを追加する
ボタンには、マウスオーバーや非アクティブなどの様々な状態があります。これを扱うのに便利な機能がステートです。同じコンポーネントの中に、複数のステートを追加して、それぞれに異なる外観を設定することができます。
ステートを利用するには、コンポーネントを選択してから、画面右側のプロパティインスペクタの「コンポーネント」の欄を操作します。ステートが追加されていないコンポーネントであれば「初期設定のステート」だけが表示されているでしょう。
では、実際にステートをひとつ追加してみましょう。ここではホバーステート（マウスオーバーの状態）を追加することにします。まず、「初期設定のステート」の右にある十字ボタンを押します。すると「新規ステート」と「ホバーステート」を選択するドロップダウンメニューが表示されます。ホバーステートを追加すると、マウスオーバーのインタラクションも一緒に追加されます。
プロパティインスペクタのからステートを追加できる
追加したホバーステートが選択されていることを確認してから、コンポーネントをダブルクリックして編集（ホバー状態の外観に変更）します。この状態で行われる変更は、ホバーステートだけに有効で、他のステートには影響しません。一方、初期設定のステートへの変更は、他のステートにも反映されます。ステートを使用する場合は、どのステートで作業しているのか確認するのを忘れないようにしましょう。
ステートによって状態の変化を画面上で再現しやすくなる
とはいえ、コンポーネントがステートを持っているかは、一目見ただけでは判断できません。デザインガイドを作成する際は、ステートを持ったコンポーネントにはステート一覧を用意するようにしましょう。また、コンポーネントに「コンポーネント名: state」などの名前を付けておくのも有効です。
コンポーネントに名前を付け、ステートがあることを伝える
コンポーネントからカラーパレットを作成する
XDには、シェイプの塗りや線の色、テキストのフォントスタイルを抽出して、アセットとして登録できる機能があります。これを利用するとカラーパレットや文字スタイル一覧を簡単に作成できます。
それでは、ボタンに使われている色を登録してみましょう。登録したい色が使われているボタンを全て選択したら、右クリックしてコンテキストメニューを表示します。「アセットにカラーを追加」という項目をクリックすると、左のアセットパネルに選択されたボタンに使われている色が展開されます。
ボタンから色の抽出を行う
この手順で追加された色の名前には、16進数のカラーコードが指定されています。この名前をチーム内で識別しやすくするために、前回の記事で出てきたデザイントークンに置き換えます。デザイントークンのルールを決める際は、デザイナーだけで決めるのではなく、デザイナーと開発者が一緒になって、双方が扱いやすい名前を考えるようにしましょう。
今回のデザインガイドではBootstrapの使用を前提としていることから、各色のベースとなったボタンに合わせて、青は「Primary」緑は「Success」といった具合に名前を付けてあります。このようにデザイン側とコード側の名称を揃えることで、実装を行う際に迷うことがなくなります。
PrimaryからInfoまでのデザイントークンをつけた例
アセットとしてカラーを登録しておくと、アートボード上の同一の色を一括して変更することができるようになります。これはデザインガイドの作成にも大きく役立つ機能です。
例として、「Primary」カラーを変更してみましょう。アセットパネル内の「Primary」カラー上で右クリックし、「編集」を選択します。カラーパネルが表示されたら、任意のを色を選択すると、アートボード上の全ての「Primary」カラーを変更することができます。
「Primary」カラーをすべてまとめて変更できる
本記事では、ボタンを例に、Adobe XDを使ってUIキットからデザインガイドをつくる手順を紹介しました。同じ様にXDの機能を使えば、デザインガイドに必要な項目を簡単に追加することができます。
次回の記事では、XDのデザインアセットとBootstrapのコードを、デザイントークンを使って連携させる方法をご紹介します。
0 notes
Text
【体験談】事業会社の1人目のインハウスエディターとして入社し、他の職種の人たちとうまく付き合うために必要なスキルと心構え
結論としては、
インハウスの編集・ライターが事業会社内で期待される働きは “マーケ × PR” って感じなんで、「自分の仕事はいい文章を書くこと」というこだわりを捨て、「つくったもので事業の成長や売上にどれだけ貢献したのか」をクリアにさせること、あるいは圧倒的な愛嬌とコミュ力でねじ伏せろ
という話です。
当たり前の話ですが、インハウスの編集・ライターの理想形は、「うちの編集者は “ものをつくる” ことでめっちゃ事業の成長にコミットしてくれるなぁ」と認められる地位か、「めっちゃいいコンテンツつくれるからあの人は別に売上とかで測らなくてもいいんじゃないか」という地位を築き上げることです。
が、そんな当たり前のことだけを note や Medium に書いて終わるのも芸がないですし、これまでずっとインハウスの PR Editor として仕事をしてきた自分ならではの視点も交えて、もうちょい掘り下げようという記事になります。
最近は Web 編集者のキャリアの可能性なんていう文脈で、インハウスでのエディターが今後もっと求められるのではといった願望っぽい話がたまに聞かれるようになりました。
ですが、実際に企業が求めているエディター像と、世の中にたくさんいるエディター・ライターのスキルセットやマインドは結構ズレがあると思っています。そのへんを変えていくと、世の中における我々の地位も少しはマシになるはずです。
では Short ver. 終了ということで、ここからは Full ver. となります（文字数は 10,000 字ほどです）
※ この記事は 編集とライティングにまつわるアレコレ Advent Calendar 2017 企画への寄稿？です。
--
私はここ 4〜5 年、複数の事業会社で 1〜2 人目のインハウスエディター兼 PR 的なポジションとなり、メディア編集とか Web 制作、SNS や広告運用、緊急事態には映像編集やコーディングをやってきました。Atom よりは Brackets 派なのですが頼むからマークダウンエディタを左右分割にしてほしい（なぜか上下分割しかできない）。
“ 1 人目のインハウスエディター” 最大の魅力は、幅広い仕事を自分の裁量で好きにやれること。社内に味方は皆無ですが「編集者はこうあるべきだよォ。それが業界のマナーであり美しき伝統なんだよォ」などと言われることもないので、100 % 自分の責任のもと、伸び伸び働くことができます。
そこで今回は
メディア運営を事業にしていないタイプの IT 系事業会社
あるいは自社事業と PR にも力を入れていきたい制作会社
社員数は 30〜300 人
という企業が、インハウスの Web 編集者・ライターを社員で 1〜2 名採用しようとしているとき、立ち上げメンバーとして入っていくためには何が重要か、というテーマで掘り下げていきます。
事業会社の中で “なんかよくわからんけどコンテンツをつくれるらしい人” に降ってくる案件といえば
オウンドメディアをやってほしい
会社やサービスをもっと知ってもらうために社内ブログや SNS をやってほしい
良い感じでプレスリリースを書いてほしい
顧客向けのメルマガを書いてほしい
求人広告やスカウトメールを書いてほしい
Web 広告のクリエイティブ（文言）で CPA 高い感じのをつくってほしい
受託の Web 制作のコピーライティング・モック制作とかをやってほしい
これら総合的に判断して優先順位をつけつつ限られた予算の中で利益にコミットしてほしい
などがあり、いろんな “つくる” 経験が積めます。が、案件ごとに
いろんな職種の人と
1 対 1 あるいは “ 1 対多” で
異なる言語で
円滑にコミュニケーションをとる必要があります。
こういう戦場に丸腰で突っ込んでいってボロボロにされて帰ってきて、ライターたちが集う場所で「やっぱ事業会社は私らのこと理解してくれんからあかんわ、編プロとかコンテンツメーカーでじっくり腰を据えて働きたいわ。時代は事業会社でのインターンより Twitter のフォロワー多い有名ライターへの弟子入りだよね」とか夢見てるだけだと、いつまでたっても第二の WELQ みたいなメディアに検索上位をジャックされ、「所詮はネットメディアだから」と軽視される規模のメディアしかつくれない人生で終わると思うので、事前に武装はしていきたいところです。
※この記事における禁句 ＝ 生存バイアス
社内に同業者いないインハウスエディター（ライター）の「超アウェー感」知ってる？
実際、やばいことはいろいろあります。
どんなスキルを持ち合わせていようが「わかりやすいから “ライター” で」
あなたが「いやライターよりは編集のほうがキャリア長いです！」と言っても、たぶん社内では「ライターの ◯◯ さん」と呼ばれます。私も一般的な Web 編集者に比べるとかなり Web マーケ・制作寄りのスキルセットなのですが、だいたい「ライターのあらやさん」と紹介されてきました��ハイパー優秀なマネージャだけは頑なに「うちのディレクターです」と紹介していましたが。
これはだいたい「編集者 is 何」という前提知識の不足が原因だと思われます。「ライター」といえば「文章を書いてる人」とイメージしやすい。
また、「ライター」という名前が一人歩きするほど、文章を書くこと以外のスキルはないものとして扱われがちなので、自分から宣伝したり仕事を取りにいく姿勢が重要です。
「記事がバズった！ メディアの PV が ◯ 万達成！ Twitter のフォロワー ◯ 人！」→「で？」
Web ライターまわりの人たちが Twitter でｷｬｯｷｬしてる感じの会話は、だいたいの職種の人からしたら “異国の風景” なので、違う言語での会話としてスルーされます。
社内で上記のようなセリフをそのまま口に出すことは、フィンランド人に日本語で「昨日の高校柔道富山県大会決勝戦すごかったんですよ！ 高校生とは思えんくらい最高の一本背負い決まってたんですよ！！」と熱弁しているようなものです。
ですので、社内での会話や Slack 上で理解してもらうには「金額換算するとこれだけ儲かった」「Vやねん！ 今期の目標達成待ったなし！」と、ビジネス目線での言語に翻訳する必要があります。
入社 1 ヶ月経過時点での「で、成果は？」
ゼロイチでのメディア運営がメインの業務であろうが、営業色が強い事業会社だと早くて 1 ヶ月、遅くとも四半期での目に見える成果が求められます。
一方で、実際にお金が動いたり、仕事につながったりすると、途端に手のひらを返したように存在価値を認められがちです。 ただ、この状態に到達するには結構時間がかかりますし（メディアなんて半年以上かかりますし）、辛いことがたくさんあると思うので、堪え忍べるかどうかがインハウスエディター・ライターの成功の分かれ道だと思います。なお私は前職のとき完全にブチギレて数ヶ月で辞めようとしました（関係各位ありがとうございました）。
サイトの立ち上げから入る場合、「数字は絶対出すんで、とりあえず 6〜12 ヶ月は泳がせてくれませんかね？」くらい言っておくほうがいいのかも。あと、メディアはどうしても時間かかるし、（アドセンス以外での）売りも立ちづらいので、受託の Web 制作、広告運用とか採用系のタスクをぶんどってきてわかりやすく短期的な数字をつくってお茶を濁すみたいな処世術も結構大事だと思います。
あなたの周囲にいる各職種のメンバーの特徴（制作・開発系部署）
というわけで、社内でのコミュニケーションを円滑に進めるため、職種別の特性と、うまく付き合うために必要なことをまとめました。
まずは同じ “ものをつくる” 部署。「数字！ 数字！」という人がいないので落ち着いていたり、殺伐としていたりします。
Web デザイナー・UI デザイナー
ディレクター的な立ち回りを求められるとき、直接やりとりする機会が多い職種です。
業務内容が近いため、比較的ライターとかに理解があるようにも見えますが、どちらかといえば単に「他人に深く干渉しない」人が多い印象です。数字目標を背負っているわけでもなく、セールスやマーケ、ディレクターに比べると穏やかな人が多いため、そもそも争いが起こることが少ないです。 積極的に擁護してくれるわけでもないけど。
ただ、淡々と「いい感じのキャッチコピー考えてよ」「ここのテキスト長いから削ってほしい」という依頼がくる感じです。
デザイナにもいろいろいるけど、編集兼ねてるディレクターが最もガチの喧嘩になるのは「ユーザーは文字なんて読まないしモジモジしてるとデザイン的にもダサいから、小さくしてこのカラムの中に全部押し込んどいたぞ」的なやつ
— H “araya” Takahashi (@51__araya) 2017年11月28日
たまにこういう戦争は起きますが、まぁ些細なことです。
個人的には「理解しあう」というよりは、「なんとなく良い感じにお付き合いする」くらいの温度感がベストかなと思います。僕らもデザインの良し悪しとかそんなわかりませんし、なんか半端に「デザインってこうですよね〜」「わかりますぅ〜」とか分かったような口をきかないほうがいいと思います。
あと写真とかカメラが好きな人が多いので、そっち系に詳しい人は仲良くなるきっかけができます。
エンジニア（コーダー）
神です。
「なぜエンジニアは神なのか」というエントリは単体で数千字書けると思いますが今回は割愛。ただ 「神だから対等ではなく、崇めなければならない存在」ということだけ頭に入れておいてください。
仕事で直接関わる機会が少ないため、編集者とエンジニアはお互いに「謎の人」というイメージが強そうですが、実は一つ共通点もあるのです。
たとえば、Web 編集者がブログやメディアのちょっとしたカスタマイズをしようと、負の遺産でしかないコードを書いたとします。それをエンジニアの方に見せたとします。
「これはひどい」
彼らは苦笑するだけで、触らぬ神に祟りなしという態度を決め込むので、ここぞとばかりに寿司を差し入れしましょう。:sushi:
「しゃーねーな」
彼らは苦笑しながら、“コードレビュー” や “リファクタリング” ��いう魔法を使います。
コードレビューとは、誤りを検出・修正することを目的としてコードを査読すること。リファクタリングとは、動作の内容は変えずに内部構造だけをいい感じに整えるという仕事です。
そう、まさに編集者が新人ライターに施している “赤入れ” と似ているのです。そういうとこで「仕事内容って実は似てるとこもあるんですね〜」と実感することができます。
ただ、編集者が誤字脱字やイケてない日本語文章をそのまま出してしまったところでせいぜい「嘲笑される」くらいですが、エンジニアのミスは事業の死に直結します。 我々が人間であることはまぁ残念ながら疑いようのない事実ですが、あなたの周囲にいるエンジニアたちが神であることもまた事実なのです。
「完璧にこなして当然」という世界観で生きていて、「こんなことやりました」と SNS でドヤれるわけでもなく、ただ黙々と頑張ってくださっている神々なので、給料が高いのは当たり前です。間違ってもライターが「エンジニアと同じくらいの給料がほしい！」とか言い出さないように教育しましょう。
あと、間違ってもエンジニアの前で「編集者やライターは 1 文字単位でこだわって、ひらがなカタカナ漢字の比率も気をつけてるんです」とかドヤってはいけません。 そんなことはそもそもプロとして仕事をする人間であればどの職種でも当然やってますし、コードを 1 行でも短くするため、動作を 0.1 秒でも軽くするために日々頭を悩ませているエンジニアたちなどは、Slack のプライベートチャンネルであなたを失笑の的にするかもしれません :trollface:
実際のところ、ほとんどの編集・ライターはエンジニアと距離を縮めることができずに壁を感じてしまいます。エンジニアと日常的に会話するには、我々にはあまりにも “共通の話題” が少ないのです。
まず、ほとんどのエンジニアは、Web メディアや表示速度向上、LP 制作、アドテクのような分野にはあまり興味がないです。やりたいのはもっと “面白そうなこと” です。
盛り上がるネタは、新しく出たツール・デバイス・言語の使い勝手や、今年参加する Advent Calendar の話や、php がいかにイケてないかという話や、今期のアニメでどれを切ったかという話や、インスタよりも Slack でウケる LGTM 画像や、そんなことよりも寿司が食べたい :sushi: という話です。tumblr のカスタマイズがいかにやりづらいかという話は私が一方的にしてますがあまり盛り上がりません。
仲良くなるとしたら、そういう開発者文化にどっぷり浸かるのみです。エンジニアの神々は “他人” とはあまり関わらない傾向があります。
ちなみに、フロントエンドのエンジニアはデザイナーに近い感じで若干クリエイターっぽく、バックエンドやアプリ系のエンジニアは寡黙で職人気質という傾向があります。人によってどっちのほうが相性いいとかもありそう。
あなたの周囲にいる各職種のメンバーとの接し方（ビジネス系部署）
インハウスのエディターは、ビジネス系・開発系どちらの管轄に入るかどうかが微妙なところです（私はビジネス管轄も開発管轄も両方経験あるので）。会社によってはセールスやマーケ系のマネージャの下だったり、経営者の下だったりにつくこともあります。
そこで、こちらの島に触れるにあたって改めて言っておきますが、あなたが入社したばかりの時点での社内では “いいコンテンツをつくってあげること” や “代表やスタッフの言いたいことを汲み取って言語化してあげること” などは特に求められていません。 最も求められるのは「売上や事業の成長にどこで貢献しているのか」というわかりやすい実感です。
マーケター・運用系ディレクター（各部署のマネージャも近い）
頭脳をフル活用して数字をあげること、“0→1” というよりは “1→100” をミッションとしている人種です。記事量産型のメディア編集長だったり、SEO 担当だったり、広告担当だったり、自社サービスのグロースハック担当だったり業務内容は幅広いのですが、人種としては結構わかりやすいと思っています。
合理主義者なので、クリエイティブへのこだわりは低いというか、「クオリティが高い低いなんて KPI 達成してるかどうかでしかないでしょ」「KPI 達成できるものがクオリティ高いってことだよ」という割り切り方をしている人が多いです。
つまり、あなたが「これダサくない？」と思うようなクリエイティブも「いや、ダサいとかじゃなくて、これで数字上がってるから」と普通に運用したりするので、意見は衝突することもあります。
ヤバいマーケターの具体例としては、今回の「編集者やライターが知見とか現状とかを共有できるといいなとおもって作りました」というアドベントカレンダーの企画で「andronavi編集部が紹介！クリスマスにあると役立つかもアプリやスマホグッズ」という宣伝でしかない記事をぶっこんでくるような、ツラの皮が厚すぎて洗濯バサミ 108 個くらいつける芸で新春隠し芸大会に出られそうな人とかのことです。彼らは「やらないよりはやるほうがいいっしょ」「数字あげられないやつにとやかく言われたくないし」という軽いノリでぶっこんでくるので、特に深く考えてないと思います。
（超わかりやすい実例をありがとうございます）
マーケ職種は基本的に「一つの作業に時間をかけるのは無駄」「たくさん案を出して、最適なものを検証していくほうが効率的」というタイプなので、クリエイティブ部署に比べるとパッと見でイケてるものが上がってくる確率は低いです。
うまく付き合う、つまり存在価値を認めてもらうためには、肌感覚でのクオリティで上回りつつ、しっかり数字も出すことだけです。
マーケターはいくら仲良くなっても私情は挟みませんし、もし彼らが肌感覚として「このコンテンツいいな…」と思ったとしても、数字がついてこなければ評価されづらいです。
人事・採用担当
採用系コンテンツを制作するときには連携する職種です。
採用系の職種は、本人あるいは特にマネージャクラスが営業畑出身であることが多いため、気質的にはセールス寄りです（エントリー数や採用単価だけでなく人材のレベルも重視されるので、セールスほど短期的な数字至上主義ではない感じですが）。
編集・ライターが貢献できる “母集団形成”・“魅力づけ” のフェーズにおいても
スカウトメールの開封率・返信率
求人への応募数（一次選考への参加率）
現場スタッフの面接の通過率（応募者のスペック、マッチ具合）
採用系イベントの告知ページおよび SNS 告知の広告効果
など、KGI（特定職種を特定人数採用）達成のための KPI を細かくチェックする体制が整えられがちです。あと “送信数” つまり “アクション数” という行動 KPI を欲しがりがち。
営業を経験していない新卒生え抜きの採用担当者は、単純に “素敵なコンテンツ” をつくることで仲良くしてもらえたりします。ただ、前項で触れた通りマネージャとなると完全に別の人種なので、うまく付き合うにはとにかく肌感覚で良いと思われるコンテンツをつくりつつ、優秀な人材からのエントリーをかき集めることです。
採用のマネージャクラスに認められようと思ったら、間違っても「社員インタビュー！ ◯◯さん（まずお前誰やねん）の日常に密着☆」みたいなタイトルの THE・自己満ブログとか書かないようにしましょう。どれだけプロのライターが巧みなインタビュー術で素晴らしい原稿に仕上げたとしても、それを読むのはあなたと ◯◯ さんのお知り合いだけです。
採用の領域自体が年々血の海になっているため、まず Web マーケティングという概念を理解しましょう。元バーテンダーや元ニートなど変な経歴の社員はどこでもいますし、職種の垣根を超えたランチ会や社内勉強会はどこでもやってますし、訴求できるポイントはたぶんそこではありません。むしろ「こういう面あるほうが求職者ウケいいっすよ」と、PR 側から提案するくらいじゃないと競争力が生まれません。
営業・セールスコンサルティング・アカウントエグゼクティブ etc
編集・ライターに限らず、エンジニア・デザイナーも同様に、もっとも我々が古くから戦争を繰り返してきた人たち。会社を明日も存続させるため、“0→1” をつくりだす人たち。
結論として、わかりあえないタイプのセールスとは一生分かりあえません。 お互いに関わるメリットがないので、関わらなくていいと思います。
もちろん心穏やかなセールスもたくさんいますが、心穏やかに見えても彼ら・彼女らの心中は「Why Writing People？」であふれています。彼らは編集・ライターの価値を理解しているのではなく “我慢している” か “考える余裕がない” のだと思ってください。
認めてもらうには超シンプルに、自分の発信力とブランドで案件を取ってくるか、記事広告や Web 運用の案件で高い売上を達成することです。
後者で最大の問題が「営業がそもそも産廃処理みたいな案件を取ってくる」事案ですが、とりあえずは背景を理解しましょう。
主に 27 歳以下の、朝から夜遅くまでバリバリ働いてる若手の多くは、「俺らは必死に頑張ってて月給 25〜30 万とかなのに、売上もあげてないエンジニアとかライターはなんであんなもらってんの？ お前らの給料どっから出てると思ってんの？」という疑問を抱いています（IT ベンチャーあるある）。
特に IT ベンチャー企業にいるようなセールスは、「達成できなかったら生きてる価値ないから」という環境で育ったか、そんな上司に厳しくしごかれて育ったというパターンが多いです。
そうなると「編集やデザイナーが苦労するかもしれないから、この案件は落ちのほうがいいのかな…」と考える余裕などなく、「まず自分のノルマを達成することが何よりも大事」なのです。そして、一般的には無名（IT 業界では有名だとしても）の会社で、朝から晩まで仕事漬けの営業という仕事をやる最大のメリットは「早期（四半期単位）の昇給・昇格」なので、周囲に足を引っ張られて自分の評価が上がらないのであればさっさと転職したほうがマシなのです。 歩み寄るかどうかはまったく別の問題ですが、冷静に話し合うためにも理解はしておかなければなりません。
そして、セールスの中堅〜ベテラン社員に「数字じゃない世界もあるんですよ」と認めさせることは、「君たちが必死で生き抜いてきた経験は今何の役にも立たない」という発言になりかねないことをまず理解しましょう。 彼らはその「数字を達成したか、しなかったか」という戦場でずっと身体を酷使して戦い、我々が「体調悪いんでリモートで働きます」と言っている日も客先に訪問し、上司にもクライアントにも激詰めされながら勝利を掴み取り、今の地位を築き上げてきたのです。果たしてそれが最適な手法だったのか、歩み寄るかどうかなどはまったく別の問題ですが以下同文。
私は基本的に、営業的な価値観と「お前らも俺たちと同じ苦労をしろ」という同調圧力でクリエイターたちも支配しようとする脳筋たちに媚びることは絶対にありません。ただ、一方的に被害者ヅラしてセールス全体の悪口を言うだけのなんちゃってクリエイターを見つけたら回り蹴りしていい条例の制定を千葉市に求めはしたい。
つらいこともあったけど、編集者・クリエイター集団より事業会社が好きです
（いらすとやを挟むと一気に脱力感が出るのがいいですね）
編集者・ライターはもちろん、デザイナーとかエンジニアでも「いやー、やっぱ十分なスキルとフォロワー数がついたらさっさとフリーになってリモートでやるべきだよね、正社員とか週 5 日オフィスに出社とか今時ダサいよね」とか言い出す輩をとりあえず引っ叩いてもいい条例とか千葉市が出してくれないかなーとか思っているあらやです（改めて挨拶）。
だいたい制作系の仕事って「フリーでいろんな仕事やってる人はイケてる」みたいな空気になりがちです。しかし事業会社で働いたことがある人はだいたい見たことあるでしょう。“なんか週に 1〜2 日ふらーっと社内に現れて、一体何に貢献してるのかまったくわからんけど月に 10〜20 万とかもらってるらしい自称コンサルタント” という生物を。一部まじで優秀な人もいますが、だいたいは…ねぇ？
そうやって陰口を叩かれる謎の人にならないためにも、事業会社でがっつり働くインハウスエディター的なキャリアにも注目が集まればいいなと思っています。
SNS や Web メディア単体でできることには限界があります。自分が惚れ込んだ経営者の力になって、他の職種のいろんな人たちと結束し、一つの事業を成功させるという大きな目標（決して上場ゴールとかではない）に向かっていくという人生も面白いです。
編集者の仕事が『価値ある情報を見つけ、集めて編み、付加価値をつけて、高く売る』ことだとしたら、いろんな人がいて、それぞれに背景があり、経営陣の人生を凝縮したようなサービス・製品がある事業会社という環境は、実に腕のふるいがいのある “遊び場” ではないでしょうか。
興味がある人は、ぜひ事業会社に突撃していってみてほしいなと思っています。まぁまぁの確率で心に一生残る傷を負ってしまうリスクもありますし、私は編プロで働いたことないから比較できないんですけど、中小規模の事業会社は青春感あって楽しいんですよ。
1 note
·
View note
Photo
ドルフロ：大規模アップデート＆改善
ドールズフロントラインは4月12日、いつもより長めのメンテナンス時間の末に大規模なアップデートが入りました。人形保有数等の拡張上限が引き上げられるといった現状からの拡張、細かなバグや表記等の修正、プランモード改善による遊びやすさ向上などです。
そして私にとってはこれが最大の改善アップデートですが、「改善内容2：データ圧縮技術によりアプリの容量が小さくなります」という項目です。
今まであったカクつき問題
iPhone7Plusでプレイしていた時はヌルヌル動いていましたが、iPhoneXSに替えてからは動作がカクカク。ラグがありすぎて移動中に次のマスにワープしたり、撃ってないのに敵がバラバラ倒れていったり、とにかく酷すぎました。アプリとして最低限の体裁を成していなかったと言って過言ありません。
このことについて、何と運営さんは昨年に認識しています。認識した上で事実上の無視をキメていました。iOSのバージョンが問題なのか、iPhoneXSの解像度が問題なのか、詳しくはわかりません。このお知らせが出た時点ではまだ指揮官に就任していなかったので、私は知らずに機種変更してしまいました。元の端末でプレイしろだなんて言われたの初めてだよ･･･
画面がカクついてラグだらけになる問題が解消されるためには、他のスマホゲームのように画面の縦横比を調整するようなアップデートが必要だと思っていました。クリプトラクトやスクフェスなんかがiPhoneXSでプレイすると画面の左右が余白になっているように。
思わぬ方法で一気に改善
そして今回、お知らせが出てから半年以上経過してようやく改善が入ったわけです。その改善方法が予想外だったので驚きました。カクつくような基本設計はそのままで、アプリ容量の圧縮という方法で改善を図ったのです。
事前に発表されていたアップデート内容を読んで、今回もカクつき解消は無いな･･･と思っていた矢先に力技での改善です。やはりiPhoneXSの解像度には対応しておらず、スピーカー部分にゲームUIで重要なボタンが隠れてしまったりしていますが、動作はヌルヌルになりました。これが大陸式の改善法なのか･･･GJ!
カクつくことを知らず機種変更してしまってやる気を失い、それが直接の原因で辞めていった指揮官を何人も見ました。残念です。私も何度引退しようと考えたことか。一部のウイークリー任務は放棄しましたし、デイリーもやらなくていいやと思った時期がありました。何とかCV藤田茜や絵師パセリでモチベを維持しましたが。
もっと早く改善するべきだったと思いますが、なんとかこれでマトモにプレイできるようになったのでひとまず安堵しました。大型イベントがおそらくGWあたりに開催されると思うので、再び製造や育成を進めようと思います。
0 notes
Text
2019年ふりかえり
例によってお正月なので2019年のことをまとめておくことにします。
仕事
今のプロダクト開発チーム（Wantedly People）にジョインしてちょうど二年くらい経ちました。去年の今頃は何をしていたかと言うと10人4ヶ月くらいの大型プロジェクトの真っ最中で、プロダクトを大幅にリニューアルしていました。これは予定通り2019年の3月末にリリースすることができました。
Wantedly ではエンジニアとデザイナーがそれぞれプロダクトマネージャとプロダクトデザイナーとして動き、一緒にプロダクト設計をすることが多いのですが（最近新しい版が出た INSPIRED でも紹介されている典型的なプロダクトチームのパターンですね）、このプロジェクトもその形でした。その中で自分がプロダクトマネージャ的な立ち位置で、コンセプト設計からドメイン設計まで、設計全般に関わりました。競争優位性や事業としての親和性を踏まえると、スタンドアローンで使うツールから何らかのピボットする必要があることが認識としてありましたが、「では何を作るべきなのか？」というところから実際にコードを書いて作れるところまでを落とす仕事です。
この過程で、Facebook や Twitter と言った SNS の構造をかなり解像度高めで見たのですが、これはエンジニアとしても学びがありました。例えばですが、Facebook は「ユーザー」以外もコンテンツ生成主体になれるんですよね。例えば Facebook ページ。この構造は更に Like のようなエンゲージメントアクションの対象も任意のものになる（技術用語で言えば polymorphic になる）。この辺りのほぼプロダクトの基本設計と言って良いような構造がバックエンドの構造（例えばグラフデータベース）と連動していたり、広告の出し方のようなビジネス面にも関わってくる。ユーザーインターフェイスの潮流としてもスキューモーフィズムが薄れたりデザインシステムのような概念が普及していますが、大きな流れとして情報を扱うプロダクトはどんどん抽象的になっていっていると僕は思っています。プロダクトの細部をどのようにモデリングをするかというような抽象的な話はどちらかと言えば「目的」ではなく「実現方法」として捉えられがちですが、プロダクトの種類のよってはその関係が大きく変わるなと感じた経験でした（こういう気付きを得てみれば、Facebook のニュースフィードの設計者であるクリス・コックスや、Twitter の設計者であるジャック・ドーシーがどちらもソフトウェア・エンジニアであったのは腑に落ちるところです）関連して、そのような設計はどの程度発明され尽くしたのか？というのはソフトウェアを設計する人間として個人的に関心を持ったところです。
…
無事リニューアルができた後は数字を見ての改善フェーズになって、多くの細かい施策プロジェクトが走るようになりました。この辺りで性質が変わってステークホルダーとのコミュニケーションが上手く行っていかなくなったので自分がプロジェクトマネジメントもやるようになりました。プロジェクトマネジメントと言っても一種の問題解決であって、プロジェクトというもののモデル化から制約条件の確認、運用フローの設計、及びそれに基づいた情報システムの設計、みたいなところなので、普通にエンジニアのスキルを転用しています。プロダクトマネジメントとプロジェクトマネジメントは分けられないのが基本で、後者だけを違う人にやってもらうというのは難しかったなあというのが個人的な学びです。仕事が増えてどうしても、とか社外にステークホルダーがいてデリバリーがクリティカル、とかそういうケースじゃないと基本は分離しない方が良いですね。YAGNI 的な考え方は組織の設計でも大事。
そう言えば僕は自分の中で勝手にメンターに設定している人が昔から何人かいるのですが、2019年に読んで面白かった本の一つに読書猿さんが書いた『問題解決大全』があります。この本では問題解決を2種類に分けていて、なにか根本原因があると仮定する問題解決をリニアな問題解決と言っているのですが、そうじゃない問題解決があると言っている。そういうものをサーキュラーな問題解決と読んでいて、これは因果関係がループしたりしているもののことを指しています。例えば人間の認識などはどんどん強化されたりしていくので、そういうのは構造自体を組み替えてあげないと解決しない、とかですね。銀行の取り付け騒ぎとかが事例として挙げられていますが、このとき取り組んだプロジェクトマネジメントも、そういう種類のものでした。
思えば、2018年に取り組んだマイクロサービス・アーキテクチャの問題解決もその手のことを無意識に考えていて、このときそれを意識化することができたな、と思っています。例えばエンジニアもコードが読みにくいと簡単に実装箇所を変えたりしますよね。それは単体で言えばただの現象なんですが、そういうものが場合によっては負の因果ループを形成してどんどん悪い状���になる、みたいなことがある。だからそういうときは初手・二手目とどう打っていくのが良いのかが単に目に付きやすいところ・見た目のインパクトが大きいところに手を付ける、という動き方では最善手ではないときがあって、そこは複雑な問題を解決をするときは考えなきゃいけないところだと思いました。
問題解決大全――ビジネスや人生のハードルを乗り越える37のツール ()
posted with amazlet at 20.01.01
読書猿
でじじ発行/パンローリング発売 (2019-09-14)
Amazon.co.jpで詳細を見る
そんな感じでプロダクトに加えてプロジェクトも見はじめたので、年の中頃から正式にプロダクト開発チームのリーダーになっています。マイクロサービスになっているバックエンドは強いメンバーが揃ってきたのでほぼ渡しました。今はサービスとしてのコンピテンシーに関わりそうなアーキテクチャや、プロダクトの方向性に関わりそうなドメイン設計だけ関わっています。そしてそれを実現するための具体的な手段として Protocol Buffers の API 定義のコードオーナーになっています。これはリニューアルのときにも強く感じたマイクロサービス・アーキテクチャの利点の一つで、プロダクトマネジメントの手段としてのアーキテクチャマネジメントと、それを実現するための具体的なインターフェイスとしての Protocol Buffers が割と必要十分な道具になるという話は、どこかで一度 LT してみたいところ。可用性の観点でも結局全てを守ることはできないので分割して管理しようねという話で、じゃあどこを変更してもどこが落ちないことがプロダクトとしてあるべき状態か、というようなこともアーキテクチャの話に乗ってきますが、その辺はありがたいことにセンスの良いエンジニアがいるのでポイント・ポイントでコミュニケーションを取るくらいで済んでいます（余談ですが、マイクロサービス・アーキテクチャの SLA 定義とかってどう障害分離されているかみたいなことがすごく関わってくるのですが、その辺りを形式的に記述するにはどうすれば良いんでしょうかね）。
逆に正式にリーダーになってからやるようになったことは色々あるのですが、プロダクトの戦略策定や暗に存在したビジョンの言語化といったコンセプチュアルな部分はそれを作るだけでなく伝える過程も含めて新しい学びがありました。作るという点では『ストーリーとしての競争戦略』という本を読んだのですが、これの競争優位性の議論がテクノロジー・カンパニーとは？というようなテーマにもつながる話で面白かった。伝えるという点では、その手のことを優秀なメンバーにどんどんインプットしていくと動き方や話す内容が変わっていくのがわかって素直に人が成長するってすごいなという驚きがありました。もちろん必要であれば認識合わせや期待のすり合わせはそれまでもやっていましたが、このときはポジティブな意味でピープル・マネジメントも悪くないなと思った瞬間でした。あと全体的にこの手のことを通して、言語化能力が1年通してかなり上がったという感覚があります。
ストーリーとしての競争戦略 優れた戦略の条件 (Hitotsubashi Business Review Books)
posted with amazlet at 20.01.01
楠木 建
東洋経済新報社 (2012-05-10)
Amazon.co.jpで詳細を見る
おおよそこんな感じの1年間でした。2020年はより比重をプロダクトに寄せていきたいなと思っています。
補遺：マイクロサービス・アーキテクチャの整理
マイクロサービス・アーキテクチャにまつわる総括的なところも個人的な関心として活動をしました。一つは、『 コンピュータプログラミングの概念・技法・モデル を読む会』というものを半年くらいかけてやりました。これは1人のソフトウェア・エンジニアとして自分が社内外問わず感じた課題感なのですが、マイクロサービス・アーキテクチャのような形でシステムを作るとなったときに、どのような計算のモデル化が当てはまり、それに対してどのような技法があり得るのか？というような視点があればもっと上手く行くケースがかなり多い��と感じています。特に、並行プログラミングと分散プログラミングの特性や、同期通信と非同期通信などのコミュニケーション・パターンなどを知っておかないと、クラウド系のコンピューティングサービスの技術選定の際にも行き当りばったりにしかならずまともに技術戦略を立てることが難しいのでは、とすら思います。
この会では、紹介されたモデル化を HTTP や三層アーキテクチャなど種々の既存技術についても当てはめて社外の参加者の方とも色々ディスカッションをしたのですが、今の Web 技術の進化の形はかなりの程度その誕生背景に影響を受けていて、今後も慣性を持ちながらも要素技術のレベルで段階的に調整されていくだろうというような見通しを持つことになりました。
そういった活動とは別に、2018年から2019年の大規模改修までに得たノウハウのアウトプットも行いました。動機としては、相対的に見えるとマイクロサービス・ネイテイブで開発されたサービスというものが2019年時点では相当少ないし、本番稼働して継続的に変更を加え続けたときのノウハウみたいなのはより少ないなと感じていて、それ故に必要だった整理というものを公開した形です。技術書典7に出した『WANTEDLY TECH BOOK 7』に「最近のソフトウェアエンジニアリング事情」として執筆したものや、それの抜粋である『Wantedly における Go 導入にまつわる技術背景』などがそれです。
より視点を拡げて見れば、昨今のアプリケーションはスマートフォンのような小さな画面の中によりシステマチックに多くの価値を詰め込む傾向があるように感じていて、それと並行して推薦やデータを扱う技術の価値というものがアプリケーションの価値に直結することも多くなっていると感じています。ここに一定のフロンティアがあるとすれば、バックエンドのシステムというものはより複雑化する方向に行くと考えられるので、分散システム化を進める要因になっている、というのが自分の今の考えです。ただこれは末端のインターフェイスの変化も関わるので、ある程度は今のスマートフォンを前提にした議論ではありますし、クラウド系のコンピューティングサービスが何をどこまで提供するかというような先端をよく観察した方が正しい結論が出せる気がしています。この辺りは今の自分のフォーカスからは外しているのでそれ以上は見ていませんが、変数が多いが故に今後が楽しみな領域だなと思っています。
生活
サービス
自分的2019年、生活に破壊的な貢献をしたサービス2選です。
家事代行サービス：Casy
隔週で利用しています。家事代行サービスの何が良いかと言うと、どんなに忙しくてもかならず2週間に1回は部屋がきれいになること、それがとても大きなメリットだなと思っています。だいたい忙しくなると散らかって散らかると余計に気にしなくなる、というようなループがあるんですが、Casy は定期的に同じ人が来るのが基本のシステムなので、それが起きない。2018年に DMM おかん を利用したこともあったのですが、これはアドホックに呼ぶサービスでした。アドホックに呼ぶとなるとそもそもスケジュール調整とかしなくちゃいけなくて利用ハードルが高いし、忙しいときほどそれもしたくなくなる。あと DMM おかん は毎回違う人を呼ぶので、そこの調整コストも高い。全然サービス設計の良さが違うんですね。結果的に DMM おかん はもうサービス終了しちゃいましたが、少なくともデフォルトでサブスクリプションにするのが家事代行サービスをデザインする際の必須要件だと思いました。はい。
宿泊予約サイト：Relux
2つ目は Loco Partners が利用する Relux です。よく Wantedly で募集出してたので DL してみたという経緯。これは何が良いかと言うと、イケてる宿しか載ってないことと、その中でも値段とは独立に品質を5段階で格付けしているところ。コストパフォーマンスという言葉で言えば、`コストパフォーマンス = パフォーマンス / コスト` で、このパフォーマンスの項のみを評価してくれてるのがありがたい。パフォーマンスで絞り込んだあとに最後にコストを見れば良いので個人的なニーズに合っている。あとは普通にアプリがあって今どきっぽくて便利。どうでもいいけどアプリの UI のチューニングは結構工夫してるなと思う割に検索はリレーショナルデータベース使ってるのか？っていうくらい遅いので改善してあげたい。“旅館” みたいな出現頻度高めのワードでクエリを投げると壊れるのでだいたい何が起きてるのか分かってしまってかわいそう。まあいいや。サービスとして見たときの個人的になるほどと思ったポイントで言うと、扱う宿の数を絞る → 一つあたりの評価にかけられるコストが増える → 信頼性のある評価が可能になる、という戦略になっているように見えます。普通は扱う宿の数は多い方が良いと思うところですが、この定説をひっくり返すことでサービスとしての強みを作り出しているのが面白いですね。
良い。 pic.twitter.com/PSB98VRTMV
— Sohei Takeno (@Altech_2015) April 23, 2019
リゾートに来ている pic.twitter.com/rAutqD5ABZ
— Sohei Takeno (@Altech_2015) September 20, 2019
僕のこのサービスの使い方は4泊くらいしてそこで好きな本を読む、っていうので、これがめちゃくちゃ良かったので2020年も習慣として続けようと思っています。
本
かれこれもう5年以上積ん読していた若桑みどりさんの『クアトロ・ラガッツィ 天正少年使節と世界帝国』という本があるのですが、これを Relux で宿泊した宿で読みました。これが本当に素晴らしくて、これでちょっと歴史趣味が再燃しちゃってます。良い本や物語に出会えるのは人生の主要な楽しみの一つです。
クアトロ・ラガッツィ 上 天正少年使節と世界帝国 (集英社文庫)
posted with amazlet at 20.01.01
若桑 みどり
集英社
Amazon.co.jpで詳細を見る
クアトロ・ラガッツィ 下 天正少年使節と世界帝国 (集英社文庫)
posted with amazlet at 20.01.01
若桑 みどり
集英社
Amazon.co.jpで詳細を見る
ゲーム
GW くらいから手を付けた『シヴィライゼーション VI』が沼でやばい。最近は MOD のリアルマップを DL して遊ぶのに少しハマっている。例えばユーラシア大陸のマップでモンゴルでプレイすると、ゴビ砂漠とかヒマラヤ山脈があるから南下して中原を侵略するかカザフスタンあたりの遊牧民族を倒してヨーロッパまで行くかしかない、みたいになって割とリアルな遊牧民族の気持ちになれて面白い。次は人とプレイしたら面白いだろうけど、どう考えても沼なのでそこまで行くか迷う。
2020年は新しくインプットしていきたいこともあるので、ゲームはほどほどにしたいところです。
0 notes
Text
From: Worktank [email protected]
Reply-To: [email protected]
Subject: 【32才 PHP開発経験】年収３０％の紹介手数料は不要です。ITエンジニアのご提案
人事採用ご責任者様
いつもお世話になっております。
株式会社ワークタンクの関戸と申します。
①SES業務、はじめました。
単金に上乗せはいたしません。
②エンジニアを採用する場合
年収３０％の紹介手数料は不要です。
案件情報がありましたら、メールしてください。
すぐに候補者を返信いたします。
案件情報を頂く際は、
★開発言語
★ご連絡先携帯番号
ご提示頂きますようお願い致します。
申し訳ございませませんが、
ZOOMやWeb会議は制限があるため行っておりません。
【今すぐ採用予定あり 】
【または近日中の予定あり】
の方はすぐ、ご対応いたします。
他にもJAVA .net C++ Linux Oracle サーバー構築 ネットワーク等のエンジニア
が登録しておりますので、何なりとお申し付けください。
【候補日】
・8月16日(水)
・8月17日(木)
・8月18日(金)
・8月21日(月)
・8月22日(火)
・その他日程
=====================================
mailto:[email protected] まで
株式会社ワークタンク
担当:関戸 （せきど）
TEL : 03-5324-2815
○電話 平日月～金８：３０～１８：００まで
それ以外の時間は、お手数ですがメールでご連絡下さい。
ご返信いたします。
////////////////////////////////////////////////////////////////////////
ID 075
性別 男性
出身地 東京都
現住所 東京都
年齢 33
最終学歴 ４年制理系大学卒
勤務先の業種 ソフトウェア・情報処理
現勤務先の従業員規模 100～299名
現在の年収 450 ～ 500 万円
現在の勤務状況 求職中
経験職種・経験年数 プログラマー(Web・モバイル関連)
J2EE/J2SE 5年
Java SE 4年
ネットワークエンジニア(設計・構築)
ルータ(Cisco) 4年
Webサーバー設計・構築
Linux 5年
語学関連のキャリア 検定資格
TOEFL 551～600点
会話能力
所有資格
希望雇用形態 契約社員
委託社員
希望職種 プログラマー(Web・モバイル関連)
希望の勤務地 埼玉県
千葉県
東京23区
東京都下
横浜・川崎
神奈川県下
職務経歴
業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語
ソフトウェア・情報系
オーディオブックサービス新規プロダクト開発 ＷＥＢコンテンツ
[ エンターテイメント ] 100人以下
基本設計
詳細設計
プログラミング
サーバ設計/構築
OS：
Linux
C
C++
Java
【担当業務】開発エンジニア
(仕様調査、アーキテクト設計、実装、テスト)
【対象環境】
OS：Ubuntu、Windows
フレームワーク：React、Material-UI、Gatsby.js、Hooks
言語：TypeScript
開発環境：Github、Trello、Slack、Google Meet、Dropbox Paper、Google Doc、
Adobe XD、VS Code、XMind、Contentful
パブリッククラウド：AWS、GCP
////////////////////////////////////////////////////////////////////////
ID 102
性別 男性
出身地 神奈川県
現住所 東京都
年齢 33
最終学歴 ４年制理系大学卒
勤務先の業種 ソフトウェア・情報処理
現勤務先の従業員規模 100～299名
現在の年収 400 ～ 450 万円
現在の勤務状況 求職中
経験職種・経験年数 プログラマー(Web・モバイル関連)
J2EE/J2SE 5年
Java SE 4年
Ruby(Ruby On Rails) 4年
データベース設計・構築
MySQL 3年
語学関連のキャリア 検定資���
会話能力
海外勤務の経験 ある
所有資格
希望雇用形態 正社員
委託社員
希望職種 プログラマー(Web・モバイル関連)
希望の勤務地 埼玉県
千葉県
東京23区
東京都下
横浜・川崎
神奈川県下
職務経歴
業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語
ソフトウェア・情報系
大学共済システム 業務系(ＷＥＢ系)
[ 官庁：その他システム ] 100人以下
基本設計
詳細設計
プログラミング
データベース設計
OS：
Linux
Java
■概要
基本設計、詳細設計、製造、単体テストを実施。
■作業詳細
設計業務から製造、単体テストまでを担当。
JavaよりはPL/SQLでの製造がメイン。
製造に関���ては、既存のソースコードを修正するのではなく、
新規機能の製造ということで0からのコーディングを行った。
単体テストはSQLDeveloperを使用しデバッグ実行を行い、
ステップ単位での試験を行った。
////////////////////////////////////////////////////////////////////////
ID 162
性別 男性
出身地 千葉県
現住所 東京都
年齢 32
最終学歴 専門学校卒
勤務先の業種 ソフトウェア・情報処理
現勤務先の従業員規模 100～299名
現在の年収 400 ～ 450 万円
現在の勤務状況 求職中
経験職種・経験年数 プログラマー(PC系)
Visual Basic 4年
プログラマー(Web・モバイル関連)
Java SE 3年
PHP 4年
語学関連のキャリア 検定資格
英検 2級
会話能力
所有資格
希望雇用形態 正社員
契約社員
委託社員
希望職種 プログラマー(PC系)
希望の勤務地 東京23区
横浜・川崎
職務経歴
業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語
ソフトウェア・情報系
【大手通信ホールディング会社PRA運用担当】 業務系(オープン系)
[ その他：その他システム ] 100人以下
基本設計
システム運用管理/保守
Visual Basic
Java
大手通信ホールディング会社の情報システム部にてRPAを中心にした業務改善を担当。
RPAだけでなくKintoneを使い、BPR（業務フローカイゼン）とその実行を実現し、工数削減に貢献。
業務フローは、人事部の残業データをもとに繁忙期や残業時間の多いものから対応開始。
特に、利用申請系の処理をRPAとKintoneをつかって完全自動化を実現したり、
購買審査フローやブランド使用料徴収フローなどを実現したり、RPAとVBAを組み合わせて、
知財情報を整理したり、残業レポートを作成したりして効率化を推進してきました。
RPA：AutomationAnywhere（A360),Bizrobo
運用管理のなかったRPAを体系的に管理統制する情報を整備するとともに、
運用視点からの開発統制や、開発支援ツール、自動管理簿作成RPAや、
アカウントの棚卸RPA、RPAのオーディットRPAの開発などを行い、
RPAの信頼度向上や安定性向上を支援してきました。
また、Kintoneをつかって知恵袋や、運用受付情報整備や、業務フロー化を実現したり、
A360の開発ひな形など情報面での整理を推進しました。
RPAの相互活用での、管理や運用支援、起動など誰も実施していない技術も習得しました。
具体的には、A360のUnattended動作環境の維持管理をBizroboにて実現したり、
A360でできない部分のBizroboによる補完などを実現
2023.8.18 From: Worktank [email protected]
0 notes
Text
Webフロントエンドのバージョニング
Webフロントエンドのバージョンをどうするか
前置き
ネット上での「バージョン」と言えば xxx.yyy.zzz 形式の SemVer が一般的である。
ただ、同時に「アプリケーションにSemVerは向かない」というのもよく言われる。
しかし、「アプリケーションにSemVerは向かない」というのは主にiOS, Android関係から言われることが多かった。
そのためここでは「Webフロントエンドからみたバージョニングの話し」を書く。
Webフロントエンド特有の事情
iOS, Androidアプリの場合、プラットフォームの要求からバージョンをつけざるを得ず、バージョンの形式も制約を受ける。
しかし、Webフロントエンドはそもそもバージョン自体ない場合も多い。
（もしくはせいぜい package.json の version を適当にカウントアップするのがせいぜいだったりする）
ここでは「なぜWebフロントエンドにバージョンが必要なのか」、「どういった形式のバージョンが望ましいか」を書く。
前提
ここで言う「Webフロントエンド」とは、「Webアプリケーション」と言われるようなそれなりにコード量の多いものを想定している。
なぜWebフロントエンドにバージョンが必要なのか
Webフロントエンドではバージョニングが重視されないことが多い。
しかし、適切にバージョンを運用することで以下のような利点が得られる。
build結果とコードの一致
現在本番にリリースされているものがどの時点のコードか特定できる。
これが行われていないと「本番リリースを行ったのに本番に出ているかどうかわからない」といった問題が発生する。
また、バージョンを適切に管理することで、過去の特定の時点の本番環境の再現などを行うことができる。
ユーザサポート時にユーザの使っている環境を特定できる
ユーザサポート時にユーザが使っている環境がと適切な案内ができない場合がある。
特に更新が頻繁でユーザの滞在時間が長いWebアプリケーションの場合、ユーザが数日リロードしておらず、使っている環境が古い可能性がある。
そのため、ユーザサポート時に問い合わせ内容と同時にバージョン番号も送ってもらうことで「想定された環境を使っているか？」を判断することができる。
どういった形式のバージョンが望ましいか
バージョン番号の管理には様々な形式が考えられるが、いくつか一般的な形式から利点と欠点を上げる。
SemVer
xxx.yyy.zzz 形式のもの。
利点
一般的であるため見慣れている
欠点
新しいバージョンの発行にcommitが必要
Webアプリケーションの場合いつどのバージョンを上げるか判断が難しい
前後関係がわかりにくい（ 0.1.0 と 0.0.10 のどちらが新しいか判断できない）
連番
1から順番に数字を上げていく形式。
利点
「いつどのバージョンを上げるか」の判断は行わなくても良い
前後関係が明確
欠点
新しいバージョンの発行にcommitが必要
日時
buildされた日時をバージョンとする（例 20200807101010 ）
利点
「いつどのバージョンを上げるか」の判断は行わなくても良い
新しいバージョンの発行にcommitが不要
前後関係が明確
いつリリースされたかが明確
欠点
buildされた時間が外部からわかる
大きな問題ではない可能性もあるが、不要な情報ではある
時刻を除いて日付のみにした場合、同日にリリースした場合同じバージョンになる
日付+連番だと新しいバージョンの発行にcommitが必要になる
buildされた環境のタイムゾーンに依存する
タイムゾーンをつけたり、epoch timeで管理する方法もあるが複雑
chunk
主にwebpack等でbuildした結果のファイル名につくやつをバージョンとする形式。
利点
「いつどのバージョンを上げるか」の判断は行わなくても良い
新しいバージョンの発行にcommitが不要
欠点
前後関係が不明
chunkとコードの紐付けが難しい
例えば、build時に環境変数から値をコードに埋め込んでいる場合、buildの設定が変わるだけで同じコードでもバージョンが変わってしまう
commit id
gitのcommit idをバージョンとする形式。
（gitで特定のcommitバージョン/リビジョンを指すアレをなんと呼ぶか問題 - Qiita）
利点
「いつどのバージョンを上げるか」の判断は行わなくても良い
新しいバージョンの発行にcommitが不要
コードとの紐付けが容易
欠点
前後関係が不明
ただし、付加情報としてbuild時の日付をつけることで前後関係をわかりやすくすることもできる
（例 2a384bb63b3c2cf696bee93163cf01bb103eea17@20200807 ）
まとめ
いくつかのバージョニング形式を比較して利点、欠点を上げてみた。
過去、実際にcommit idをバージョンとしてみたが、大きな問題はおきなかった。
もし同じような問題を抱えている場合commit idの使用も検討してみるといいかもしれない。
その他
バージョンはビジネス的な目的でつけられる場合もある。
その場合、 v0.y.z と表記することで「正式版ではない」という意思表示をしたり、大規模なUIの修時にバージョンを上げたりする。
ただし、ビジネス目的のバージョン番号はあくまでもビジネス上の要求から宣言されるものであるため、技術的なバージョンとは分けて設定するほうが良い。
例えば、アプリケーション全体としてのバージョンはビジネス目的とし、バックエンド、Webフロントエンド、iOS, Androidアプリの各バージョンとは切り離しておく。 そうすることでビジネス上、技術上それぞれの成約から離れたバージョニングを行うことができる。
3 notes
·
View notes
Link
ＴＥＤにて
スティーブン・ピンカー： 暴力にまつわる社会的通念
（詳しくご覧になりたい場合は上記リンクからどうぞ）
聖書の時代から現在まで暴力が減少してきていることをスティーブン・ピンカーは図示して説明します。
イラクやダルフールの非論理的で腹立たしい現実もありますが、それでも人類史上もっとも平和な時代を我々は生きていると語ります。
20世紀には数々の残虐行為が見られました。スターリン、ヒトラー、毛沢東、戦前の日本、ポルポト、ルワンダやその他の集団的な戦争。
21世紀に突入して、まだ７年しか経過していませんが、既に、ダルフール紛争や酷い状況を目にしてきました。
こうしてある共通の理解に至りました。現代社会は、暴力にあふれ調和のとれた原始の時代から離れてしまったから今の危険がある？というのです。そうではなく暴力は減少しているのです。暴力の減少は、フラクタルな現象です。
これは数千年、数百年、数十年。そして、数年のスケールで観測できます。
16世紀の産業革命、理性の時代の始まりが、転換点だったようです。一様ではなくとも世界中に見られます。
啓蒙運動の時代。
イギリスやオランダで始まり、特に、西洋では顕著です。一万年前まで人間は、狩猟採集型の生活をして永住地や政府はありませんでした。
次には、聖書から古代文明における社会の風習を見ることができます。やがて社会的な刑罰という形で、どんな社会でも手足の切断やそれ以上の拷問は容認されてきました。
現代になると、さらに減少していきます。つまり、トマス・ホッブズが正しいというものです。
ホッブズによると人間の自然状態とは「孤独で貧しく、不機嫌で残酷、しかも短命」血の渇望や、攻撃的な本能や縄張り争いが原因なのではなく、無政府状態のロジックが原因なのだそうです。
また、ホッブスの解決策である「リヴァイアサン」では、ある種の状況下で、非暴力を含む協力は、双方に利益があるとも指摘しています。
過剰な物資の貿易を行い両者が争いをしないこと。又は、戦時編制を解き、いわゆる平和の配当を分配することでいかなる時でも戦う必要がなくなることにつながると言っています。
ゲーム理論で言うところの「ポジティブサムゲーム」です。
ポールローマーやクルーグマンなどが理論的に数値で解明した戦争よりも貿易で解決した方が善いかもしれない？ということにも通じます。
一千年単位のスパンでは、男性や女性の若死にが、普通であった昔。
女性や子供など、他人に危害を加えることに抵抗は感じませんでした。
テクノロジーやマクロ的な経済効率が、人間の限界を遥かに超えていき、ドラッカーの言うように、人間の寿命を伸ばして人生をより長く楽しくさせるにつれて、人間は、一般的に人生への価値を高めるようになります。
これは、政治学者のジェームズペインの議論です。
また、人が関わるポジティブサムゲームの件数が、コンピューターの登場とインターネットの登場によって、爆発的に増えたと言います。
人間の限界を遥かに超えていくテクノロジーが、物資やサービスやアイデアの交換を、より遠方と。より大人数で大規模に行えるようにしたからです。
その結果、皮肉にも死者よりも生きている他者の価値が高まり、自己中心的な理由での暴力は減るのです！！
哲学者であるピーターシンガー。彼は、長い進化の過程によって、人間は共感できるようになったと論じています。原因は何にせよ。
暴力の減少には、深い意味があるため「なぜ戦争をするのか？」と問わずに「なぜ平和があるのか？」と問うべきです。
（合成の誤謬について）
合成の誤謬とは、ミクロの視点では正しいことでも、それが、合成されたマクロ（集計量）の世界では、必ずしも意図しない結果が生じること。物理学では、相転���みたいな現象です。性質が変わってしまうということ。
ミクロのメカニズムが個人同士の経済における仕組みであるのに対して、マクロのメカニズムは、国家間や経済全体の循環における仕組みだからである。
例えば、家計の貯蓄などがよく登場するが悪い例えです。前提条件が、所得が一定の場合！！所得が一定じゃない増加する場合は？これは、論じていませんので参考になりません！！（法人が提供する製品やサービスの価格も一定の場合も前提条件です）
１９３０年代のアメリカ経済が金融危機2008と似たような状態に陥った時、ケインズは、「倹約のパラドックス」というケインズ経済学の法則を発見しています。
それは、ポール・Ａ・サミュエルソン(1915-2009)が、近代経済学の教科書「経済学」の冒頭で「個人を富裕にする貯金は、経済全体を貧困にする！（所得が一定の場合）」というわかりやすい言葉で表現しました。しかし、庶民の所得が増加し、貯蓄が投資、消費に回る場合には、「倹約のパラドックス」は生じません。
その後、この「倹約のパラドックス」は、アメリカの経済学者・ケネス・Ｊ・アロー(1921- )が「合成の誤謬」を数学的論理に基づいて「個人個人がそれぞれ合理的選択をしても、社会システム全体は合理的選択をするとは限らない」を検証してみせた。
要するに、部分最適ではなく、全体最適させていくということ。
つまり、新産業でイノベーションが起きるとゲーム理論でいうところのプラスサムになるから既存の産業との
戦争に発展しないため共存関係を構築できるメリットがあります。デフレスパイラルも予防できる？人間の限界を超えてることが前提だけど
しかし、独占禁止法を軽視してるわけではありませんので、既存産業の戦争を避けるため新産業だけの限定で限界を超えてください！ということに集約していきます。
なお、金融危機2008では、マイケル・メトカルフェも言うように、「特別資金引出権（SDR）」は、2008年に行われた緊急対策で、一国だけで行われたのではなく、驚くほど足並みの揃った協調の下に国際通貨基金（IMF）を構成する188ヶ国が各国通貨で総額2500億ドル相当を「特別資金引出権（SDR）」を用いて世界中の準備通貨を潤沢にする目的で増刷してます。
このアイデアの根本は、元FRB議長であったベンバーナンキの書籍「大恐慌論」です。この研究がなければ、誰一人として、変動相場制での当時の状況を改善し解決できなかったと言われています。
それ以前では、固定相場制でのマーシャルプランが有名です。
（個人的なアイデア）
児童虐待？女性差別？男女関係のトラブル？
極端な場合は保護が必要ということを前提にしても問題がある。
男女平等が社会システム内では功利主義的には有効？
混乱を産み出し憎しみの連鎖を起動させてるだけで果たしてそうなのか？
国の歴史によっても異なるし、上記の事例に関しては、法の下の平等は万能ではない！道理に反するということでもあります。
太古からの厳しい自然淘汰を生き抜く上で多少の児童虐待？女性差別？男女関係のトラブル？が良い作用を与えていたのも事実であって
数万年かけて培われた本能的な児童虐待？女性差別？男女関係のトラブル？は、犯罪者扱いするんじゃなくて隔離して教育してもいいし、国家が対策マニュアルをオープンソースで公開して男女の特性子供の特性として共有すれば？
極端な男女平等思想が憎しみの連鎖の原因かもしれない？
それを社会システム内で最適化させて一千年単位のスパンで少しずつ改善するほうがいいし、マスメディアも慎重に吟味してセンセーショナルな報道をしないことだ。
本当に殺しては社会システム内ではダメだからテレビ的にはタレント生命、テレビ、ラジオ出演者生命や広告代理店関係者、芸人芸能人生命、俳優生命など。
是非、不幸をあおるやつらをテレビ的に殺してほしい。
さらに・・・
勝手に警察が拡大解釈してしまうと・・・
こんな恐ろしいことが・・・
日本の警察は、2020年3月から防犯カメラやSNSの画像を顔認証システムで本人の許可なく照合していた！
憲法に完全違反！即刻停止措置をみんなで要求せよ。
日本の警察の悪用が酷いので、EUに合わせてストーカーアルゴリズムを規制しろ！
２０２１年に、EU、警察への初のAI規制案！公共空間の顔認証「原則禁止」
EUのAI規制は、リスクを四段階に分類制限！
禁止項目は、行動や人格的特性に基づき警察や政府が弱者個人の信頼性をスコア化や法執行を目的とする公共空間での顔認識を含む生体認証。
人間の行動、意思決定、または意見を有害な方向へ操るために設計されたAIシステム（ダークパターン設計のUIなど）も禁止対象にしている。
禁止対象の根拠は「人工知能が、��別に有害な新たな操作的、中毒的、社会統制的、および、無差別な監視プラクティスを生みかねないことは、一般に認知されるべきことである」
「これらのプラクティスは、人間の尊厳、自由、民主主義、法の支配、そして、基本的人権の尊重を重視する基準と矛盾しており、禁止されるべきである」
具体的には、人とやり取りをする目的で使用されるAIシステム（ボイスAI、チャットボットなど）
さらには、画像、オーディオ、または動画コンテンツを生成または操作する目的で使用されるAIシステム（ディープフェイク）について「透明性確保のための調和的な規定」を提案している。
高リスク項目は、法人の採用活動での利用など違反は刑事罰の罰金を売上高にかける。
など。他、多数で警察の規制を強化しています。
前提として、公人、有名人、俳優、著名人は知名度と言う概念での優越的地位の乱用を防止するため徹底追跡可能にしておくこと。
人間自体を、追跡すると基本的人権からプライバシーの侵害やセキュリティ上の問題から絶対に不可能です！！
これは、基本的人権がないと権力者が悪逆非道の限りを尽くしてしまうことは、先の第二次大戦で白日の元にさらされたのは、記憶に新しいことです。
マンハッタン計画、ヒットラーのテクノロジー、拷問、奴隷や人体実験など、権力者の思うままに任せるとこうなるという真の男女平等弱肉強食の究極が白日の元にさらされ、戦争の負の遺産に。
基本的人権がないがしろにされたことを教訓に、人権に対して厳しく権力者を監視したり、カントの思想などを源流にした国際連合を創設します。他にもあります。
参考として、フランスの哲学者であり啓蒙思想家のモンテスキュー。
法の原理として、三権分立論を提唱。フランス革命（立憲君主制とは異なり王様は処刑されました）の理念やアメリカ独立の思想に大きな影響を与え、現代においても、言葉の定義を決めつつも、再解釈されながら議論されています。
また、ジョン・ロックの「統治二論」を基礎において修正を加え、権力分立、法の規範、奴隷制度の廃止や市民的自由の保持などの提案もしています。現代では権力分立のアイデアは「トリレンマ」「ゲーム理論の均衡状態」に似ています。概念を数値化できるかもしれません。
権限が分離されていても、各権力を実行する人間が、同一人物であれば権力分立は意味をなさない。
そのため、権力の分離の一つの要素として兼職の禁止が挙げられるが、その他、法律上、日本ではどうなのか？権力者を縛るための日本国憲法側には書いてない。
モンテスキューの「法の精神」からのバランス上、法律側なのか不明。
立法と行政の関係においては、アメリカ型の限定的な独裁である大統領制において、相互の抑制均衡を重視し、厳格な分立をとるのに対し、イギリス、日本などの議院内閣制は、相互の協働関係を重んじるため、ゆるい権力分立にとどまる。
アメリカ型の限定的な独裁である大統領制は、立法権と行政権を厳格に独立させるもので、行政権をつかさどる大統領選挙と立法権をつかさどる議員選挙を、別々に選出する政治制度となっている。
通常の「プロトコル」の定義は、独占禁止法の優越的地位の乱用、基本的人権の尊重に深く関わってきます。
通信に特化した通信プロトコルとは違います。言葉に特化した言葉プロトコル。またの名を、言論の自由ともいわれますがこれとも異なります。
基本的人権がないと科学者やエンジニア（ここでは、サイエンスプロトコルと定義します）はどうなるかは、歴史が証明している！独占独裁君主に口封じに形を変えつつ処刑される！確実に！これでも人権に無関係といえますか？だから、マスメディアも含めた権力者を厳しくファクトチェックし説明責任、透明性を高めて監視しないといけない。
今回、未知のウイルス。新型コロナウイルス2020では、様々な概念が重なり合うため、均衡点を決断できるのは、人間の倫理観が最も重要！人間の概念を数値化できないストーカー人工知能では、不可能！と判明した。
複数概念をざっくりと瞬時に数値化できるのは、人間の倫理観だ。
そして、サンデルやマルクスガブリエルも言うように、哲学の善悪を判別し、格差原理、功利主義も考慮した善性側に相対的にでかい影響力を持たせるため、弱者側の視点で、XAI(説明可能なAI)、インターネット、マスメディアができるだけ透明な議論をしてコンピューターのアルゴリズムをファクトチェックする必要があります。
＜おすすめサイト＞
ロジェカイヨワ戦争論と日本の神仏習合との偶然の一致について2019
ジャミラ・ラキーブ：実効性のある非暴力抵抗運動の秘訣
ゲリー・スラトキン: 銃による暴力を伝染病として捉えよう？
ハワード ラインゴールド: 個々のイノベーションをコラボレーションさせる
ピート・アルコーン：2200年の世界について
日本テーラワーダ仏教協会
仏教と物理学
ボブ•サーマン：私たちは、だれでも仏陀になれるという話
イギリス保守党。党首デービッド・キャメロン: 政府の新時代
マイケル・サンデル：失われた民主的議論の技術
＜提供＞
東京都北区神谷の高橋クリーニングプレゼント
独自サービス展開中！服の高橋クリーニング店は職人による手仕上げ。お手頃50ですよ。往復送料、曲Song購入可。詳細は、今すぐ電話。東京都内限定。北部、東部、渋谷区周囲。地元周辺区もＯＫです
東京都北区神谷のハイブリッドな直送ウェブサービス（Hybrid Synergy Service）高橋クリーニングFacebook版
#スティーブン#ピンカー#マガー#人類#戦争#古代#文明#哲学#ゲーム#貿易#ノーベル#暴力#宗教#フラクタル#ポール#ローマー#クルーグマン#仏教#テーラ#ワーダ#NHK#zero#ニュース#発見#discover#discovery#カイヨワ
1 note
·
View note
Text
Anthemとかいうとんでもないクソゲーのレビューを書いてみた。
Anthemは決して人におすすめできるゲームではありません。評価が低いのにも軒並み納得できますし、よく類似ゲームとして出されるDestinyのほうが完成度が高いのは間違いありません。
この発想でいえば、むしろ今Destinyをやったことがない人がAnthemを始めれば、Anthemをクリアした後、Destinyをプレイすることで、2倍楽しむことができるでしょう！大発見！今Destinyをやるか、やった後にDestinyをやるかあなたには未来があるわけですね。Destinyをやろう！
え？もう俺はDestinyをやっているって……？ならAnthemをプレイするのはやめたほうがいいかもしれません。僕はHALO信者なので盲目的にBUNGIEを愛していますが、あなたもBUNGIEに感謝してしまう可能性があります。早くHALOを出せ。
それよりもこのAnthem、10,000円近いですし、このゲームを買うお金でカニを食べに行ったり、ちょっといい服を買ったり、友達と遊びにいったほうが良い経験ができるでしょう。そういえば今10,000円で買えるちょうどいい空気清浄機があるんですよ。（という流れでAD貼るアフェリエイトメディアではない。）
ただ私や、このゲームが好きな人、もしくはゲーマーにとって10,000円というのはさほど高い感覚ではないでしょう。
ゲームセンターに通って一回10分程度のゲームを1PLAYするのに100円。1時間600円。1万円使うには大体17時間ほどかかりますが、たった17時間。我々ゲーマーにとっては一本のソフトで過ごす時間としては僅かなものです。もちろんこれはゲームセンターを非難する投稿ではありません。そ���ぞれの価値の在り方の話をしているだけです。
愛するゲーマーの皆さん。前置きが長くなってしまってすいません。それではこのゲームのどこが駄目なのか、大きな部分だけ説明させてください。細かい部分が聞きたいという人は @asglld までお声がけください。
●日本語はテキストのみ。
このゲームのストーリーは英語音声です。日本語音声が用意されていません。そのため英語がわからないすべての日本のユーザーは字幕を日本語にして、プレイをしなければなりません。
また、この字幕の表示位置が画面下部というクソ仕様で美麗なAnthemのグラフィックを楽しみながら字幕を見ることは叶いません。1つのストーリーをちゃんと理解するためには、いったん字幕最優先でゲームプレイせざるを得ないでしょう。ただこれはそもそもAnthem自体が日本市場をメインターゲットに据えていない背景があるでしょう。もっと我々が日本国内のビデオゲーム市場を支えることができれば、きっと音声が用意されます。あ、主人公の男性ボイスは小山力也さんでお願いします。
●頻繁にサーバーとの接続が切れます。
すでにいろいろなSNSで騒がれている事実ですので、それくらい知ってるよという方も沢山いると思います。そうです。あなたのご存知の通りではありますが、想像を遥かに超えて接続が切断されます。
昨日も友人と遊ぶためにパーティーを組んでストロングホールドと呼ばれる、
小規模なレイドダンジョン、インスタンスダンジョンのようなものにいったのですが、2回に1度、メンバーが切断され戻ってくる前に他のプレイヤーが補充され、一緒に快適にゲームプレイができないという問題が発生します。
また、その問題の後戻ってパーティーを組みなおそうとすると、招待できなかったり、ゲームの難易度がそれぞれ異なって表示されたり、また違う人が落とされたりする問題が平然と発生します。
1つのミッションを終わらせるのに、バグで20分、本編10分の時間を割かれることは、Anthemの世界においてごく自然的なこととご理解ください。私には到底理解できませんが。どうなってんだこのゲーム。
●最初にUI/IAの煩雑さに苛ついてしまうかもしれません。
今でも苛ついています。
このゲームのプレイアブルキャラクターはとある街中を移動します。Destinyをプレイされたことのある方は、各惑星の街並みをイメージしてください。あのような仕様です。あ …… いえ、すいません嘘をつきました。あれの下位互換です。本当にすいません。
この街中での移動ですが、まず移動速度がクソを極めています。移動速度が遅く、目的地までワープさせてくれと何度も思うでしょう。あぁクソ！思い出してイライラしてきた。
また、画面上部に目的地がコンパスで表示されるのですが、遮蔽物を無視して直線での目的地が表示されるため、都度マップを確認しなければ目的地までたどり着けないでしょう。ちなみに、この目的地が表示されなくなるバグも存在します。
これのせいで昨日も仲間4人でゲームをしているとき、メインストーリーを進めていた1人が突如ミッションが表示されなくなりました。他の3人は「どうせAnthemのひどいUIのせいで道に迷っているのだろう」と思い、あっちを行けだのこっちに行ってみろだの、さんざんガイドするも到着できない身内に、だんだんとギスギスが生まれそうになった時、なんとクライアントの再起動で解消！クソかよ。Anthemはとても気まずい温度感すら与えてくれます。これが4DXって言うのかな？
その他にも武器の分解の仕様や、更新頻度とラインナップが不釣り合いなショップ。選択肢の必要性を感じないNPCとの会話や、戻ってくるたびに居場所が微妙に変わるNPCなど、さまざまな手法であなたのストレスを溜めていくことになります。
●そんなAnthemですが、私はこのソフトを友人にプレゼントしました。
そうです。こんなバグとクソ仕様のゲームですが、誕生日でも記念日でもなんでもない日に、友達にプレゼントしたんです。理由はAnthemが私にとって面白いゲームだからでした。正気の沙汰ではないですよね。私もそう思います。
このゲームのバトルの仕組みやモチベーションサイクルの設計は、Destinyで培われたShare world shooterのソレと全く同じで、ガーディアン経験者のほとんどの人が、似たような体験をAnthemで感じるでしょう。
また、その比較で言えばあらゆる点で劣化版であり、IGNのレビューで「10数時間遊べるゲームにするためには残された仕事が多すぎる」という、コメントが残された理由も重々に理解できます。
ですが、広大で美麗なフィールドを仲間と飛び交う感覚は、このゲームでしか得られることのできない体験であり、まさにこれがAnthemの本質的な面白さでもあります。
戦闘の仕組自体は決して真新しい体験やレベルデザイン、システムが採用されているわけではありません。単純に簡単に武器や特殊攻撃の手数と、組み合わせによって発生するコンボアクションができ、それぞれの爽快感が非常に優れているため、純粋に他のゲームより面白いという感覚があります。
これもAnthemの魅力でしょう。いや、それしかないのか。
複雑なゲームシステムやプレイヤースキルの有無が問われるような技巧的ゲームでなく、単純に見た目と爽快感の気持ちよさが強いゲームだと言っても構わないと思います。
（※ただし戦闘中以外の爽快感は無く、上述の通り苛立ちを感じるレベル）
私はそうした理由からこのゲームを友人にプレゼントしました。昨日もバグで6回ほど落とされましたが、落とされたことよりも早く戻って、一緒にこの広大なマップを飛び回って戦いたいという気持ちが勝っているのです。
多くの人にとってNot for meだったタイトルかも知れませんが、
私にとってはJust for meがAnthemでした。
SNSやAmazon Reviewを見る限り、なんとなく Not for All的ニュアンスで書かれている方を散見するのですが、そうではないよ、という事をここに記させていただければと思います。
また、開発会社もバグについては認識しており、これらのバグのうち、いくつかは改善に向かっています。レアドロップの確率が減少されたりと、決して良い改修ばかりではありませんが……。あとバグが多すぎて公式の修正発表を素直に信じられないフリーランサーは僕だけじゃないですよね？
ともあれ今後はアップデートにより改善されていくAnthemに感動し、また初期にこのクソな体験をしたプレイヤーであるフリーランサーたちは、レガシーを知る存在となるでしょう。いや、そうなって欲しい。救われたい。
Final Fantasy XIVの根性版をプレイした先輩たちも、あの頃は何がクソだった、ダメだったといいながら今なおプレイしている沢山のユーザーがいますし、人間ちょっとダメなところがある方が愛嬌あってかわいいものですよ。何言ってるんだ俺は。
こんな駄文を読んでくださった素敵なゲーマーのみなさんといつかゲーム内で出会えることを楽しみにしています。
まぁちゃんと出撃できればの話ですが……。
1 note
·
View note
Text
Adobe XDがSketchよりも優れている理由
最近、私の周りでもAdobe XDを使用する人が増えてきました。特に日本では、SketchユーザーよりAdobe XDユーザーの方が勢いがあるように感じます。
SketchとAdobe XDを長きに渡り使用し、その結果Adobe XDを使用することにしたUIデザイナーの比較記事を紹介します。海外だとSketchの方が多く感じてましたが、そういう流れなのでしょうか。
Why Adobe XD is better than Sketch.
by Simon Fairhurst
下記は各ポイントを意訳したものです。
※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。
はじめに
私の前回の記事では25,000を超える閲覧と共有があり、SketchとAdobe XDの2つのツールの比較について補足したいと思いました。
前回の記事を読んでいない人は、下記をご覧ください。
基本的なことは予想通りで、Adobe XDの継続的なアップデートの後、私が反対したことはすべて取り戻されました。その理由はこの記事で解説します。
この記事では、Adobe XDに重点を置いていますが、UI/UXのソフトウェアに関する意見はすべて個人的な好みに基づいています。この2つはほとんど同じことができますよね？ さらに、コラボレーションツールとしても機能します。
それでは、SketchとAdobe XDの比較を始めましょう。
Sketchの特徴
Sketchはすでに何年も前から存在しています。8年ほど前に仲間のデザイナーから「みんなが使っている」という理由で、これからはPhotoshopを使わずにSketchを使うように言われたことを覚えています。
私はSketchに飛びつくまでに時間がかかりました。それは躊躇していたからではなく、Sketchや他のツールを試すのに時間がかかったからです。
プラグインについて
プラ��インは作業を効率的にするツールとしては素晴らしいものです。しかし、ソフトウェアを継続的に破壊したり、クラッシュさせたり、アップデートが必要だったりする場合、効率的と言えるでしょうか。
60以上のアートボードとモバイルデザイン、シンボル、スタイルを備えたUIをデザインしようとしても、思っているほど効率的には機能しないかもしれません。納品直前にSketchファイルを開いたことが何度もありますが、プラグインが壊れていたり、起動する前にアップデートに時間がかかったり、最悪の場合Sketchがクラッシュしたこともあります。
現在、ほとんどのプラグインはサードパーティが開発したもので、信頼性が低いことが分かっています。そのため、Sketch自体を非難することはできません。
しかし、Sketchユーザーにとってプラグインは重要な存在です。プラグインなしでは、Sketchは単なるベクター形式のデザインツールです。
信頼性について
前述の通り、Skecthは私自身そしてチームのメンバーにとってあまり効率的ではありません。大規模なプラットフォームで作業する場合、すべてを1つのファイルに収めてデザイナー間で共有できることは素晴らしいことです。しかし、プロジェクトがモジュールの再利用に依存している場合、シンボルは非常に便利ですが、ソフトウェアは永遠にクラッシュします！
「その理由はソフトウェアではなく、マシンだ」とあなたは考えるかもしれません。念のために言っておくと、私とチームのメンバーは現在、最新のMacBook Pro 15inchを使用しています。マシンパワーが不足しているとは思いません。
Sketchはクラッシュすることが多いだけでなく、ファイルがかなり破損します。Sketchファイルをパッケージ化していますが、別のマシンで開くとシンボルが壊れていたり、フォントスタイルが消えていたりします。納品直前に、他のデザイナーと一緒に仕事をしなければならない時は、効率的とは言えません。
エクスペリエンスについて
Sketchは全体的にかさばっているように感じられます。長い間Adobeに追加されてきたPhotoshopと同じくらいかさばっています。5ページ以上のWebサイトをデザインすると、遅れが感じられます。インポートする前に画像やアセットを圧縮しても、納品が迫っているときに作業するのはあまり良いことではありません。このツールはかさばってくると、ラグが大きくなるので、ソフトウェア自体のUIもますます使いづらくなるように感じられます。キャンバスにはたくさんのオプションや機能が詰め込まれており、デザインするスペースがほとんどありません。
Sketchが、Photoshopと同じ道を進んでいると感じずにはいられません。誰もが遅いソフトウェアを使いたくなりません。
総括
テンプレートやモジュールを使用して、同じように見えるWebページをすばやく作成したい場合は、Sketchをぜひお試しください。シンボルやフォントスタイル、Abstractのようなプラグインは効率性に優れています。しかし、もしデザインの可能性を広げ、既存にはない独自のデザインで作りたいと思っているタイプのデザイナーには、私はSketchを勧めません。
Sketchはどれだけアップデートされても、他のソフトウェアと比べて時代遅れで、かさばり、使いづらいものになっていると感じます。
Sketchは長続きしましたが、エクスペリエンスデザインの世界ではあまり歓迎されていないのかもしれません。個人的にはSketchを使用するのが好きではありません、そしてチームのメンバーも使用していません。
Adobe XDの特徴
Adobe XDは比較的新しいソフトウェアで、私を興奮させます！
以前の記事ではまだベータ版でしたが、Adobe XDは正式版がリリースされ、毎月のアップデートによる改善も含めて、本当によくなりました。Figmaと並んでUI/UXのための最高のツールだと思います。
信頼性について
Adobe XDを12ヵ月間使ってきましたが、私とチームのデザイナー6人を含めてクラッシュしたことは一度もありません。どんなサイズの画像を入れても、アートボードやシンボル・コンポーネントがいくつあっても問題なく、本当に信頼できるソフトウェアです。
Adobeは最近、Sketchと同様にサードパーティのプラグインを導入しましたが、プラグインをいくつ追加してもソフトウェアの信頼性は維持されているように感じます。ラグもクラッシュもなく、シームレスに動作します。少なくとも、私はまだラグもクラッシュも経験していません。
また、ドキュメントの共有も最小限の作業ででき、ファイルサイズが大きくならないように圧縮されます。そして、他のマシンでファイルを開いても、シンボルやフォントやアートボードが破損することはありません。チームの他のデザイナーにすぐに引き継ぐことができ、非常に効率的です。シンボルやコンポーネントは、クラウド上のドキュメントにリンクしているため、オリジナルのデザインがマシンにない場合でも、「リンクがありません」と表示されるのではなく、正しく表示されます。
エクスペリエンスについて
Adobe XDでUIのレイアウトをするのは、非常に直観的です。Adobeは基本にこだわっており、私はデザイナーとしてそのやり方は大好きです。必要な時に必要なツールさえあれば、インターフェイスの設計に特別なものは必要ありません。
ソフトウェアが処理するスピードは信じられないほど速く、効率を大幅に向上させています。Adobeがどのように管理してきたのかは知りませんが、非常に堅牢なものに取り組むことは素晴らしいことです。
Adobe XDでは写真を図形にドラッグするだけで、簡単にマスクが作成できます。SVGアイコンをドロップすると、すぐに編集可能なベクター形式に変換され、モジュールのサイズ変更もレイヤーを操作する必要はありません。これらはデザイナーとしての時間を節約するもので、Adobe XDで体験するまではこれらがいかに素晴らしいものであるかを実感することはできませんでした。
Restaurant Finding App Concept
自動アニメーション
Adobe XDの機能を見てましょう。
「自動アニメーション」というだけで、UIデザイナーは鳥肌が立つかもしれません。ボタンのアニメーションを表示したり、カルーセルがどの方向にスクロールするかクライアントに実演する時などに、フラットなグラフィックだけでなく、UIのエクスペリエンスを見せることができます。アイデアを売り込むこと、デザインだけでなくエクスペリエンスを売り込むこと、実際に素晴らしい体験をすることは必要な予算を増やすことに繋がります。
Adobe XD以前は、After FXやPremier Proなどが必要でした。しかし、現在は違います、Adobe XDがあります。Adobe XDでインタラクティブを作成するのは非常に簡単なので、時間をとられる必要はありません。
Adobe XDでは、プロトタイプの自動アニメーションをスクリーンに記録し、動画にエクスポートすることもできます。これはプレゼン時にも、デベロッパーに渡す時にも役立ちます。
この記事はチュートリアルではないため、自動アニメーションのやり方については説明しませんが、非常に簡単で効果的なので、まだの人は試してみてください。
自動アニメーションは非常に強力で、群を抜いた最高の機能です。プラグインは不要です、Adobeはよくやったと思います。
プロトタイプ
私は以前に、画像をInVisionにアップロードするためにPhotoshopとSketchからエクスポートする必要がありましたが、ちょっとした修正があるたびに同じことをしていました。最初はCraftプラグインを使用していましたが、アートボードが表示されない、誤って上書きされる、コメントが消えてしまうなど、多くの問題がありました。なんて面倒なことでしょう！ 私はほとんどすべてのクライアントでOverflowを使用しています、Overflowはユーザージャーニー用のアプリです。
Adobe XDを使用すると、これらすべての機能が組み込まれているため、心配する必要はありません。プロトタイプとデザインをいつでも、素早く切り替えることができます。テキストを素早く変更し、ビジュアルをエクスポートすることなく、数秒で公開できます。エクスポートや置換がないので、複製は作成されません。プロトタイプのタブにリンクすると、ユーザージャニーが表示され、これらのために別のソフトウェアは必要ありません。
Adobe XDで一番のポイントは（私の意見では）、ブラウザでクライアント用に開くプロトタイプのリンクをエクスポートすると、すべてがベクター形式で表示されることです。InVisionでエクスポートしたときに比べて、数倍も優れています。
しかし、Adobe XDにはまだ欠点があり、今後のアップデートで修正されることを望んでいます。
プロトタイプのリンクの保存は問題です。InVisionを使えば簡単にログインでき、すべてのプロトタイプが1ヵ所にあります。しかし、Adobe XDの場合は、リンクはAdobeアカウントの複数ページにネストされているように見え、急いでいるときには見つけにくいことがあります。ほとんどの場合、コアのXDファイルを見つけて開き、リンクを再度エクスポートする方が簡単です。
デザイナーとして、プロトタイプにコメントをつけるのは好きではありません。個人的には口頭でチーム内で議論しながらコメントするのが素晴らしいことだと思っており、クライアントからデザイナーまでの観点からすると、コミュニケーションとクライアント管理が不十分だと考えます。どのような修正が行われたのかを正確に把握するのは難しく、クライアントが忍び込むのは簡単です。また、ビジュアルを更新する際にコメントを失う危険性が常にあります。つまり、将来的に信頼できるバックアップのドキュメントがないということです。これはInVisionのような複数のプロトタイピングツールにまたがる大きな問題です。
デベロッパー用のデザインスペックを共有
初めてSketchのプラグインとしてZeplinを使用した時は驚きました。デベロッパーに渡すためにすべてのアセットをエクスポートする必要がなくなり、フォントサイズやパディングや配置に関するすべての決定を説明する必要がなくなり、SketchファイルをZeplinにドラッグしてデベロッパーを招待するだけで、開発時に必要なものがすべて揃います。
Adobeは（ありがたいことに）Zeplinの良いところをソフトウェアに組み込みました。Adobe XDからエクスポートする必要がなく、リンクを生成するためにファイルを任意の場所にドラッグする必要もありません。「共有」をクリックし、ドロップダウンから「開発用に共有」を選択するだけです。URLが自動生成され、すぐに使用できます。繰り返しになりますが、これはAdobe XDに標準で組み込まれている機能で、Zeplinに毎月の料金を支払う必要はなくなります。
総括
Adobe XDは素晴らしいと思います！ 高速で、信頼性が高く、効率的で、インテリジェントで、しかもこの便利なソフトウェアは無料です。信じられません！！
ここまで読んでくれてありがとうございます。もしこの記事を気に入ってもらえたら、共有をお願いします！
0 notes
Text
Through the Valleys - PushTheWinButton's Vanilla Plus Modding GuideのDESCRIPTION
概要
Through the Valleys - PushTheWinButton's Vanilla Plus Modding GuideのDESCRIPTIONの日本語訳です。
"https://www.nexusmods.com/oblivion/mods/51105"
翻訳
このMODについて
バニラプラスの精神をシロディールの地で再現した、初心者向けの改造ガイドです。
スルー・ザ・ヴァレー
PushTheWinButtonのバニラプラス改造ガイド
はじめに
『Fallout New Vegas』は私が改造したことでより知られているゲームですが、実際には『Oblivion』をプレイしたり改造したりする方が楽しいと思っています。というのも、Oblivionは、私が10年以上前、発売直後に（ユーザーとして、またアマチュアの改造家として）改造を始めた最初のゲームだからです。
これは、ゲームのバニラな精神を維持しつつ、非常に安定した、バランスのとれた、強化されたMODリストを作成することを中心としたものです。これは、ゲームをオーバーホールして、たくさんの新しい（しばしばストーリーを壊すような）アイテムや機能、きれいなグラフィックを詰め込むことを目的とした旧来の改造の概念とは異なり、ゲームを不安定にすることがよくあります。バニラプラスのシーンは、由緒ある「Viva New Vegas」MODガイドとQolore氏のたゆまぬ努力によって大いに盛り上がりました。Qolore氏はその後、Bethesdaの他の主要ゲームのガイドを作成したにもかかわらず、Oblivionは未だにバニラプラスの盲点となっています。
しかし、今は違います。
このガイドはOblivionのバニラプラスガイドの決定版となることを目指しており、コミュニティが経験してきた様々な時代にMODを作ったり使ったりしてきた私自身の長年の経験に基づいています（また、既存のOblivionガイドの中で新規プレイヤーに与えられている粗末なアドバイスに対する私の一般的な不快感もあります）。
範囲
このガイドは各セクションに分かれており、私が推奨するMODのリストと、それぞれのMODの簡単な説明、そしてダウンロードとインストールの手順が記載されています。MOD名はNexus上のMODのページにリンクしています。このガイドに掲載されているすべてのMODは、Nexusからダウンロードすることができます（例外として、重要なMODがありますが、それについては完全な説明をしています）。すべてのファイルは英語で書かれており、外国語のサイトへのリンクはありません。
MODは、私自身が長時間のプレイテストを行い、各MODの品質やコンフリクトなどを手動でチェックした上で選ばれています。怪しげなスクリプトや壊れたスクリプト、没入感を壊す、伝承に優しくない、不自然な設定メニューやアイテムを含むMODはリストに載せません。もしあるMODがリストから外れていると思うなら、それは私がそのMODが標準に達していない、バニラプラスの概要に合っていない、あるいは同じコンセプトでより良い、あるいはシンプルなソリューションがあると考えているからでしょう。また、上記の基準に合致していても、ガイドをより簡潔にするために、いくつかの小さなMODを省略していることにもご注意ください。
パッチが必要な場合は、このページのダウンロードセクションで提供します。また、カスタマイズが必要なMODの場合は、事前に設定されたINIファイルも提供します。Wrye BashやxEditなど、メインのMODマネージャー以外のMODツールの使用を要求することはありません。また、最適化されたロードオーダーファイルを提供しますので、Mod Organizer経由でインポートして、手動でソートする必要はありません。
Qolore氏の言葉を借りてバニラプラスの意図を要約すると、このガイドは以下を提供します。
安定性 ： クラッシュをゲームの中核機能にしてはいけません。このガイドには、必要不可欠な安定性強化がすべて含まれており、プラシーボや危険なMODは含まれていません。このガイドを完全にインストールすれば、クラッシュはゼロになるはずです。もちろん、New Vegas Oblivionでの保証はありません。
パフォーマンス : このガイドに掲載されているすべてのツール、設定、およびMODは、最大限のパフォーマンスを保証するために、慎重に選択され、プレイテストされています。
より良いゲームプレイ : このガイドには、ゲームのコアな体験を大幅に変更したり、ゲームのロアーから離れたりすることなく、ゲームプレイを大幅に改善する多くのMODが含まれています。
カスタムMODとパッチ : 必要に応じて、本ガイドはカスタムMOD、既存MODの補遺、MODのパッチを提供し、互換性を持たせてガイドとの整合性を図ります。
以上のことから、このガイドには私自身の改造が多く含まれていることに注意してください。私は基本的に、私のゲームインストールの合理化されたバージョンを再現しているので、必然的に私自身のMODも含まれます。もしあなたがそのようなことに過敏になっているのであれば、これは利益相反の宣言と考えてください。
このガイドの使い方
このガイドは、あなたがオブリビオンのGOTYデラックス版を使用していると仮定しています。つまり、Knights of the NineとShivering Islesだけでなく、すべてのDLCを持っているということです。
できればOblivionを新規にインストールした状態でこのガイドを始めることをお勧めします。少なくとも一度はゲームを起動し、グラフィック設定などを行っておく必要があります。
私がリストアップした順にMODをインストールするか、Mod Organizerを使用している場合は、MODの優先順位リスト(左のペイン)をこのガイドに記載されているのと同じ順に並べることをお勧めします。アセットの���合を解決するためには、この順序が最も最適であることを確認しています。MODのメタデータの分類、名前の変更、並べ替えについてはお任せしますが、探し物がしやすいようにMODの設定を整理しておくことを強くお勧めします。
このガイドの最後に、2つのものを提供します :
Wrye Bashで作成され、私が手作業でチェックしたカスタムパッチで、私が「必須」とマークした部分のMOD間のコンフリクトをすべて解決します。必須ではない（Not Required）」MODを好きなだけ追加することができます。つまり、私の指示に従うだけで、コンフリクトを心配する必要はありません。もしあなたが私のパッチを使わずに自分のbashedパッチを作りたいのであれば、私の~Required~と~Not Required~のマークを無視して、好きなMODをインストールし、自分のMODをいくつか追加することもできます。
Mod Organizerにインポートして、リストアップされたすべてのMODに最適な方法でロードオーダーを自動的に並べ替えることができるロードオーダーファイルです。これにはすべてのオプションMODが含まれますが、すべてのMODをインストールしている必要はありません。つまり、ロードオーダーを気にする必要もありません。このロードオーダーは、私のパッチを使用しない場合に、Wrye Bashで独自のbashedパッチを作成する際にも整理されます（ただし、最適な結果を得るために、いくつかのMODに手動でタグを追加する必要があるかもしれません）。
もしあなたが経験豊富なMODユーザーであれば、MOD名と各MODに記載されている短い要約以上の説明を読む必要はないでしょう。また、特定のMODをインストールする必要があるかどうかの判断もできているでしょうし、ガイドにMODを追加する方法もわかっているはずです。
経験の浅いユーザーの方には、MODのファイルや構造を理解する能力をある程度期待していますので、全くの初心者の方のお手伝いはできません。しかし、初期のMODや、特にxOBSEのような非標準的なインストールプロセスを持つMODのインストール手順については、できる限り説明したいと思っています。改造の基本を説明したガイドはたくさんありますが、以下に簡単にまとめてみました。ガイドを書くにあたっては、経験の浅いユーザーが、私が推奨するすべてのMODをインストールし、追加のMODを追加しないことを想定しています。これは、あなたがインストールしたいものを選べないということではなく、あなたが自分で行った変更を私は考慮できないということですので、ガイドを読む際にはそのことを念頭に置いてください。
経験の浅いユーザーが知っておくべきこと。
あなたのゲームがインストールされている場所。
プログラムのダウンロードとインストールの方法、およびファイル閲覧システムをうまく操作する能力（例：Windowsユーザーとしての能力）。
ゲームのルートディレクトリとデータディレクトリの違い（以下にまとめてあります）。
MODがどのように構成されているか（これも以下にまとめています）。
ロードオーダーとは何か（こちらも以下にまとめています）。
基本的なModdingの概要（初心者向け）。
Spoiler: Show
フィードバック
このガイドを気に入っていただけましたら、このガイドを推薦していただくことをお忘れなく。
MOD作者は、比較的少ないクレジットで多くの時間を作品に費やし、すべて無料で行っています。あなたが協力できる最善の方法は、言葉を広めてコミュニティを構築することです。
追加や削除の提案、あるいはガイド全般に対するフィードバックがあれば、コメント欄に投稿していただければ、必ず読みます。返信する時間がなくても、私はすべてのコメントを読んでいます）。私は当分の間、この��イドの継続的なサポートと改良を提供したいと考えています。
(私はゲーム内のスクリーンショットを撮るのがとても苦手なので、ユーザー画像のセクションでご自由に投稿してください。よろしくお願いします！)
ツールとプログラム
改造ツールといっても、必要なものは1つだけです。
Spoiler: Show
ユーティリティー
-必須-
ユーティリティーとは、Oblivion Script Extenderとそのプラグインのことで、MOD製作者のために機能を強化したり、ゲームエンジンのコードの問題を解決したりします。
Spoiler: Show
バグフィックス
-必須-
このセクションでは、大量のバグやゲームの不整合を修正するMODに焦点を当てています。
Spoiler: Show
ユーザーインターフェース
-必須ではありません-
バニラのUIをシンプルに改善します。
Spoiler: Show
ゲームプレイ - コア
-必須-
これらのMODは、バニラプラスのゲーム性を向上させるための核となるものです。レベリングの改善、不公平なスケーリングの修正、その他一般的なバランス調整が中心となっています。
Spoiler: Show
ゲームプレイ - エクストラ
-必須ではありません-
ゲームプレイに関連した、より小規模ではありますが、非常にお勧めの追加MODです。
Spoiler: Show
ワールドビルディング
-必須-
没入感を高めるために、ゲームワールドにLore-friendlyな追加や変更を行います。
Spoiler: Show
サウンドとオーディオ
-必須ではありません-
ゲームのサウンド関連の改善、例えばいくつかの効果を置き換えたり、アンビエンスを追加したりします。このセクションはガイド全体には厳密には必要ありません。
Spoiler: Show
キャラクタービジュアル
-必須-
フェイス、ボディ、アパレルの改善。
注：(Optional)または(BBB-Only)と表示されているModは、このパッチを使用するために必要ではなく、スキップすることができます。
Spoiler: Show
グラフィック - コア
-必須-
ゲームワールドのビジュアルと没入感を向上させるための、必須のライティングとテクスチャの強化です。
Spoiler: Show
グラフィックス - エクストラ
-必須ではありません-
バニラのメッシュやテクスチャのエラーを修正するものなど、バニラに適したグラフィックの改善が追加されています。このリストの中から自由に選んでください。
Spoiler: Show
遠くのLOD
-必須ではありません - WIP-
ゲームに新しい遠景LODモデルを追加するMODで、特定のオブジェクトを遠くから見ることができるようになります。このセクションはまだ完全なガイドの一部ではありませんので、MODへのリンクを貼るだけで、説明や手順は記載しません。興味のない方はこのセクションを読み飛ばしてください。
注意：LODを増やすことは、どんなマシンでもパフォーマンスを低下させ、ロード時間を大幅に増加させるので、自分が何をしているのか分かっていて、強力なセットアップを持っていない限り、お勧めできません。個人的には、これらのMODはスクリーンショットにしか使いません。
Spoiler: Show
その他のツール
-必須ではありません-
このガイドでは必要ありません。このセクションでは、上級者向けのその他の改造ツールにリンクしています。いずれの場合も、これらのプログラムを使用する場合は、MO2から起動することをお勧めします。
Spoiler: Show
最終ステップ
このガイドはほぼ最後まで読んでいただきました。さて、最後の仕上げをしましょう。
MODを導入したゲームでは紛争は避けられません。小さなものもあれば、深刻なバグを引き起こすものもあります。しかし、このガイドではそのような心配をする必要はありません。このセクションでは、最適なロードオーダーと、このMODリストのすべてのコンフリクトを解決するためのハンドチェックされたパッチを提供します。
Spoiler: Show
私のMOD
私は自分のMODの作成とサポートに多くの時間を費やしているので、寄付はありがたく受け取ります。
ここをクリックしてすべての私のMODを見る
www.DeepL.com/Translator（無料版）で翻訳しました。
06/19/2021 00:00 a.m.
0 notes
Last Seen Blogs
sojung-shin
So Jung
swinging-through-the-stars
welcome to my space
miraculerfromanotherunivers-blog
Untitled
starflungwaddledee
✧･ﾟa little wanya seeking starlight ﾟ･✧
porterfieldhaas52
The Journaling of Dehn 601