読者です 読者をやめる 読者になる 読者になる

三流プログラマが脱三流するために書くブログ

PHP, オブジェクト指向プログラミング, デザインパターン, リファクタリング, DDD, 関数プログラミング, etc.

1. ひとり振り返り会

KPT

動機

脱三流ブログ、最初の試みは改善について。

改善の基本は、まず過去の振り返りと現状分析です。

と言っても、キャリアの初めから振り返っていては長くなってしまうので、キャリアをスタートした会社で、炎上プロジェクトに参加することが多くなった、入社5年目辺りからにします。

■ 何がプロジェクトを炎上させるのかを考えた結果、会社を辞めた頃

結果的にその会社には8年近くいたんですが、その後半は、火消しで参加したものも含めれば半数以上のプロジェクトで炎上を経験しました。

要因としては、

  • 厳しい納期
  • 少ない予算
  • 技術力不足
  • マネジメントの不足

厳しい納期

業界初の○○みたいなプロジェクトでは当然ながら納期は絶対でした。

業界初なので、手探りで進めた部分も多かったため、同時に技術力不足、マネジメント不足もありました。こういう類のプロジェクトで、どういったマネジメントでプロジェクトを進めればいいのか、まだ答えが出せていません。

ピーター・ドラッカーの本とか読み始めたのもこの頃です。

少ない予算

スケジュールは徐々に遅れてきているけど、とにかく人は増やせない、みたいな。 たいていお金を融通するのは上の方のひとなので、この辺は若手だとどうにもならないし、役割分担としてエンジニアが予算について采配できないケースが多いです。

なので、ここに関しては考えてもしかたないので、機能を削るか後回しにするかしましょう、と交渉するにどどめます。

技術力不足

テクニカルなスキルに限定すれば、私は昔から、スピードは速いけど雑 (結果不具合も多い)、という傾向がありまして、どうにかしないとなぁ、と思っていました。

キャリアの最初の頃、テスターをやっていたことがあったのですが、とにかく単調な作業がきらいで、ところどころ端折ったりしてました。

その点を補うために、最近はテストを自動化し、テストコードに割く時間を増やして、リリース後に不具合が出ないように心がけています。 ただ、テストケースを正しく記述できているか自信のないことがたまにあり、なかなか必要最小限の時間と労力でテストが書けていないのが現状です。

マネジメント不足

どうでもいいけど工数のかかる機能追加を納期厳守で、とか、急いで修正しなくても運用に支障のない程度の不具合を、今すぐ直せ、みたいに言ってくるマネジャーは明らかに無能だと思っていたけど、当時はそういうプロジェクトにいてもどうすることもできなくて、終電逃したことも度々ありました。 今なら戦いますけど。

自分でマネジメントをやったこともありましたが、やはりコードを書きたいという思いを強く感じたので辞めました。今後もよほどのことがなければマネジメント職には就かないと思います。

とは言え、マネジャーをサポートするために、見積もりをできるだけ正確に出す、とか、時間管理をしながら、遅れを放置しないようにする、とか、非マネジャーでもマネジメントに貢献できる部分はあると気づいてからは、常にマネジメントを意識して仕事をするようにしています。

得たもの

この頃に得たものは、様々な経験。炎上プロジェクトも問題解決に関心が向くようになったきっかけをくれましたし、自分以外の人間がどのように問題をつくっていくか、というのを観察することもできましたし、この頃の経験でいまに活かせていることはたくさんあります。

技術面に関しても、Unix系サーバー (Solaris) で一通りコマンドを覚えたり (この頃は Emacs 使ってましたがいまは Vim 派です)、C/C++CGI 書いたり、Java で Socket サーバー書いたり、色々やらせてもらったので、そういうのも多少糧になっているかな、と (移り変わりの早いこの業界、過去の経験が活かせないことも多いので、あまり過去のことは考えないようにはしていますが、コンピュータの基本は変わってないので、普遍的な部分に関しては無駄にはなってないと思います)。

得られなかったもの

得られなかったものは、 マネジメント。リードエンジニアをやることはあっても、要件定義とかはマネジャーやアーキテクトがやるようなプロジェクトが多かったので、上流工程にはあまり関われなかったです。

一回どこかでマネジメントちゃんとやっとけばよかったなーと思うこともたまにあります。ちょっとやって、すぐに止めてしまったので、もったいなかったという気もします。

デキるマネジャーの共通点として、あんまり忙しそうにしていない、というのを感じていて、プロジェクトをうまく回すために、メンバーに気を配りながらこっそり障害になりそうな予兆を見つけては潰していってるかんじでした。

一介のエンジニアであっても、そういうマネジメントができるようになれば、マネジャーの手助けをしながらプロジェクトを成功に導けるんじゃないかと思っています。

■ 社内SE やってた頃

請負でソフトウェアをつくっていると、なかなかクライアントの中まで入り込んで、業務フロー改善とかシステム化のコンサルティングとかはできなくて、それだったらインハウスのエンジニアになろうと思って転職しました。

業界にもよりますが、私のいた会社は外食系だったので、コンピュータに詳しくない人だらけでした。そのため、ソフトウェアとつくる傍ら、パソコンが動かなくなったとか、ネットワークが繋がらない、とか、そういうヘルプに応える日々でした。

でも、こういうのがなかなか楽しくて、パソコン研修開いたり、Excel のマクロをつくって営業資料を自動作成できるようにしたりして、社内のコンピュータスキルを少しでも上げられるようにあちこちの部署を廻って活動していると、こちらも営業や経理の仕事を学べるし、ユーザーが近くにいるので、反応がダイレクトに受け取れるってのもいいですね。

得たもの

協業の大切さ、面白み。

ビジネスは色々な要素で構成されていて、それぞれのプロセスを担うひとがいて、情報システムはそれをつなぐ役割があって、ということで、自ずと全体を俯瞰して見るようになります。いまでも、単にプログラムを書くだけでなく、どの機能がビジネス面でどういうインパクトをもたらすか、というのを考えながら、ときに発注者と議論も交えながら、ビジネスとの関係、システム全体における整合性、業務フローの改善なども意識して仕事ができるようになりました (ウェブ業界に転身してからはあまり要求される局面も少なくなりましたけども…)。

得られなかったもの

政治力。

後半は部長に昇進したというのもあって、部門間折衝とか役員に対するプレゼンとか、そういう交渉事を乗り切るためには政治力が不可欠になっていました。 具体的に言うと、システム導入やウェブサイトのリニューアルに関する事前の根回し、決裁が下りるまで役員と粘り強く交渉、営業からの無茶な要求を、波風を立てずに突っぱねる非情さ、などなど。まぁぜんぜんできてなかったわけではないので、これぐらいでいっかという妥協もできなくはないのですが、頼まれたら断れない、反対されたら引き下がる、という性格が元で、協力者を集めたり、自分と異なる意見を持つひとを説得したり、というのがいまでも苦手だったりします。

ときにはそういう突破力みたいなもの必要だと思うんですけども。

■ ウェブ業界に移ってからいまに至るまで

ひょんなことからウェブ業界に転身することになって、HTML/CSS/JS/PHP が書ければ仕事はあるよってことで、ウェブサイトつくったり、EC サイトやったり、色々やったんですが、けっきょくどれも似たようなものになってしまって、最近どうも飽き気味です…

3年くらいやってきて、結論としては、サイト制作はもういいかなっていうのと、やっぱり業務システムが楽しいよなーということです。

得たもの

最新のテクノロジー。

ウェブアプリケーションフレームワーク使うようになって、便利だし、ソースコード読むと感心するし、WAF 使わない開発には戻れません。 あと Git。 中には Subversion 使っているプロジェクトもありましたが、もう戻れないですね。

grunt, gulp, webpack とかのビルドツール、CoffeeScript, TypeScript とかの AltJS、AngularJS とか React とかのフレームワーク、フロントエンドの進化は大変なことになってますが、そういうのを実地で使えるのはウェブ業界の方が案件多いのではないかと思います。

得られてないもの

マネジメント。

スタートアップだったりベンチャーだったりっていう規模の仕事が多いので、どうしても自由闊達、悪く言えば統制の取れてない現場が多いです。

それでも上手く回っているケースもあるんですが、目の前のことで手一杯っていうか、これサービスが大きくなったりひとが増えたりしたら破綻するよなーということもときどきあったりするので、そういうのにどんどん口出ししていきたい、けど、あまりできてない、というのが悩みどころ。

ときどき提言したりするんですが、けっこうな確率で無視されます。それはきっと、必要と思われてないということなのかなと思いつつ、必要性を訴えることもしてないし、なんか中途半端なかんじです。

フリーランスだと業務委託でやっているので、本来はそういうところは範疇外なわけで、そんなのいいからお前の仕事しろよって言われないように、本分は守りつつ、プラスアルファの価値提供をよかれと思ってやってます!という体で、叩かれないていどに口出ししていこうと思います。

まとめ

Keep

  • 色んなことを経験したいという欲求に従うこと
  • 俯瞰的視点を持つこと
  • 新しい技術への興味を持つこと

Problem

  • 自信を持ってテストが書けてない
  • 人を動かせない
  • さり気ない気配りができない
  • ウェブ業界そろそろ飽きてきた

Try

  • Elixir で DDD してみる
  • Codeception 使ってみる
  • 毛嫌いしてたけどデイル・カーネギーの「人を動かす」読んでみる

Problem 4つになっちゃったけど、まいっか…

人を動かす 文庫版

人を動かす 文庫版