ITコンサルティングってやる意味あるのかな - Life is Really Short, Have Your Life!!
微妙にそんな事を感じてしまった今日この頃。意味があるというか、意義を見出すのが本当に難しいなぁと。 企業がITに期待することなんて「売上UP」か「生産性向上」のどちらかでしかない。で、大変残念ながら、導入するだけで売上UPするITソリューションなんて、どこにも無い。 ビジネスモデルやそれを支えるビジネスプロセス、更には営業戦略やマーケティング等の総合的な取り組みがあって、初めて売上をUPするための対策が取れる。単価を上げるのか、顧客を増やすのか、商材を増やすのか、購入回数を増やすのかを決めた上で、ITを活用するノウハウを貯めて成功する確率を高めていくしか無い。差別化を図るのは、目に見えない所であるべきだ。 生産性向上というのは「今までやっていることをもっと速く出来るようになること」ではなく「手を動かさなくてもいいようにすること」が達成できていないと意味がない。そのためには、企業内に流れる情
フローチャートは制御構造を書く以外の用途に適さないのでは - Life is Really Short, Have Your Life!!
アラフィフのおじ様方がすごく好きなのよね・・・これ。 フローチャートって、制御構造をイメージして表現するために作られたものなんじゃないかなぁ。制御構造って逐次、分岐、繰り返しの３つしかないから、それらのイメージを可視化するために使う。ま、それならわかる。でも、例外/オブジェクト/同期 or 非同期/スレッド/ジェネレーターやデコレータといった現代ではふつーのプログラミングになると全く表現できないですよね、これ。 プログラミングをイメージで可視化するための記法って、21世紀向けに再発明されていいんじゃないかな。え？UML？(∩ ﾟдﾟ)アーアーきこえなーい
仕様書策定の良いツールはないものか - Life is Really Short, Have Your Life!!
やっぱりOfficeソフトを使っている会社さんが多く、画面設計書なんかはPowerPointで書かれていたりします。 当然のことなんですけど、「この画面項目はDBのどのテーブルのどのカラムに該当するか」がわからないとプログラムを書くことが出来ません。そういう情報をパワポに盛り込んでしまうと、DB側で変更があった時に差分が取れなくなります。取れなくなるというか、手で修正する必要があります。逆も然りで、ER図に変更があった場合は設計書に反映しないといけない。 例えばだけど、ERに変更があったらそこからテーブル作っちゃって、画面設計書の項目をマッピングする時に作ったテーブルのカラムをプルダウン(オートコンプリート)で選んでいくみたいなレベルまで徹底している現場って…あるんでしょうか？ こういう不整合が重なると、仕様書が死ぬと思うんだけど... Markdownで書けばいいじゃんっていう説もあるよ
営業事務(マーケ担当)はSQLを覚えるべきだし、2時間で覚えられる。 - Life is Really Short, Have Your Life!!
qiita.com めっちゃええ話。これはすごく意味がある。細かいツッコミをすれば、上記はSQLを簡単に投げられるようになった話でありSQLを駆使できるようになったわけではないのだけど、そのうち覚えるやろ。 弊社では商品企画を担当する社員がおりまして、ExcelでVLOOKUPはできるけどデータベースの操作はしたことがない、というレベルです。僕が隣でSQLを書いているのを見て、「これなら出来そうだから教えて」と言われたので、教えました。2時間の講習でここまで覚えてくれました。 データベースとテーブルの関係 SELECT,FROM,WHERE,LIKE,ORDER BY JOIN,GROUP BY,CASE-WHEN 簡単なDB関数 なので、「エプロンという品名の商材を抽出して、伝票日付が4月と5月の売上の2013年以降の年度別の対比が見たい」というSQLが書けるようになりました。具体的には
iPad mini4 を活用すべく検討していること - Life is Really Short, Have Your Life!!
Macbook Pro Retinaが正直重たいので、出先ではiPad miniのSIMフリーモデルに切り替えようとしています。僕の利用用途の90%は満たしてくれるので。 メールとネット 各種データ(Googleドライブ) Excel/Powerpoint Evernote Terminal(SSH) Markdown editor 足りないものがこの２つ。 Sketch3 / Prottのようなツール Sketch3でスケッチ書いてそれを紙芝居のように見せるアプリは流石にない。iOSにサーバーを立てるのは難しいみたい。 開発/実行環境 エディタはあるけど実行環境は無いからね。こればっかりはね。 あとはキーボードとスタイラスペンとカバーを買えば、完璧。 2016.03.25 追記 iPad Pro 9.7が出ました。これで決まりですわ。 以下、自分用メモ。これらをセットアップすればノートP
顧問エンジニア育成入門、作るしか無いかもしれん - Life is Really Short, Have Your Life!!
この種の議論は僕が10年前に通った道だ。10年間何も変わっていない。 今のIT技術者への期待論を見ていると、まるで建築士に、「何でも良いからカッコいい家を作ってよ」とそっくりかえって言い放つ住人の姿のようだ。自分がどんな暮らしをしたいのかも言えないくせに、提案だけを求める。そして、出てきた図面を見ると、「こんな値段じゃ高すぎるよ！」と、必ず文句をつける。 ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ : タイム・コンサルタントの日誌から なんでこうなるかと言えば、ITシステムというのは建物ではなくプラント(工場)だからだ。建物はそれを作るだけで良い。ただ、プラントになれば話は別。どういった情報を収集し、集計もしくは加工し、最終的にどんな価値を提供すれば良いのかを考え無くてはならない。 で、問題は「どういった情報を収集し、集計もしくは加工すれば、経営に資する価値が生まれるのか」を
論理削除の前に別テーブルに切り出せるかどうかを考えよう - Life is Really Short, Have Your Life!!
めっちゃよくまとまっているので、大変助かりました。 blog.mogmet.com t-wada氏の「とりあえず削除フラグはアカン」については、僕も全く同感です。論理削除をしなければならないビジネス上の理由がスッポリ抜け落ちている。「とりあえず削除フラグ立てて何かあれば戻せるようにすればいいンゴ」ってのは論理設計を放棄していると言い換えても良いし、「ユーザーの言葉ではない」という指摘も重要。こちらに書かれています。 ledsun.hatenablog.com じゃ、フラグやめてどーすんのって話。フラグを立てたくて立てる人はおらん(はず)。「削除フラグを追加するとSELECT時に常にWHERE句で削除フラグを引っ掛ける必要があるのでクソ」→「削除日や状態カラムを使おう」では解決にならん。t-wada氏の資料でも解決策で上げられてたけど「×」マークがついてます。下記に変わっても誰も嬉しくないと
ユーザー企業にとってエンジニアを雇用するのはギャンブル - Life is Really Short, Have Your Life!!
Eメール、グループウエア、Officeソフト、レンタルサーバ。用途が限定的なものは便益がすぐにわかるのでどんな企業だって導入できる。でも、業務システムは別。インストールすればいい、契約すればいいというものではない。ハードルがくそみそ高くなる。 経営に資するITを正しく手に入れる手順 自社の事業の全体図(ビジネスモデル)を描き それを支える業務プロセスを描き 何をITに載せる意味があるかを描き ITに落としこむだけの情報を揃えて 実際のITシステムを導入する この5段階のプロセスを踏まねばならない。正しくやろうとしたら、ね。これを提供できる技術がITじゃないってことぐらい、誰でもわかる。何をITに載せる意味があるのかを見出すのが最も大切で、その意味にもベクトルやレベル感がまちまちだ。ある企業は見積のプロセスを強化したいだろうし、ある企業は在庫のリードタイム短縮を目指しているかもしれない。エン
kintoneで業務システムが作れるのか問題 - Life is Really Short, Have Your Life!!
井上さんの記事読んだ。 Yes/Noで言えば、余裕で出来るでしょう。業務という名前を出すと仰々しいけど、そんなの議論するまでもない。 エンジニア不足の時代を見据えたPaaS ITで何かを解決したいヒトはITが当たり前になれば増えていく。でも、ITで課題解決が出来る人は人口不足から始まりIT技術の細分化等で減少していく。ニーズがあっても、供給が足りないという状況は加速していく。井上さんもこのミスマッチについては言及されている。 エンジニアの需給ギャップが問題になるなら、エンジニアがいなくてもITを提供できるようになればいい。プログラムレスで必要なプログラムを手に入れる。そのような狙いもPaaSにはあるんじゃないかなと感じました。 NoSQL的な考え方が基本 1アプリ：1フォーム：1テーブル：n一覧ですから、例えば受注というアプリを作ったとすると、受注と受注明細というデータの塊について、CRU
僕の要件定義アプローチを整理してみる - Life is Really Short, Have Your Life!!
あとでメインのブログにまとめようと思うので、軽めに書いておきます。 先日要件定義の手伝いを頼まれたことも踏まえて、少し自分の考えをまとめたいと思います。 コンピュータに出来ることは少ない 最初に訪れる問題は、システムで行えること・達成できることを大風呂敷を広げた状態で考えていないかどうかの確認です。Amazonと同等のレコメンドエンジンが欲しい！って言われても、はいそうですかと出来る話ではございません。 打ち合わせをしていくと「コンピュータに任せればあとはよしなにしてくれる」という空気感は、必ず所々に出てきます。そこを詰めていかないと認識がずれたままなので、いかにコンピュータでやることを具体化出来るかというのが要件定義の最重要課題だと思います。 業務フローを書こう 細かいのは要らん。決めたいのはシステムを利用する仕事の世界地図。見積から受注までの管理が必要なのか、売上のBIを分析したいのか
ITによるマネジメントの無人化は大正解だと思う - Life is Really Short, Have Your Life!!
小売りや外食など店舗網を急拡大している企業の中には、システムにより業務プロセスを驚くほど完璧に標準化して統制を利かせている企業が何社もある。成長に急すぎてマネジャーの育成が追い付かず、システムに代替させているのだ。ある社長は「理想はマネジメントの無人化」と平然と言っていた。— 木村岳史(東葛人) (@toukatsujin) 2014, 11月 14 これは大正解だと思う。弊社もそうありたいと考えている。 ここでいうマネジメントというのは、受注を請けてから入金に至るまでの一連の流れを属人性を排除して回すことが出来るITシステムを作りたい、ということだと理解している。そうなると、社長は会社にいる意味がなくなり自分の時間を更なる営業活動に使ったり、違う事業に投資できたり、そのようなことが可能になる。 小さな会社ではあるけれど、引合〜受注〜発注〜出荷〜納品〜請求〜入金〜回収までのよくある販売管理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
VLOOKUPって検索値が含まれている列は「左端」じゃないとダメなんだ... - Life is Really Short, Have Your Life!!