ツイート拡散について ～少しだけ前のめって分析編～
筆者は言葉や文章を分析する専門家ではありません。 本文の分析はあくまでも筆者個人の仕事に活かす方向で書かれています。 異論反論ありますでしょうが、温かい目で見守ってやってください。
今回は？
前回の「ツイート拡散力に驚いた ～バズる方法は書いてないよ～」から数日経過した現状と、ツイートした内容を改めて分析し本業に活かせることができないか？を考えていきましょう。
このブログのメインタイトル完全に忘れていましたが、本来はこうゆう記事を軸にするべきですよね。。。
その後の状態は？
※2019/4/17 14:00時点 エンゲージメント総数：4800以上
フォロワー：300
フォロー：440
RT：680（更新中）
いいね：2130（更新中）
伸びましたねぇ～。
ただの自己満足ツイートが色々な人に見られるというのは変な感じですね。
増加したフォロワーも100人中20残ればいいほうなのかなと勝手に思っていますがどうなのでしょう。
それと意外だったのがネガティブなRTやDMがほとんど見当たらなかったことです。
※通知範囲外では色々言われたりもするのでしょうが、こちらの耳に入らないのであれば気にしないタイプです
通知で見た限りですが、
酒の誘いDM：1件
反応に困る：数件
ツイートの内容を勘違いかな？：数件
なぜ少なかったのでしょう？
他ではよく聞くのですが、何が違うのでしょうか？
こちらも分析対象ですね。
筆者自身の価値観
以下を念頭に入れておくとより理解が深まるのではと思いますので、お付き合いください。
- ・最近多いエンジニア希望者の学習方法に疑問があった
- ・エンジニアになりたいという割には誰かに答えを聞いて早く解決することが正解だと思っているのは違うのでは？と感じていた
では分析タイムといきましょう
ツイート内容を改めて見てみましょう。
初めてLinux触った時、初めてdocker触った時、初めて動くコードが書けた時、恐らく全部理解してたエンジニアなんて居ないはず。
まずはヘッダー部分です。
「初めて」というのがキーワードですかね？
誰でも経験する「初めて」。少しだけ「恐怖」というイメージがあるのかもしれません。
少なくとも筆者には恐怖感があります。
【Linux, docker, 動くコード】恐らくこれは他の用語でもいいところです。
自分がエンジニアなので、身近に存在し少しだけ触るのが怖い感じ（画面黒いしｗ）のものを選択したまでです。なのでエンジニアでない方は自然と読み替えているのではないでしょうか？
「全部理解していたエンジニアなんて居ないはず」
自分がこの文でイメージするのはイベントでスピーカーをしているような剛腕エンジニアですね。
そんな人達だって「初めて」があり、自分たちと同じだよと伝えることで「恐怖」→少しだけ「安堵」に変わったのかもしれませんね。
みんな初めは理解してないけど、手を動かして何となく覚えて、もっと手を動かして覚えることを増やしただけ。
次に本体部分。
「みんな」ということで、読んでいる人も含ませられたのかな？と。
ここで他人事ではなく、読んでくれた人が自分自身に置き換えてくれたのかなぁ。
「手を動かして」と「何となく覚えて」ここが大事な要素ですよね、きっと。
最初から100点を目指しても仕方ないというか、実質無理なんですよね。
仕事で必要な知識と学校で必要な知識の違いといいますか、100点なんてないんですよ仕事には。
※限られた条件内での100％は存在しますが・・・矛盾に聞こえますねｗ
それを目指して頑張るのは良いことです、でも「手を止めて」まですることではないのかなと思っていますし、共感ポイントだったのかもしれません。
人生終わるまではすべてが途中経過
だから、始めは「何となく」でいいんです。
で、「もっと手を・・・」と次のステップを示しています。
一気にではなく少しづつ覚える、手を動かしていくと【点】と【点】が繋がる時があります。
その繰り返しで成長するのだから、最初は出来なくてもいいですよ。という感じでしょうか？
また、「・・・だけ」と言い切る形にしたことで、簡単そうに見えますよね？
分からないから何もできないは、言い訳にすらならないよ。
最後にフッター。
ここが一番賛否両論ある箇所でした。
『マウントしてる』や『別の言い回しが好き』など、言われてみればそうとられても仕方ないなぁと思います。 ですが、ここはあえて強めに伝えた方が良いかなと判断しました。
本文エリアで「何となく」でもいいんだよと甘やかしたので(笑)、最後はビシッとね。
本当に伝えたいことは【遅くてもいいから、自分で考えて手を動かして物事を解決しよう】です。
筆者はTwitterでみんなから好かれたいのではなく、自分が成長する刺激やキッカケを求めています。
ですので、多少強く言ってフォロワーが減ろうが、陰でdisられようが気にしないのです。
ツイートでも言いましたが、「コントロールできないことはコントロールしようとしない」この自分ルールはすごく大切にしています。
話が反れましたね。
「言い訳にすらならない」この部分では「言い訳」という言葉にひっかかる人もいるでしょう。恐らくその引っ掛かりは普段から実際に「手を動かして」いれば感じないのでは？と思います。
「手を動かせば」何かしらの結果が出ます。
それはゴールからみれば10％か30％か。もしかしたら、5％だったかもしれません。
でも結果がでれば次のアクションを起こしやすいです。その時に有識者に頼ってもいいですし、ネットで調べるのもいいでしょう。
大切なのは自分でまずはやってみる。ですよね。
まとめ
う～ん。拡散した理由はツイートを分析してもイマイチわかりませんでしたね(笑)。これだ！というモノが見つけられませんでした。
なので、やはりツイート内容というよりもTwitterの仕組みで拡散したと考えたほうが良さげですね。
筆者自身も【共感された数字＝正論】だと思っていませんし。
たまたま拡散しちゃって、その内容がたまたま本ツイートだったと結論づけます。
今後にどう活かせるか？
このブログの本題です。
今回筆者が学んだことは、
- Twitterの共感数で自分の主張や主義を変えてはいけない
- 伝えたいことは全員に伝わるよう努力すること（好かれる好かれないはその後の結果でしかない）
- 読んだ人が自分に置き換えやすい手法（言葉）を上手く使えれば、PJのマネージメントでも活きそう
- 当分は人にやさしく接しようｗ（好かれるのが目的でなくても、嫌われる必要もないよね）
こんな感じですかね。
とにかく、ツイート拡散は筆者の中では「初めて」の経験でしたが、ブログネタにもなりましたし、仕事にも影響がありそうなので上手く利用していきたいです。
めでたしめでたし。
忘れ物（ネガティブなRTが少ないのは？）
忘れていました。。。
サクッとやりましょうね。
想像ですが、ネガティブな意見は若い人や女性に対して行われる可能性が高いのでは？と考えます。
なので今回少なかった要因は以下ではないでしょうか？
- 40歳のおっさん
- 強気発言多いけど、無駄に自分を持ち上げていない
- iconが最近の実写
- 30未経験から這い上がってきたバックグラウンドがある
と勝手に分析していますよ。
以上、ありがとうございました。
ツイート拡散力に驚いた ～バズる方法は書いてないよ～
注意：この記事はバズることを目標にした内容ではありません。
はじめてRT500超えた記念に書いたブログですよ。
突然通知が止まらなくなる
ある土曜日の朝4時。
あるツイートに触発されて、いつものように少し強めにツイート。
少し寝て起きるとtwitterの通知件数がおかしなことになっていた。。。
サイレント設定でよかったなぁなんて考えながらアプリ開くと、「いいね」が初の100件越え＋コメントもはいってました。
それまでのステータス
フォロワー：190
フォロー：366
RT：９
いいね：25
で、今どうなっているか？
※2019/4/15 14:00時点
フォロワー：268
フォロー：430
RT：508（更新中）
いいね：1563（更新中）
拡散する仕組み
色々なサイトで紹介されている内容では「インフルエンサー」が重要とのことでした。
世間に与える影響力が大きい行動を行う人物のことだそうです。
この「インフルエンサー」が【いいね】や【RT】（リツイート）をすると爆発的に拡散されるという仕組み。らしい
※今回の件ではバズっているかどうかがわからないので「バズる」という言葉は使いません
今回のツイートは何故拡散されたのか？
Twitterはアカウントだけ作って今年まで放置（有名なエンジニアのみフォローしていただけ）していたので、理解していない要因がありそうです。
自分なりに考えてみましょう。
内容
ITエンジニアなら誰しもが経験している内容のツイートですよね。
言っていることは「初めてはみんな同じだから手を動かそう」ということだけです。
強いて言えば、最後が強い口調なだけですね。
時間
上記にあるように、土曜の朝4時です。
拡散の条件には向いていないような気もしますね。
インフルエンサー
フォローしている人のツイートに「いいね」をした後、以前から想っていたことをこの内容でツイート。
その人にRTしてもらったのがよかったのでしょうか？
(名前の利用許可確認していないので、ここでの名前は伏せますがフォロー数9千オーバーの方です)
そこから何故一気に伸びたかは寝ていたので・・・すいません
コメント返し
数人からコメントがありましたので、起きてすぐに返信。
なぜこのツイートをしたのかを簡単に説明しつつ補足したくらいで、特別なことはしていない。
RT
コメントなしの方には何もせず、時間があればその方のツイート見たりする程度。
いいと思ったら今まで通り「いいね」する。
コメント付きでRTしてくれた方には、内容問わず「いいね」返し。
自分も自由にツイートしているし、どんな意見にも異論反論があるのは当然ですものね。
フォロワー
その日30名ほどに解除されたけど、ブロックチェーン系のフォローしたら増えた`仮想通貨・・・`という意図していないフォロワーだったので問題なしです。
（計ったかのように同じタイミングで解除してきたので、そういうことなのでしょう）
70名ほど増えましたが、いつものように対応。
まとめ
自分なりのまとめは、
・手を動かすことを優先しているエンジニアでもそうでないエンジニアでも共感される内容だった。
→手を動かす人：普通に共感「いいね」
→そうでない人：自戒をこめて「いいね」・ある程度拡散すると、内容問わず広がり続ける心理的要因もあるかなと
→流行っているからとりあえず拡散
→自分の気に入っている人がしているからRT,いいね
当然、最初のインフルエンサーさんのRTが発端だと思いますが、プロフィールの写真を猫に変更したこともプラスになったのでは？と付け加えておきます（笑）
これを書いている現在も伸び続けています。
きっとこれが最初で最後でしょうからこの機会に色々吸収したいです。
【作業ログ】つけていますか？
ここでいう作業ログとは？
その日やった（やっている）ことの単純なメモ。
どんなメリットデメリットがあるの？
メリット（予想）
- ・覚えているうちに記録として残せるので、自分は忘れても安心
- ・環境構築など他の人にも連携しやすい(wikiとして残す時の元になる)
- ・進捗報告時に書いたことを言えばOKでは？
- ・作業チケットの中の自己管理UPに期待
デメリット（予想）
- ・面倒くさそう
- ・面倒くさいので、習慣になるまで続けることが難しいそう
- ・進捗が進まない日に読み返すと気が沈みそう・・・
基本ルールは？
基本、第三者に見せることはないため自由。
→自由じゃわからんよ、筆者のルール教えて
筆者ルールの一例
ファイル管理
working-log
|- yyyy
|- jan.txt
|- feb.txt
...
って感じで作ることが多いです。
自分の場合はあとでgrepすることが多いのでファイル数は少ないほうが楽。月単位なら大体何をやったか見当がつきやすい。誰かに提出するものでも見せるものでもないので、管理しやすい方法でやることが一番です。
書き方
書式は気分で変わりますが、2時間置きくらいで作業を止めて書くように心掛けています。
タスクチケットに対してどうやって解決したかを書くことが多いです。
例（内容はテキトーですからね）
yyyy/MM/dd ■その日やること ・httpのインターセプター処理作成 ■やっていること（やったこと） ・angularのインターセプター需要は？ →ある。 通信のやり取りがjsonのみなのでヘッダ固定化したい Authorization: Bearerでtoken処理挟みたいなど。 ・標準で用意されてないの？ →4から追加のHttpClientで可能 https://...(参照元は残すようにしています) →それまではHttpラップして自作していた ■懸案事項 ・複数記述可能か？ →・・・ ・テストはどうやる？ →・・・ ・既存ソースに追加する時の影響範囲は？ →・・・
※個人メモなので正確かどうかはわりといい加減でOK。正確さが必要ならちゃんとした資料作成時にやればいいぐらいの気持ちで。
なんで2時間ごとに書くの？
1時間や30分の場合もありますが、時間区切りでやる個人的メリットは以下です。
- 忘れる前に残せる(帰りに一気にやればいいやと思ってやったら、失敗したので)
- 作業に没頭し過ぎると視野が狭くなりやすい体質のため強制的に一呼吸
- 突発的な問題などで一旦作業から離れても、見返せばすぐ再開できる
そもそも始めたキッカケは？
SIer時代に同じチームメンバーだったあるベテランエンジニアのマネです。
それまでは自己タスクの管理を行っていなかったので、夕会での進捗報告では大雑把な返答をしていた。
スクラムマスターをやるとメンバーの進捗管理も大事なので、まずは自分が進捗状況を明確に話せるようにならないとね。という理由。
それと、チーム内の環境構築手順や使用ツールをwikiに記載するときにメモがあれば楽だったなぁと。
実際にやってみてどうだった？
■文字に起こすことで以下の効果を実感
- ・自己のタスク進捗が把握しやすい
- ・ググりの迷路から脱出しやすい（なんのために検索したのか思い出しやすい）
- ・問題の切り分けが早くなり、作業効率が上がった（アラート上げる時間も早くなった）
- ・コードにコメントなくてもログを読み返すと何のために作成したかがわかるし、リファクタリングしやすい
■チームで採用してみたら
- ・向いている人そうじゃない人がいる
- ・進捗報告の時間短縮
- ・抱えている問題が表面化しやすい
- ・課題問題を言い合える環境ができ、みんなで何とかしていこうと前向きになる
※あくまで個人の感想です
他の人に勧めますか？
作業を中断されることを苦痛と思う人もいるので、個人的に効果はあっても強要はできません。
たまたま自分は習慣になり6年ほど続けられていますが、自分の成功例は自分だけの成功例なのでねｗ
気になったら一度やってみて、合わなかったら辞めればいいと思いますよ。
「とあるフリーランスエンジニアができるまで」 ～大規模案件（後編）～
今回のお話は？
大規模案件に参画したまでは良かったが、スキル不足と精神的苦痛から強制退場間近。
体制変更で急遽降ってきたライブラリ管理者（以後リブ管）という仕事が次のステップへの階段でした。
ステータス
| 気力 | 体力 | 知識 | 素早さ | 器用さ | コミュニケーション力 | 伝達力 |
|---|---|---|---|---|---|---|
| 40 | 15 | 30 | 40 | 60 | 50 | 30 |
かなりの瀕死状態です。
やる気も体力も減る一方で、回復する見込みなど皆無。
起死回生
さてさて、開発メンバーから信頼をなくし四苦八苦していた状態からのスタートです。
開発もリリースまで半分ほど進んできたところで体制変更を迎えました。
今回は各チームのソースを一括管理していたチームの解体です。
ライブラリ管理にはIBMのRational ClearCaseを使用していました。
自分にとっては初めてのバージョン管理ツールであり、cvs?svn?って感じの理解度でしたし、説明を聞いても全くイメージできませんでした。
ですが、統合管理チームが解体するにあたって各チーム内にリブ管をアサインしてくださいと、通達がくるわけです。
で、当時大きなタスクを任されていない自分が担当することになるのですが、IBM社員以外誰も経験がない訳ですよ。
今の知識でマニュアルをチラ見したのですが・・・
(そっと閉じました)
そんな感じでリブ管として色々当時は勉強し（※）、ブランチ・ソースの管理や競合対応、リリースパッケージ作成などに手を出します。
※現在はRational ClearCaseという名前もググらないと思い出せないほどです
代えの利かないメンバーへ
開発も進んでいくと各テスト環境へ様々なバージョンをリリースしていくのですが、ここで自分が取り組んでいた管理方法がたまたまよかったらしく、他のチームへ連携してくれとの依頼が来ます。
そうなると、足手まといだった人間がどうにか一人前と認識されるのです。
一つ上手くいくと何故かいままで上手くいかなかったこともクリアできるようになり、どんどん周りの評価も上がっていきます。
どこかのCMで「周りの評価などバカらしい・・・」みたいなことを言ってますが、自分の評価ほど甘いものはないと思うタイプですので、こうゆうことも上昇するキッカケになりました
全体MTGで話せば管理者たちにも認識され、行員さんと仲良くもなります。
で、どうなった？
リブ管メインでしたが、当然バグ修正やテストコード作成などちゃんとタスクを消化していたら、次の人員削減にもかからず、気が付けば初期メンバーとして一定の信頼を勝ち取ることになります。
それまで、担当できなかった新規画面も任されたり、他チームとの連携窓口をしたりと実力不足を他で補っていき、自社を辞める時までその案件でお世話になりました。
退社
何んとか自社の裏タスクもクリアし、ある程度開発手順や管理方法がわかってきたところで念願の退社となります。
30未経験からSIerになって２年半。プライベートはボロボロになっていました。
3年目という重圧に負けないように、毎日ぎりぎりで生活していた報いでしょう。
睡眠時間も平均4時間、土日もどちらかは出勤して対応してたら、そりゃあ～ね～。
詳細は省きますが結果として残ったものは３DKの広い部屋に一人という状況でした。
で、もう思い残すことはないのでちゃんとした開発会社に転職したいと考えます。
外の会社の話を聞く機会が増え自社への不満が溜まっていたのでしょうね。
まとめ
今回の話は、一度失敗してもどこかに這い上がるチャンスはあるよ。ということでしょうか？
ただし、チャンスがあっても全員が掴めるとは限りません。
チャンスを逃さないコツとしては、どんな時でも覚悟を決めたら諦めない。
そんな感じでしょうか。
次回
今回も読んでいただきありがとうございました。
次回は「色々疲れたから一旦地元に帰る～近所の開発会社に転職」か「SIerになるまで何してた」を書こうと考えています。
退社時のステータスとスキル
| 気力 | 体力 | 知識 | 素早さ | 器用さ | コミュニケーション力 | 伝達力 |
|---|---|---|---|---|---|---|
| 40 | 15 | 30 | 40 | 60 | 50 | 30 |
| 20 | 5 | 35 | 40 | 70 | 60 | 40 |
| ↓20 | ↓10 | ↑5 | 0 | ↑10 | ↑10 | ↑10 |
スキル
アジャイルを経験したSIerのお話
アジャイルを経験したSIerは、フリーランスになる決心をする
2019/4/8現在、「とあるフリーランスエンジニアができるまで」としてブログを書かせてもらっていますが、今回はスクラム案件で得たものを中心にお話しします。
話の時系列は「独立直前」です。（メインが終わっていないのに外伝とか・・・）
ソフトウェア開発には色々なやり方がある
一口にソフトウェア開発といっても様々な開発手法が巷には溢れています。
代表格はウォーターフォール（以後WF）とアジャイル、プロトタイピング。
各々の手法によるメリットデメリットにつきましては、他の方が詳細に比較しているため、ここでは省略させていただきますね。
2019年現在、この手の記事はネットや書籍等で飽和状態です。
ですので、今回は私個人が経験した事を例にして、6年前(2013)に初めて触れたスクラムが、現在の自分にどう影響しているのかを残しておこうと思います。
学んだこと
- ・新しいバスに乗ってもらうには乗っている姿を見せ続けること
- ・どんなコネクションでもないがしろにはしない
- ・良いと思われる仕組みでも改善して続ける
- ・否定的な意見を分析すると改善策につながる
- ・納得できない人にやってもらうには、お願いに変換すると確率が上がる
- ・人間的に好きになってもらうより優先すべきことがある
スクラムとの出会い
2013年、未経験から始めたSIerも何とかやってきましたが、このままでいいのか？感は一向に拭えずただ生き延びてきた自分にその後の人生が変わる出会いがあります。
- ・やる気に満ち溢れているPM
- ・同じ転職組のフリーランスエンジニア
- ・自由が利く開発環境
当時の自分は意識の低いSIer。アジャイル開発という言葉すら知りませんでした。
そもそも孫、ひ孫請け案件ばかりの状況下では開発スタイルを提案するなんていう選択肢は持っていません。
それまではWFだけが開発手法だと思い込んでいましたし、そのやり方に疑問をもったことはありませんでした。
そんなSIerがアジャイル（スクラム）というモノに触れてしまうのです。
※「とあるフリーランスエンジニアができるまで」と合わせて読んでいただくと背景がわかりやすいかと思いますので、そちらもよろしくお願いします。
スクラム開発の一例(2013～2015)
参考書籍は？
一番読み返したのは「SCRUM BOOT CAMP THE BOOK」ですね。
今更本書の説明はしませんが良本です。
当時の状況は？
当時のSIer案件はWF一択であり、開発手法から選定するなど無駄な取り組みなわけです。周りからは当然懐疑的な視線を浴びますｗ
また、参画した部署もバックエンド。ひとつのミスが数百万人に影響してしまうので、とにかく安全であることが全てでした。
そんな中にあっても素晴らしい人材は居るもので、自分を採用してくれたPMはとにかく凄かったですね。
できるPMって本当に居た（プロダクトオーナー）
新しい何かを始めるには、それを支援してくれる人達は必須です。
自分にとっての支援者の一人がPMでした。
当時自分は34歳。PMの彼は31くらいでしょうか。
一言で彼を表現するなら「コミュニケーションの申し子」ｗ
彼自身はエンジニア経由でPMになったのではないので、開発は基本一任してくれました。そうゆう経歴のひとは他にもたくさん居ますが、投げっぱなしではないのです。
任せたらちゃんと一任してくれますし、責任も折半してくれていました。
管理者経験ある方ならわかると思いますが、簡単そうで意外とできないことなんですよね100％お任せって。自分の評価に繋がるわけですから人によっては口や手を出してしまいますし、それがチームの邪魔になっていることすら理解できないのです。
要所要所で方向確認やステークホルダーへの根回しなど行いチームが開発に集中できるように動いてくれる、プロダクトオーナーとしてほぼ完璧な存在です。
彼はどんな職種でも成功するメンタリティーを備えていました。
（現在は別の仕事で大活躍しています）
こうゆう人と一緒に仕事ができることはそう多くはありませんので、縁というのは大切にしていきたいですね。
メンバーとして取り組んだこと
3人の少数チームでメンバー構成は
ここでは様々な事を経験し吸収していきます。
などなどキリがないほどインプットしていきました。
メンバー個人としては、開発に集中できる環境が初めてだったし、タスクの粒度も細かくして話し合えばやることが明確になり、手が止まるということが少ないと感じました。
アナログでやることで椅子に座ったままよりもリアクションしやすく、達成感や充実感も得やすかったと思います。
マスターとして取り組んだこと
メンバーとして半年ほどスクラムを経験したあとはスクラムマスターとしてチーム運用を期待されます。
その前に妨害
元々チームリーダー候補として参画していますので予定通りだったのですが、元請けは納得していなかったようで、一悶着ありますｗ
半年前にひ孫請けで参画。当時からリーダー候補として採用されたのですが、元請けからしたら、自社の社員からリーダーにしたいのですよ。単価が全く違いますからねｗ
そこでMTGを行うわけですが、こっちには知らせずに元請けの社長が登場（初見ｗ）。そして何故か自分も強制参加させられます...。
そこでMTGを行うわけですが、こっちには知らせずに元請けの社長が登場（初見ｗ）。そして何故か自分も強制参加させられます...。
※元請け社長＝A、元請け営業＝B、お客様（最高責任者の部長とPM）、自分の計5名
A「新しいWebチームを作るにあたりご提案させてください」
B「チームリーダーとして責任を果たすにはウチの社員の方が連携しやすいので、是非○○さんもしくは△△さんでお願いします」
部長「・・・」(チラッ)
PM「・・・」(チラッ)
自分「・・・」（何故見る）
A「開発の安全性やスピードを考えたら、ウチの人間にやらせた方がいいですよね？」
B「○○さんや△△さんもWeb開発の経験があるので、大丈夫です」
PM「Webチームは試験的にアジャイル開発でやっていきたのですが、その二人できます？」
A,B「・・・」
A「経験はないですが、リーダーとしてはウチの人間の方が・・・」
部長「彼はどう思ってるの？」「半年別部署まで行って経験させてきたけど」(チラッ)
自分「スクラムでやらせてもらえれば、次の開発は2か月で終わらせることが出来ますし、Aさんのところの新人も受け入れて教育します」（大風呂敷を広げる）
部長「じゃあお願い」
PM「ですよねｗ」「このMTGする必要ありました？」
A,B「・・・いや、彼はひ孫だし・・・」（チラッ）
自分（だから、なぜ見る）
======= その後 ===========
自分とBさん + 元請け現場リーダー（Cさん）の3人でMTG
B「という訳で、彼にリーダーやってもらうことになりました」
C「最初からそういう契約でしょ？なんでかき回すの？」
B「社長が・・・」
C（自分へ）「すいません。変なことに巻き込んでしまって・・・」
自分「いや、色々見れて勉強になりましたｗ」「ですが、ご相談させてください。現場の連携が不安であるなら、間の１社いらないですよね・・・」
ここで自分は現在のひ孫から孫に繰り上がる契約を取り付けます（笑）
条件としては、元請け新人を受け入れて教育することと、開発期限は厳守すること。
スクラムマスターのスタート
さてやっとスタートです。このブログもここからがスタートなのです。
最初の仕事はとにかく新チームでスクラムを回してみることでした。 （長くなるので箇条書きで進めます）
チームメンバー。入れ替わりで常時３～５名（２ｗスクラム）
- ・ベテランエンジニア（C,C++メインでJava未経験。50代♂）
- ・開発未経験エンジニア 2名（他チームでテスターなど。20代♀）
- ・前のチームメンバー（20代♀）
- ・前のスクラムマスター（サポートのみ。40代♂）
- ・自分（30代♂）
- ・ベテランエンジニア（自社では取締役。40代♂）
- ・優秀エンジニア（20代♂）
不安要素
成功したこと
- ・ベテランさんの拒絶は想定内、色々な役割を与えた結果バスに乗ってもらえた
- ・ゴールまでの道筋を明確に伝えることで、新人でも手詰まることがなく進めた
- ・定時帰りでも遅れずにリリースできた
- ・朝会、振り返り会などMTG司会を順番制にしたら、全員が責任をもって開発できた
- ・メンバーが代わってもWebチームとしての文化を残せた
- ・PMの作業負担を減らし、チームに関わってもらう時間をふやした
- ・別チームもスクラムでやりだした
失敗や布教不足だったこと
- ・一部では定時帰りとスクラムを結び付けて広められなかった （チーム運用改善の結果ではなく、見積が多すぎたと判断されることが多い）
- ・「結局人でしょ？」と言われることが多い（でもそれはWFでも同じなのにね）
- ・スクラムだと疲れるメンバーも存在する（ただコーディングしたいエンジニアに多い）
まとめ
本当はスクラムマスターでの経験をたくさん書きたかったのですが、ごめんなさい文才がなくただ長いだけの内容になってしまいました。
自分のスクラムマスターとして成功したかどうかは、その時のメンバーが現在どうなっているか？だと思いますが・・・どうなんでしょうねｗ
Twitterでもつぶやきましたが、メンバーから言われて嬉しかったのは
- ・スクラムマスターって自分でも出来そう（何かを広めるには必要な感覚ですよね）
- ・えっ、そのまま使うんですか？（資料やコードの精度が上がりました）
- ・このリーダー大丈夫？（メンバーの責任感向上ｗ）
- ・他のチームより笑顔が多くて前より楽しかった（大事）
- ・気が付いたらWebアプリが完成してた（迷う時間が少なかったのかな？）
- ・朝会の「今日の一言」が地味にネタ切れで辛かったので、趣味の話になりがちでした（アイスブレイクの一環で日直さんは一言いうのですが、こちらの意図としてはその人が何に興味をもっているなどを引き出すことでした）
ですかね。主に送別会で言われたことなので、どこまで本気か定かではないですが。
それと自分の送別会の時はたくさんの人が参加（PMの力）してくれたのも嬉しかったなぁ。
とあるフリーランスエンジニアができるまで ～大規模案件（前編）～
今回のお話は？
受かると思っていなかったメガバンク案件。
今回は案件入場からのお話し（前半）です。
ステータス
| 気力 | 体力 | 知識 | 素早さ | 器用さ | コミュニケーション力 | 伝達力 |
|---|---|---|---|---|---|---|
| 100 | 65 | 20 | 50 | 80 | 80 | 50 |
やる気に満ち溢れています。
やるしかない
誰もが知っている銀行の開発案件。一体どんなことをするのか？不安もありますが、楽しみで仕方なかったです。
初めて聞くPM、PMO、PLなんて言葉。組織構成すら分からないけど、とにかくやるだけなんです。
アンチマネーロンダリングのプロジェクトで、噂によると30億以上かけたという、大手ベンダーが元請けの大プロジェクトです。
IT業界の常識は非常識？
そんなプロジェクトに参画したSIerが目の当たりにするITの常識。
そうです、ITゼネコンですね。いわゆる多重下請け構造です。
当時は、自分（自社）がどの位置づけなのか理解しておらず、お客様以外の元請けや協力会社は同じ土俵で仕事をしているものだと勘違いをしていました。
まぁ、そんな勘違いは一瞬で吹っ飛ぶのですがｗ
とにかく全てが初めて見る景色でしたので、今思うと最初のころはかなり危うい発言をしていたのではないでしょうか？
※ちなみに当時はひ孫請けでした。
プロジェクトってこんなに厳重なの？
銀行案件ということで、セキュリティに関しては今振り返ってみても、一番厳重でした。プロジェクトの内容が内容なので、仕方ないのかもしれません。
出勤時はまずロッカーに携帯や貴重品を置く。エレベーターの前にはガードマン、フロアの出入り口にもガードマンが配備されていて、物々しい感じです。
当時ニュースになった情報漏洩もあり、開発端末は当然のことながら、紙すらフロアから出せないように管理されていました。
それで困るのは別チームとのMTGです。ノートPCの持ち出しなんて以てのほか、資料も持ち出すたびに申請を出して荷物検査を受けるのです。
slackやskypeでのMTGなんてないですからね。
セキュリティーのためとはいえ、あの環境下では開発が遅れても仕方ないと思います。
開発環境
IBMプロジェクトに関わっていたので、開発環境はもちろんIBM三昧。
グループウェアはNotes。ソース管理はRational ClearCase。IDEはRAD(EclipseベースのIDE)。
当初は何をするにもドキュメントを読むことから始まり、苦労した覚えがあります。 ※IBMからも開発チームが参画していたのですが、下っ端プログラマーには接点がありませんでした
いきなり2画面担当
とは言ったものの、どんな環境だろうとやることは一緒。。。なはず
それに、自社から受けた裏タスクは、最低でも1年は生き残ることです。
あの頃の自分は、社畜なんて言葉は知りませんでしたが、まさしくソレでした。
当初担当したのはパッケージ製品からデータを受け取り次画面へ渡すという、今では簡単な内容でしたが、研修でStrutsやったばかりの人間には少しばかりハードルが高かったです。
ですが、チームリーダーからしたら、3年目のプログラマーに対して少し楽なタスクを与えたと考えていたのでしょう。すぐに新しいタスクが舞い降ります。
その内容は、データ解析してファイルに分割し、指定の構成でディレクトリ作成の後zipに固めてアップロードだったと思います。「3年目なら大丈夫だよね」って笑いながら言われましたよ。
・・・いやいや、最初の画面すら持て余していたのに、なんてことをしてくれたのですか。設計書見ても何をどうすれば実現できるのかわからない。ググろうにも、セキュリティー上外部とネットは繋がっていません。業務中は携帯（ガラケー）も持ち出せないので、完全にガラパゴスです。
ですが、当時の社畜さんは限界なんて知りません。
毎日終電、次の日は4時半起き（銀行案件って朝が早いし、通勤1.5時間だったので）。それでも足りないときは土日も作業。
予定より少し遅れて何とか終わらせます。が、待っていたのは協力会社のリーダーからの呼び出し。（自分から見たら2階層上の会社のひと。直の上位は間だけで開発者はいない）
何も言えないジレンマ
個人的には遅れはしたものの、初めて1画面の作成「入力～バリデーション～DB～解析～出力」をやり遂げたのですが、周りから見れば出来て当然なわけですよ。
何度も言いますが、ここでは3年目なんです。ちょっとしたメンバー間の会話にも気を使い、それっぽくふるまう必要もあり、喫煙中でも気が抜けません。
そういった背景は現場では一切言えないので、呼び出しをくらって注意された時もただただ黙っていました。
口を開いたら「まだJava覚えて半年なんだよ！」と言ってしまいそうだったからｗ
でもね、どんなに我慢しても限界はあります。
サポートなんてなかった
知ってしまっている今では何故わからなかったのかすら、分からないのですが。
当時は開発の流れがわからない、次にやることが分からないのです。一回でも経験していれば違うのですが、ちょっとの先が見えないので、常に準備ができないのです。
設計書を見る→コードにする。これだけでも当時は時間がかかるし、未熟なため一回で想定通り動くコードは書けません。
さらにプロジェクト全体が遅れだすと、理由を探して対策案を上に出さなければなりません。そうすると、だいたいが自分の遅れによる影響となり、居心地も悪くなる一方でした。
自社からもう一人先輩が参画していましたが、彼も一杯いっぱい。
社長や部長も現場まで来ることはなく、そのうち飲みに連れていくから頑張れとだけ。
こんな状態で、まともな仕事が出来るはずもなく、プライベートにも影響が出始めていました。
その結果
とうとう元請けのチームリーダーに呼ばれ面談します。
本来ならここでぶちまけてしまうところなのでしょうが、それはしませんでした。
※先に言うと、自分の送別会まで黙っていました（送別会では暴露しちゃうのですが・・・）
そこで、伝えたことは「すいません。できません。」でした。
「え？できないの？」「本当にできないの？」と驚かれましたが、「できません」とだけ伝えました。
そんな状況でしたが、その後「できない」といった箇所をリーダーが教えてくれて、なんとか2ページ目も完成します。
が、当然印象は悪くそのあとのタスクはライブラリ管理やドキュメントの整備などでした。
でも生き残る
プロジェクト発足当初は、Lib管専用のチームがいてプロジェクト全体のソースを管理していたのですが、カットオーバーで人が抜けたため各チームでLib管を持つように体制がかわります。
一度ダメ出しを食らい、評価も下がっていたので、次のカットオーバー要員は確実でしたが、この体制の変更にチャンスがあると考えました。
結論として、その時は生き残るのですが、方法は次回に。
学んだこと
技術的には何も持っていないに等しい状態でしたので、とりあえず耐えればレベルアップします。
敢えて言えば、我慢と根性と嘘はダメ絶対。
ステータス
| 気力 | 体力 | 知識 | 素早さ | 器用さ | コミュニケーション力 | 伝達力 |
|---|---|---|---|---|---|---|
| 40 | 15 | 30 | 40 | 60 | 50 | 30 |
| ↓60 | ↓50 | ↑10 | ↓10 | ↓20 | ↓30 | ↓20 |
次回
プロジェクト内の立場と精神的に崖っぷちに立たされたわけですが、そこからどうやって1年ほど生き残れたか。
これを読んだ若いエンジニア（もしくは希望者）は、絶対にマネしないこと。自分の身は自分でしか守ってあげれません。
とあるフリーランスエンジニアができるまで ～SIer初案件と現実～
今回のお話は？
3ヶ月の研修を終えたばかりの、初心者マークエンジニアが初めてプロジェクトというものに触れるお話。
ステータス（研修3ヶ月後と同じ）
気力モチベーション |
体力体調管理能力も含んだ値 |
知識技術知識や言語理解度など |
素早さフットワークの軽さ |
器用さ技術の習得効率（コツの掴みやすさ） |
コミュニケーション力円滑な人間関係を築けるかどうか |
伝達力意図したとおりに伝えられるか |
|---|---|---|---|---|---|---|
| 80 | 70 | 15 | 40 | 75 | 75 | 55 |
スキル
初案件
なんとか3ヶ月の研修を終え、SIerとして初案件に参画します。
内容：当時の先輩エンジニアが参画していた航空会社のプロジェクト。業務改善の提案が受け入れられたことで可能となった持ち帰り案件。
「改善前」
- xmlで作成されたデータを他社へ解析依頼
- 解析結果は次営業日
- 新着情報がすぐに取り込めない
「改善後」
クライアントアプリの作成
当時の記憶が曖昧なので、ざっくり説明となりますが。
【要件】
地域情報と飛行プランを組み合わせたデータをクライアントアプリで表示し、別システムへ送る。だったと思います。
【成果物】
SWTで作成したクライアントアプリ。
ここで人生最初で最後のSWTを使用します（仮にJava案件やったとしてもSWTはないだろう）。
※記憶が曖昧なためSWTをググったら、2018年の記事がヒットしたのには驚きました
自分の担当としては、お客様との要件を詰めながら、xpathでデータをゴリゴリやることだったと記憶しています。
覚えた事
・xml構造と解析方法。
・xpathの使い方
・再帰呼び出しの処理
・ググり力
覚えてたけど忘れた事
・SWT
メガバンクの大規模案件へ
最初の案件が記憶に残っていないことには理由がありまして、1か月ちょいで別の案件にアサインされたからなのです。
会社としても大規模案件に人を入れた方が利益になるので、ベテランや中堅エンジニア5名に自分を加えた6名で面談へ。
ここだけの話（と言いながら世界中に発信されるのですがｗ）、どうやら「ひ孫請け」だったので「3ヶ月研修と初案件やったばかり」なんて言えるはずもなく、3年目のJavaエンジニアとして面談することになったのです・・・いわゆるブラックな業務命令ですね
採用枠は2名。ですが会社も受かるとは思ってないため、別案件の面談を受けたりxml解析を手伝ったりしていたわけですが、ある日部長から飲みに誘われます。（お酒は大好物）
作業があったので少し遅れて店に入ると、そこには先輩と部長と社長がいて、すでに始まっていましたｗ
「あれっ？3人そろってどうしました？」「おめでとう」「はい？」「だから、おめでとう！」「・・・ありがとうございます。」（汗）
そうです、誰も予想していなかったメガバンク案件に何故か受かってしまったのです。
まぁ、会社としては大満足な結果なので、酒くらい飲ませますよね。
取引先には3年目として請求できるが、支払う給与は1年目でOKなわけですから。
こんな内容だと、これを読まれている方は「ブラック最悪」「詐欺だろ？」など思われるかもしれませんが、当時の自分は「やるしかない」が一番の感情でしたね。
そもそもの話、自分の状況を思い出してください。
30歳、未経験、地元から彼女と出てきたばかりの同棲1年目。そんな自分を拾って研修中も8割くらいですが給与ももらっていたのです。
どんな状況であれ会社にメリットがあるなら、とりあえず頑張ろうというのが当時の本音です。
恐らく当時の自分は、理由を考え逃げるのは簡単だけど最初の一手ではないなんて思っていたのかもしれませんね。
ただね、やはりというか、これが後の悲劇の始まりだとは・・・当然ながら思いもよらないわけです
っていうお決まりのセリフが出たところで、今回は終わりにします。
補足
念のため言っておきますが、当時お世話になった会社がいつも経歴を偽って面談に派遣するわけではありませんよ。ぶっちゃけその飲み会で社長本人に聞きましたが、3ヶ月を3年にしたのはさすがに初めてだとのこと。
やってせいぜい半年だそうですｗそれもアウトだ！
これはフリーになってから経営者達と飲む機会があったので同じ質問をしたら、10年前のSIで中小ならどこも同じだねって笑ってたよ。
ステータス
| 気力 | 体力 | 知識 | 素早さ | 器用さ | コミュニケーション力 | 伝達力 |
|---|---|---|---|---|---|---|
| 100 | 65 | 20 | 50 | 80 | 80 | 50 |
| ↑20 | ↓5 | ↑5 | ↑10 | ↑5 | ↑5 | ↓5 |
学んだこと
これが良いか悪いかは人それぞれでしょう。一目散に逃げる人、法に訴え論破しようとする人、嫌でも黙って受け入れる人、チャンスと思って受け入れる人
自分の場合は、外的要因や会社の都合はどうでもいい、どんな状況でも成長に繋げて乗り切ってから次の手を考えようということを選択しただけなのです。
自分の人生においては、自分の選択した結果に責任を持つべき。
他人の成功例が全て自分にも通用するかは分からない
次回
メガバンク案件で得たもの逃がしたもの
初心者エンジニアが3年目としてプロの現場に入ります。
どんどん書きっぷりが揺れていて、読んでくれる人には申し訳ない感じなのですが、とりあえず全話やってみてから再編集しようかと甘い考えでいます。
次回もどうぞよろしくお願いします。
