Try T.M Engineer Blog

多摩市で生息するエンジニアが「アウトプットする事は大事だ」と思って始めたブログ

イトーヨーカドー内にある「ポッポ」のたこ焼き器が最先端だった件

イトーヨーカドー内で、ラーメン、ポテト、たこ焼き、焼きそば、チャーハン等が食べられるファストフードショップ「ポッポ」
ちょっとした待ち時間や空腹時に食べたくなるあの味。そして、時々出てくる新商品がとても魅力です。

www.7fs-poppo.jp

そんな「ポッポ」で驚きの新発見があったので記事にしてみました。

今日も、いつもの様にイトーヨーカドーに買い物に来ていたのですが、ふと「ポッポ」の新商品に目がいってしまいました。新商品は「New てりマヨたこ焼き」

私は、関西出身という事もあり、たこ焼きが大好きです。
照り焼き味も大好きです。
私は迷う事無く「てりマヨたこ焼き」を注文しました。

すると、店員さんが「10分程、御時間かかるけどいいですか?」と聞いてきました。
ちょうど、たこ焼きのストックが無くなったところだったのか、別の店員が作り始めていたので、私は「構いません。」と答えました。

待ち時間の間、私は「ポッポ」で、たこ焼きが作られる過程をじっと見ていました。
そこで、私は「ポッポ」のたこ焼きの作り方が、最先端だった事に気付いてしまいました。

最先端のたこ焼き器


たこ焼きを作る時、具材を手で入れ、串でたこ焼きをひっくり返す。私はそれが普通だと思っていました。しかし、「ポッポ」は違いました。

自動たこ焼き機 スーパーたこまるこ | たこ焼き道具 | 藤田道具

な、なんだこれは!自動転がし式のたこ焼き器。初めて見ました。
何が凄いのか… ポイントを纏めてみました。

  1. たこ焼きを自動で転がして焼いていく「自動転がし式」
  2. 1列が1船分(8個)でたこ焼きの残数判断が容易
  3. オプションの「セットホッパー/スーパーフッ素樹脂鉄板(交換用)」で、全たこ穴に瞬時具材投入可能

1. たこ焼きを自動で転がして焼いていく「自動転がし式」


「自動転がし式」初めて見ました。
調べてみると、楽天等で個人でそれっぽいのが買えるみたいですね。

item.rakuten.co.jp

YouTube等の動画でも見ましたが、たこ焼きの完全な自動転がしはまだ難しい模様。
でも、こういった試みはとても面白いと思ったので、技術の進化に期待です。

2. 1列が1船分(8個)でたこ焼きの残数判断が容易


そうですよね。1船(8個)なんですよね。
たこ焼き器には、色々な形がありますが、1船分に合わせた1列8個or6個がベストなんですよね。

3. オプションの「セットホッパー/スーパーフッ素樹脂鉄板(交換用)」で、全たこ穴に瞬時具材投入可能


まさに神具!
たこを焼いている合間に、次の具材をセットできるのが魅力です。
このオプションは絶対買いだと思いました。

最後に


ずらずら書きましたが、この『どうすれば、楽してたこ焼きが焼けるのか』という課題に対して、追求して生まれた商品はとても凄いと思いましたし、たこ焼きに対する情熱を感じました。
今後とも、「ポッポ」と二人三脚でたこ焼き器の発展に期待したいと思います。

プロジェクトで使われるマネジメントの種類について

今回は、プロジェクトで使われるマネジメントの種類について、語りたいと思います。
マネジメント全体について語りだすと文章が纏まらなかったので、まずは「種類」について語りたいと思います。

自分の立ち位置について

マネジメントの話は、個人の経験、裁量によって話す内容が大きく違うと思うので、事前に私の経歴を少し書いておきます。
私は東証一部上場企業の客先常駐のSEです。
大学卒業後、約10年をこの会社で過ごしてきて、プロジェクトでリーダーと呼ばれる仕事を約5年程続けており、今もリーダーの立場でマネジメントの仕事をしています。

プロジェクトで使われるマネジメントの種類について

さて、今回はプロジェクトで使われるマネジメントの種類について語りたいと思います。会社のマネジメントとかは話しません。自分が経験、見てきたプロジェクトで使われるマネジメントの種類について語りたいと思います。
いきなりですが、種類はこんな感じだと思います。

 1. セルフマネジメント
 2. リーダー(チーム)マネジメント
  2-1. 専任マネジメント
  2-2. プレイングマネジメント
 番外編. スリーピングマネジメント

1.セルフマネジメント


英語で書くと「self management」です。セルフなので自分自身をマネジメントする人を「セルフマネジメント」と呼びます。
「セルフマネジメント」で使われる主なスキルは以下の2つで、このスキルを使いこなせる人が、次の「リーダー(チーム)マネジメント」へと進化させられます。(強制)

・タスクばらし ・・・ 作業を自分の裁量でばらして複数のタスクに置き換えること。
・優先順位付け ・・・ "タスクばらし"によって置き換えられたタスクの優先順位付けを行うこと。

2.リーダー(チーム)マネジメント


1.の「セルフマネジメント」をチーム、プロジェクトまで範囲を広げて行う事を「リーダー(チーム)マネジメント」と呼びます。「セルフマネジメント」で使われる2つのスキルの使用範囲を、作業⇒プロジェクト、自分自身⇒チームへと広げてマネジメントを行います。ただ、やっている事はセルフ時代から大きく変わらないので、2つのスキルをより使いこなす事が重要になります。

あと、リーダー(チーム)としての付加価値をどこまで付けるかも重要になります。
付加価値とは、「リーダー(チーム)としての作業効率の向上」「チームメンバーの育成」「チームメンバー内での情報共有」・・・etc です。
この付加価値をどこまで付けれるのかが、リーダーとしてのミッションなのだと私は思います。

2-1.専任マネジメント


2.リーダー(チーム)マネジメントの中でもリーダー(チーム)マネジメントを専任で行う人の事です。
大規模のプロジェクトでは、管理するメンバーが多いため、専任マネジメントとなる事が多いです。プロジェクト単位で要員管理、工数管理、進捗管理を行い、社内と顧客への報告を行ったり、時には営業として顧客から仕事獲得に向けて行動します。

2-2.プレイングマネジメント


2.リーダー(チーム)マネジメントの中でもリーダー(チーム)マネジメントを専任でしない人の事です。
手を動かしながらマネジメント業務を片手間に行います。小規模のプロジェクトでは、管理するメンバーが少ないため、プロジェクトのマネジメント負荷が少ないので片手間でマネジメントを行います。片手間といっても専任と同様で、要員管理、工数管理、進捗管理を行い、社内と顧客への報告を行ったり、時には営業として顧客から仕事獲得に向けて行動します。

専任とプレイングマネジメントの使い分けが重要では?


2-1.専任マネジメントと2-2.プレイングマネジメントは、プロジェクトの規模によって使い分けるのが重要です。しかし、私はこの使い分けができていない企業を多く見てきました。個人的な意見ですが、余程大きなプロジェクトで無い限りは専任にはならない or 使わない方が良いと私は思います。というのも、専任となる事でマネジメントの経験や実績は上がりますが、それだけ手を動かす機会が減るため、業務や開発知識が停滞します。これは実際に経験した事ですが、手を動かす仕事しか無い時に、人材として社内に専任マネジメントが余っていたので本来プロジェクトにプログラマーを入れるべきところ、専任マネジメントを無理矢理入れて炎上したプロジェクトもありました。別に専任マネジメントを否定するわけではありませんが、企業は専任とプレイングマネジメントの比率を考えるべきです。こうなってしまうのも、多くのIT系企業は、プログラマーからマネジメントになることが昇進と考えているからです。そうではなく、マネジメント⇒プログラマープログラマー⇒マネジメントへもう少し柔軟にできるようにすべきだと私は思います。

熱くなってしまいましたが、要は「リーダー(チーム)マネジメントになってもプログラマーとしての心を忘れずに開発知識を日々学んでいきましょう。」というのが、私の言いたい事です。
(10年間SEという名の『何でも屋』を続けてきて、技術力が全く無く後悔している人より...)

忘れてました・・・番外編です。
こんな人にはならないようにしましょう。本当に実在するから世の中怖い・・・

番外編. スリーピングマネジメント


2-1.専任マネジメントの進化系。寝てるだけで仕事がまわる不思議なマネジメントで、規模の小さいプロジェクトで専任マネジメントを入れると、周りのリーダークラスだけで業務が回ってしまい、専任マネジメントはやることが無くなってしまう現象が発生する。(誤解が無いように言うと、専任マネジメントスキルが低いと、付加価値を付けれられないため、やる事が無くなってしまいスリーピングマネジメントになってしまうもの)

仕事をしていると、たまにこんな人もいるので気をつけましょう。

プロを目指す人のためのRuby入門を読んでみて

やっと、読み終わりました。(思ったよりも時間が掛かってしまいました...)
私がエンジニアとして尊敬している伊藤淳一さんが書かれたRuby本(チェリー本)です。

いやぁ、勉強になりました。
伊藤淳一さん、こんな素晴らしい本を世に生み出してくれてありがとうございます。

私自身、プログラミングのプの字程度の知識しかないエンジニア(if/for/while文,関数,変数がわかる程度)なんですけど、凄く勉強になりました。
今までJavaやCの言語しかやってこなかった人間としては、Rubyには驚かされる事ばかりでした。

特に驚きを感じたのは、動的型付け言語であること。
変数宣言時にStringやint等の宣言がいらないのは「マジか!」って思いました。

次に、Rubyのコードの書き方は1つではなく、様々な書き方ができること。
「いや、自由過ぎるでしょ!他人の書いたコード読む時大変なんじゃないの?」と思いました。

他にも、Rubyには驚かされる事ばかりでしたが、そんな言語に対して著者はなんて分かりやすく説明しているんだ。そう感じた技術本でした。

読者レベルについて

さて、上記にも述べましたが、私はプログラミングのプの字程度しか分からないエンジニアです。
著者のブログは以前から読ませて頂いており、Rubyについて書かれた記事が多かったので、個人的にRubyとはどの様な言語なのかをネットで調べていた時期がありました。
そのため、Rubyに対しての知識はゼロではなく、少しだけ前知識はありました。
そんな私がこの本を読んでみた感想を大きく3つにピックアップして書きたいと思います。

1.まるでカンファレンスで説明を受けているような錯覚に!

本書は読者を大変意識して書かれているため、読んでいてカンファレンスで説明を受けているような錯覚になります。
また、読んでいて気になる点があれば「こちらについては、後で説明するよ」「こんな書き方もできるけど一般的じゃないよ」等、必ずといっていいほどフォローや著者の意見が文章の中に混ぜ込まれています。なので、読者としては常に安心して読むことができるそんな本になっています。

2.Rubyのバージョンを意識!

本書はRubyのバージョンについても、意識して書かれています。
これは私が実際に経験した話ですが、Rubyについて独学で、しかもネットにある情報だけで勉強していると「あれ?あの記事にはコードがこう書いてあったのに、この記事では書いてない or 違うぞ? 」と、何度も思う事が何度もありました。この本を読んで「ああっ、バージョンの違いだったのか‥」と疑問がスッキリ解消しました。
ネットにアップされている情報は、バージョンまで意識して書いてる人といない人がいるので、今後、ネットにアップされているコードを読む時にも、本書は非常に役に立つと思います。

3.ブログとQiitaとの連携で、ボリュームは本書以上 !

私は最近、技術本を手にする機会がなかった人なので、もしかしたら他の技術本でもやられているかもしれませんが、本とSNSの連携には驚かされました。
本書では、本書を読むための前提となる知識や捕捉事項を著者のブログやQiitaで説明しています。そのため、この本を買えば本以上のボリュームの知識を得ることができます。こんな事ができるのも、著者が普段から技術についてブログやQiitaでアウトプットをしているからなんだと思います。いやぁホント凄い人だなぁと思いました。

と、私の感想は以上です。
本当なら、もう少しプログラミングについて突っ込んだ感想が言えればいいのですが、何分知識不足なものなので、今後精進していきたいと思います。m(__)m

最後に

本書はRubyを学ぶ上で、購入すべき1冊の候補に入ると思います。(本書の内容、ボリューム的にも)
私のような、プログラミングのプの字しか知らない人でもRubyを学習するなら十分おすすめできる1冊です。
今後ですが、ぶっちゃけ本書1回読み終えた程度では、プログラミングのプから卒業は難しいと感じたので、もう2回くらいは読みたいと思います。
その上で、次はRuby on Rilesにも挑戦したいと思います。

2018年の抱負について

今週のお題「2018年の抱負」

明けましておめでとうございます。

昨年を振り返ると、書いたブログ記事は8つ。
う〜ん、ブログの更新頻度が2ヵ月に1回のペースというのは、自分自身が十分なアウトプットができていない証拠ですね。
個人的に「計画性がない、時間が思うように確保できない」といったところに問題がありそうな気がします。(トホホ・・・)

本年度は「計画性を持って時間を確保して、もう少し更新頻度を増やせたらいいな。」と思います。
というわけで、今年の抱負(目標)をざっくり箇条書きにしてみましょう。

 1) JavaRubyの勉強をする。
 2) ブログ更新頻度を増やす。
 3) TodoistやGoogleカレンダー等のツールを使って計画性を持つ。
 4) 少し運動量を増やす。

ふむ、こんな感じかな。
纏めてみると、以下の様な感じ。

今年(2018年)の抱負:
「事前に計画を立て、勉強や運動、ブログの更新時間を確保し、実行すること!!」

う、う〜ん、なんかそれっぽいのができました。
しかし、今までダラダラと生きてきた自分にできるのか、まったくもってわかりませんが、努力目標でがんばりたいと思います。

というわけで、本年度もどうぞ宜しくお願い致します。

プロを目指す人のためのRuby入門を読む(道中)

私がブログをやろうと思った「きっかけ」の人でもあり,エンジニアとしても尊敬している伊藤 淳一さんがRubyの本を出されたとの事なので,さっそく買ってきました.

f:id:special-moucom:20171204011014j:plain

ぶ,分厚い… 本書のタイトルは「プロを目指す人のためのRuby入門」です.
タイトルの通り,ただの入門書ではありません.「プロを目指す人のための…」とあります.

本書にも入門書の扱いではなく「今までほかの言語をやっていたが、これからRubyを始めてみたい人」や「Rubyプログラミングを始めてしばらく経ったが、まだまだ自身が持てない人」を想定して書いているとあります.

また,本書は以下に該当する人にとって,大変お勧めできる本とのこと.
試しにチェックしてみました.

Q1. すでにほかのプログラミング言語で3年以上の開発経験がある。
  もしくは「プログラミング歴=Ruby歴」で、 Rubyを始めてから
  半年以上経っている。(Yes/No)
  ⇒Yes.
Q2. Rubyを学習する動機はRailsアプリケーションの開発に役立てるためだ。(Yes/No)
  ⇒No. だが、Railsはいつかやってみたい。
Q3. すでに仕事でRubyを使っている。もしくはこれからRubyを使った
  仕事に就こうとしている。(Yes/No)
  ⇒No.
Q4. 単純に伊藤 淳一さんが書いた本に興味があり、読んでみたいと思う(Yes/No)
  ⇒Yes.

結果,私が該当したのはQ1だけでした.
ちなみに,Q4は私が勝手に作りました.

「オイオイ!」と思う方もいるかもしれませんが,実は私がQ4を追加したのは深い意味があるのです.

その意味について答えたいと思いますが,その前に何故,私が伊藤 淳一さん(以降,伊藤さん)を尊敬しているのか.
その理由を以下3つに纏めてみました.

 1. 考え方に共感できる.
 2. 自己表現が上手く,技術記事が大変わかりやすい.
 3. 将来の星である.

  1. 考え方に共感できる.
    伊藤さんは良くブログで,「〜した方が良いですよ. 僕も〜していました.」と 自身の経験談を交えて説得力のある話を書いてくれるので,人生の先輩として大変勉強になりますし,共感もできます.

  2. 自己表現が上手く,技術記事が大変わかりやすい.
    私はアウトプットや説明が下手なので、大変参考にさせて頂いています. Vim正規表現Rubyは、伊藤さんの記事を読んで学びました.他にもRuby on RailsGitHub、Heroku、Markdown等も名前を知ったのは伊藤さんの記事からじゃないでしょうか…
    本当にお世話になっています.

  3. 将来の星である.
    驚く事に,伊藤さんは私よりも年齢が上で,自分の年齢より上の方で,これだけ活躍できるのかと驚かされます. これは私の環境にも関係しますが,年齢が30 or 40代の方で身近に「憧れの人」「将来この人の様になりたいと思える人」が皆無なんですよね. 私は仕事をする上で,こういった「憧れの人」,「将来この人の様になりたいと思える人」が身近にいる事が,自身のモチベーションを高め,成長にも繋がると考えています. しかし,身近にいないとなるとネットで探すしかないですよね.

色々書きましたが,1〜3を要約すれば,「自分の不得意な分野の中での人生の先輩であり,憧れの人である」というのが,私から見た伊藤さんの立ち位置ではないでしょうか.
しかし、あくまでネット上にある情報だけで判断した感想です.かなり妄想が入っているので,「ああ...尊敬しているんだなぁ,ふーん...」くらいの気持ちで流して貰えると助かります.

さて,その上でのQ4の意味を答えましょう.

Rubyを学びつつ,伊藤さんのわかりやすい文書の書き方,説明や表現方法を学びたい.(Yes/No)」

当然,Yes.です.そのために,購入しました.
書評は次回の記事で書こうと思います.なんせ分厚いので,今やっと8章突入したところです(涙)