最近、業務でスクラムをはじめて本格的にやる経験がありました。なんちゃってスクラムをやったことはあったのですが、レトロスペクティブとかやってこなかったので、この本を読んで気になった箇所を書いておきます。 見積もりスプリントプランニングで見積もりする際は、例えばプランニングポーカーでみんなの想定を確認することがあります。なんとなくやっていましたが、これは想定が違ったりする場合にみんなで話し合い認識を合わせるという効果があると書かれていました。これは意味がありそうだなと思います。 デイリースクラム毎日行うデイリースクラムは進捗報告会ではなく、問題を見つける場であると書かれていました。ともすれば「昨日は～～をやって、今日は～～をやる予定です。問題は起きてません」みたいな報告だけをすることになってしまいます。そうではなく、問題があれば共有してみんなで解決していく必要があると思いました。 また、タイムボックスを守ることも大切とありました。実際にやってみると、相談事などがあって時間を守れないことも多かったです。そういう中でも時間を守れるのが実力が高いチームと書かれており、納得しました。 まとめスクラ ...

自分は仕事やプライベートでも考えすぎて、行動に移すのが遅いと感じることがあります。例えば、部屋のものが散らかってきたからラックを買ったほうがいいなと思っても先送りしてしまうなど。 ラックを買って整理した方が部屋がきれいになって生活しやすくなるのは分かっているんですが、家具を選ぶのに時間がかかったり、そもそも選びもしなかったり。頭で分かっていても行動できないことが多いです。また、別のときは分からないことを自分でとことん調べたりしてしまいます。Googleで検索しても前提知識が少なくてよく分からなかったりするのでとても時間がかかってしまい、これなら先に知ってる人に聞いておけばよかったとなることも。 こうなってしまう原因はいくつかありますが、ひとつは完璧主義かなと思います。自分ひとりで100%正しいものを作ろうとがんばってしまっている感じです。他の人と協力したり、質問したりすればいいのにそれができないか、できても遅くなってしまっている状態です。もうひとつは、コミュニケーション能力不足だと感じています。自分の困りごとを言語化できないか、できても相手に伝わらないから、それなら自分でがんばろうとな ...

日々プログラムを書く仕事をしていると、「なんかこのコードは読みにくいな」と理解に時間がかかるコードもあれば、「あー、こういうことね！」とすぐに内容がわかるものもあります。それは単純に自分が知らないプログラミング言語や業務知識を必要とするものだから時間がかかるのか、はたまた以前に自分が書いたコードと似ているからもしくは簡単な処理しかしていないからなのでしょうか。 本書は「コードを読む」という、あまり焦点があてられてこなかったプログラミングの領域に、認知科学からアプローチする内容になっています。 3つの混乱コードを読むときによく理解できない原因として、知識不足、情報不足、処理能力不足が挙げられています。 知識不足はそのプログラミング言語の知識がなく構文がわからないというようなときです。また、その言語自体はよく知っているが、処理内容が別の場所に書いてあり内容がよくわからないといった場合は情報不足に当てはまります。処理能力不足はfor文でループさせながら変数の値を変化させる場合などに、頭の中で変数の値を考えながらコードを読む必要があり頭がパンクしてしまうといった場合です。 混乱の原因これら3つ ...

よく読んでいる連載「仕事が「つまんない」ままでいいの？」で、「「生涯エンジニアでいたい」は、本当の理想なのか？」という記事が更新されていました。記事を書かれたのは昔エンジニアで、今はNPO法人を経営するなどエンジニア以外の仕事をされている竹内さんという方です。 ご自身は若い頃何となく「生涯エンジニアでいたい」と考えていたそうですが、現在は明確なビジョンを持っておられるそうです。ビジョンを持つために必要なことは記事を見ていただくとして、「社会課題と自分の技術を結びつける」ということを書かれていました。そこで、自分がやってきたことを振り返って書いておこうと思います。 小学生向けイベント実施団体のWebサイト作成実施内容小学生の保護者の方数名が活動されており、休日に小学生向けにさまざまなイベントを開催されていました。1枚ものページしかなかったホームページを、私がWordPressでデザインも含めて作成しました。既存のプラグインでは対応できない箇所は、自作しました。イベントの告知や過去の内容を閲覧できるようになりました。 解決した社会課題貧困な家庭が見えづらくなる中、小学校でさまざまなイベント ...

Visual Studio Codeで開発をする中で、Markdownを書くことも多いと思います。画面分割してプレビューを見ながら書けるので私もよく使います。そんな中でMarkdownに簡単に画像を挿入する方法を紹介したいと思います。 画像ファイルから挿入画像ファイルをMarkdonwに挿入する場合は、ファイルをドラッグ＆ドロップしながらShiftキーを押します。 スクリーンショットから挿入スクリーンショット（クリップボード）から挿入する場合は、Ctrl+Vで挿入できます。 画像の格納場所の指定方法デフォルトでは画像はMarkdownと同一階層に保存されます。任意の場所に保存したい場合は、markdown.copyFiles.destination設定を変更します。 例えば、source/doc/配下のMarkdownに画像を挿入した場合は、source/images/に画像ファイルを保存したい場合は次のように設定します。 項目：/source/**/** 値：../images/ Markdownファイル名などに応じて画像ファイル名を変更することも可能です。詳しくは、公式ドキ ...

FlutterでRiverpodを使った状態管理をする方法をまとめます。 目的アプリ全体で共有したいデータを管理する方法としてRiverpodを利用します。 Riverpodのインストールまず、Riverpodをインストールします。主に2種類あり、flutter_hooksを利用しない場合はflutter_riverpodを、利用する場合はhooks_riverpodをインストールします。 1234567dependencies: # flutter_riverpod flutter_riverpod: ^2.4.3 # hooks_riverpodの場合 hooks_riverpod: ^2.4.3 flutter_hooks: ^0.20.2 flutter_riverpod hooks_riverpod flutter_hooks アプリ全体で状態管理Riverpodで状態管理するために、アプリ全体をProviderScopeウィジェットで囲みます。 1234567import 'package:hooks_riverpod/hooks_riverpo ...

リモートワークで Slack や Teams など、チャットでのテキストコミュニケーションが増えてきました。同じテキストによるやりとりでもメールとは違って気軽に送ることができます。 他の人が送っている内容を見ていると、自分が送っているものよりも堅苦しくなく気持ちよく読むことができました。違うことはわかったのですが、どうすればそんなふうにかけるのかよくわかっていませんでした。 そこで「テキストコミュニケーション力の基本」（日本実業出版社）を読んでみたので、感想を書いておきます。 感想この本は見開きで 2 ページでテキストコミュニケーションのルールが説明されています。悪い例とその改善例が示されており、「こうすればよかったのか！」ということがよくわかりました。 例えば、「相手に確認をお願いするとき」という例では次のように 2 つの例が示されています。 悪い：企画書をお送りします。ご確認ください。 よい：企画書をお送りします。お手隙のときにご確認いただけると幸いです。 P.66 rule.20 相手に都合がある。伝えるタイミングを考える 忙しいときにチャットが来ても、これならイラッとす ...

最近、PM やリーダーとして、システム開発プロジェクト全体を俯瞰して把握する必要が出てきました。「Google のソフトウェアエンジニアリング」（オライリー）を読んだので、気になったところをまとめておきます。 本書は 25 章からなる分厚い本かつ全部は読んでいないので、ここで書くのはほんの一部になります。 チームリーダー入門アンチパターン：全員の友人になる 友情を、人当たりよくチームを率いることと混同してはならない。（中略）自分のチームと親しい友人関係（あるいは途方もなく強面）にならずとも、チームを率いて合意形成できるということを、覚えておいてほしい。 P.109 5.4.4 アンチパターン：全員の友人になる 正直自分は人間関係が得意でなく、一定の距離を持って接するタイプです。例えば一緒に昼食をとるなどしてメンバーとつながりを持ちつつも、仲良くなればなるほど良いというわけでもないというのは、それができそうにない自分は少し安心でした。 建設的パターン：エゴを捨てよ リーダーシップの役職に就いたばかりの者のほとんどは、全てをうまくやり、全てを知り、全てに答えを用意するという途方もない ...

Next.js 13 より、App Router が使われるようになりました。基礎的な使い方をまとめます。 対象環境 Next.js 13 App Router の基礎ページ URL: https://example.com/about 123app └ about └ page.tsx ページは URL に表示したい名前でディレクトリを作成して、その中にpage.tsxという名前でファイルを作れば OK です。 ローディング1234app └ about ├ page.tsx └ loading.tsx loading.tsxをpage.tsxと同一階層に置いておくと、読み込み中だけloading.tsxの内容を表示してくれます。 Not Found12app └ not-found.tsx 存在しない URL にアクセスすると、not-found.tsxの内容が表示されます。 まとめApp Router はローディングや Not Found ページを簡単に表示できるので使っていきたいと思います。

この本は、2021 年 2 月から 2022 年 2 月にかけてみずほ銀行で連続して発生したシステム障害の検証報告書となっています。みずほ銀行では、この間合計 11 回の障害が発生しました。 これらの障害の原因は DB 障害や HDD 故障など様々ですが、その「真因」は企業風土にあるのではないかと金融庁に指摘されたそうです。具体的には「システムに係るリスクと専門性の軽視」や「言うべきことを言わない、言われたことだけしかしない姿勢」があると書かれています。実際、開発から運用フェーズに移ってから人員削減をしたり、障害が発生しても部門間の連携が取れていなかったりしたとのことです。 感想みずほ銀行の障害はニュースでもよく取り上げられていたため、原因が気になっていました。さすがに銀行の勘定系のような大きなシステムでは、いろいろ考慮しないといけないんだなと思いました。ただ、原因を探っていくと大元は企業風土にあるということで少し意外でした。自分の日々の業務では、チームワークなどに関係するのかと思います。 書籍 ポストモーテム みずほ銀行システム障害 事後検証報告 出版社のページ Amazon