鑑賞 バーフバリ 伝説誕生 うわ、おもしろい

インド映画と侮るなかれ。色々エフェクトもおもしろいw

バーフバリ 伝説誕生 [Blu-ray]

バーフバリ 伝説誕生 [Blu-ray]

 
バーフバリ2 王の凱旋 [Blu-ray]

バーフバリ2 王の凱旋 [Blu-ray]

 

 

 

続けることで普遍に至るか多様な経験から普遍に至るか

エンジニア業も年数だけを数えればそこそこやっているのだけれど、中堅エンジニアに至るまでに事象から事象の本質を捉える技術が必要になる仕事が多くなってくると思っています。

事象の本質とは見えているものを含めたその裏側や中身を捉え、起きている事象を捉え直すとた方がイメージしやすくて良いかもしれません。

この本質として捉える対象は普遍であり、辞書を引けば2(イ)に当たります。

ふ‐へん【普遍】の意味
1 全体に広く行き渡ること。例外なくすべてのものにあてはまること
「人類普遍の原理」⇔特殊。
2 哲学の用語。
㋐宇宙や世界の全体に関していえること。
㋑特殊・個物に対して、ある範囲のすべての事物に共通する性質。 

 

dictionary.goo.ne.jp

 

この普遍に至るには2つの道があるのですがどちらで習得するかは全くもって仕事の機会に依存するのでなんとも言えませんが多くは片方に寄っているケースが多良いのがエンジニアが普遍を身につけるパターンだろうと思っています。

専門を続けることで普遍に至る

エンジニアに多いと言うか日本に多いかもしれませんね。続けることに割と美学を持っているじゃないですか。なんでも道にしてしまうので。少しは減って来たかもしれませんが年功序列なんてサラリーマン道そのものですし。

話を戻してエンジニアも続けることで専門を身につけやすい職業だと思います。そして専門を続けるからこそ経験則で得る知識が個人に属人化することで

「俺はこうして覚えた」

的な育成を対象者に丸投げするケースが多いかと。全くもって再現性がないのでどこにエンジニアリングの要素があるのかと思いますが。

それはさておき、専門を身につけることで普遍を掴む技術を身につけるということは現場を歩いていれば割と見られるのですが、じゃあそれは事象の範囲を広げたら同じようにできるかと言えばそうならないところが面白いところです。

何を言っているかというと、隣の技術エリアに入った途端持っている専門とは違いますから普遍を掴むことができなくなるんですよね。不思議ですが。

多様な経験から普遍に至る

 一方、反対に位置するのが多様な経験から普遍を捉える技術を身につけるというケースもあります。どちらかと言えば専門を突き詰めるよりは技術領域は広く間口を広げ、物事の本質、性質の中から共通項を取り出すことが出来る技術を身につけているとでもいいましょうか。

一言で言えばゼネラリストなのですけれど。

そこそこの経歴を振り返れば、製造業、金融業とセクター的に歩かされたし、アプリからインフラの経験をさせてもらったのは、普遍の観点で見返せば専門の突出がない分、普遍を身につけられる環境にあったのかもしれません。

また、PMBOKのようなフレームワークはその出自が普遍の代表のようなものですからPMBOKを学びイズムを理解できるということは多様な経験から普遍に至る典型だったのかもしれません。

個人的な考えとしては、専門から普遍に至ることはそれに至る(と思うかどうかは別として)ためには経験する事象が類似ばかりで共通項である性質に気づく訓練の機会が少ないと思うのです。

つまり、普遍に至ること自体に無理ゲーさの難易度がある、と。

その観点から思うのは属する組織の中でも業種を変えるとか普遍性のある思考的なフレームワークを嗜むことを自ら進んでいかないとどう足掻いたって向こうからやってこないのですけど。

そうすると専門から普遍に至るエンジニアは極端に減るんですよね。勝手に落ちていくというか。だってそればっかりやっていて、身につけることは類似案件ばかりで狭い範囲で気づく機会があるのかと。

そうした結果が技術を身につけること自体が道になり、エンジニアの普遍から遠ざけ、見える事象に対する対処しか技術(それを技術というのかという考え方は別にあると思うけど)としては持ち得ない、と思うのです。

 

全員が全員では切り替えてとは言えないのは業務ドメイン的な知識も必要でしょうが、普遍を捉える技術はやはり多様性の経験から組み合わせる選択肢を増やさないと発想自体が生まれないので多様性をいかに身の回りに置くかが普遍の技術を身につけるために大事なんだと思うんです。

 

 

 

うちの営業はもうダメかもしれない

いろいろな機会で知り合いが増え、ざっくばらんに話すようになるとそれぞれの組織の違いを知る機会もまた増えたりするのですが、お互い開発サイドなので立ち位置はエンジニアの目線かマネージャの目線でのどちらかです。

組織によって違うんだなと最近思ったのは、提案を誰がするかということ。まあ、営業がいるかいないかだけなんですけど。

ある人の組織は営業職がなく、提案はエンジニアが全部やるらしく、別の方は営業がいて一緒に提案するようです。

前者の職種として営業がいない組織であれば中堅以降は主体的に提案に関わることが多くなるだろうとは容易に想像できますし、後者の場合はエンジニアと営業とで役割分担があって双方で協力して提案することになるでしょう。建前上は。

うちの営業はどっちのタイプ

何人か聞いていると、組織の職種、権限分掌もあって 建前上は、提案プロセスは営業主体、エンジニアは提案にかかる技術情報の提供、仕様、見積もりを支援するケースが多いいようです。その組織により役割分担の線引きの違いはあるとして。

それよりは営業のキャラの個人差が大きくて、ブルドーザーのように案件をラッセルする営業もいれば、受け身で全く動かない営業もいるようでどっちでも大変だなと経験的には同情を禁じえません。(涙

よく見かけるあるあるパターンは営業が(まだ契約していないから顧客と決まったわけじゃないのに)顧客の言いなりになってそれを押し返したり交渉したりすることは1ミリも考えずに、提案している顧客に要望を聞いてそのまま流してくるパターンでしょうか。これは受け身の営業に多いとのこと。

ブルドーザーのように通った後はぺんぺん草も生えていないような営業の場合は、その営業の考えによって振り回されるところがエンジニアにとってはあれでしょうけれど。

エンジニアと営業のコンフリクト

提案するエンジニアサイドと営業サイドで意見、考え方の違いが出るとギャップが出ますし提案なんてRFPとかだと提案に使える時間が限られていたりするので兎角衝突しがちです。

普段からシステム開発しているエンジニアにとっては、提案自体が(提案専任のエンジニアがいなければ)プロジェクトに参画中のエンジニアなりPMが兼務状態で提案をすることになるのでその時期は稼働が半端なくなります(真面目な提案であれば。除く人売り)。

忙しいからこそ、提案の時間を捻出するためにどれだけ何をやりたいかを知りたくなるのが人情なのですが…。全体を営業が握っているとスケジュールの可視化とかエンジニアとの役割分担やエンジニアに対する期待や組織の見積もりプロセスの進め方などがどうやって進める気でいるかを知りたいのにエンジニアに伝わらないケースばかりだと。

一方、営業職の人に話を聞いてみるとRFPは提出期限が決められているからスケジュールを組みやすいらしいですが、そうでないと顧客の都合で日程が変わるのでエンジニアが欲しいスケジュールを立ててもクルクル変わるので意味がないからざっくりしたマイルストーン(的な)ものしか持たないと言うのです。まあ、そういう考えもわからなくもないですけれど。そうならそうと先に言ってもらわないとそれに付き合うエンジニアは先が予測できないので単に振り回されているように見えるだけなんですけれどね。

タチの悪い営業対策

 まだブルトーザータイプは主体性を持っているので最初にどうするのか聞けば覚悟はできますけれど、タチが悪いと言うか筋が悪いと言うか営業しているのと言うタイプの受け身の営業が担当についたら全部後手に回るのでエンジニアから見ればそう言うタイプの営業は外れだし、関わりたくないですよね。

でも組織の営業として付けられるわけだし、案件はエンジニアとしても取らないとおまんま食い上げになるので困るし。

 

じゃあどうするかと言うと、主体を取り上げるんです。どうせ持っていないのだから。実質営業のいない組織と同じです。営業事務のいる組織、とでも思いましょう。

エンジニアサイドは具体的なスケジュールで動いた方が楽ですし、そう進めるのに慣れていますから、だったら、顧客とのスケジュール調整などは営業に意向だけ伝えてやってもらってエンジニアの考える段取りに乗っけて来てもらうんでしょうね。

そうなると顧客が本当に何をやりたいかをインタビューするスキルも必要になるし、課題から解決方法を顧客が想定しているソリューションとは別のアイデアを出してアドバンテージに繋げられるかもしれません。

 

 

 

 

営業力 100本ノック (日経文庫)

営業力 100本ノック (日経文庫)

 

 

 

 

プレイングマネージャのつらみ

プレイングマネージャってあるじゃないですか。プロジェクトマネージャ業とエンジニア業の両方を一人で兼務させるアサイン方法。潤沢な工数がないとか、まあ、基本はバジェットかリソースの制約なんだけれど。プロジェクトの規模が小さい(短期)だとプロマネを1人月入れてもプロマネ業が一人月もあるのかとか、ね。

組織のプロジェクトマネージャに対する考え方が現れる一つの断面だと思うんですね。

  1. プロマネとエンジニアを兼務させる
  2. プロマネを複数のプロジェクトを兼務させる

どちらもプロマネ業が一人月分の作業がない前提ですが、短期で小規模でプロジェクトリスクも大きくないなら微妙な感じになるわけです。コスト面からも。

また、エンジニアのリソースも山積み、山崩ししても平準化できずに半端が出たりしてそれをじゃあプロマネで、と。

プレイングマネージャの良さ

常識的にはプレイングマネージャをさせるのはそのプロジェクトの適用技術を持っていて、リーダ的なポジションの実績があるからプロマネに引っ張り上げてアサイメントするのです。マネジメントとしては。ITじゃなくても課長が自分の仕事を持ちつつも部下の仕事の助言をして作業させるようなイメージなのですけれど。

プレイングマネージャでいいところは、プロマネが技術をわかっているのでプロジェクトの技術的なリスクに対しては精度があるのですよね。いや、技術を知らないプロマネアサインするなと思うかもしれないけれど、大規模専任になればプロのプロマネが求められるので技術は技術のプロをアサインしてデレゲートするからそれでいいんですよ。プロマネの職務のあるべき姿としては。

プレイングマネージャの悪い面

 技術で問題がおきて長引くと他がなおざりになるですよ。特にプロマネ方面が。問題のイシューに掛かりっきりになって他のリスクの芽に気づかなかったり。進捗の遅れも見逃し始めるし。そうした目が届かないところで小さな躓きから煙が立ち始めると一気に余裕がなくなるんですね。プレイングマネージャの。

そういった経験も大事だけれど内心気を揉むのでこっちも目を配らないとといっても自分を中心に課題解決のリソースアサイメントをするのでリソース枯渇してデッドロックになるんですよ。まぁプレイングマネージャのキャパはエンジニア一人ひとりで違うのでそうした経験をさせないとキャパを実感できないのはつらみですが。

 

エンジニアのアサイメントも基本的に工程分割した上工程下工程のアサイメントとかピーク時のみのアサイメントとかしていてはエンジニアは育たないわ、そんなアサイメントされたエンジニアは仕事に対してパートタイマー的な仕事の仕方をするわと碌な事がないのと一緒でプロマネ業も目的があるなら別だけど考えもせずにプレイングマネージャをやるとツラミしかないのですよ。

 

 

 

 

エンジニアとして仕事を選びたいなら

プロジェクトにアサインするとプロジェクトにあれこれと愚痴を言ったり、そろそろ小さなプロジェクトのPM(と言ってもプレイングマネージャ)かサブシステムのSEリーダを担うことを期待していると伝えても、いちエンジニアでいいというメンバがいるとキャリアをどうしようと考えているのか聞きたくなるわけです。

考えてみましょう。ビジネスですからビジネスに貢献したエンジニアを評価します。過去のエンジニアとしての役割を果たして評価されていれば中堅層までは無難に評価されているはずです。そうでないとしたら、マネージャにエンジニアとしての貢献が他のエンジニアと比較して何か問題があるのか、他の評価されているエンジニアが優秀すぎるからかもしれませんが、多くは前者で技術評価はそこそこでも相対的なビジネス貢献の評価になった途端に他のエンジニアにアドバンテージがあるからです。

それでそこそこの評価を受けているからこそ、次のステップの場での期待をするわけです。ビジネスを広げるためにはリーダが必要ですから。そうした考えがあるからこそ、次世代のリーダを育成するための機会を作るのですが、それに乗らないエンジニアがときどき出て来る。それもわからなくはないのはリーダ業の大変さとリーダ業の魅力がそのエンジニアにとっては大変さ>魅力という式が成り立っているんだろうからと。

多分に個人的な感情ベースではそれでもいいのは個人の感じる範疇だからだけれど、仕事としてはどうなのよ、と。いちエンジニアのままだと専門のプロとしてのエンジニアになることを考えていて、そっちで行くならそれは選択肢なのでありです。問題じゃないかと思うのは嫌だからとやりたい仕事も考えていないでそういうことをいうエンジニアですねぇ。じゃあ何やりたいのと聞いてもぼんやりも考えていない方が多いし、それ思いつきじゃなのと思うような仕事を言い出すこともあるし。

それでも仕事を選びたいなら。

一つ目は、準備をしておきましょう。準備とはやりたい仕事にアサインされて成果を発揮できるようにということです。

二つ目は、どこにやりたい仕事があるか自分で情報を取りに行きましょう。待っていては実績のあるエンジニアが優先してアサインされますから。

三つ目は、こういった仕事をやりたいんだ、こういった仕事で貢献したいんだとアピールしましょう。

 

あとは今アサインされている仕事の中でやりたい仕事に必要な要素、スキルを見つけてレベル上げしておきましょう。それでもアサインが進まないなら社内転職や社外転職を考えましょう。

 

 

IT技術者の長寿と健康のために

IT技術者の長寿と健康のために

 

 

 

引き継ぎは過去の負債の可視化である

システム開発のプロジェクトでは工程の進度により知的作業>労働集約型の作業が逆転し、労働集約型の作業ボリュームが増えるため、局面でエンジニアを増減することが当たり前のように行われているのだけれど、よくよく考えてみれば労働集約型の作業なんてないんだよねぇ。型(パターン)でプログラムをいくらでも複製できるかといえばそんなことはできないのだから。なにせ、プログラムなんて一品モノだし。

とは言え、局面での作業ボリュームの増減はプロジェクト期間を縮めれば縮めるほど山の高さは高くなり歪な要員計画になるし、そんな要員計画を計画どおりに回せるのは神業か回っていることにしているだけのどちらかに違いないですよ。

プロジェクトの情報量

 なんて誰も意識しないだろうけれど、プロジェクトを着手する前から情報は生まれていて、プロジェクトが着手されると日々刻々と情報量が蓄積されていく性質を持っているのですが、それはプロジェクト開始時点でプロジェクトオーナが何を実現したいかプロジェクトチームに具体性を持ってオーダできていないからです。もしプロジェクトオーナが実現したい要件なり仕様なりをプロジェクト開始時点でプロジェクトチームに渡すことができればプロジェクトの情報量は開始時点で垂直に立ち上がり、以降は大きな方針転換がなければ微増するだけです。

情報の継承

 プロジェクトの情報量は開始前から時間の経過とともに増殖するのであれば、プロジェクト期間中の要員の増減でプロジェクトの情報量を増減するタイミングでスナップショット的に情報の移転を行いたいと考えたいですが、現実的にはできないのはご承知のとおりです。

幸いにプロジェクトのリポジトリが存在していたとしてもそのリポジトリが最新の状態で維持されていることはまずありえないですし、あったとしてもリポジトリに表現されていること以外の経緯なり判断基準はリポジトリ形式知としては記録されないからが一つの理由。もう一つはそれを記録したエンジニアの裁量で何を記録し、何をエンジニア自身の中に属人的な情報として留めるか依存するからです。

もうひとつ引き継げないこと

 があるんですよ。例えば、エンジニアが増えるときにプロジェクトのリポジトリがあったとしても伝える側のエンジニアの技術力は参画するエンジニアに渡すことができないです。当たり前ですが。

逆にワークロードが減る、つまり人員が工程の進度で減員する場合は各メンバに分散していた技術力が集約されるかと言えばやはり無理があるわけです。ITは極度に分業化が進みすぎたのでここのエンジニアの技術の専門性が違いすぎますし。

引き継ぎ資料を作るのは過去の負債

 よくあるのが引き継ぐから引き継ぎ資料を作ってスキトラしておいてというやつ。これめっちゃ無駄というかそのときになって初めて言語化される業務があるということです。今まで何やっていたんだ、と。

そうなんですよ、本来はプロジェクトの進捗の成果としてリポジトリなりで可視化されておけばよかったものを日常的にやらないから負債として積み上がっていっただけで。

だいたいそういったやっつけの引き継ぎの資料なんて書き手が思いついたことだけしか書かれないんですから当然トラップは仕込まれるわけです。書けといった方が間接的に仕込んでいるのが真相ですが。

 

 

結局、日々リポジトリなりなんなりに情報を突っ込んでおいて、引き継ぎなんて(技術は引き継げないから)無理だし、無駄が多いのでその分、道幅的な立ち上げ、立ち下げの期間をソフトランディングできるようにバッファ期間を確保しておくしかない(=オーバーヘッドが出て生産性なんてパーになる)ということを理解しておきましょうということです。はい。

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

 

エンジニアの仕事の5原則

エンジニアそれぞれの価値観で仕事をしていると思いますが、ワタシが仕事をする上で原則として考えていることに次のようなものがあります。記載する順番で優先順位が高いです。

 

プロフェッショナルとしてのイズム

プロフェッショナルとして一定の作業品質の仕事をすること。エンジニアとしてのこだわりではなく、プロとしてのイズムに沿っているかです。

遵法である

コンプライアンスを逸脱しないこと。レギュレーション違反で実現しても困るのはスポンサーですし。

スポンサーの実現したいことを実現

スポンサーであるお金を出すビジネスオーナが実現したいことを実現する。成果はエンジニアが実現したいことではありません。 

研鑽する

継続して技術、手法を研鑽すること。

身につけた技術、手法はそのとき課題解決できただけで同じやり方で新しい課題が解決できるかどうかはわかりません。 短期間で繰り返しリリースする要件を実現する要件がある場合、どのシステム開発手法が適切か判断できる知識を持っている必要があります。

プロセスをデザインする

 作業は再現できなければなりません。再現可能を実現するために作業プロセスをデザインすることが必要です。デザインした作業プロセスは検証し実現性を確かめなければなりません。

 

 

ワインバーグのシステム思考法  ソフトウェア文化を創る〈1〉

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉