中洲卓也

システムエンジニア/ セクションリーダー/ 業務システム開発/ オンプレミス/システム構築/クラウドのスキル習得中/ Azuruに興味があり/ 201804 西野亮廣エンタメ研究所に参加

中洲卓也

システムエンジニア/ セクションリーダー/ 業務システム開発/ オンプレミス/システム構築/クラウドのスキル習得中/ Azuruに興味があり/ 201804 西野亮廣エンタメ研究所に参加

コミュ力を上げて行こう

システムエンジニアって、プロジェクトの関係者、インターフェース先の他システムの担当者、またプロマネやその上の事業部長など、たくさんのお客さまとコミュニケーションを取りながら作業を進めています。 コミュ力はシステムエンジニアにとって大切なスキルのひとつであることは分かっていますが、どうやってコミュ力を磨いていくかを分かりやすく解説してくれている動画があります。 オリラジ 中田敦彦のYouTube大学の２つの動画です。※チャンネル登録者数が現在242万人なのですでに見られた方

中洲卓也

    • お客さんのプロレスを見極めるようになりたい

      ▼先日、要件定義を実施しました お客さまに要件定義のご説明をさせていただいたときの話です。 ４月から要件定義を始めていた案件がありました。お客さまからの要望は「既存システムのライセンス費用が高いためコスト削減して欲しい」ってことだったので、２つの観点で要件定義を進めました。 ・稼働するサーバーを社外からお客さまのデータセンターへ移設して保守費用を削減する ・既存システムを刷新して、業務に必要な機能に絞り込んでOSS化することでライセンス費用をゼロにする もちろん既存システ

      中洲卓也

      • 他者目線で行動するためには

        僕の投稿には、目（耳じゃないよ）にタコができるほど、システムエンジニアは他者目線を持った方がいいよっていう言い回しが登場します。 僕も当てはまると思うんですがSNSで発信していると、ついつい自分が中心になって発信しているという感覚を持ってしまいがちなので、他者目線をもっているだけで物事が良い方向に進むと思ってます。 自分の思いのままに設計したりプログラミングしたりすることは気楽ですが、そんなことしてたら残念ながら独りよがりの使いもんにならないアウトプットになっちゃいますよ

        中洲卓也

        • あいさつはしないよりした方がいいよね

          ここ最近、筋肉質な投稿が続いたんで、ゆるい感じで投稿します。 ▼僕はあいさつをすることが染みついている 僕は中学のとき野球部で、先輩、後輩の上下関係がめちゃくちゃ厳しくて、毎日クソでかい声で先輩にあいさつしていました。たしか校舎の廊下ですれ違ったとこもでっかい声であいさつしていた記憶があります。それは社会人になっても変わってなくて、どこでも比較的大きな声であいさつしています。 ▼あいさつを返してくれない人 たまに僕からあいさつしても、あいさつを返してくれない人がいます。そ

          中洲卓也

          プロジェクトをマネージメントしよう（後編）

          ▼これまでのあらすじ マネージメントは実力だけではなく運とタイミングもあるので、チャンスがあれば挑戦して欲しいです。なぜならマネージメントで得られるメリットは大きく３つあるからです。 メリット１「思考がタスク→プロジェクトに変わる」でプロジェクト思考に変わることで、ミスったときにタスク思考だと悲壮感しかありませんが、それが楽観的になれたりします。 メリット２「自社がビジネスパートナーとなる」では、プロジェクトの体制作りのプラットフォームとして自社を活用することで、モノづくりと

          中洲卓也

          プロジェクトをマネージメントしよう（後編）

          中洲卓也

          プロジェクトをマネージメントしよう（中編）

          ▼前編のあらすじ マネージメントは実力だけではなく運とタイミングもあるので、チャンスがあれば挑戦して欲しいです。なぜならマネージメントで得られるメリットは大きく３つあるからです。 メリット１：思考がタスク→プロジェクトに変わる メリット２：自社がビジネスパートナーとなる（自社のプラットフォーム化） メリット３：お客さまでの評価と自社の評価のズレが解消される（評価の循環） ひとつめのメリット「思考がタスク→プロジェクトに変わる」によってプロジェクト思考に変わることで、ミスった

          中洲卓也

          プロジェクトをマネージメントしよう（中編）

          中洲卓也

          プロジェクトをマネージメントしよう（前編）

          ▼マネージメントについておさらい 過去に投稿したテーマ「車輪の再発明はやめとこうね」では、マネージメントはメンタル（システム開発に取り組む姿勢）が変わるから早期に経験できるといいよね、というコメントをしましたが、それはどちらかというと若手のエンジニアに向けてのメッセージでした。今回のターゲットは、お客さまの評価は高いけど、社内の評価がそれほど高くない、モチベーションが下がり気味のエンジニアです。 ▼チャンスがあれば挑戦してください 僕らのビジネスモデルでマネージメントするこ

          中洲卓也

          プロジェクトをマネージメントしよう（前編）

          中洲卓也

          要件定義で業務を整理しよう

          ▼要件定義に需要があるのか そもそも、要件定義をハックする以前に、SES（お客さまにサービスを提供するビジネスモデル）として、僕みたいな広く薄いクレープの生地みたいな業務知識で外部設計を主戦場としているシステムエンジニアが、要件定義のフェーズに需要があるのかというと「あり」ます。ただ、クセのある業務である「金融」や「経理」の開発経験は薄いので、ご縁がありませんが、それ以外の基幹系（受発注、在庫管理など）や承認系（ワークフロー）などの業務についてはアサインされた実績があります。

          中洲卓也

          要件定義で業務を整理しよう

          中洲卓也

          言語化は世界を広げる作業である

          ▼うまく言語化できないことがある システムエンジニアの観点で、肌感で成果が上がった規則性や法則を言語化（可視化）すれば、誰でも使えるカタチ（システム化）になるというコンセプトで投稿しています。 僕の経験を言葉にしている過程で、ときどきうまく言語化できないことがあります。 うまく言語化できていないということは、つまるところハックする答えが見つかっていないということです。 ▼ルートヴィヒ・ウィトゲンシュタイン 突然登場したこの人物、西洋の哲学者で、以下の代表的な言葉を残してい

          中洲卓也

          言語化は世界を広げる作業である

          中洲卓也

          相手の時間を奪っていることを踏まえて行動しようね

          ▼時間は有限である 僕が20代の時は残業なんて気にしないで気が済むまで仕事ができたので、時間は無限にあると思い込んでいましたが、いま時代は働き改革によって労働時間に制約があります。その限られた時間でこれまで以上の成果（売上）を上げようとすると、時給を上がり、時間に対する価値が上がっていきます。それは、自分たちだけでなく、相手も同じことが言えます。 ▼だからと言って対話することを躊躇することはない 外部設計では、情報をかき集めるために担当者の方との対話が多くなり、 それだけ相

          中洲卓也

          相手の時間を奪っていることを踏まえて行動しようね

          中洲卓也

          フェーズ跨ぎのトリセツ 詳細設計→外部設計 （後編）

          ▼前編のあらすじ 意気揚々と詳細設計から外部設計へ進んだのですが、手持ちの情報だけでは判断できないことがあると、考え込む時間が多くなり、進捗が遅れて高稼働になっていきました。何とかつくった設計書をお客さまにレビューしていただくと、指摘事項が多く、次第に意気消沈。 業務知識が深まれば改善できると思ったが、同じ業務システムのアサインされることはなかったため、業務知識を深めるどころか、浅く広がっていくだけで、改善の糸口がつかめない辛い状況が10年続きました。 ▼改善のきっかけは後

          中洲卓也

          フェーズ跨ぎのトリセツ 詳細設計→外部設計 （後編）

          中洲卓也

          フェーズ跨ぎのトリセツ 詳細設計→外部設計 （前編）

          今回の記事は、僕がシステムエンジニアになるために、おそらく一番苦労したことなので、要点だけ伝えるのではなく長文（ストーリー）となりますが、お付き合いください。 僕の経験上、コーディング→詳細設計のフェーズ跨ぎは難なく進めれるため、その流れでプログラム→詳細設計→外部設計は地続きであると思って、外部設計へ突き進むと大きめの落とし穴があります。 詳細設計と外部設計の作業の違いは、以下の通り考えるか、編集するかの違いだと思ってます。 ・詳細設計：どうやって作るかを考える作業 ・

          中洲卓也

          フェーズ跨ぎのトリセツ 詳細設計→外部設計 （前編）

          中洲卓也

          価値をあげることを意識して行動しよう

          年度末は、お客さまと単価交渉をする時期です。 経済の状況や経営状況にも左右されますが、お客さまからの評価が高いと、単価アップする確度が高いです。だから僕たちはお客さまからの評価をできるだけ高めて、お客さまも気持ちよく単価アップしてくれたら最高ですね。 それでは、そんな状況をどうやって作るか、評価を上げる為にはどうしたら良いか。僕は、価値を上げる事だと思ってます。僕は価値を、付加価値と希少価値の大きく２つに分類しています。 ・付加価値とは、現状にプラスアルファすること。 ・希

          中洲卓也

          価値をあげることを意識して行動しよう

          中洲卓也

          車輪の再発明はやめとこうね

          車輪の再発明とは「広く受け入れられ確立されている技術や解決法を知らずに、同様のものを再び一から作ること」です。 業務アプリ開発での車輪とは、プログラミングだとサンプルソースなどがそれに当たるものですが、詳細設計、外部設計、要件定義については、車輪に該当するものが見当たりませんでした。 ですので、詳細設計、外部設計、要件定義のフェーズについては、これまでゼロベースで苦労して成長するしかありませんでした。そんな苦労した下積みがあるから、いまの自分があるという気持ちは持ってますし

          中洲卓也

          車輪の再発明はやめとこうね

          中洲卓也

          インターフェースはローリスクハイリターン！

          僕の経験上インターフェースは、業務アプリ開発で、トラブルが発生するベスト３にインターフェースはランクインぐらいハイリスクな領域です。インターフェースとは、システム間でやりとりするデータ連携のことで、トラブルの原因となるのが、項目の齟齬、文字化け（文字コードの考慮不足）、連携タイミングの認識があっていないなど色々あります。 このようなトラブルを招いてしまう要因は、大きく２つあると思ってます。 要因１：他者目線が欠けているため 他者目線とは、システムエンジニアの場合、相手のシ

          中洲卓也

          インターフェースはローリスクハイリターン！

          中洲卓也

          改善はマイナス→ゼロ→プラスの2ステップで考えよう

          僕はサービスや運用などを改善するとき、何か新しいことを始めたくなりますが、まずは既存のマイナスを正しいカタチ（ゼロ）にしてから、プラスにすることを考えています。 野球で例えると、試合に勝つために、新たにメジャーリーガーを獲得するのではなく、点を取られなかったら負けることがないので、守備を鍛え直すイメージです。 システムエンジニアの場合だと、「スキル」を改善（スキルアップ）したい場合は、いきなり新しいプログラム言語を学び始めるのではなく、いまの現場で出来ていないことを、出来

          中洲卓也

          改善はマイナス→ゼロ→プラスの2ステップで考えよう

          中洲卓也