記事一覧
コミュ力を上げて行こう
システムエンジニアって、プロジェクトの関係者、インターフェース先の他システムの担当者、またプロマネやその上の事業部長など、たくさんのお客さまとコミュニケーションを取りながら作業を進めています。
コミュ力はシステムエンジニアにとって大切なスキルのひとつであることは分かっていますが、どうやってコミュ力を磨いていくかを分かりやすく解説してくれている動画があります。
オリラジ 中田敦彦のYouTube
お客さんのプロレスを見極めるようになりたい
▼先日、要件定義を実施しました
お客さまに要件定義のご説明をさせていただいたときの話です。
4月から要件定義を始めていた案件がありました。お客さまからの要望は「既存システムのライセンス費用が高いためコスト削減して欲しい」ってことだったので、2つの観点で要件定義を進めました。
・稼働するサーバーを社外からお客さまのデータセンターへ移設して保守費用を削減する
・既存システムを刷新して、業務に必要な機
他者目線で行動するためには
僕の投稿には、目(耳じゃないよ)にタコができるほど、システムエンジニアは他者目線を持った方がいいよっていう言い回しが登場します。
僕も当てはまると思うんですがSNSで発信していると、ついつい自分が中心になって発信しているという感覚を持ってしまいがちなので、他者目線をもっているだけで物事が良い方向に進むと思ってます。
自分の思いのままに設計したりプログラミングしたりすることは気楽ですが、そんなこ
あいさつはしないよりした方がいいよね
ここ最近、筋肉質な投稿が続いたんで、ゆるい感じで投稿します。
▼僕はあいさつをすることが染みついている
僕は中学のとき野球部で、先輩、後輩の上下関係がめちゃくちゃ厳しくて、毎日クソでかい声で先輩にあいさつしていました。たしか校舎の廊下ですれ違ったとこもでっかい声であいさつしていた記憶があります。それは社会人になっても変わってなくて、どこでも比較的大きな声であいさつしています。
▼あいさつを返し
プロジェクトをマネージメントしよう(後編)
▼これまでのあらすじ
マネージメントは実力だけではなく運とタイミングもあるので、チャンスがあれば挑戦して欲しいです。なぜならマネージメントで得られるメリットは大きく3つあるからです。
メリット1「思考がタスク→プロジェクトに変わる」でプロジェクト思考に変わることで、ミスったときにタスク思考だと悲壮感しかありませんが、それが楽観的になれたりします。
メリット2「自社がビジネスパートナーとなる」では、
プロジェクトをマネージメントしよう(中編)
▼前編のあらすじ
マネージメントは実力だけではなく運とタイミングもあるので、チャンスがあれば挑戦して欲しいです。なぜならマネージメントで得られるメリットは大きく3つあるからです。
メリット1:思考がタスク→プロジェクトに変わる
メリット2:自社がビジネスパートナーとなる(自社のプラットフォーム化)
メリット3:お客さまでの評価と自社の評価のズレが解消される(評価の循環)
ひとつめのメリット「思考
プロジェクトをマネージメントしよう(前編)
▼マネージメントについておさらい
過去に投稿したテーマ「車輪の再発明はやめとこうね」では、マネージメントはメンタル(システム開発に取り組む姿勢)が変わるから早期に経験できるといいよね、というコメントをしましたが、それはどちらかというと若手のエンジニアに向けてのメッセージでした。今回のターゲットは、お客さまの評価は高いけど、社内の評価がそれほど高くない、モチベーションが下がり気味のエンジニアです。
要件定義で業務を整理しよう
▼要件定義に需要があるのか
そもそも、要件定義をハックする以前に、SES(お客さまにサービスを提供するビジネスモデル)として、僕みたいな広く薄いクレープの生地みたいな業務知識で外部設計を主戦場としているシステムエンジニアが、要件定義のフェーズに需要があるのかというと「あり」ます。ただ、クセのある業務である「金融」や「経理」の開発経験は薄いので、ご縁がありませんが、それ以外の基幹系(受発注、在庫管理
言語化は世界を広げる作業である
▼うまく言語化できないことがある
システムエンジニアの観点で、肌感で成果が上がった規則性や法則を言語化(可視化)すれば、誰でも使えるカタチ(システム化)になるというコンセプトで投稿しています。
僕の経験を言葉にしている過程で、ときどきうまく言語化できないことがあります。
うまく言語化できていないということは、つまるところハックする答えが見つかっていないということです。
▼ルートヴィヒ・ウィトゲ
相手の時間を奪っていることを踏まえて行動しようね
▼時間は有限である
僕が20代の時は残業なんて気にしないで気が済むまで仕事ができたので、時間は無限にあると思い込んでいましたが、いま時代は働き改革によって労働時間に制約があります。その限られた時間でこれまで以上の成果(売上)を上げようとすると、時給を上がり、時間に対する価値が上がっていきます。それは、自分たちだけでなく、相手も同じことが言えます。
▼だからと言って対話することを躊躇することはない
フェーズ跨ぎのトリセツ 詳細設計→外部設計 (後編)
▼前編のあらすじ
意気揚々と詳細設計から外部設計へ進んだのですが、手持ちの情報だけでは判断できないことがあると、考え込む時間が多くなり、進捗が遅れて高稼働になっていきました。何とかつくった設計書をお客さまにレビューしていただくと、指摘事項が多く、次第に意気消沈。
業務知識が深まれば改善できると思ったが、同じ業務システムのアサインされることはなかったため、業務知識を深めるどころか、浅く広がっていくだ
フェーズ跨ぎのトリセツ 詳細設計→外部設計 (前編)
今回の記事は、僕がシステムエンジニアになるために、おそらく一番苦労したことなので、要点だけ伝えるのではなく長文(ストーリー)となりますが、お付き合いください。
僕の経験上、コーディング→詳細設計のフェーズ跨ぎは難なく進めれるため、その流れでプログラム→詳細設計→外部設計は地続きであると思って、外部設計へ突き進むと大きめの落とし穴があります。
詳細設計と外部設計の作業の違いは、以下の通り考えるか
価値をあげることを意識して行動しよう
年度末は、お客さまと単価交渉をする時期です。
経済の状況や経営状況にも左右されますが、お客さまからの評価が高いと、単価アップする確度が高いです。だから僕たちはお客さまからの評価をできるだけ高めて、お客さまも気持ちよく単価アップしてくれたら最高ですね。
それでは、そんな状況をどうやって作るか、評価を上げる為にはどうしたら良いか。僕は、価値を上げる事だと思ってます。僕は価値を、付加価値と希少価値の大
車輪の再発明はやめとこうね
車輪の再発明とは「広く受け入れられ確立されている技術や解決法を知らずに、同様のものを再び一から作ること」です。
業務アプリ開発での車輪とは、プログラミングだとサンプルソースなどがそれに当たるものですが、詳細設計、外部設計、要件定義については、車輪に該当するものが見当たりませんでした。
ですので、詳細設計、外部設計、要件定義のフェーズについては、これまでゼロベースで苦労して成長するしかありませんで
インターフェースはローリスクハイリターン!
僕の経験上インターフェースは、業務アプリ開発で、トラブルが発生するベスト3にインターフェースはランクインぐらいハイリスクな領域です。インターフェースとは、システム間でやりとりするデータ連携のことで、トラブルの原因となるのが、項目の齟齬、文字化け(文字コードの考慮不足)、連携タイミングの認識があっていないなど色々あります。
このようなトラブルを招いてしまう要因は、大きく2つあると思ってます。
要
改善はマイナス→ゼロ→プラスの2ステップで考えよう
僕はサービスや運用などを改善するとき、何か新しいことを始めたくなりますが、まずは既存のマイナスを正しいカタチ(ゼロ)にしてから、プラスにすることを考えています。
野球で例えると、試合に勝つために、新たにメジャーリーガーを獲得するのではなく、点を取られなかったら負けることがないので、守備を鍛え直すイメージです。
システムエンジニアの場合だと、「スキル」を改善(スキルアップ)したい場合は、いきなり