ISAINA(イサイナ)が美味しい
ISAINAを飲んでみたんですが、美味しかったです。 値段もお手頃です。
全量芋焼酎「ISAINA(イサイナ)」新発売 | 宝酒造株式会社
概要: - 宝酒造株式会社は、2022年2月22日に新たな全量芋焼酎「ISAINA(イサイナ)」を新発売します。 - この焼酎は、飲み方によって香りが変わる新感覚の本格芋焼酎として紹介されています。 - 「炭酸割り」では、独自の「かおり酵母」によりリンゴを思わせるフルーティーな香りが特徴で、食中酒や洋食シーンに合わせるお酒として楽しめます。 - 一方で「ロック」では、焼き芋のような甘い香りが楽しめます。 - ボトルデザインも特徴的で、和食・洋食を問わず、テーブルを華やかに彩るデザインとなっています。 - 近年、香りの特徴を訴求する「香り系芋焼酎」の販売が伸びており、特に若年層に人気があるとのこと。
商品概要: - 商品名: 全量芋焼酎「ISAINA」 - 品目: 単式蒸留しょうちゅう(本格焼酎) - アルコール分: 25% - 原材料: さつまいも(九州産)、いも麹 - 容量: 900ml - 参考小売価格: 1,280円(税抜) - 発売日: 2022年2月22日
考察・質問: 1. 「ISAINA(イサイナ)」の香りが飲み方によって変わる点は、他の焼酎とどのように異なるのでしょうか? 2. 独自の「かおり酵母」はどのような特性を持っているのでしょうか? 3. 「香り系芋焼酎」が若年層に人気の理由は何でしょうか?
以上が、提供されたURLの内容の要約と考察です。何か他に質問や情報が必要であれば、お知らせください。
ISAINAは、宝酒造株式会社が2022年2月22日に発売した全量芋焼酎です[1]。以下は、ISAINAに関する詳細情報です。
Motorola moto g53j 5G 買い替えた
Motorola moto g53j 5Gに機種変更しました。
特徴や感想を書いてみます。
MOTO G53J 5G スマートフォンの主な特徴とレビュー
ディスプレイ: 6.5 インチの大画面ディスプレイを搭載しており、リフレッシュレートは120Hzです。これにより、5Gの大容量コンテンツを滑らかに楽しむことができ、目の疲れも軽減されます。
カメラ: 高性能な5,000万画素のデュアルカメラシステムを持っています。特に、クワッドピクセルテクノロジーを採用しており、低光量下でも高品質な写真や動画を撮影することができます。
音響: Dolby Atmos® とステレオスピーカーを搭載しており、多次元サウンドを体験することができます。また、大音量でも音が割れにくいスマートパワーアンプ機能も備えています。
バッテリー: 業界トップクラスの大容量5,000mAhバッテリーを搭載しており、一日中5Gコンテンツを楽しむことができます。
デザイン: エッジの立ったシャープなデザインで、持ちやすさとスタイリッシュな外観を兼ね備えています。また、指紋が付きにくい質感と、長く使えるカラーバリエーションが魅力です。
その他の機能: FeliCa & NFCに対応しており、おサイフケータイやワクチン接種証明書アプリ、マイナンバーカード、運転免許証などの読み取りも可能です。
価格: 34,800円(税込)
このスマートフォンは、高性能なカメラや大容量バッテリー、高品質な音響など、多くの魅力的な機能を持っています。価格も手頃で、コストパフォーマンスが高いと言えるでしょう。
公式だと、売り切れてるようです。
「デスマーチ」を読んだ
この本を読んだ理由
デスマーチの最中なので、どうすればよいのか知りたかった。
デスマーチとは
初めから失敗することがわかっているプロジェクト
公正かつ客観的にプロジェクトのリスク分析をした場合、失敗する確率が50%を超えるプロジェクト
なぜデスマーチは発生するのか
社内の政治
無謀なスケジュール(通常12ヶ月掛かると見込まれるものが、6ヶ月に短縮される)
予算(人員不足、人数は足りていても経験の無い人ばかり)
過度の要求(提供する機能が多すぎる、要求される性能が高い)
その他いろいろ
デスマーチを乗り切るにはどうすればよいのか
トリアージ(要求の優先順位付け)
クリティカルチェーンと制約条件(よくわからず使いこなせないのにデスマーチプロジェクトでやろうとすると失敗の要因になる)
スカンクワーク(会社の偉い人たちや部外者に邪魔されないように会社から隔離された場所で作業を行う)
そこそこ使えるソフトウェア(完璧ではないがそこそこ安く、速く、機能が充実していて、安定して使えるソフトウェア)
80:20の法則(ソフトウェア全体の内、使われる機能は20%であり、残りの80%はなくても困らない)
デスマーチプロジェクト(に限らず)の主な問題は、技術的な要因であることは少なく、人に起因するものであることが多い(ピープルウェア問題)。
ITプロジェクトを円滑に進めるためには、ピープルウェア指向アプローチで取り組む必要がある(プロジェクトの問題を解決してくれる銀の弾丸はない)。
交渉術の例が面白かった。
例) プロジェクトが9月1日ではなく、9月5日に完成するとしたら、9月2日に倒産を宣言するのですか?
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
- 作者: エドワード・ヨードン,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2006/05/03
- メディア: 単行本
- 購入: 9人 クリック: 355回
- この商品を含むブログ (118件) を見る
「イシューから始めよ」を読んだ
- 作者: 安宅和人
- 出版社/メーカー: 英治出版
- 発売日: 2010/11/24
- メディア: 単行本(ソフトカバー)
- 購入: 48人 クリック: 660回
- この商品を含むブログ (142件) を見る
知識労働における生産性を上げるためにはどうすれば良いかということについて書かれています。
生産性を上げるためには、今解決するべき問題(イシュー)は何かを見極めて、 そのイシューを解決することで可能になるとあります。
がむしゃらにタスクを消化した結果、疲弊してあまり成果が出てないとか感じている場合は、 なにかヒントが得られるんじゃないかと思います。
見積もりやスケジュール管理で参考になる記事10選を読んで
印象に残ったところ忘れない内にメモ。
工数見積もりやスケジュール管理で参考になる記事10選 | UX MILK
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
スケジュールと工数は一緒にしない。
工数3人日は、3日後に終わるわけではない(3日間全部、そのタスクに使えるわけじゃない)。
進捗率の図り方
- 0%(未着手), 25%(着手), 50%(動く), 75%(レビュー中), 100%(完了)
不安とストレスから解放される見積りとスケジュール方法 - Qiita
不確実性コーン
- プロジェクトが進むに連れて、工数見積もりのブレが少なくなっていく
- プロジェクト初期で60 ~ 160%のブレがある
- 詳細設計の段階で+10% ~ -5%くらい
スケジュールバッファ
- 実際には6ヶ月後に完了する予定だけど、1ヶ月はバッファとして5ヶ月後に完了としておく
フィーチャバッファ
- 作る機能を減らして工数を削る(必須の機能のみで完了とする)
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
理想時間と現実時間
- ソフトウェア開発は、オーバヘッドがつきもの
- 3日で終わるからといって、3日後に完了するスケジュール組むとやばい
- クックパッドのところでも記述されてる
- 3日で終わるからといって、3日後に完了するスケジュール組むとやばい
見積もりの解決策として、ポイントでつけるというのがわからないので本を読む。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本(ソフトカバー)
- 購入: 74人 クリック: 764回
- この商品を含むブログ (226件) を見る
開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | 開発手法・プロジェクト管理 | POSTD
あいまいな要件
- 実装に着手出来るほど仕様が固まってないために発生する手戻りによる遅れ
- 開発を始める前に機能について検討すること
- なぜ必要なのか、どんな機能なのか、どう使われるのか
- 開発を始める前に機能について検討すること
要件の変更
- タスクを開始するとすぐに変わる仕様
- プロトタイピングで仕様を固めて手戻りを減らす
- 仕様変更によりスケジュールが延びることを伝える
- マルチタスクはスピードが落ちる
- 同時に2つ以上のことをやらない
だいぶ開発者目線だと思う
「クリティカルチェーン」を読んだ
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
- 作者: エリヤフゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2003/10/31
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 142回
- この商品を含むブログ (118件) を見る
プロジェクトマネジメント本。
大学の講師がプロジェクトマネジメントについて授業をしていくなかで、 なぜプロジェクトは遅れるのかについて結論を導き出していくストーリーになっている。
TOC(Theory of Constraint)
制約条件。
ボトルネックを改善することで全体のスループット(生産性)を向上させることができるというもの。 逆にボトルネックを改善しなければ、他を改善したところで全体のスループットは向上しない。
例えば製品Xを作るとして、そのためにステップAとステップBを行わなければならない。
ステップAは完了するのに1時間かかり、ステップBは2時間かかるとする。
ステップの順序がA > BとするときにXが完成するのは3時間掛かる。
ステップAが先に完了して、ステップBに渡せる状態で開始しても全体では2時間掛かるわけなので、 全体の時間を短くする(スループットを上げる)ためには、ステップB(ボトルネック)を改善しなければいけない。
ステップBがボトルネックでなくなったならば今度はステップAがボトルネックになるので ステップAを改善するというサイクルを繰り返していく。
TOC
でプロジェクトのリードタイムを短くする。
クリティカルチェーン
プロジェクト開始時には非クリティカルパスだったパスが、 遅れて結果的にクリティカルパスよりも長くなってしまうことがあるためクリティカルパスになってしまう。
例えば、ステップの担当者が同じだけど開始時期が同じなのでどっちかを開始できない状況になり、 結果的にクリティカルパスよりも長くなってしまうとか(リソースのキャパシティを超えている状況)
クリティカルパスはステップの従属関係を見てリードタイムを決定しているため、 リソースの競合については考慮されてない。
クリティカルチェーンは、クリティカルパスにリソースの競合についての視点を加えたもの(?)。
プロジェクトの計画はクリティカルチェーンでやる。
「世界を動かすプロジェクトマネジメントの教科書」を読んだ
世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
- 作者: 佐藤知一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/09/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
プロジェクトマネジメントに関する本。
プロジェクトの定義から進め方まで解説していて、ストーリー形式で話が進んでいくので読みやすい。
マネジメント系はストーリー形式多い気がするんだけど結果が見えにくい分、状況をイメージしやすいようにする意図があるのかな
チャレンジのOS
本書のなかでプロジェクトを成功させるために必要なチャレンジのOS
という言葉を使っている。
OSというとコンピュータのOSを連想するけども、 プロジェクトマネジメントの観点でいうところ組織の習慣や体制のことを言い表している。
改善のためにツールを導入したところでOSがちゃんと機能してなければ意味がないというところかな
システムズアプローチ
チャンレンジのOSの1つ。
プロジェクトにとりかかる際に、 このプロジェクトはどういう作業(アクティビティ)で構成されているのか、 アクティビティの前後関係(クリティカルパス)はどうかを見ながら 計画(WBS)を作成していく。
ここでアクティビティに抜け漏れがあると、手戻りが発生してダメージ大きいのでしっかりやっておかないといけない
各アクティビティ毎に見積もり工数を載せてプロジェクト全体のスケジュールを出す方法なども紹介されている。
プロジェクトの実行フェーズだけでなく、
まずプロジェクトとは何か
やなぜやるのか
といったところにも触れている。
プロジェクトマネジメントのスキルは、 経験を積むことで得られる属人的なものだと思っていたけど技術なんだなと感じた。
行き当たりばったりで作業をやってしまうことが多いので、 作業の洗い出しとクリティカルパスを意識しないといけないな。
WBSは、作るの面倒だからツールで運用して行けたら良い。