はてなブログかnoteか
以前、こんなのも書いたけど。
noteはいい感じなんだけどやっぱり書くときにできないことが引っかかるので、はてなブログにとりあえず書いて見てるこの頃。
いや、ちゃんと Craft CMS でブログ用意してそっちでやればすむ話ではあるのだろうけど。
noteがいいな、というところ
こちらでも書かれているけど。
noteはいまのエディタ機能で問題ない人にとってはすごく使いやすいところだと思うし、課金しやすいシステム（書く人・読む人双方にとって）で、いいねがしやすい雰囲気がすごくいいですよね。
無料で何でも読めるのもありがたいけど、それを応援する仕組み、ってのがあった方がお互いハッピーな結果になる気がしますよね。
Markdownがマストかどうか
markdownでかけた方がいいな、と思ってる所はあるんですが、ブログならリッチエディタでもいいかもな、と思い始めてる自分もいます。
日常のメモとかはmarkdownですけどね。
半田さんのXDディレクション資料をみて学んだこと
半田さんのスライドを拝見して。
なるほど、ふくらはぎ、下半身が重要なのか。。。（違
仕事場の足下環境が重要かもな。
資料の分散
そうそう、機能と見た目の参照ファイルがわかれるのは問題、というのを最近改めて痛感した。
これまではそういう感じで別れるもんだ、と思っていたのだけどやっぱこれは非効率。
XDとパワポとWikiと。これは失敗だったな、と激しく反省。すません。。。
XDで注釈をシンボル
注釈をシンボル
なるほどなー。そういう使い方があるか。
似たようなツールには大体、注釈・コメントみたいな機能は結構ついてるんだけど、あれは、デザイナ＜＞デザイナ、デザイナ＜＞フロントエンド、デザイナ＜＞プログラマ、みたいな情報のやりとりには合致するのかも、、、しれないけど。
自分の周りではまだ見たことがないな。。。。
デザインスペック、使えるんだけど、そこかー、というのは自分が欲しい情報じゃないからだろうな。
それとは別に、リモートだとできるだけ共有しやすいツールと言うことで、オンライン系の方がいいのかなぁ、、、と思ってしまったりする。
タスクの分類方法
余談の話も共感しまくり。
タスクはときに「ページ」に紐付く
とか。
ここ、backlogでissue立てる際の単位を何にするか？という話を最近考えていて、ページがマッチする場合と機能がマッチする場合があるなぁと考えている。
この辺は案件の内容やフェーズ次第ではあるのだけど、機能を1つのissueとして作ってそこにぶら下がる作業などを子チケットにしていくのがいいのかなぁとか考えている。
Gantt Chart 的思想なSmartsheet
Smartsheet、、、何回かチャレンジして挫折してるのだけど、WBSという視点からやること洗い出しの、各作業なりに割り振りできるからちゃんとできるようになればみんながハッピーな所に持って行けるのかなぁと言う気がしている。
Backlogでもできるのかもだけど、階層が
・カテゴリ／マイルストーン
・親チケット／子チケット
しかないと、そこに引っ張られてしまうので、、、
その辺、使ったことはないけど、マンモスプロジェクトみたいなピラミッド型も悪くないのかも？と思ったりもしている。
どちらにせよ、全体が見通せて、進捗・残タスクがわかる。
そこにスケジュール（変更に追随・依存関係を保持するの）ものっけられるっていうのがやりやすいツールなんだろうな。
タスクの全量はどんなツールでもできる・見通せる話なのであとはそこをまわしていくディレクターの仕事ですね・・・
運用中とリニューアル中でのWikiの使い方とか改善したいこととか
まみりんさんのエントリーを読んで。
運用視点っていうのは普段あまり意識していなかったからなるほどなー、と思った。
運用目線のドキュメント
誰がどこを管理しているか、とか確かにリニューアルしたときは明らかだけど時間がたつにつれ忘れて行ってしまうし、そもそもリニューアルを担当していないメンバーにとっては全然知らない話だろうし。
いや、自分でリニューアルを担当してても、運用期間が長くなってくるとかなり忘れてくるな。
リニューアル時点でも体制図とかは重要だしなぁ。
管理がCMSとそれ以外が混じってるのもまさに時間がたてば忘れてしまう、という感じだなー。
CMSで管理しててもどこで管理してるか忘れるレベルだから、それがわかるようなドキュメントが残っていた方が安心だな。
後から読んでもわかるドキュメント
リニューアル中もWikiに色々とドキュメントを残すようにはしているのだけど、書いてる自分は大体どこに書いたかはわかってるんだろうけど、他のメンバーにとってはどこに書いてあるかがわかりにくいんだろうなぁと。
Wikiの1ページ目というか、Homeはそれぞれのページへのリンクで目次的な使い方にした方がいいんだろうなぁという気がしている。
Backlogでやってると手動で全部のページを載せるとかはちょっと手間だったりするけど、リンクのリストと概要をメモっておけばあとで見る人にとっては使いやすいのかなぁと思ったりしているので、次の案件では意識的にやってみようかと思っている所。
全豪オープンテニスのトーナメントを見てみる
これから大坂選手の全豪オープンの決勝が始まりますねー。
頑張ってほしい！！
トーナメントがどんな感じで作られてるのかなー、とかおもって見てみた。
今日は女子の決勝だからかプルダウンの順番が変わって、女子シングルスが先頭にきてるっぽい。
トーナメントページ
vueでやってるのかな。
今年は少しはvueを理解できるようになりたい所なので勉強してみよう。
スマホでみてて拡大表示すると試合が進むと見づらい感じ。ここは拡大表示にしない方が見やすかったりするのかもなぁ。
データ
トーナメントごとにデータは別々で、例えば女子シングルスのデータはこれっぽい。
https://prod-scores-api.ausopen.com/event/85996/draws
データ自体はDrupalで管理してるのかな。
試合結果
これが試合の結果っぽい。
プレーヤー単位でセットごとにスコアをいれていって勝った方にチェックとかつけてるのかな。
プレーヤー情報
プレーヤーのデータがこの辺か。
直接選手には紐付いてないみたいだけど、この辺はあれなのかな、ダブルスとか考慮してるのかな。
大坂選手の情報。
ダブルスのデータ見ると、そうみたいでした。
試合の結果も何回戦か？は別に持たせておきつつそれとリレーション張ってる感じなんだろうな。
どいう管理画面なのかがすごく気になるなー
試合の結果も気になるなー。頑張れー。
ATOKの自動変換を試してみる
ATOKにも自動変換ってのがあるのね、と言うのを今更ながら知った。
自動変換
入力した文の文節の区切りや変換候補を自動的に判断して、変換します。
変換キーを押さずに、漢字かな交じり文を作成することができます。http://support.justsystems.com/faq/1032/app/servlet/qadoc?QID=041282
Macのライブ変換も評判はあまりよくなかったりするわけだけれども、とりあえずどんなもんか？というので試してみることにする。
Typoが多すぎてそもそも、どのくらいメリットがあるのかとか、すごいのかとか気づかないかもしれないのだけれど。。。
とりあえずは数日使ってみてから、考えることにしよう。
句読点が判定基準になってるっぽいな。
クライアントとエンジニアの間でのコミュニケーション
全然つなげてないというかコミュニケーションの役に立っているのかなぁと思うことが多いけど。
クライアントがディレクターと話し、ディレクターがエンジニアーやクリエイターと話す。一件、この間に挟まる部分は無駄に思えて、クライアントと実装者を直接つないだりしちゃうことがあるのだが、大抵うまく行かない。
— たにぐち まこと／学ぶ。をちゃんと (@seltzer) January 25, 2019
クライアントがディレクターと話し、ディレクターがエンジニアーやクリエイターと話す。一件、この間に挟まる部分は無駄に思えて、クライアントと実装者を直接つないだりしちゃうことがあるのだが、大抵うまく行かない。
— たにぐち まこと／学ぶ。をちゃんと (@seltzer) January 25, 2019
ディレクターは、クライアントのあいまいな依頼から気持ちを汲み取って、それを実装できるレベルに落とし込み、エンジニアーやクリエイターと話ができる両方の気持ちを理解できる能力が必要。
— たにぐち まこと／学ぶ。をちゃんと (@seltzer) January 25, 2019
実際、お客さん側の通訳にたつくらいのスタンスの方がチームとしてもやりやすいのかなぁと思うこともある。
ただなんでもかんでも間でつないでるとボトルネックになってしまう気がするので、それはそれで場合によってはデメリットになるような気もするなぁと。
あとはディレクター側の実装に関してのスキル不足を感じるときもあるので、そのへんはちゃんと学ぶなりして会話できるようなところまで持って行けるようにしないといけないなぁ。
