2020年4月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

最近のコメント

最近のトラックバック

無料ブログはココログ

2020年4月19日 (日)

Base64で送信されてきたhtmlから画像ファイルの保存と、相対パスに書き換えるプログラム(C#)

ダウンロード - e8b387e69699.zip

ASP.Net(Web Form)で、クライアント側からBase64で送信されてきた画像ファイルを、html文から抜き出して、Webサーバに保存して、相対パスに置き換えるプログラムです。.aspxのプログラムから一部抜粋しています。



using System.Text.RegularExpressions;
using System.IO;

(省略)

#region SaveBase64ToImageAndReplaceUrl/ Base64で送信されたhtmlから画像ファイルをサーバに保存して、URLを置き換える
        /// 
        /// Base64で送信されたhtmlから画像ファイルをサーバに保存して、URLを置き換える
        /// 
        /// html
        /// 置き換えられたhtml
        public static string SaveBase64ToImageAndReplaceUrl(string htmlContent)
        {
            //base64の正規表現 
            string strImg = @"data\:image/(jpeg|png|gif|jpg|bmp);base64\,(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?";

            //正規表現で、Base64を画像ファイルへの相対パスに置き換える
            string content = Regex.Replace(htmlContent, strImg, new MatchEvaluator(ReceiveImage), RegexOptions.Compiled | RegexOptions.IgnoreCase);
            return content;
        }
        #endregion

        #region ReceiveImage / 画像ファイルを受信して、サーバに保存して、相対パスを返す
        /// 
        /// 画像ファイルを受信して、サーバに保存して、相対パスを返す
        /// 
        /// 正規表現で一致したBase64の文字列
        /// 画像ファイルへの相対パス
        private static string ReceiveImage(Match match)
        {
            return ReceiveImage(match.Value);
        }

        /// 
        /// 画像ファイルを受信して、サーバに保存して、相対パスを返す
        /// 
        /// 正規表現で一致したBase64の文字列
        /// 画像ファイルへの相対パス
        private static string ReceiveImage(string imgBase64)
        {
            
            if (imgBase64.Substring(0, 10) != "data:image")
                return imgBase64;

            //拡張子を取得
            string fileExtention = GetImageFileExtention(imgBase64);

            //Base64の先頭部分を取る
            imgBase64 = Regex.Replace(imgBase64, @"data\:image/(jpeg|png|gif|jpg|bmp);base64\,","");

            //バイト配列にしてから、サーバの設置場所にファイルを保存する
            Byte[] imgByteArray = Convert.FromBase64String(imgBase64);

            string SavePath = HttpContext.Current.Server.MapPath("../Upload/");

            string filename = DateTime.Now.ToString("yyyyMMddHHmmssfff") + fileExtention;

            File.WriteAllBytes(SavePath + filename, imgByteArray);

            //相対パスを返す
            return "../Upload/" + filename;
        }
        #endregion

        #region GetImageFileExtention/ 拡張子を取得する
        /// 
        /// 拡張子を取得する
        /// 
        /// Base64のコード
        /// 
        private static string GetImageFileExtention(string imgBase64)
        {
            //ファイルの種類を取得する
            Regex re = new Regex(@"data\:image/(?.*?);base64\,", RegexOptions.IgnoreCase
                                | RegexOptions.Singleline);
            Match match = re.Match(imgBase64);

            //拡張子にして返す
            return "." + match.Groups["fileExtention"].Value;
        }
        #endregion

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 の感想

 

 

『みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」』(日経BP)を読みました。
私も、一応IT技術者で、IT業界に身を置く身ですし、知人もみずほ銀行の2019年に稼働した勘定系システム「MINORI」の開発に関わっており、開発工数の35万人月の何人月かは、彼の分だったので、書店で並んでいるのに気になって読んでみました。

 

構成としては、2019年に稼働した勘定系システム「MINORI」の開発や今後について、2011年3月に発生した、東日本大震災での義援金受付でのシステムトラブル、2002年4月の第一勧業銀行、富士銀行、日本興業銀行の三行合併の直後に起きたシステムトラブルという、この19年に及ぶみずほ銀行のシステムに関することがまとめられています。
2002年4月の第一勧業銀行、富士銀行、日本興業銀行の三行合併の直後に起きたシステムトラブル、については、以前「動かないコンピュータ」で読んだことがあるような気がするので、再録なのでしょう。

ちょっと残念だったのは、2019年に稼働した勘定系システムについて、やや奇麗事で片付けられているなという感じを受けました。35万人月もかけた、プロジェクトでどんないざこざが起きて、どのようになったのかが、あまり見えなかったのは残念です。

このような大規模システムに関わることは、今の職場ではなさそうですが、それでも気になる事、自分の会社でもやらないといけないと思ったことはありましたので、まとめておこうと思います。

 

2019年に稼働した勘定系システムの開発プロジェクト

ユーザ部門が要件定義時に「現状と同じで」というAS ISの要件定義は、禁止して、あるべき業務フローを考えさせた。

ユーザ部門は、本当に今のままでよろしくということが、多いので、これをやったことは、すごいと思います。
私の経験した中で最悪のパターンは、現状システムから出ている帳票の数字の根拠が分からないのに「これでよろしく」という客がいました。

 

4重チェックでシステム品質を高めた

開発エンジニア(第1線)、開発エンジニアのプログラムを側でチェックする(第1.5線)、情報システム部門の視点で品質を満たしているチェックする(第2線)、業務監査の視点で品質をチェックしている(第3線) 業務監査視点でのチェックをするというのは、なかなかできないことだと思いましたが、システムは社の業務に深く関わることですから、基幹システムですと、これぐらいやらないといけないのかもしれません。

要件定義前に建てたスケジュールの見直し

要件定義をした後に工数を見直した結果、当初の想定より長引く工程があって、スケジュールを見直したようですが、通常ですとベンダーの検収に関わったりして、無理やりなスケジュールのまま突き進まなかったのは良かったのかと思います。

 

ユーザ部門に早い段階でシステムの機能確認をさせた

要件通りに作っても、出来上がったシステムを見て、「あーじゃない、こーじゃない」とユーザ部門が言うのが常ですが、それを早い段階でつぶしていったのだなと思いました。

 

システム切り替え時も入念な準備と訓練を行っていた

システム切り替え時の進捗管理ツールまで作っていたらしいですが、そこまでできなくても事前準備を入念にやったりはできるかなと思います。移行時の「トラブルを想定した訓練も行ったりしていたようで、このあたりは、自分の会社でもやっておいた方が良いかもしれません。

2011年3月の震災直後のトラブル

システムの老朽化対策をしていかないといけない

1回作ったから終わりでは無くて、新規開発ではなくても適宜改修作業はしていかないといけないと思いました。

トラブル発生時の手順や判断基準を予め作っておかないといけない

システムトラブル時に、その場で手順を作ったりせずに、事前に手順や切り戻しのタイミング、役員への連絡するタイミングなどを作らないといけないと思いました。

システムがブラックボックス化するとトラブルが長引く

退職者からの引継ぎが十分でなかったりして、システムの全容を把握できていなかったりすると、ブラックボックス化してトラブルの要因やトラブル解決に時間がかかったりしてしまうようになってしまうなと、心当たりがあることが書いてありました。

 

販売サイトへのリンク

e-honへのリンク
hontoへのリンク

2020年3月 8日 (日)

ODP.NET Managed Driverを用いた、Oracle接続用クラスのサンプル(C#)

.Net Framework4以降のバージョンで、オラクルに接続するためのドライバで、Oracleクライアント不要のドライバ ODP.NET Managed Driverが提供されています。

Oracleクライアントがらみで、度々面倒なことが起きたので、プログラムを書き直そうという話になり、元になるサンプルプログラムを書いたので、参考に載せておきます。


using System.Data;
using System.Configuration;
using Oracle.ManagedDataAccess.Client;

namespace CommonClass.DbAccess
{
    #region データベースに対する問い合わせを実行するクラス
    /// 
    /// データベースに対する問い合わせを実行するクラス
    /// 
    public class ExecuteDb
    {
        protected bool _isBeginTrans = false; //接続中 true、切断中 false

        #region プロパティ OracleConnection

        private OracleConnection _cnnDb;

        /// 
        /// プロパティ OracleConnection
        /// 
        public OracleConnection CnnDb
        {
            get { return this._cnnDb; }
            set { this._cnnDb = CnnDb; }

        }
        #endregion

        #region プロパティ OracleTransaction
        private OracleTransaction _tran;

        /// 
        /// Oracle トランザクション
        /// 
        public OracleTransaction Tran
        {
            get { return this._tran; }

            set { this._tran = Tran; }
        }
        #endregion

        #region コンストラクタ
        /// 
        /// コンストラクタ
        /// 
        public ExecuteDb()
        {
            this._cnnDb = new OracleConnection(GetOracleConnectionString());
        }

        /// 
        /// コンストラクタ
        /// 
        /// Oracle Connection
        public ExecuteDb(OracleConnection cnnDb)
        {
            this._cnnDb = cnnDb;
        }
        #endregion


        #region デストラクタ
        /// 
        /// デストラクタ
        /// 
        ~ExecuteDb()
        {

            if(!this._isBeginTrans)
            {
                ///openしていたら、closeする
                if (this._cnnDb.State == ConnectionState.Open)
                {
                    this._cnnDb.Close();
                }
            }

            
        }
        #endregion

        #region GetOracleConnectionString/Configから接続文字列を取得
        public static string GetOracleConnectionString()
        {
            return ConfigurationManager.AppSettings["OracleConString"].ToString();
        }
        #endregion


        #region  BeginTrans トランザクションを開始する
        /// 
        /// トランザクションを開始する
        /// 
        public void BeginTrans()
        {
            if(! this._isBeginTrans)
            {
                //切断していたら再接続
                if(this._cnnDb.State == ConnectionState.Closed)
                {
                    this._cnnDb.Open();
                }
            }

            //前回のトランザクションを破棄
            if(this._tran != null)
            {
                try
                {
                    this._tran.Rollback();
                }
                catch (Exception ex)
                {
                    this._tran.Rollback();
                }
            }

            this._tran = this._cnnDb.BeginTransaction();
            this._isBeginTrans = true;
        }
        #endregion

        #region Commit/コミットを実行する、切断する
        /// 
        /// コミットを実行する、切断する
        /// 
        public void Commit()
        {
            if(this._isBeginTrans)
            {
                this._tran.Commit();

                this._tran.Dispose();

                if(this._cnnDb.State == ConnectionState.Open)
                {
                    this._cnnDb.Close();
                }

                this._isBeginTrans = false;
            }
        }
        #endregion


        #region Rollback/ロールバックを実行して、切断する
        /// 
        /// ロールバックを実行して、切断する
        /// 
        public void Rollback()
        {
            if (this._isBeginTrans)
            {
                this._tran.Rollback();

                this._tran.Dispose();

                if (this._cnnDb.State == ConnectionState.Open)
                {
                    this._cnnDb.Close();
                }

                this._isBeginTrans = false;
            }
        }
        #endregion

        #region RunSql/クエリ以外の処理実行
        /// 
        /// クエリ以外の処理実行
        /// 
        /// OracleCommand
        /// 処理件数
        public int RunSql(OracleCommand cmd)
        {
            try
            {
                int result = 0;

                cmd.Connection = this._cnnDb;

                //トランザクションが開始されていたら、開始する
                if (this._isBeginTrans)
                {
                    cmd.Transaction = this._tran;
                }

                result = cmd.ExecuteNonQuery();

                return result;
            }
            catch (OracleException ex)
            {
                throw new Exception(ex.Message);
            }
            catch (Exception ex)
            {
                throw new Exception(ex.Message);
            }
            finally
            {
                if(! this._isBeginTrans)
                {
                    if(cmd.Connection.State == ConnectionState.Open)
                    {
                        cmd.Connection.Close();
                    }
                }

            }

            
        }
        #endregion

        #region RunSelect/クエリを実行する
        /// 
        /// クエリを実行する
        /// 
        /// OracleCommand
        /// DataTable
        public DataTable RunSelect(OracleCommand cmd)
        {
            DataTable dt = new DataTable();

            try
            {
                cmd.Connection = this._cnnDb;

                //トランザクションが開始されていたら、開始する
                if (this._isBeginTrans)
                {
                    cmd.Transaction = this._tran;
                }

                if(_isBeginTrans)
                {
                    //トランザクション中の場合
                    cmd.Transaction = this._tran;
                }
                    
                using (OracleDataAdapter da = new OracleDataAdapter(cmd))
                {
                    da.Fill(dt);
                }
                return dt;
            }
            catch(OracleException ex)
            {
                throw new Exception(ex.Message);
            }
            catch (Exception ex)
            {
                throw new Exception(ex.Message);
            }
        }
        #endregion
    }
}
#endregion


2020年2月 6日 (木)

仕事論 「水曜どうでしょう」2人の名物ディレクターが働き方を語る 藤村忠寿、嬉野雅道著を読んだ感想・書評

仕事論 「水曜どうでしょう」2人の名物ディレクターが働き方を語る(藤村忠寿、嬉野雅道著 総合法令出版)を読んだ感想・書評になります。

 

 

「水曜どうでしょう」で、大泉洋さんやミスターこと鈴井貴之さんより目立つ、名物ディレクターの藤村君とカメラ担当だった嬉野君が書いた本になります。

テレビマンとして、ビジネスマンとしての藤村忠寿さんと嬉野雅道さんの一面を読みとれる本となっています。会社(この場合はテレビ局)や、未だに新作が発表される「水曜どうでしょう」の仕事としての考え方なんかがまとめられています。

メディア関係でない職種の私でも、「ああなるほど」と思うところがあるので、いくつか書いておこうと思います。

  • 人は組織に属して、生きていく、フリーで生きていける人も何らか他者と協力関係を築いて生きている
  • 出来ないことは、しっかり根拠をもって出来ないと言う
  • しっかり計算された企画書だけみて、承認するような上司はいけない、企画書を出した部下の熱意を見ている
  • 普段からチーム内で話ができていれば、会議はいらない
  • 組織を変えるには、一人だとわがままだと思われるから、「共感する人」とやらなければいけない、少なくとも二人いればいい。
  • 現場で働く人達が、意志をもって働きやすい環境を作って、自分で考えて、仕事を楽しい物にしていけば、会社の雰囲気も変わっていく。
  • ブラック企業でなければ、20代は我慢して経験を積んだ方がいい。
  • 「やりたい仕事」については、その思いをずっと持ち続けないと、会社の中で何もできない人間になっていまう。
  • 組織を変えられるのは、経験を積んだ30代になってから、40代からは下の世代に前例を示さないといけない
  • 会社に属している肩書きを利用する。
  • 市場調査やマーケティングに頼るのではなく、自分自身が売れると思ったものを作った方がいい
  • トラブルが起きたときは、トラブルを収めるだけでなく、原因を追究しないと、自分の判断基準を作れない
  • 今自分たちの状況の中で、できることをやっていく
  • 失敗をネガティブに捉えない、ミスから新たなものができるかもしれない
  • 選択肢に迷ったら、とりあえず一つを選んでやってみる。失敗しても何から拾い物はある。
  • 客観的に物事をみれる人がいるということは、大きな意味がある。
  • 自分で考えて、自分で判断していく仕事は、最終的に人生と重なる
  •  

販売サイトへのリンク

e-honへのリンク

hontoへのリンク

 

2020年2月 3日 (月)

バッター液で衣をつけたチキンカツ

以前、NHKの「ガッテン!」で、冷めてもサクサクのトンカツというものが、番組に取り上げらていました。

よく、チキンカツを作るので、チキンカツで試してみました。

A0043_20200203081101

材料

  • 鶏むね肉・・・1枚
  • 塩・・・少々
  • 胡椒・・・少々
  • パン粉・・・適量

バッター液(NHK、試してガッテン! から引用)

  • 小麦粉・・・大さじ4
  • 卵・・・1個
  • 水・・・小さじ2

作り方
下準備


1.鶏むね肉をチキンカツにするために、程よい大きさに切る(2枚~3枚に程度にする)
2.1で切った鶏むね肉が平たくなるように棒などで叩く
3.塩・胡椒で下味を片面につける

バッター液の作成と衣をつける
4.材料をダマができないようにまぜる
5.3で下味をつけた、むね肉を両面、バッター液につける
6.鶏むね肉にパン粉を付ける
 
揚げる
7.油を180℃に熱して、そこに6でパン粉をつけた鶏むね肉を入れる
8.両面揚げて、中まで火が通ったら、油からあげる

 

食べてみて、確かに冷めてもサクサクしていておいしかったです。

2019年12月17日 (火)

photolibrary(ストックフォト)で販売している写真素材 青いボトルに入った水

ストックフォトサイトのphotolibraryで販売している、青いボトルを撮った写真を載せておきます。

写真をクリックすると、販売ページに移動します。

スピリチュアルが好きな知り合いからは、ホ・オポノポノのブルーソーラーウォーターのようだと言われたのですが、スピリチュアルについては良く分からいので、そうなんだぐらいしか思わなかったですが、調べてみると、なるほどと思いました。

家に青いボトルがあって何となく奇麗だなぐらいで撮ったものです。

 

1.青空と、青いボトルに入った水


青空と青いボトルに入った水  写真素材


青空と青いボトルに入った水  写真素材

 

2.太陽光に照らされた青いボトルに入った水


太陽光に照らされた青いボトルに入った水  写真素材


太陽光に照らされた青いボトルに入った水  写真素材

2019年11月27日 (水)

システムの商談時のリスク診断の指標について

SEマネージャーのためのプロジェクト管理」(桜田孝 著 青山ライフ出版 )を読んだ中で、参考になりそうなところがいくつかあったのですが、その中でプロジェクトのリスク総合診断というところで、商談時のリスク診断というところを備忘録がてらまとめておこうかなと思います。

商談を開始するときのリスク管理で、リスクが大きいは、コンティンジェンシー予算を増やしたり、リスクを軽減したり、最悪、商談を辞退する必要性があるとしています。

リスクを確認する方法が、書かれていますが、そこを引用しますと


次の9つのうち,3つ以上該当するプロジェクトは、問題を引き起こす可能性が高いとのこと。
1.新規顧客からの受注
2.新システムの要件が「現行どおり」となっている
3.新技術や経験のない処理方式を採用している
4.IT企業と顧客の間で一括請負契約を結んでいる
5.IT企業のプロジェクト原価率が95%以上
6.開発期間が短納期
7.プロジェクト・マネージャーが類似システムの開発経験なし
8.IT企業が下請けに90%以上回している
9.顧客の要件定義能力に問題がある
(「日経コンピュータ 2010/1/15 NTTデータ 岩本副社長(当時)」からの出典とのこと)

さらに著者は経験的に下記の項目を上げています。

10.プロジェクト・マネージャーが過大な自信を持っている
11.ベンダとユーザの間の関係が"馴れ合い"で相互に甘えがある
12.ユーザに過大な期待を売り込んだ「何でもやります」
13.決めたことを一言でひっくり返す「独裁者」がいる
14.既存ベンダが辞退した案件である

『』が参照文献からの引用・一部変更

あと私独自に指標になるかなと思うのを上げますと
15.顧客側のTOPが独断で導入を決めたりして、具体的な要件が無い
16.顧客側の要求が、「完璧な資料を持ってこい」などと要求が高い、ミスがあると激昂したりする
17.経営層が極端が政治的思想を持っていたり、宗教への過度の信仰をしていて、それを社内に徹底している。
18.社風がワンマン企業の会社
19.パッケージ導入をする際に、その業界、業種、規模に導入するのが初めて
20.パッケージへのカスタマイズが多数生じる

チェックする項目は、最大10件程度が良いとしています。(3~4割該当したら、危険と言う感じでしょうか)

 

ホントにあった、炎上した案件に当てはめてみる

ある人材派遣会社への、管理システムを導入プロジェクト(大炎上した)で上の20項目を当てはめようと思います。(ちょっと多いですが)

1.新規顧客からの受注
 →該当

2.新システムの要件が「現行どおり」となっている
 →非該当(あれもやりたい、これもやりたいになっていた)

3.新技術や経験のない処理方式を採用している
 →該当(大規模案件だからとあれこれ、盛沢山になっていた)

4.IT企業と顧客の間で一括請負契約を結んでいる
 →非該当

5.IT企業のプロジェクト原価率が95%以上
 →非該当

6.開発期間が短納期
 →非該当(長期間だったが、後から考えたら足りなかった)

7.プロジェクト・マネージャーが類似システムの開発経験なし
 →該当(技術、分野とも初めてだった、それで余計なことをして火に油を注いだ)

8.IT企業が下請けに90%以上回している
 →非該当(オフショア含めて、50%ぐらいですかね)

9.顧客の要件定義能力に問題がある
 →該当(要件定義を絞れていない、開発側がまとめたものを自分たちは成果を評価するような感じだった)


10.プロジェクト・マネージャーが過大な自信を持っている
 →該当

11.ベンダとユーザの間の関係が"馴れ合い"で相互に甘えがある
 →非該当

12.ユーザに過大な期待を売り込んだ「何でもやります」
 →該当(担当営業は、大風呂敷を広げる人だった、自分では閉じない)

13.決めたことを一言でひっくり返す「独裁者」がいる
 →該当(開発側のPMと顧客側の責任者が独裁者、このせいで病気になったメンバーがいる)

14.既存ベンダが辞退した案件である
 →該当(既存ベンダーは、置き換え案件でも何もしてこなかった)


15.顧客側のTOPが独断で導入を決めたりして、具体的な要件が無い
 →非該当

16.顧客側の要求が、「完璧な資料を持ってこい」などと要求が高い、ミスがあると激昂したりする
 →該当(顧客側の責任者は資料にミスがあると、開発側の社長を呼び出して恫喝している)

17.経営層が極端が政治的思想を持っていたり、宗教への過度の信仰をしていて、それを社内に徹底している。
 →該当(左右どちらかに振り切れています)

18.社風がワンマン企業の会社
 →該当(役員が急に馘になるような会社らしい)

19.パッケージ導入をする際に、その業界、業種、規模に導入するのが初めて
 →非該当

20.パッケージへのカスタマイズが多数生じる
 →該当(パッケージがあることが逆に足を引っ張った)

全体で12件該当

引用元にあったNTTデータの副社長が書いた項目(1~9)で、4項目該当、該当が3つ以上あると炎上する確率が高いらしいので、商談開始の時にこのようなリスク管理ができていれば、辞退するという手もあったかと思います。
(もしくは、要件定義後の再見積もりの段階で辞退するなど)

このような項目を使って、リスク分析を商談の時にすれば、効果はあるかと思います。

ただ、営業の評価が受注金額ベースで、その受注したプロジェクトが最終的にどうなったかを評価しない限り、改善できないだろうなと思っています。それと、戦略的失注をしたときに、マイナス評価にならないような会社の制度がないとダメでしょうね。

「SEマネージャーのためのプロジェクト管理」を読んだ感想

SEマネージャーのためのプロジェクト管理(桜田孝 著 青山ライフ出版 ISBN 978-4-434-21802-6)を読んでみました。

SEと書いてあるので、システム関係のプロジェクト管理について書いてあります。

著者の紹介を見ると、著者は三菱電機の相当大きいプロジェクトを担当していていたようなので、そのことを留意して読まないと、いけないかなと思います。

過剰なプロジェクト管理は、プロジェクトの停滞を招くかと思いますので、このプロジェクトではどのような管理方法が良いか、進め方が良いかは考えていかねばならないかと思いますので。

内容は、プロジェクト管理の、教科書と言う感じで、プロジェクト管理に関する様々な、手法をプロジェクト計画~完了までを網羅したものとなっています。

大学の教科書や社内の研修資料と言った感じで、硬めな雰囲気の本で、いくつかプロジェクト管理を経験した人向けの内容かなと思います。
自分の経験を踏まえたうえで「こういう方法もあるんだ」等と思うことがあるかと思います。

ベンダー向けの本とは思いますが、導入先企業のプロジェクトの担当者が読んでもためになるかなと思います。システム会社はこういうものなのか、と思うと思います。この本でも、ユーザー側の協力が重要と度々言及されています。ユーザーのプロジェクトに関わる姿勢についてもことによっては、リスクとなると書いてあります。(間違った「お客様は神様」精神の担当者だったら、激怒するかもしれませんが)

また、「余談」というコーナーがところどころでてきて、著者が経験したり、見てきたプロジェクトの話(失敗が多い印象)が本書の本当の良さだと私は思います。

2019年11月20日 (水)

「本屋の新井」を読んでの感想

「本屋の新井」(新井見枝香 著 講談社 ISBN 978-4-06-513413-9)

有名な書店員、新井見枝香さんの2冊目のエッセイです。
(2019年11月現在、三省堂書店に在籍だと思っていたらHMVに転職されていました)

一冊目(「探しているものは そう遠くはないのかもしれない」)は、私生活の話題が多かったですが、今回のは、書店員としての話題が多めです。
本の紹介が多いですが、書店の内部事情を書いているところが面白かったです。

その一部
・図書カードが書店には利益にならないこと
・POPについての話
・書店で本を購入したときに入れてくれる袋が書店には結構負担になっている話
・棚整理の話

これ読むと、書店で、本を棚から手にとって買うのを止めたときは、元の位置に戻したり、買った書籍を袋に入れてもらうのは止めようと思ったりします。

近所の本屋のお姉さん(年上の女性はお姉さんというのが礼儀)も、袋やカバーを毎回辞退していたら、感謝されたのは、こういう理由があったのかと思ったりしました。

本の紹介もされているので、紹介されている中で、気になった本は読んみるのも良いかと思います。

2019年11月 7日 (木)

10年以上社会人をやって思った、経営者一族が会社を牛耳っている、ブラック企業の特徴と見分け方

ブラック企業は表からだと分からないので、その見分け方というのは、就職・転職活動をする人には是非とも知りたいところ。

求人に「若手が活躍」、「アットホームな職場」、「夢」「やる気」なんていうキラキラした言葉が並んでいると危険だというが、良く言われています。

他にも色々な見分け方があるかと思いますが、私自身の経験で思った経営者が会社を私物化しているところはブラック企業の可能性が高いと思ったので、その特徴と見分け方を2つ載せておこうと思います。

経営者一族に権力が集中している

経営者一族に権力が集中している会社は、社内で独裁体制になっていて危ないと思います。

具体的には、役員に経営者一族の名前が連なっていたりすると危ないです。

また、上場企業限定になりますが、四季報に掲載されている株主構成に、大株主に経営者一族や、経営者一族がやっている資産管理会社が複数出ている場合は、要注意だと思います。

こうなっていると会社を一族で牛耳っていることが多いですし、従業員の命よりも、経営者一族のカネが大事という会社ができあがります。

そういう会社は、業績を良くするために、無理を従業員に強いて、厳しい売り上げノルマを課したり、経営者一族が従業員の生殺与奪権を握っているような振舞いをしたりしていました。

非上場の場合だと分かる術が無いのと、中小企業だとそもそも一族経営が多いので、そこは留意してもらえたらと思います。

経営者の思想を押し付けている

経営者が書いた標語が社内の至る所に貼ってあったり、経営者自身の書いた本や、思想にあった本が並んでいるような会社も危険なことが多いように思います。
経営者自身が、「軍国主義復活」、「共産主義革命」、「ある宗教の信者」という思想でも、会社に持ち込まなければいいのですが(公安調査庁としては一部は良くないと思いますが)、会社に持ち込んで従業員におしつけているのは、会社を私物化していて良くないと思います。

経営者は、従業員を兵隊、捨て駒、信者候補ぐらいに思っているかもしれません。

私は、右系の会社内部を見たことがあるのですが、「大日本帝国の悪い部分」を濃縮したような会社でした。

«ストックフォト(photolibrary)で販売している写真素材 変わったメロンパン