ニートが怖くて生きていけるか

読者です 読者をやめる 読者になる 読者になる

ニートが怖くて生きていけるか

年収780万を捨てて我が道をゆく

WPFのUnityContainerでシングルトン管理する方法。PrismのModuleで使うかも

元プロの社畜 @nabeemichi です。

WPFって何状態から3週間ほど経過して、そこそこアプリの規模も大きくなってきた。

開発し始めたときから、DIコンテナとしてUnityを利用していたのだが、

シングルトンでインスタンス管理したい場面と出くわしてので、メモとして記録しておく。

シングルトンとしてコンテナ内で管理する方法

IUnityContainerでRegisterTypeするときに、ContainerControlledLifetimeManagerを渡してあげるとシングルトンとして管理される

using Microsoft.Practices.Unity;
using Prism.Modularity;

    public class HogeModule : IModule
    {

        [Dependency]
        public IUnityContainer Container { private get; set; }

        
        public void Initialize()
        {
            // シングルトン化するためにライフタイムマネージャーを渡す
            Container
                .RegisterType<IHoge, Hoge>(new  ContainerControlledLifetimeManager());
        }
    }

PrismライブラリのModuleを利用して、実装している場合に[Dependency]でインジェクションしたいクラスをコンテナに登録する場合などに利用する。

RegisterTypeでContainerControlledLifetimeManagerを渡さない場合は、[Dependency]でインジェクションするたびにインスタンスが生成される。

実験方法

シングルトン管理対象クラスにコンストラクタを作成する。

今回の場合はHogeクラスにコンストラクタを実装する。

public class Hoge : IHoge
{
     public Hoge {
        Console.Write("hoge");
     }
}

このコンストラクタ部分にブレークポイントおいたりしてテストすると、コンストラクタが一回しか呼ばれないことで確認できる。

このHogeクラスをインジェクションするクラスを2つ作成

using Microsoft.Practices.Unity;
public class Foo : IFoo
{
        [Dependency]
        public IHoge Hoge { private get; set; }

}
using Microsoft.Practices.Unity;
public class Zoo : IZoo
{
        [Dependency]
        public IHoge Hoge { private get; set; }

}

こいつらを適当にインスタンス化するとテストできる。

ちなみにHogeModuleクラスで

Container
       .RegisterType<IHoge, Hoge>(new  ContainerControlledLifetimeManager());

この部分を

Container
       .RegisterType<IHoge, Hoge>();

こう変えると、ブレークポイントでHogeクラスのコンストラクタが2回よばれることを確認できる。

ググることは思考停止をもたらす理由。いいことだけじゃないデメリットもちゃんとある

f:id:hrmch-ioii:20170426004531j:plain

元プロの社畜 @nabeemichi です。

最近、全く知らないプログラミング言語をやってて、

ググりまくってるんだけど、やっぱりググるってことはいいことだけじゃない。

いいことがあれば、かならず同じくらい悪いことだってある。

ググれるようになった世界は素晴らしいけど、でもやっぱり大きなデメリットがある。

検索しているってことは、答えを探しているだけ。考えて答えを導くわけじゃない。

ググるってことは、検索するってことなんだけど

検索するってことは、基本的に頭を使わなくてもできちゃう。

キーワードを考えるのに少し頭を使うこともあるけれど、

知りたいことをワード区切りにして検索すれば、基本的には答えにたどり着く。

グーグルはすごいから、ほとんどの答えは検索で見つかる。考えなくてもいい世界

最近は全くやったことないことやってる。

全くやったことなから、一日中ググってるだけの日とかあるのだ。

ググってると聴いたことない単語がどんどん出てくる。

どんどん出てくるからググり続ける。

これで答え見つけちゃったときは要注意。

何も考えてない証拠だ。


何も知らない単語から答えにたどり着くまでの過程

最近は全く触ったこともない言語のC#、WPFとPrismっていうライブラリ使ってWindowsアプリ作ってる。

何もわからない僕は、「WPFとは」とかでググり始める。

そうすると、だいたいMVVMって単語が出てき始める。

次は「MVVM」で検索し始める。

そうするとWPFはMVVMをサポートしきれてない中途半端野郎だから、MVVMをサポートしてくれるPrism入れたほうがいい

みたいな情報を得ることができる。

次は「WPF Prism」で検索だ。

そうすると、Prism使うとMVVMで実装できるしいい感じになるよってことになる。

となると、次の検索は「WPF Prism サンプル」になる。

で、サンプルに行き着くと、

だいたいアプリ作れる状態になる。

もはや、サンプルを改造して自分の作りたいアプリ作れば、正直動くアプリが完成する。

こうやって調べてしまうと、呪文のようにサンプルを真似してるだけ状態。


ここまでで、一番問題なのが考えてないってこと。

わからない単語を次々調べていったら、アプリがつくれる状態になってしまってる。

サンプルというテンプレートを手に入れたら、こうゆうふうにすればいい感じに動くのね!

って言う状態で、ほとんどの人は止まってしまう。

だって結果出てるからね。

それでなんとかなるしね。

ググるは答え合わせするために使う

思考ってのは、

こうなってるかもしれない。だからこのはずだ

ってのが基本だと思う。

まず、分からないことがあったら速攻調べるのじゃなくて、

こうかもしれない!

と考えてから答えをあわせる為にググると、

なんかよくわからないけど、調べてたらわかった状態じゃなくて、

理解して自分で導いた答えを出せるようになる。

ググりまくってるだけだと、勝手に答えがわかって、なんでそれやらなきゃならないのかの理解をしないまま、できちゃった状態になる。

そうすると、なんかトラブった時何もできない状態になる。

C#すら触ったことないド素人がWPFとprismをキャッチアップする方法

f:id:hrmch-ioii:20170303235058j:plain

元プロの社畜 @nabeemichi です。

ぼくは、Windowsネイティブアプリを開発することになってしまっている。

でもC#も触ったことない。WPFなんて初めて聴いたよ状態から3週間ほどで、

それなりにアプリが動く状態になった。

そんな僕が、やったキャッチアップ方法を解説する。

他の言語ができれば、どうにかなる

プログラミング言語全般的にそうだと思うんだけど、

1つの言語をそこそこできるようになっていれば、

他のプログラミング言語はある程度どうにかなる。


そんな思いでWPF+prismライブラリを採用して、ゼロからアプリ作ってるんだけど、

情報なさすぎでびっくり状態。

やっぱり、Windowsネイティブアプリなんて今の時代つくるやついないだろってことだね。

お役所とか医療機関絡みじゃないと作らないか。

Windowsネイティブアプリって不便だもんね…WEBアプリにしようよって感じだよ。

そんなこと言っていても案件消化できないから、キャッチアップした。

WPFは中途半端すぎるからライブラリのキャッチアップを

WPFを触ってて一番思ったことは、

なんて中途半端なんだ…

ってことだ。その中途半端さを補ってもらうためにPrismライブラリを使ったりするわけだが、

もはやキャッチアップ対象は、WPFではなくてPrismのキャッチアップに焦点をあわせたほうがいい。

Prismを理解したら、それなりのWindowsアプリ作れる。

www.nabehiromichi.com

だからWPFって、なんだ?状態の人は、WPFという単語でググるのはもう辞めたほうがいい。

さっさとPrismをNugetからインストールして、Prismの使い方をマスターするほうが成果だせる。

ググってばかりじゃあ、動くものはできない。動いてるものからキャッチアップする

とはいいつつも、「WPF Prism」でググってても結局は何もできないし、

キャッチアップした気になってるだけ状態。


ググって知識入れてるつもりになってるよりは、動いてるものを一つづつ追いかけてく方が理解できる。

OJT的な感じで、実際に動いてデバックできる状況のソースコードを手に入れることが実はググるより良い手段だったりする。

Prismはgithubにサンプルソースが公開されてるので、ビジュアルスタジオをインストールしていれば、デバックしてキャッチアップできる状況を作ることができる。

github.com

Prismの主要機能を理解したら、もうこれをダウンロードしてデバックするのが一番理解しやすい。

僕はこのサンプルソースを見つけてから理解Prismの機能を理解することができた。

困ったら、ここのサンプルソースを参考にしする為に、何度もみたりデバックしてる。


ここのサンプルは、あたりまえだけど、めっちゃ重要なんだけど、

Visual Studioさえあれば、サンプルソースをビルドできる。

エラーなく、目的のサンプルを選んで、プロジェクトを選択してちゃんと読み込める。

ビルドに必要なソースがちゃんと全部そろってるのだ。

重要なんだけど、意外とサンプルビルドできないとかあって、その時点でキャッチ諦めたり

他のライブラリ探したりしてしまう僕にとっては重要。 今週のお題「部活動」

ググればそれなりの情報はでてくるけど、やっぱり本家の情報をベースにキャッチアップ

情報ってのは、正確性を保つのが難しいもの。

情報が古かったり、そもそも信じていい情報なのかどうなのかってのを判断するのに時間がかかる。

ただ、流石に公式のDocumentは信頼性がある。

だって、せっかくつくったライブラリだから使ってほしいはずだしね。

ここ間違ってたら、もうどうしようもないでしょ。

その最も信頼できるであろうドキュメントがここにある。

github.com

この公式ドキュメント見つけるのに、実は僕は時間がちょっとかかってしまった。

理由は、githubのwikiページにになかったからだ。

こうゆう大事なものって、目につきやすいWikiとかにあるものだとおもってたから、

正直Wikiみたときは、使わせる気ないクソライブラリだなって思った。

だって、普通WikiにAPIリファレンスとか、使用方法書いてあるのが普通だと思うからね。

でも、こいつは、ソースとしてバージョン管理してある。

正しい管理方法だと思うけど、流石にそこを一番先に探しにはいかないかな。

まとめ

さっさとPrismのサンプルソースをダウンロードしてデバックできる状況をつくって、動いてるものを動かしながらキャッチアップする。

github.com

サンプルからひつようなところをピックアップしながら、開発するのが一番はやくPrism使ったアプリを作れると思う。

僕らが考えるべきところはPrismがどうなってるかよりも、ビジネスロジックをどうするか?の方が大事だから。

そこに僕らの価値があるはず。


公式ドキュメントは、Wikiにないから、こちらから

github.com

自転車通勤して3週間でわかった。涼しくてもリュックの汗をかく原因と気温

元プロの社畜 @nabeemichi です。

ロードバイクで通勤して3週間ほどたった。

今は4月で、気持ちの良い気温の日が続くが、ロードバイクで通勤すると

荷物を入れてるリュックのせいで、背中に大量の汗をかく。

4月の夜は意外と寒いはずなのだが、それでも汗をかく。

背中の汗をかく気温がちょっとだけわかってきた。

ロードバイクは前傾姿勢。ママチャリよりもリュックの密着度が高い

f:id:hrmch-ioii:20170421004836j:plain

ママチャリはサドルよりもハンドルの位置が高い。

だから上半身が起きた状態で自転車にのれる。

そのためリュックを背負っていても、背中とリュックの間にそれなりに空間つくれるのだが、

ロードバイクはサドルが高い。そして、ハンドルがサドルよりも低い。

こうなると、勝手に前傾姿勢になってしまう。

前傾姿勢になると、リュックが背中に密着する。

もろに、リュックにかかってる重力が僕の背中全体にかかってくるわけだ。

走行中に背中とリュックの空間をつくろうとして、

肩甲骨をグイッと出してみてもだめだ。

リュックは僕のせなかに密着し続ける。

空気の入ってくる余地はない。

僕の背中の熱を溜め込みまくってくれる。

朝は交通量も多い。ストップ&ゴーが多くなる。

車のも渋滞気味なので、車の横をすり抜けるのにもスピード落として通過する。

幅寄せしまくってる車とかあると一旦止まらないといけない。

ぶつかったりしたら嫌だしね。

トラックなんかは、普通車よりも幅がひろいから、自転車の通る道を勝手に狭くしてしまってる。


朝の信号は変わる時間間隔が短いように思える。

青になったと思ったるすぐに赤になる。

ものを動かす上で、最もエネルギーを必要とする場面は動かす直前だ。

朝はストップ&ゴーが多いからエネルギーを使う。

エネルギーを使うと体が熱くなるので汗をかく。

ロードバイクは軽くてスピードが出せる。無意識のうちにスピードだしてしまう。

スピードがだせると、出さなきゃいけないような気がしてくる。

基本的に車道を走ってるから、車に負けてたまるか!

とか、無駄な意識がでてしまう。

朝の通勤時間は、車も混んでるからあまりスピードもださない。

すぐに信号でとまるから、ずっと同じクルマと追いつけ追い越せ状態が発生する。

なんか、勝てそうな気になってくる。

そうなると人間ってものは厄介で、勝とうと頑張ってスタートダッシュ決めたり、

ちょっと無理して自転車こいだりしてしまう。

体の温度は急上昇間違い無し。


f:id:hrmch-ioii:20170421010821j:plain

朝は自転車通勤してる人も多い。

ママチャリの人が前にいると、追いついてしまって、簡単に抜き去ることができるロードバイク。

後ろから車が来ないことがわかると、一気に抜くためにダッシュしてしまう。

これもまた汗をかいてしまう原因だ。

汗をかきたくなかったら、だまってみんなと同じスピードで走ればいい。

でも、できないのだ。

夜の気温は10℃くらい。寒いのに汗をかく。

夜はまだまだ寒い。

中袖に上着が必要だ。

そんな気温なのにリュックを使って自転車通勤した背中はこの有様だ。

f:id:hrmch-ioii:20170421010945j:plain

おもらししたみたいにはっきりと汗が背中から染み出してる。

f:id:hrmch-ioii:20170421011234p:plain

気温は13℃で、夜だから太陽の光もない。

背中以外は寒いくらいに感じるのに、背中だけ汗だくだ。

おそるべし、リュックの保温力。

人にもよるだろうけど、10℃以上になったらもう背中が蒸れることは避けられないと思う。

対策をしよう。だって会社についてからはずかしいし、いもちわるいもん

自転車の汗ムレ対策リュックでもいい。

これは自転車のってる人には有名らしいけど、

かっこわるい。

背中にメッシュが仕込んであって、リュックの背中の形状は丸くなってる。

背中との密着を背中丸型形状とメッシュで極限まで少なくしてやろうっていう作戦。

でも仕事に必須なノートパソコンは真っ平らだ。

パソコン収納できる気がしない。

これを買っても僕には無価値だ。


モンベルも自転車に乗る人に対策を講じている。

こいつも、背中丸型形状、背中メッシュ作戦で攻めてきている。

ドイターと違ってザックカバー内蔵なのはいい感じだが、

こいつも真っ平らなノートパソコン入れるには向いてなさそう。

なにより、ノートパソコン収納ポケットがついてない。

汗対策して、ノートパソコン守れないとか、もはやなんのために会社行くのか目的を見失ってる状態を作ってしまっては意味がない。


今使ってるバックを改造する方向が最も現実で、お金がかからない方法

どんなリュック使おうが、強制的に背中とリュックの間に空間を作ってしまえ作戦だ。

さらにこいつもつけて、汗とリュックとの戦いに勝利する

肩の汗にも対抗する作戦だ。


これからどんどんあつくなってくる

現時点でもめっちゃ汗はかく。

気持ちい汗をかくためにも、気持ち悪い蒸れによる汗の対策をとっていく。

今から汗と戦って、夏までに必勝法を確立せねばならぬ。

スパゲッティソースコードに愚痴って何が解決するの?できることをできる単位でやるしかないんだよ

f:id:hrmch-ioii:20170420004454j:plain

元プロの社畜 @nabeemichi です。

僕は今フリーのエンジニアとして企業に常駐して働いてる。

どんな企業でも難解なソースコードはあるものだ。

それはリリースを優先させた結果なのかもしれないし、

人がたりなくて、新人に任せっきりにしたのかもしれない。

でも、所詮人が作ったものだ。

人間がつくったのだから、同じ人間が理解できないわけがない。

理解するための工夫と努力はしないで愚痴っていても何も進まないのだ。

どんなプロダクトにも闇のソースコードは存在する。

ぼくは開発者としてIT企業で6年ほど働いてた。

その企業もそこそこ歴史のあるプロダクトを持っていたりしたのだが、

なんじゃこりゃ?誰が理解できんの?

ってソースコードはある。

スパゲッティのように絡み合っていて、どこがどうなっているのか解きほぐすことができないソースコードだ。

そんなソースコードはだいたい不具合がある。

机きれいに片付けれないやつがミスが多いのと同じように、

整理されてないソースコードは不具合も多い。

そんなソースコードを修正しないといけない。

愚痴っても、バカにしても、笑いものにしても何も意味はない

闇のソースコードを見つけたエンジニアがやることはだいたい決まってる。

そんなソースコードを作ったやつを特定して、バカにしたり笑い話を作る。

隣のエンジニアに、面白くその話をして悲劇のヒロインになったつもりになる。

基本はそれだ。

そして、闇のソースコードを作ったやつに責任をなすりつけたりして、

成果を上げれないことは自分のせいじゃないって雰囲気をつくる。


そんなのはどうでもいい。

さっさとその不具合で困ってるユーザーを救ってあげることが最優先なのに、

人をバカにすることが最優先になってる。

エンジニアってやつは、インテリなやつが多いからなおさら。

ちなみに、ぼくは自称不良開発者なので、技術とかどうでもいいし、すこぶるバカだ。

エンジニアが大好きな最新技術なんてどうでもいいし、かっこいい難しいエンジニア用語は全く知らん。

もっとわかりやすい言葉で説明してね。技術大好きエンジニアさん。


エンジニアの仕事は、かっこいい技術を使うことでもキレイなソースをかくことでもない。

ユーザーに価値を届けること。

ただこれだけ。

だから、人をバカにして悲劇のヒロインぶってるやつは仕事してない。

さぼってるんだ。

だから仕事が遅いんだよ。

あなたの仕事は、その不具合という問題をさっさと解決することなんだ。


ユーザーは、ソースコードにも技術にも興味はない。

どうだっていいのだ。

ただ、自分の仕事が早く確実にストレスなく簡単に終わるようになればいいだけ。

そこにしか興味はないんだ。

理解できないソースコードを作ったのは人間だ。どうにかなる。

f:id:hrmch-ioii:20170420004556j:plain

どんなソースコードだって、しょせん人間が作ったものだ。

同じ人間である僕達が理解できないわけはない。

ただ時間がかかるのと、頭を使う量が半端ないだけだ。

ソースコードが隠蔽されたライブラリとかが原因じゃないなら

ソースコードが全て見れる範囲でおこってることなら、必ずスパゲッティソースコードは解ける。

どんなに難しい数式や発見だって、

誰かが一回解いていれば、絶対にとけるのだ。

なぜなら、参考になるものがあるから。

だから、人間が作ったものは、絶対に人間が理解できる。

解決するには、理解できる単位に分けるしかない。ただそれだけだ。

問題を大きくとらえすぎなんだ。

めちゃくちゃなソースコードが大量にあったり、スコープが広すぎるから理解できないと思ってしまう。

大きな難しい問題の大本は、

小さい問題なんだ。

小さい問題が沢山積み重なって、絡み合って大きくなったから難しい。


小さい問題は簡単に解ける。

だったら問題を小さくすればいい。

問題を小分けにして、理解できるレベルにしちゃえばいい。

これを繰り返せば、大きな難しい問題だって

いつの間にか小さくなって簡単になってる。


スパゲッティなソースコードも理解できる部分から小さく切り出して、ちっちゃなメソッドにすればいいだけ。

そうやってきりだせばいいじゃないか。

デザインパターンなんて気にする必要なんてない。とにかく小さくしていけばいいだけだ。


修正範囲が多すぎる?

そんなこと言ってたって、理解できなくて不具合解決できないよりましだ。

テストすりゃいいだけだろ!


テストする時間がない?

そんなスパゲッティなソースコードをリリースしてるときに、十分なテストできてたと思うの?

どうせできてないよ。

テストできてないんだから、主要なパターンのテストを黙ってしてたほうがマシな結果になるよ。

さっさと自分ができることをやるんだ。愚痴っても何もおきないぞ

きみが頭がよくて、すごい技術があるのはわかった。

でも、結局何もしてないよね?

人をバカにして喋ってるだけだ。

その時間を、できることに費やせばいい。

ただそれだけだろ?

間に合わなかったら、やったことを説明すればいいじゃないか。

こんだけあって、こういう方法でやったんですけど、無理でしたって。

なので時間もう少しください。

って言うだけだろ。

どうせ人は足りないんだ。

君ができなかったからといって、誰かが引き取って一瞬で終わらせることもない。

でも確実に前進させることはできる。

やれることを少しずつやった君ができなかったら、

その期間では誰もできなかったってことだよ。

責められる責任はない。終わらなかったことに対して、でもこれだけやったってドヤ顔すればいいだけだ。

キッズシューズ買うなら酒々井プレミアムアウトレットが靴の種類が多くておすすめ

f:id:hrmch-ioii:20170418233015j:plain

元プロの社畜 @nabeemichi です。

子供の靴を買うために、酒々井プレミアムアウトレットに行ってみたのだが、子供靴を取り扱ってる店が多かった。

子供が気に入らないと履いてくれない

僕には2歳の娘がいるのだけれども、気に入った靴しか履かない。

気分によってはお気に入りの靴でなくても履いてくれるのだが、

だいたいはお気に入りの靴しか履かない。

この前までは、犬の柄の靴がお気に入りで、毎日同じ靴しか履いてなかった。

そんな靴も小さくなって、履ける靴がなくなってきた。

子供の靴を沢山扱ってる店は少ない

子供の靴って、どこで買ったらいいか迷う。

ショッピングセンターの中歩いても、キッズシューズを扱ってる店は少ない。

子供服屋さんで取り扱っている場合もあるけど、種類が少ない。

おまけに取扱いサイズも少なかったりして、ほしいサイズなかったり。

だから、実際に履かせてみて比較したり、

子供が気に入ってそうな反応をみたりするのが難しかったりする。

靴は実際に触ってみて、重さを感じるのも重要

今回は酒々井プレミアムアウトレットで靴をみたのだけれど、

実際に靴を履いてみて、子供がテンション上がる靴ってのがある。

それは、好きな色だったり、デザインだったりが大きいのかもしれないけど、

履きやすさや靴の軽さも関係あると思う。

f:id:hrmch-ioii:20170419000811j:plain

実際に、我が娘もテンション上がった靴があった。

どのくらいテンション上がったかと言うと、履いて脱ごうとしないどころか

店中を走りまわり初めたのだ。

この靴を買ったのだが、持ってみてびっくり。

履き比べした靴の中で一番軽いと感じる靴だった。

靴の幅が、我が子にジャストでフィット感もよさそうだったから、実は軽さよりもフィット感の可能性もあるけど…

子供の靴はできるだけ安く買いたい。すぐに履けなくなるから。

大人の靴もそうだけど、同じものならできるだけ安く買いたい。

子供の靴ならなおさら、安く買いたい。

だって、子供の足はどんどん成長していくから

大人より同じ靴を履いてる期間が短いから。


実際に履き比べができて、安く買うことができる場所となると

やっぱりアウトレットがいい。

酒々井プレミアムアウトレットは子供靴を扱ってる店が多い

アウトレットも沢山あって、お店もアウトレットによって違う。

僕が今回行った酒々井プレミアムアウトレットは子供靴を扱ってる店が多いようなきがする。

探した靴のサイズは13.5センチ。

このサイズの靴を取り扱ってる店を紹介しようと思う。

プーマ

f:id:hrmch-ioii:20170419001816j:plain

今回の娘の靴はPUMAで2500円で購入。

f:id:hrmch-ioii:20170419002413j:plain

靴底も滑りにくそうだし、軽い。

なにより、子供が履いて気に入ってくれたのを見つけれた。

僕が行った時は、13センチくらいの靴は3種類くらいおいていた。

ナイキ

f:id:hrmch-ioii:20170419002138j:plain

ここのナイキは4種類くらいキッズシューズをとりあつかってた。

ニューバランス

f:id:hrmch-ioii:20170419002605j:plain

キッズシューズでは、絶大な人気なのかしらないけど、小さい子がよく履いてる。

そんなnew balanceもアウトレット価格で購入できる。

ここも3種類くらいあった。

ミキハウス

f:id:hrmch-ioii:20170419004643j:plain

子供服で有名なmikihouseもアウトレット価格で子供靴も売っている。

ミキハウスはミズノとコラボしてたりしてけっこう靴にも力入れてると思う。

我が子のファーストシューズはミキハウスで購入したが、アウトレットでもなかなのお値段する。

ここはさすが子供用品専門。

取り扱ってる靴の種類は沢山ある。

ちょっと数えるの面倒くさいってくらい靴の種類あるから、数えなかった。

まとめ

ひとつの場所で、これだけ子供靴扱ってるのって珍しい気がする。

いろんなメーカーのいろんな種類の子供靴を履き比べできるから、

子供が履いてみて気に入る靴を見つけるなら酒々井プレミアムアウトレットがいい。

アウトレット価格で購入できるし、ついでに自分の買い物もできるし。


酒々井プレミアムアウトレットは成田空港にから近い。

都内からだと1時間半くらい。

場所は Google マップ で確認できるよ。

業務改善するためには、業務をロジカルにしないといけない理由

元プロの社畜 @nabeemichi です。

IT企業で働いて、今はフリーのエンジニア。

週3日くらいは企業で常駐して仕事してる。

現状の業務を改善するために、アプリつくっているのだが、

毎回思うことがある。

業務の目的を見失ってる。だって常識だから

僕がアプリとかシステム作って業務を改善するときは、ド素人。

その業務やったことないからね。

だから質問するんですよ。


なんでその業務してるんですか?


って。

だいたい答えてくれる人いないけど。

これは質問の仕方が悪いかもしれないですけど、

だいたいみんな知らないってことだよね。

典型的な答えは、「昔からこうやってるから」ってゆう答え。

既に常識としてみんな受け入れてる。

今はもうやる意味ないことかもしれないのに。

みんな楽になりたいだけ。だから目の前のことをなんとかすることに注目してる

自発的に仕事してる人ってけっこう少ない。

まかされた仕事をこなすことが目的の人がほとんど。

だから、自分の仕事が楽になることしか考えない。

こうなると、だいたい目の前の面倒くさいことばっかり気になる。

けっこうどうでもいいような要望ばかりでてくるんだ。

だから、、、なんでそれしてるんですか?

って気持ちになるんだけど。

理由を知ってる人はもうやめちゃってていなかったり…

みんなExcel大好き。だってなんでもできるから

現行システムが編集しにくいからExcelで一気に編集して、効率化したい。

とか、あるあるなんだけど。

なんでExcelになる?

使い慣れてるのはわかるけど、Excelにしたら、編集するためにまた違う作業増えない?

Excelの中で、編集しないといけないもの探して、編集して。

いやいや探すとかし始めたら余計めんどくさくないでしょうか?

そもそも全てのデータExcelでみます?

全データ見る必要性ってなんでしょうかね?

って質問すると、特に答え帰ってこなかったりして。

ほんとにやりたいことってExcelじゃないよね?

すべてのデータを一覧することでもないよね?

問題がある部分を編集したいんだよね?

だから、問題のある部分がすぐわかるようになって、

編集量が多かったらグルーピングして一気に編集さえできればいいよね?

だったら、同じ編集したいものだけ抽出できればいいだけだよね?

やっぱりExcelって必要ないよね?


だいたいこんなパターン。

みんなすぐに使い慣れてるExcel使えば楽になるって発想になる。

そもそも、21世紀なんだから問題ある部分くらい勝手に編集していい感じにしておいてほしいけど。

業務改善するなら、まず業務をロジカルに説明できるようにすること

実際に業務してる人は、業務の存在理由を考えたりしないんだ。

さっさと帰りたいとか、そういういうことを考えてる場合が多い。

よくわからんけど、いつもやってるってのもある。

だから、本当に改善するならその業務の存在理由をロジカルにしないといけない。

ロジカルにするために掘り下げていくと、

そもそもやらなくていい業務だってある。

今回の例だと、全てのデータを一覧で見るとかになるんだけど、

すべてのデータを一覧でみるだけで僕は頭クラクラするよ。

そもそも、編集したいデータってなんなのさ?

ってとこまでつっこまないといけないんだけど。

ロジカルにすることで、改善する方法だって見えてくる。

改善する方向が間違ってないかの確認だってできる。