自分を大切にするということの意味
やっとわかった気がする。
自分を大切にしない人間は周囲を不幸にするし、何をやっても上手く行かないと思いがちで自虐心からどん詰まることが多い。じゃ、自分を大切にするってどーゆーことなんだろうなぁって考えてみたら、「自分の人生に起きる様々なことを、きちんと迎え撃つこと」が自分を大切にするって言葉の意味なんだ。ふと思いました。
キチンと迎え撃つためには、正しく物事を捉えなくてはいけない。臆病なのが一番あかん。アドバイスのしようがない。自虐にかける言葉はない。うるせーバカと誰かが言うしかない。臆病と慎重はぜんぜん違う。自分を守ることだけで精一杯になってしまうので、結果的に卑しいことをやってしまう。別にどうみても追い詰められているわけでもいないのに、臆病だから迎え撃つことができないので、自己憐憫や被害者意識が心を支配してしまう。そうなったら終わり。どの道を通っても息詰まる。
キチンと迎え撃つためにもっとも重要で難しいのは、感情で物事を考えないこと。事実だけをつなげ合わせて筋道を立て、納得の行く決断を下せるようになること。そうでなければ、自分の周囲の人間を不幸にする。もちろん、思い通りに行かないことはあるよ。思い通りに言ってたら今頃ロックスターになっていたと思う。でも、あっさり死んでたかもしれない。わからんもんだ、何がこれから起こるなんてことは。
キチンと迎え撃てるようになれば、自分が全てを頑張らなくても「これだけはお願いしたい、助けて欲しい」っていう線引きがすごく鮮明になって、頑張れって素直に応援できる様になると思う。まわりのひとが。
自分を大切にして、自分の人生に起きる様々なことを、きちんと迎え撃てば、自分で自分のレールを敷くことが出来る。
それが人生というものだ。
SIerの弱体化で誰がビジネスアプリケーションを作るのか問題
ずっと同じことを考えている気がするけど、微妙に違うしれないので書くだけ書く。
人月で工数積算してマージンを抜くビジネスが、そもそもマージン抜けるほどの工数で値段付けするのが通用しなくなってきたよねというのがここ数年の変化だとしましょうか。人を出すだけで金を儲けるなんてそれってITエンジニアの無駄遣いだよねっていう。このモデルが崩壊した場合、今後は誰がどうやってビジネスアプリケーションを作っていくの？ 担い手はいるの？ というのが全然見えて来ないのではないでしょうか。
AWSがいくら破壊的だろうが、あれはプラットフォームのサービスであってアプリケーションのサービスではない。最高のメンテナンスが出来る環境があっても、どんなプラント建てるんですか御社はって問いに答えは出せない。エンプラになればプラントの工程の一部やつなぎをAWSでやるんだろうけどさ。
上流と下流が分断しているのがSI業界の最もあかん所でかつそれが主流なので、上流と下流が崩壊してプログラマの市場価値上がるンゴって言っても、外注管理しか出来ない会社と下請け仕事しか出来ない会社が出来上がるだけなのでは...と。すんごく乱暴に言えばね。ずっとそのやり方でキャリアを積んでしまった以上、陸に上がった魚は海に戻ることは出来ない。
工数を圧縮しないとペイしないよねって話になってくると、お金のかけ方を変えるしかない(一括請負辞めよう)というブームが生まれた。お互い無駄な保険をかけるのを辞めましょうというのがポイントだと思うけど、「定額で毎月20万かかります」でYESといえる中小企業がどれだけあるんだろう。500万一括が買う立場からすればベストだよねぇ...という気がする。大企業はエンジニア雇う意味もあれば使いこなせるリソースもあると思うけど、中小企業にはよほど上手くやらないと難しい気がする。一人で全部やりますってエンジニアが入ればいいけど。そうでない場合、ビジネスアプリケーションをデザインするプロ(SIer)が必要になるはず。
デザインって書いたのは、必ずしもスクラッチで実装するのが正しいとは限らないから。PaaS/SaaSを使ってうまいことバランスを取ればいい。そうすれば値段も下がる。そういう業務デザインをできる自分でありたいし、そこにニーズが有るのならそういう仕事をやってみたい。
最近のマイブームは、Apps Script | Google Developers です。そんな夜。
輸入雑貨販売は大氷河時代に突入
雑貨小売の「プラスハート」が民事再生法申請、負債38億円 国内倒産 - 不景気.com
健康コーポ、パスポートを子会社化 株式65％取得、雑貨事業を強化 ：日本経済新聞
前職では雑貨業界にいたので、上記のニュースには驚きました。プラスハートさんもパスポートさんも雑貨の小売店チェーンでは超がつくぐらい大手の会社です。バラエティ雑貨というジャンルは輸入雑貨がほとんどで、価格帯が1000〜2000円ゾーンが多い。
しかし、円安や増税の影響を受けてメーカーさんがバシバシ上代(一般小売価格)を上げてくる。商品の品質はそのまま(むしろ代わり映えしないので下がっている)で、値段だけが上がるという泥沼です。消費者が低価格志向だから離れたんじゃなく、値段と商品がミスマッチになった結果だと見ています。3Coinsさん等の台頭で、2000円の雑貨とワンコイン雑貨に大差がないわけですからねぇ..小売店が売れないわけですから、当然雑貨製造メーカーも在庫がだぶついているはずです。秋冬商材がどれだけ叩けるのかによって、ぐげげげげ。
雑貨屋さんじゃなくてセレクトショップとして何かしら高級路線を出すか、商品を絞って特化するのかのどっちかしかないんだろうなぁ。
見切り千両、損切り万両
ええ言葉や…
車の運転でよくこのことを僕は例える。アクセルを踏むのは誰でも出来る。車の運転で最も難しいのはブレーキング。ブレーキングのタイミング、力の入れ加減などによって車に与える影響は全然違うし、プロの世界ならタイムに大きく差が出る。
何かを始めるのは確かに難しいけど、撤退するのはもっと難しい。事業をやり始めてやっとアクセルが踏めるようになったのにブレーキを踏むのは嬉しくないことだし。突っ込んだお金のことや、想い入れなどが邪魔をするんだよねぇ…前職でもそうでした。
ま、そんなの関係ないけどね。いくら金を突っ込んだからもったいないとか、どうしてもやりたいから辞められへんとか、単なる感情論。また、「いくらの利益が出るまでやる」というのもズブズブになる。負ければ負けるほどアツくなる博打と同じ考え方。そうじゃなくて、「いくらの金を失ったら回収困難のため撤退」にするのが正しい。
そうは言っても赤字の事業を撤退することが正しいとは限らない。同業者がくたばってその分のシェアが流れてくるケースもある。もう1年引っ張っていたら黒字になった、なんてこともあり得る。最初は赤だったけどスケールメリットが効いてくるようになって黒になるとかもある。はじめから黒字になる事業なんて、ほとんど無いよね。
僕が一番得意なのは、見切ること。見切るというか、見極めるというのが適切かも。見切るかどうかの基準は簡単で、ROIがどこにあるのか。ROIってのは、それをやる意味があるかどうか。意味があるというのは、その仕事や事業に関わる全てのステークホルダーにメリットがあるのか。メリットが無いなら次に続かないんだから辞めちまえで終わり。
辞めまーすって宣言すると面白いもんで「いやいや、だったらこういう条件でいかがですか」って逆に提案頂けることも多かったり。続ける意味が、条件が変わることが出てくる。
色んな意味で、見切り千両損切り万両ってのは正しいなと思います。
WebAPI連携可能な販売管理ソフトが少なすぎる件
PCAクラウドぐらいしか知らない。
API連携無料で出来る販売管理システムがあれば、すげーいいと思うんだよね... 世の中の販売管理システムはLAN前提のクラサバアプリしか無いし、Kintoneで頑張るのは無理じゃん。Webアプリだったら無料で使えるのがたくさんあるけど、WebAPIが用意されていて無料で使えるのは皆無だった。
うーん、ニーズがないのかなぁ。我々みたいに不定形なサービスを販売する会社ならまだしも、モノを売る会社さんの場合は販売管理システムがなければどうしようもないはず。まぁ今後自分がやっていくビジネスの中で、「WebAPI連携が可能な販売管理システム」がどれぐらい求められているかは、注視していきたい。
Kintoneを触ってみたら想像上に出来ることが少なかった件
最近、仕事で使いたくてKintoneを触り始めています。想像をはるかに超えたレベルで、できることが少なくて驚いています。これでアプリ作って納品出来るんかな...
アプリについて
Kintoneではアプリを作ることが出来ます。このアプリと言われているものをぶっちゃけて言えば、マスタメンテしか作ることが出来ません。1つのアプリに1つの入力画面しか作ることが出来ない仕様になっています。入力画面と一覧/検索画面が各々1個ずつあるだけで、それ以上の画面を作ることが出来ません。
入力画面のことをKintone用語でフォームと言います。フォームには明細型のデータも保存できるので、header_detailな入力画面を作ることも可能です。でも、1個だけ。責務が違うなら別アプリに外出しする必要があります。
販売管理を作るのは無理ゲー
販売管理で受注登録することを考えると、下記の4つのアプリが必要になります。
- 受注入力
- 顧客管理
- 商品管理
- 単価管理
単価の管理と言ってるのは、B2Bでは同じ商品でも顧客によって卸単価が異なります。なので、商品と顧客をキーに最新の単価を取得しなければなりませんし、登録する時に単価を保存する必要があります。在庫の引当も必要です。JavaScriptでゴリゴリ頑張ってアプリ間連携をすればできるんでしょうけど、使い勝手がすごく悪くなるのが目に見えています。
アプリでレコードを登録する際に、別のアプリの操作が必要になることが多いのであれば、大量にカスタマイズされたJavascriptというWeb版Excelマクロが出来上がる恐れがあります。
検索条件は柔軟に設定できる
ここは文句ありませんでした。検索条件の保存もできるので、便利です。
集計もアプリ単位
集計も可能ですが、受注と顧客と商品をJOINして商品名がXXの6月の販売実績を顧客コード順でソート…というのは無理ゲーのようです。アプリ単位でしか集計不能です。それらのデータを1つのアプリのレコードとして保存すれば集計できますけど、正規化されていませんから顧客アプリ側で変更があったら終わりです。変更を検知する仕組みがありませんので、Javascriptで頑張るしかない。
業務系アプリでWPFを使うメリットがなかった件
非常によくわかるお話だった。特にここ。
MVVMの原則に従って一生懸命、コードビハインドからコードを追い出したところでほとんどメリットが感じられません。
業務系のアプリはデスクトップのテンキーをベースに操作ができることを求められるから、キー関連のイベントを拾わざるをえなくなり、結局コードビハインドは追い出せない。ボタンをクリックするの？Enterで検索開始すればいいじゃない、とかさ。
MVVMをやる時に一番困るのがコードビハインドからViewModelに処理を投げてそのViewModelからUIにメッセージを返すところ。ココがよくわからなかった。WPFのMVVMは敷居が高く、オレオレ実装でやると予期せぬバグを生み出す温床になります。同じデータなのにAさんとBさんで表示結果が1個のセルだけ違うというバグが...
WPFはWindowsFormの感覚で作ると火傷するということです。全く別物と考えていいでしょう。あと、画面がどうしても重たい。UIを仮想化している為だと思うがUserControlに色々コンポーネントを付け足していくスタイルだと仮想化されたUIが更に重くなる(JSでいうDOMみたいなやつ)みたいで、画面の描画がロースペックなマシンだと時間がかかる。これをチューニングするとなると、作り方を大きく変えないといけない。
WPFの利点にコントロールの外観を自由に変更できることがある。同じデータを円グラフとテーブルの表で表示する、なんてことは大得意。でも、そのメリットを享受できるケースは業務系のアプリにおいてとても限られている。
振り返ってみるとWPFの一番のメリットは画面サイズが固定でなくても良い所と、依存関係プロパティ、データバインディングの３つだった気がした。
WPFは画面サイズやウインドウサイズに応じて自動的に画面の再描画が走るので、相対配置に対応している。Windowsフォームは原則サイズ固定だけど、下記のやり方を使えばフレキシブルにできるみたい。
依存関係プロパティってのは、CSSのように html { font-size:20px;} って指定すると、全てのfont-sizeプロパティを持つUI(p,span,td...など)に変更が伝搬される仕組みのこと。Styleとコントロールは完全に独立されている設計だから。Windowsフォームでは出来なかった。やるとすれば親Formで再帰でループ回してfontsizeプロパティを持ってるなら変更する感じになるかな。別にこれじゃなくてもええけど、他にやり方を知らない。
データバインディングについてはWindowsフォームでも出来る。コードビハインドで画面のViewを内包したモデルを作ってインスタンス作ればいいだけ。多分オブジェクトのネストにも対応してくれるだろう。
WindowsFormsでの単項データバインドまわり | tocsworld
結局、Windowsフォームでもやりたいことはできるし、画面のコンポーネントがダサいというか古臭い所はあるだろうけど、WPFより操作は簡単で作りやすい。デスクトップアプリはWebアプリの３倍難しいのが僕の肌感。Web上に乗っかってるサンプルコードをちょいちょいで見様見真似で....っていうのは困難。GUIのハンドリングは実にめんどくさい。高い操作性を得るためなら、クライアントに配るライセンスがフリーのツールを買うのが最も正しい選択だなと、3ヶ月WPFをどっぷりやっておもいました。
おわり。
