unixtimeを日付に変換するのは rrdtoolを使う際には さけてとおれないよね
お仕事
gitちゃんとやらなきゃな
pythonとvueをさわってみる
vueはつかえそうだね。たしかに最低限の動きだし
ユーザとしてもレスポンス早いから作業時間軽減にもなるし
rrdtoolをさわってみた
出力時間が unixtime 表示なのでわかりにくい
情報取得後に、日付変換する必要あったのね
unixtimeを日付に変換するのは rrdtoolを使う際には
さけてとおれないよね
めんどうだけど、rrdファイルには必要最低限の生情報だけいれとくから
あとは自分たちで変換してねというスタンスよね
オフショアといって、近隣諸国にＩＴ開発を外だしするのよくないよね。次世代を担うＩＴ開発の若手が国内から育ってくる機会が減るんだよね
オフショアといって、近隣諸国にＩＴ開発を外だしするのよくないよね。次世代を担うＩＴ開発の若手が国内から育ってくる機会が減るんだよね
ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている
まあ事業をITを前提としたものに変えていこうという話だから経営者の意識が変わらなければ何も起こらない訳で。 ビジネス
労働者に還元しなかった。これ
DXってのは、デジタルがコモディティ化する「前」に完成した「ビジネスの型」を、デジタルを前提としてリデザインすること
“0-1のフェーズは人気で、1-10のフェーズになると急に不人気になる。具体的には社員数が20名くらいになるともう”
頭からケツまで手順の決まってる作業なら、人員を注ぐほど効率は上がるだろう。クリエイティブな分野ではそうはいかない。
アジャイル開発して2週間に1度基本的にリリースするようにするのはシステムを維持するために必要なことだなぁと思った。
「コンプライアンス」を重視するはずのこの国が、労働法規に関してだけそんなもの無かったかのように振る舞いのは何故か。
派遣や実習生をどんどん広げて経団連の言うこと聞いてたら当然こうなる。賃金が下がってて内需が増えるわけない
スコープ＝プロジェクトの作業範囲。スコープが固まるタイミングを握っておく。プロジェクトの最小単位はアクションと体制
こういう伝統的な SIer の現場の不幸は、エンジニアリングを事務手続きとして回収してるところにあると思うんだよね
良い人がいると現場の改善が進むし、本格的なシステム導入時にも現場とシステム会社の間で通訳として役に立つと思う。
ドラマで見たところだ！他の社員から何してるかわからないコンサルって言われてるの！
「問題の根本は「人」と「制度や仕組み (プロセス)」にある。」
ソフトウェアプロジェクトの工期は工数の三乗根に比例する
DXをやるためには開発者体験としてのDXも必要。コンサル頼むのでなく自前でエンジニア気質もつことが大事
DXをやるためには開発者体験としてのDXも必要。コンサル頼むのでなく自前でエンジニア気質もつことが大事
本当に胡散臭い人間おおいからな
現場にあってないこと言う人間多い
コンサルが金食い虫…そういう人達もいるけど、コンサルだからこそ金払う価値のある人達も多いのよ？
クライアントが知識不足だとこうやって無価値なコンサル費用を支払うことになる。結局自前で知識をつけるしかないのよ
気質としてはシリコンバレーだけ特殊な気がする。法律/規制を変えるプロセスが必要で各国で特色が出てるのはあると思う
採用目的だろうがなんだろうが、自分たちの組織文化をオープンにして一緒に働くチームを作っていくのすごく大事な時代。
以前勤めてたSIerはVSS,Notes,一太郎だったなぁ。その後どうなったかggったら吸収合併されて消滅してた
コンサルの是非は置いといて鬱病に片足突っ込んでると思う
コンサルなんて良心が1ミリでもある人間なら、長く続くわけがないって印象
芸能人の話もプログラムの話も風俗の話も経済の話もできる方が豊かな気はする。
DXをやるためには開発者体験としてのDXも必要というのは腹落ちした
“API をオープン化することを重要視しています。” / 死なない程度の感電は好奇心の表れとして捉えたらいいのか
タクシーって“需要供給バランスを守るため”として営業エリアが制限されていたりと保護が強くて利用者には不便なまま
辞めてくれるだけまだマシ やりかた変えなくて仕事も覚えないし、辞めもしない これが一番多くてやっかいなんだよな
エンジニアは転職先がたくさんあるのでクソ環境で我慢するインセンティブが無いからヤバい現場で見かけないだけかと。
負債使ってレバレッジかけるなら、返済計画ちゃんとしろよなっていう。初期開発の突貫工事が借金だという認識ないのか
観測範囲では、人脈で転職、非IT企業のDX部門強化に直応募、アクセンチュアを筆頭としたIT寄りコンサル、て感じ
業務コンサルとして入ったなら要件整理、業務フロー、業務プロセス整理とか業務観点で強いならやれるかもね
コンサル下流のシステムエンジニアで近くでコンサル見るけど、上司捕まえて無理やりレビューもらったり、システム無理ならウザいくらいお客さんと仲良くなれる人だけがコンサルタントになれるイメージがある。
ふつうに考えるとソフトウェアに限らず、人数を増やすとコミュニケーションコストが増大し、何らかの管理法がなければ上手く行かないのは自明であり、早く終わらないのかとかにしないと、勿体ない。
本当に理解して欲しい層に届くかどうかが問題
気合で何とかなると思っている層の存在をどうするか。 分割や段階的に開発する以外に、半完成部品の組み合わせという方法も良さそう
もともと技術力は凄いけど空気を読まないちょっと面倒臭いハッカーみたいなイメージだったのが、短期間で官公庁や大企業の事務方の事情も踏まえた組織改革の人みたいになったのすごいな。いまや人望もある。
消息を聞くのは、CTO・技術営業・エバンジェリスト・大企業の情シスとか。エンジニアの場合そのまま残ってる人が多いなぁ。そもそも転職市場でお世話になる必要がなさそう。非IT企業の神になるのは、オススメ。
業務改善って結局会社のカルチャーを変えることだから。ツール導入や自動化しても「自動処理の成功を目視でチェックし、チェックシートに記入。その後上長の承認を得る」とかしてたら自動化の意味まったくないし・・
業務コンサルとして入ったなら、要件整理、業務フローとか業務観点でのテスト作成かレビュー等があると思うのでそちらで知見を生かせる(たまに業務すら熟知してないとかシステム音痴すぎるユーザーはいるけども…)
