RAW現像に手を出しています

いままでカメラと写真を撮るのは好きできたけれど、どうにも RAW 現像というのはやってこなかった。

というのも、撮って出し（と呼ばれているらしい）撮影したときのカメラでの見た目そのままの JPEG で残しておくのが楽だったし、あとから見た目を変えてしまうことになんとなく抵抗感があったからかもしれない。別に写っているものに手を加えて変えてしまうわけでもないので、「撮ってそのまま」みたいなことに勝手な鮮度みたいなものを感じているのかも。

カメラを SIGMA fp にしてからというもの、プロダクトの魅力か魔力かカメラをとにかく触りたくなる。そこでメニューで見つけたのが「現像」機能だった。機能があるからには使いたい。でもいつ使うんだろう？

カラーモードは、SIGMA の売りでもある「T&O」か「風景」を好きでよく使うのだけれど、山で緑がきれいな写真を撮ったつもりが「T&O」になっていて元気のない枯れた絵になっていることがあった。うーんなんだか記憶の色でもないし、見せたい色でもない。ああそうか、こういうときに RAW（fp では DNG）で撮っておけば後から自分が見ていた景色を再現できるのかと、ようやく気がついたのでした。

修正をしているのではなくて、自分の見ていたものを再現する。そう考えると、変な抵抗感は無くなっていました。

スマートフォンにカメラを繋いで写真を取り込めば、その場でアプリを使って現像できる手軽さも良くて、これはなかなか楽しいことになりそうだなー。

2ヶ月ぶりの山登り

先週の日曜日に約 2 ヶ月ぶりの山登りに行った。
こんなご時世なので山行中もできる限りマスク。
すれ違うときのあいさつもあいさつも控えめか黙礼に。
変に声を張り上げてこれみよがしなのよりも、
「わかってますよ」とスッと会釈してすれ違うのもなかなか粋。

↓ は YAMAP さんがブログへの埋め込みに対応したそうなので

切り取られてしまっているので元の写真もいっしょに

睡蓮

写真アップ用のサイト（Tumblr）を用意した

ここでやっても良かったんだけれど、
貼り付けての見やすさとかまとめなことを考えて
いつからぶりかの Tumblr を開始した。

https://nishisasa-photo.tumblr.com/post/617349801143566336

nishisasa-photo.tumblr.com

飽きるまではちょこちょこアップしていこう📷

はてなブログに Tumblr へアップした写真を表示する、
ブログパーツとかウィジェット探したけど
すぐに見つからなかったのでまたいつか。

デスクトップ（物理）を整えた

4月から基本的にテレワークな状態になったので、自分はあまりつかっていなかった机の上をカッコいい感じにしたいと思い始めていました。
そこでよく見ていたのが ↓

note.com

配置や配線は当たり前に、天板のオーダーから塗装、はては線を塗ったりとただならぬこだわり！こういうこだわり大好きです。

しかしながらさて自分も、とはなかなか行かない領域。
いろいろ考えて少し手を入れてみました。

まずはモニタアーム。
つい先日、長年の夢だったモニタアームを購入したのですが、なんと使っている机の張り出した部分が短すぎてがっちり固定できない問題が判明。どうしたものかと思っていたのですが、妙案を思いつきました。
……妙案というか引き出しを犠牲にする案です。
机を 180 度回転させ、本来正面となる向きを壁側に向けるのです。そして引き出した引き出しの中でモニタアームを固定し、さらにケーブル類やコンセント、電源系を引き出しの中に全部しまってしまう作戦。
こんな感じになりました。

ケーブル類がまとまるとそれだけでスッキリ見えていい感じに（個人の感想です）

あとはブックスタンドに PC を載せて、HHKB など機器類をもとに戻せば完成。

地味にブックスタンドに角度をつけるためにボール紙を挟んでいて、HHKB のケンブルはこの隙間から通しています。

これ以上は Magic Trackpad 2 に買い替えたり、モニタをベゼルレスな 4K に買い替えたり（そして 4K 対応として PC のスペックを上げたくなったり）、机を DIY して超気に入るものに替えたりとどうやってもお金がかかりまくってしまうのでひとまずここまで……。
机の上にマットを敷くのはやりたいかも。

山道具がおいてあったり鳥谷のポスターがあったり（写ってないところにカープグッズも多数）懐かしの CD が並んでいたりと、なかなかの雑然とした空間ができあがりました。満足。

API Gateway の HTTP API と Lambda を開発用・本番用のバージョン違いで接続する

めずらしく AWS ネタ。
けっこうどうやるんだ？ってなったので自分用のメモ。
要は API Gateway のステージとステージ変数を使って Lambda ファンクションのエイリアスを呼び分ける話。
「動的統合」というやつらしく IAM ロールは自分で用意・指定する必要があったところが（自分には）肝でした。

Lambda 側の準備

本番用と開発用とは Lambda の「バージョン」と「エイリアス」で表現する。なにも設定を変更してない状態だとバージョンは $LATEST だけ存在している。これを本番用の prod と開発用の dev に分ける。
現在の $LATEST バージョンをひとまず仮に本番用とするためバージョンを発行（作成）する。

まだ一度もバージョンを作成していないと、バージョン 1 が作られる。

次にエイリアスを作成する。
本番用は固定されたバージョンの 1 を利用して、開発用は常に最新の $LATEST を使うとした場合。

開発用なので dev としたエイリアスを、バージョンは $LATEST を見るように作成する。
同様に本番用として prod エイリアスをバージョン 1 を見るように作成する。

これで Lambda 側の準備は完了。

API Gateway 側の準備

用意した Lambda のエイリアスに対応する形で API Gateway に dev ステージを用意する。

ステージの名前は自由に。
ステージ変数の名前として「キー」に好きなものをつける。ここでは LambdaAlias。
ステージ変数の値には Lambda で作った開発用のエイリアスを同じ dev をつける。
（この「値」が API Gateway の呼び出す Lambda ファンクションのエイリアスとして使われることとなる。）

同じことをデフォルトのステージ $default でもおこない、「値」は prod にしておく。
（本番用にちゃんと区別したい場合はデフォルトのステージを使わず prod ステージを用意すると良いはず。）

あとは統合する Lambda ファンクションを arn で指定するときに、エイリアスを :エイリアス名 までつけて指定すれば OK。
arn + :エイリアス名 とするとそのエイリアスで Lambda ファンクションを指定できるそう。
arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxxxx:function:hogehoge:${stageVariables.LambdaAlias} こんな雰囲気。

「一致する Lambda 関数がありません」と出てくるけどちゃんと保存できます。

これで動くかなと思ったらそうではなくて、いまやっている「動的統合」の場合は「アクセス許可を呼び出す」のところを自動ではなく明示的に指定しないといけないそう。
自分はここから IAM 力の低さにつまづいてしまった……。
以下のページにもあるのだけれど、

動的統合を構築する場合、それに応じて権限を更新することも重要です。統合が単一のLambda関数を指す場合、HTTP APIは呼び出し権限を自動的に追加します。ただし、複数の関数を使用する場合は、ロールを手動で作成および管理する必要があります。これを行うには、Lambda関数オプションを呼び出すための[Grant API Gateway permission to invoke your Lambda function]をオフにし、適切な権限を持つカスタムロールを入力します。

高速、低コストで、より良いAPIの構築 – HTTP APIが利用可能（GA）になりました | Amazon Web Services ブログ

とのこと。
具体的にどんなロールを用意したらいいの？ってなったけど チュートリアル: 2 つの AWS のサービス統合と 1 つの Lambda 非プロキシ統合を使用して Calc REST API を作成する - Amazon API Gateway の内容に沿ってロール作成したものを使えばうまくいきました。

最終的にこういう状態に。

試す

ここまできたら API Gateway に本番用と開発用の 2 つのステージで URL が得られているはず。

• https://hogehogehoge/
• https://hogehogehoge/dev

上が本番用で下が開発用。
あとは API Gateway のルートに作成したパスをつなげれば本番用・開発用の使い分けができる。

もし API 実行して Internal Server error が帰ってきており、Lambda の実行ログが Cloud Watch にも無いようなら、API Gateway から Lambda を呼び出せていないので IAM まわりを確認する。 そうでなく Lambda の中でこけているなら通常どおり Cloud Watch でログを見て修正する。

シネスコレイアウト写真の3段重ね

人がしてるのをみてシネマスコープ（風？）に切り抜いたり撮ったりしてる写真たち、Instagramにアップすると16:9くらいに横が切れるなーと思ってた。

そんなところにこれまで使ってなかったInstagramの「レイアウト」で、縦か横に3段重ねにするとちょうど収まることに気がついた！

こんな感じ。  

見やすいかというと……？だけどたまには奇をてらった感じで良いかも📸

ネコ写真（荒地山）

荒地山を登ったときに見たネコたち。
しましまと茶色とふさふさの 3 匹いたみたい。

ずっとついてきてなにかをねだるネコ

ついてくる

ねだり鳴き

うらめしい

ロッククライミングネコ

しなやか

「理想」「現実」「方法」「実行」に分けてみた

スクラムで出てくる振り返りとプロセス改善について考えていると、「理想」と「現実」のどっちも認識してそのギャップを埋める「方法」を適切に見つけ出した上に「実行」できることを自然と求められていて、それは大変に困難なことなのではないだろうか……と思って書き始めた。そもそも「理想」「現実」「方法」「実行」に分けてどれだけ考えているだろうかなーと。

勉強会に行ったり本を読むことは「方法」を学ぶことなんだけれど、実はその「方法」を適用することで達成される「理想」の状態についても知ることができる。自分はこれがとても大切だと思っている。どんなことをするにも最善の状態を認識できていないと、いまできることに引っ張られてしまってどうしても妥協が強く出たアウトプットしか出なくなるから。「現実」からの積み上げだけだと最終的な結果が必要なものに届きにくいと感じているのもある。ゴールに「理想」をおいて、ゴールまでの道のりまでを一定の粒度や単位に分解して進めていく方が、最も短くブレなくゴールに着けるんじゃないかなーと。
一方で「現実」の方もきちんと理解しないといけないと思っている。状況が見えていないのに「理想」だけ追い求めてもそれは無謀というものになってしまう。できないことをいきなりやろうとしてもうまくいかないし、結果が求めていたものじゃないかもしれない。より効果的でより効率的な「方法」を選び取るには「現実」を理解しておかないといけないと思うから。

「理想」と「現実」のどちらも「方法」選択に重要な要素なんだけれども、ここがあいまいなまま「方法」を選択してしまうからうまくいかなかったり、手段が目的になっているなんて言われたりしてしまうのかもしれない。 ケースがたくさん出てきそう。

• アウトプットは出てもアウトカムじゃないってときなのかもしれない
• なにかを複数人で進めていると他人に対してどうしてそんなことしたの？と疑問に思うこともあるけど、きっと見ていた「理想」の程度や方向性が違っていたのかもしれないし、もしかするとそもそも「理想」像が見えていないのに無理をしていた・させていたのかもしれない。
• 視座の高さとか視野の広さっていうのは「理想」をどれだけ見れているのかってことなのかもしれない
• エンジニアなら勉強会に参加しよう、みたいなのは社外の大きな世界で高い「理想」に触れてほしいという思いからなのかもしれない
• キャリアパスってどう考えてる？なんて面談で聞かれるのは「理想」と「現実」をどう捉えていますか？という質問なのかもしれない

しれないしれない問答。思い当たるところがたくさん？

「実行」について……どんなに「理想」と「現実」から良い「方法」を見つけても「実行」されないと意味がないはず。なんだけれど、個人的にはコツコツやらないといけないここが難しい。どれだけ早く理解できてもやらなきゃなにもはじまらない。結果が見えた気になってるだけだとダメ……そう思って、意識してこれを書き始めたのかも。

はじめに戻ると、

「理想」と「現実」のどっちも認識してそのギャップを埋める「方法」を適切に見つけ出した上に「実行」できること。それは大変に困難なことなのではないだろうか

だから、きっと工夫の仕方や考え方のフレームワークという形で「方法」がたくさん別の名前で存在しているのだろう。けれどもそれはやはり「方法」でしかないので気をつけないといけないのかなって。

「理想」のところを目的とか 5W1H でいう Why のところに置き換えるとまた違ったことが考えられるかも？時間切れなのでまた考えてみようー

認定スクラムマスター（CSM）になった

認定スクラムマスター研修 を受けてテストも合格したので認定スクラムマスターになりました。だからといって完璧っていうものでもないので「俺たちの戦いはこれからだ！」ですね。日々精進あるのみ。

研修はだいたい 5 人チームが 6 つで進行、少し説明を受けてあとはチームで議論したりワークしたりを 2 日間みっちりやる感じでした。講師の方は車をモジュール化することで早いフィードバックと改善ができるようにした経験をお持ちの方。ハードウェアでもそういった進め方ができるのかと興味深く聞いていたけど、そういえば昔この人のプレゼン動画を見た記憶が……。最近では航空機、特に戦闘機の開発にもスクラムの考えが取り入れられているお話おもしろかったです。
1 日目の終わりに「ハッピーアワー」と称した会は英語日本語混じりにとても盛り上がった！素早いリリースができるようにしておく準備の重要さと同じくらい、英語のスピーキングが必要だと痛感……

ところで、これから仕事でスクラムマスターなことするのかというときっと否。
仕事ではいまのところマネージャーとして自社サービス事業の責任を持っています。人数も少ない小さなチームなので、役割はスクラムマスターかというとそうでもなく、（名刺にある）プロダクトオーナーかというとそうでもなく、何でもやる人。確かなのは利益に責任があること。
機会があれば別のチームや部署でスクラムマスターとして役割を持てると良いのかな。考えてみよう。

その他のその他

2019 年の振り返りで書いた

その他 いつも自分で改行を入れてみていたけど、スマートフォンなど横幅がせまい環境だと変に改行して逆に見づらいのかなとも思った。なので今回は改行を自分で入れずに段落な感じに書いてみた。どちらが読みやすいかあとで自分で確認してみよう。

↑これ、まあこれはこれで見やすいし書かれた「文章」って感じがしたので継続してみる……

2019年と2020年

わりと自分用の記録（？）と展望

2019年

毎年 1 回くらいはどこかで機会をつくって社外の場で登壇するようにしていたのだけれど、2019 年は 1 回も社外で話をすることが無かった。仕事での変化や事業のテコ入れなどいつもより多少考えることが大きかったのもあるけれど、生活の方での動きが大きかったのが一番の理由になりそう。

仕事の方では、会社ではじめて早数年のサービスのプロダクトオーナーを人に譲ってみて、半年後にまたプロダクトオーナーになった。プロダクトオーナーといっても役割定義にこだわっていられる状況でもないので、サービスの進む方向を決めたり予算管理もする一方で開発もすれば運用もするしインフラ構築整備もしながらプロモーションの管理をしつつ問い合わせ対応だってする感じ。こういう未分化なのが良くないのかもしれないけれど、状況をどう変えていくのが良いのかなーと思いつつ改善のために様々変化させつつ日々が過ぎていった……。結果を出したいなー。

生活の方では引っ越ししてみたり山登りを始めてみたり。夏からはじめた山登りは、まだハイキング程度のものだけれど今後も続けて体力・技術を上げていきたい。それにしても 2019 年はこの山登りをはじめたのが自分にとって一番大きな変化だったかもしれない。アウトドア趣味なんて親や親戚もほとんどなかったから、そもそもこれまでやったこともなくて学校行事で林間学校や野外活動するくらい。可能であればずっと家にいたいタイプなので、個人的には大事件。

山登りは YAMAP があるのも大きかった。自分の活動記録はこれ こういった形でログが取れるのも良いし、GPS を使ったスマートフォンでルーティングができるのも良い。こういうユーザーと直接接するサービスに関わってみたいなと思えた。ちなみに 2019 年 7 月から今日までで YAMAP に記録されたのは

• 距離 合計 81,572 m
• 標高 合計 5,447 m

らしい。

軌跡

摩耶山・六甲山がほとんどで、金剛山と加西アルプスが少し離れたところに。金剛山は標高 1,125 メートルで実際に登れるのはもう少し低いところまで、上り下りは 750 メートルくらいが最大なのでまだまだ……。

2020 年

仕事の方はいまの事業をなんとかしてみたいのが半分、そろそろなにか違うことを考えてみたいのが半分。後者はずっと言ってるのでどうしたものか。余り書くと会社であれなのでこの話を書くのはここまで。でも会社最適されすぎないように、自分の力が通用するのかはかるためにも、会社の外・別で仕事してみたいな。

生活の方は 2,000 メートル級の山に登ってみたいなーと思っている！雪がなくなるまでに近所の低山で体力（と技術）を上げておきたい。あと雪山を（登るのではなくて）歩いてみたい。

その他

いつも自分で改行を入れてみていたけど、スマートフォンなど横幅がせまい環境だと変に改行して逆に見づらいのかなとも思った。なので今回は改行を自分で入れずに段落な感じに書いてみた。どちらが読みやすいかあとで自分で確認してみよう。