仕様策定についての考察
弊社で新規機能の開発が行われていた際に以下のような問題が発生していた。
- デザイナーとエンジニアチームで仕様についての理解、認識がズレていた。
- デザイナーがビジネスチームに仕様を共有するフロー上、誤った認識で顧客に共有されていた。
1点目については、技術的に不明瞭な段階で、現時点で可能そうな仕様が共有された。 その後エンジニアチームで技術的に明確になった時点で当初共有されていた仕様ではなく、理想的な仕様で実装されていたものの、デザイナーチームには共有されていなかった。
2点目は1点目の認識の差異が原因となり、ビジネスチームに伝えた仕様と実際の仕様が異なっていたため、顧客に改めて最新の仕様を共有しなければいけない必要が生じた。
今回の背景としてはタスクフォースチームで緊急度が高く、納期が存在していたため発生したと思われるが、有事に限らず普段の開発フローにおいても明確化されたワークフローや意思決定プロセスを定義しておくことで、仕様の策定から実装、運用までの流れを加速させ、より密なコミュニケーションが可能になると考える。
そこでいくつか思考実験を行ってみる。
登場人物の紹介
- ビジネスチーム（顧客との対話、ビジネス影響の判断、機能の提案等を行う）
- デザインチーム（UI・UXの設計、機能の提案等を行う）
- エンジニアチーム（機能実装、障害対応、保守運用、機能の提案等を行う）
ある機能を開発するとき、上記の3チームが直接的に関わる。 そこには知識の壁が存在し、相互理解ができない可能性があると考える。（例: デザイナーはHTTPの仕組みを理解していない。）
そこでお互いの代表者がそれぞれ歩み寄り、両者の同意が得られるレベルまで仕様について議論する必要がある。
ビジネス上のインパクトが納得できる機能か？ ユーザー体験やペルソナで想定されるストーリーは十分に納得ができるか？ エンジニアリングにおいても十分に調査でき、実現可能性に見通しが立っているか？
代表者は各領域のエキスパートであり、この開発において最重要責任者であると考える。 例えば、当初の調査で十分だと思われていた要件定義が、実装段階において不十分であると分かった場合には、急ぎ3者を含んだ仕様策定会議を開き、修正を行う義務を持つ。
しかしながら上記の仕様策定において、いくつか課題がある。
外から見ればエンジニアは1チームのように見えるが、技術領域で分割すると大まかには以下の様に分けられる。
ここでは更に知識の壁が発生し、インフラストラクチャ、バックエンド、フロントエンドの順に壁が厚くなる。
エンジニアリング領域毎に、事業影響が異なるため、安易にリーダーを選出できない課題がある。
フロントエンドのエンジニアがインフラストラクチャやバックエンドの領域に関する仕様については基本的に責任を負える立場にないといった具合だ。
隅に追いやられたような形のフロントエンド領域だが、デザイン領域の意思決定にはフロントエンドのエキスパートがいなくてはならない明確な理由が存在する。
それは実装可能性の可否と、変更コストの判断である。デザイナーチームはプランを彼らにレビューしてもらうことで、そのプランが提案可能かどうかが判断できるようになる。
そこで、仕様策定におけるデザイン領域の決定は、フロントエンドとデザイナーのエキスパートの2名で意思決定を行うようにする。
このような関係性がインフラストラクチャとバックエンド領域でも起こり得る。
実現したい仕様によってはインフラストラクチャに影響を与え、その結果バックエンド（またフロントエンド）はその影響を踏まえた上での設計が必要となる。
インフラストラクチャへの影響は必ず起こるわけではないため、必要だと判断したときのみ仕様策定に関わってもらうようにするのが良いだろう。
今までの考察をまとめると下図のような関係になる。
フロントエンドはバックエンドとインフラストラクチャと完全に切り離すことができないため、デザイナーチームとの連携などやや関係するチームが多いものの、見た目や挙動の変更に大きなコストがかからないよう、基盤周りは整備しておきたい。
バックエンドとインフラストラクチャのリーダーは常に密なコミュニケーションを心がけ、インフラストラクチャのリーダーが仕様策定に参加しない場合においても、バックエンドにどのような変更が行われるのかは常に情報が更新されるようにしておくのが好ましい。
今回の登場人物にはいわゆるプロジェクトマネージャーといった人物は存在していない。今の予想では時間軸と意思決定プロセスの担保を行うことが考えられる。時間軸はいわゆる納期や回転率をマネジメントし、意思決定プロセスの担保は、結果的には正しい情報を元に関係者が動ける状態を維持する責務を指す。
OCWとその認知度、またアクセシビリティについて思ったこと
OCWという言葉をそもそも聞き慣れないせいで、日本人のどのくらいがこの概念について知っているのだろうか。
結局、知るものしか利用されないようではよろしくなく、常識として日本人の全ての人が知っている前提を作った上で、利用する・しないの判断が行われるような状態が望ましいと考える。
もったいない、日本人ならではの考え方かもしれないが... 京都大学のOCWに限っていっても6000もの（品質が保証されている）講義が無料で受講できる時代にまで来たのは喜ぶべきだろう。
もちろん、コンテンツの拡充やOCWに協力的な大学を増やすなどの課題はまだまだあるが、それと平行して認知度を高めていくこともOCWの拡充に間接的に貢献できると考える。（MITの入学生のうち一定数がOCW活動が入学の理由だったように。つまり大学にも見返りがある取り組みだ。）
英語を目の当たりにしても、当たり前のようにINPUTできる人とそうではない人がいる中、根本的な概念は英語圏をベースとしても、やはり日本国内で認知度を上げると考えると、概念の翻訳は必要になってくるように思える。
あくまで主観での話に過ぎないが、 Open Education という言葉を日本語で伝えようとした時、どのような言葉が良いのだろうか......
教育の自由化、みたいな言葉が刺さりやすいかもしれない。フリー教育だと低質な印象を与えるが、ここでいう自由化の場合、公立が民営化されるという意味合いは感じられず、どちらかというと今まではクローズドであった教育の中身をオープンにする印象の方が強く感じられる。
また、アクセシビリティにも課題があり、OCWでコンテンツがオープンになったは良いものの、そのコンテンツにたどり着くまでの道筋は容易かどうか。
コンテンツ、LMS又は配信サイト（YouTubeを含む）、履修するユーザー、これらの内、LMS又は配信サイト（YouTubeを含む）と履修するユーザーを繋ぐプラットフォームがあれば、異なるOCWプラットフォームにおいても、自身の興味・指向性にあったコンテンツにアクセスできる可能性が高まると予想される。
ITと教育に関するリサーチ
最近は論文を書くにあたっての調査で、教育に関する論文やレポートなどを手当り次第読んでいます。
自分用メモとなりますので、ご容赦下さいませ。
「eラーニングの広がりと連携 : 1.オープン・コース・ウェアの現状と展望」にて、OCW(OpenCourseWare) すなわち講義をデジタル化しネット上で配信する公開講義の活動と、その日本版であるJOCW を知る。
Members | OE Japan によれば13もの大学がOE Japan (JOCWの新名称) のメンバーに所属しており、オープン教育リソース(OER)活動を行っている。
個人的に気になった講義をいくつか参考程度にのせておく。
東京大学、京都大学、筑波大学辺りは講義がまんべんなくある印象ですが、やはり予算不足が原因なのか講義の母数の少なさや、使いづらいUIなど、まだまだ課題が残っている印象を受けた。
その他、いくつかの大学は 講義動画をYouTube上で配信しており、講義数も多くかなりクリーンな印象。
京都大学が先陣をきっているみたい。 2008年から開設し、講義数も約6000本とかなりのボリューム。
次いで筑波大学でしょうか。 2013年開設で講義数は253本。
東京大学は2018年開設なので、かなり後発的な動きではありますが、自身のサイト UTokyo OpenCourseWare では 1400を超える講義を扱っていて、YouTubeではその一部を紹介するといったスタンスのようです。
膨大な動画を配信するのは、保守・運用のコストがバカになりませんから、YouTube上で配信しつつ自分たちの大学のデータベースにコンテンツを保持するといった形が選択肢としては良いのではと感じました。
また、OE Japan のサイトには活動報告がいくつか載せられており、以下のレポートを読んだ。
非常に興味深い内容で、引き続きキャッチアップしていきたい。
JOCW でgoogle検索をかけたところ、 SCORM(Shareable Content Object Reference Model)といった標準規格があることも知った。 SCORMは eラーニングのプラットフォームとコンテンツの標準規格で、アメリカ国防省系の標準化団体ADL(Advanced Distributed Learning Initiative) が策定している。 要約すると、講義等のコンテンツと、それをユーザーに配信するシステム(ここではLMSを指す)を上手に分離し、コンテンツが配信システムに依存しないような作り方を決めている。
サイバー大学 論文を書くための準備運動
サイバー大学（以降はサ大）に入学してはや半年。 月日の流れは加速していきますね。
3年次編入で入学して、春・秋／学期で見ると残り3/4だ。
それと合わせて、仕事のためのスキルアップも、もう少しで基準に達せられるかというところ。
サ大は、卒業するためにはゼミ（半年）に所属する必要があるが、実は卒論は書かない。実質レポート以下の提出物で、誰でも卒業できるように出来ている。
一般的な大学でいう卒業を書くという工程は特別研究（１年）という任意受講の講義で行われる。
特別研究を受講するためにはゼミを受講済み、または同時期に受講していなければいけない。
そして3年次編入で入学した者が4年次で卒業し、かつ特別研究を受講するには4年次の春学期に、およそ14~16単位の講義、ゼミ、特別研究の3つを同時に走らせなければならない。（社会人学生に選択肢は残されていない）
状況を整理すると、ゼミは瞬殺できるとして、講義は単純に講義数に比例して時間が必要になるので、必然的に特別研究に割けるリソースが少なくなる。
特別研究でやることはすなわち研究なので、開始してからどうすれば良いのかなんて考えていたら状況的に危ういのは目に見えている。
そこで4年次の春学期の負担をなるべく分散させるために、開始前から研究を始めるためには何が必要か、論文を書くためにはどうすれば良いのか、などのポイントを予め抑えておくことが大事だろう。
手始めに 論文・レポートの基本 を軽く読んでみた。
自分なりにまとめると、以下の4つの工程をきちんと抑えることが大事だと思いました。
- 研究テーマを定める
- 問いを立てる
- 論文の基本的な書き方を覚える
- 論文を書く
研究テーマは幅広くてよく、自分が興味・関心の高い領域と言い換えてもいいのかなと。
問いは論文の切り口になり、一文で表現できるほど明瞭でなければならず、研究したい内容そのもの。
書き方や実際に書く経験も大切だが、コンテンツがなければ書きようもないため、この研究テーマと問いを立てる工程は今すぐ始めて、特別研究が開始するころには終えている必要がありそうだ。
ISUCON 2021 予選 に出場してみて
所感とか（書き殴りです。）
結果は、初期スコアから変わらず笑
ちゃんと systemd の起動コマンドの中身まで見たのに、ビルド+実行されてるように空見してしまって、永久に初期ビルドで戦ってました汗
試合終盤、ベンチマーカーに不具合が発生し、そのまま試合終了時刻を過ぎたので、終わったものと考え夕食に出かけるも、ラーメン出された辺りに延長のお知らせが。
食って帰ったら丁度終わりの時間で、最後にちゃんと測っておきたかった、悔しい気持ちが残りました。ヒイ。
とにかく、やるべきことはいくつか拾えたので、次回に活かせるよう、武器の調達リストを作っておくことにする。
今回のアプリケーション構成
一般的なWebアプリケーションと捉えました。
Nginx <-> App <-> DB といった初期構成でした。
またAWSのECサービス上で1インスタンスに上記の3者が内包され、3台立ち上がっているような状態でした。
そしてベンチマーカーはそのいずれか1台を指定する方式でした。
AWSで使える25ドルクレジット（ほとんどのサービスで利用可能）は配布されていたので、初期構成から大きく変わっても全然良いよという雰囲気を感じました。 （ただしRDSは有料枠でした泣）
対策
ここでスコアを上げるためには、どういう攻め方があるのかを考えると、
3者それぞれチューニングする
- Nginxのチューニング方法
- Appの改善（言語特性としてGo, Rust辺りに親しむ、N+1問題やアプリ内キャッシュ等、ビルド方法の切り替え）
- DBのスロークエリ改善やスキーマ変更等
ロードバランシングで負荷分散を行う
DBの構成を変える
- Read系, Write系で分離
- NoSqlの部分適用
ボトルネックの可視化
- alpや、New Relic等
- アプリケーションログ出力設定
各種オペレーションスクリプトの用意
- 環境構築（ISUCONの環境ではなく、ツールの用意や設定ファイルの書き換え等）
- 自動デプロイ（ローカルで開発し、本番にスムーズに反映できるフローを構築する）
- ログ抽出、ボトルネック特定のための指標の自動出力
- ベストスコア計測（ログ出力の停止、各種ツールの停止、本番用ビルド等）
チェックリスト！（座談会でご教授頂いた）
- 本番、まずなにをやるべきかをリスト化したもの。
- きまりきった作業は予め手順書化しておき、戦う土壌が出来るまでは少なくとも脳死でリラックスして取り組めるように。
などが考えられるかなぁ...
これらを地道に用意し、当日はチームで分担した動きでそれぞれの役割を果たせば自ずとスコアは伸びるのではないでしょうか。
ぼやき
言語色々と用意されてましたが、デフォでGo版が建ってました。 そのままベンチで2500程でましたが、Node.jsに切り替えると1200程。 言語特性は避けられないね。
とわいえ、スケーリングや負荷分散などで大きく伸ばすと言語特性は無視できるとの声もちらほら。
完全に最適化された場合にのみ差が出るようなイメージでしょうか？ それならむしろエンジニアとしての知見勝負になりますね！
UUIDを発行してSELECTしてるのを見ると広告配信を思い出しました。 DynamoにUUID辺りを移植してみたらスコア上がってたりしたんだろうか。
MariaDBのチューニングの仕方とか知らなくてググりながら進めてました。 コネクション数が最大150なのは驚いた。
さいごに
今回は一人での参加となりました。
チーム移動やら何やらで、一切事前準備出来ず、また10時開始なのに14時に寝坊して参加するも、ソースコード的にはかなり改善点を見つけられたし、Nginxログを解析して改善の優先順位付けしてからの動き出しなど、冷静に進めることができました。
まあ流石に準備なしはアレなので、次回は普通に挑みたいと思います。
切なさと達成感
本日をもって2年間もの間携わってきた広告配信システムから離れることとなった。 任期満了といった形で、システム自体が役目を終えていくということで、保守整備等は今後ともインフラチームと細々とやっていくけれども、 要件定義から開発やバグ修正といった工程はもうやってはこない。
言葉で言い表せない、様々な感情が湧いてくるのを感じる。 ようやく肩の荷が下ろせる。 そういった安堵の気持ちもあれば ああ、あの痺れるようなシビアな世界ともお別れか、といった切ないような気持ちもある。
広告配信システムはとても複雑だ。とても。 私達のチームは、入稿管理から、配信、測定までのライフサイクルを全て開発・保守していたので、2・3年経ってようやく全体の仕様が掴めてくるといった具合だ笑
開発も、技術スタックや経験によって、触っていいものとダメなものがあって、特に配信や測定なんかは、パフォーマンスやファイル連携IFの複雑さから、とても敷居が高くて触れる人が限られてしまう。
私は新卒入社で3年目になるわけだけれども、入稿管理から配信までを担当できるようにまで育てていただいてて、少し誉れのようなものを感じながらお仕事を続けていたんだ。
もともと27歳・IT未経験でこの世界に入ったんだけど、最初にアサインされたのがこのチームなもんだから、当時はビビッたなぁ(笑)。 えっ良いんですか、ボクで？ それでも、何度も血反吐を吐きながら(笑)積み重ねた経験はたしかに心に刻まれてるなぁと感じる。
自分の寿命を削ってでも必死に食いついた日々。誰に言うわけでもないのに、それを不幸自慢とも言えなくもないような微妙な感覚もある。
ただ、やっぱりもっと自分を褒めて良いんだと思う。俺はこんな大変な仕事もこなせたんだぞ、私すごい！！ってね。自分を大いに褒めていい。
そして支えてくれたみんな感謝だ。何度も辞めようと思ったけど、みんながいてくれたから今があるんだと思う。本当に感謝。
新しいアサイン先は、会社の社命を掛けたプロジェクト。他のプロジェクトを全て解散させ、全てのリソースをここに集中させる意思決定を行った経緯がある。
広告配信では、React, NodeJS, Scala, AWS といった技術スタックだったのが、今後は Elm, ReactNative, Go, Scala, GCP といったものに変わっていく。 ドメイン領域はもちろんながら、言語・インフラも大きく変わることになるので、しばらくはキャッチアップに追われるだろう。また大きく成長する機会をいただけることに感謝したい。
ただ単なる開発者としてのリソースなら、若くて優秀な人たちがたくさんいる中で埋もれるしかないだろう。もちろんそれでも良い。一番とか特別は追い求めない。ただ、自分が気付いた点については惜しみなく価値提供を行っていきたい。例えば育成とかね。
兎にも角にも、初めて携わったプロジェクトの終わりを見守ることができて、嬉しい限りだ…
変化する
すみません、先に断っておくと、今まではわりかし見ている人を意識して書いていましたが、これからは何も意識せず思うがままアウトプットする場にします。
今日お散歩してて思ったのよね、今の自分が考えていることって、記憶・5感からのインプット・これまでの生活で構築された脳神経・食事で体に入ってきた様々な物質・etc... それらがおりなす刹那的な火花だってことに。
つまり再現性なんてなく、もう次の瞬間には異なる思考になっているし、ずうっと変化していく。
過去にしがみついていても現在は変化するし変わっていない錯覚をしているだけで、肉体〜精神は刻一刻と変化し続ける。
そう思ったら、今の思考をアウトプットする価値は一定にあって、それは思い出を残すよりももっと色濃く、私という人間のアーカイブに成り得ると思った。
言語で100%のアウトプットなんて出来やしないけど、少なくとも未来の私が読むぶんには正しく伝わるから良しとしよう。うん。
今日はミート・スパゲッティを食べた。 いわゆるレトルトソースとパスタをあえただけだが、私なりのこだわりがある。
それはAll In Oneであること。 どういうことかというと、レトルトを暖める = 鍋に水を入れて沸騰させるのと、パスタを茹でる = 鍋に水を入れて沸騰させるプロセスは同時に同一リソースで行われる。 つまり同じ鍋で1回水を茹でるだけで完結するということだ。
それだけだと面白くないので、今日は大きいトマトと豚肉、人参にほうれん草を買ってきた。 そう、これらの食材をミート・パスタに加えるわけだが、プロセスは変わらない。
食材毎に茹でるために必要な時間を逆算し、それぞれ順番に鍋に放り込んでいく。 ちなみにパスタは7分で茹で上がってしまうので一番最後だった。
肉・野菜・炭水化物、それらが一度に採れて ∧ 調理に必要な手間はお水を沸かすだけ ∧ 洗い物は鍋とお椀1つのみで済む。
うむ。まだまだパスタは汎用的に利用できそうだ。
