プロジェクトの脆弱性診断はどうしたら実現できそう
ふとこれみて2つのことを思うわけです。1つは、ブコメにも書いたけれど発想が面白い。もう1つは、テストでバグを仕込んで検出率で品質を確認する手法です。
リクルートテクノロジーズ シニアセキュリティエンジニアの西村宗晃氏（にしむねあ氏）いわく「Ruby on Railsで頑張って書いた、脆弱性てんこもりのソーシャルメディアアプリケーション」。そこから半日かけてそのソースコードを修正し、どれだけ堅牢化できるかに取り組むユニークな勉強会が行われた。
そのあと、これプロジェクトそのものでやったらおもしろいなぁ、と。場面設定を考えるのがものすごく大変そうだけれど。
プロジェクトメンバ一人一人のペルソナ、プロジェクトのプロファイル、あとステークホルダーも必要だ。小さなチームにしても5人以上になりそうで面倒…とすでに作業イメージを想像して夏バテしそう。
ソフトウェアの脆弱性
脆弱性は通常、脆弱性のナレッジ（DBとかシグネチャとか）と照合して拒否したり、危ないよと教えてくれるわけです。ざっくりした物の言い方としては。
肝心なことは、ナレッジと照合する言語化された情報が存在するということです。もちろん、脆弱性のナレッジとして登録されている情報しか識別できませんけれど、それでも多くの脆弱性を可視化してくれます。可視化としたのは脆弱性もレベリングされていて、全部が全部対処する必要はないからです。
脆弱性診断ツールで可視化され、レベルが高（ヤバみがある）であれば直せ、でしょうし、中程度でも直させるでしょう。これも人が認識できるから次のアクションとしてコードを直そうと思うのです。可視化されなければ気づきもしませんし、直そうとも思いません。それにそのコードの脆弱性を突かれるとは思いもしないでしょうから。
プロジェクトの脆弱性は可視化できない
ソフトウェアの脆弱性は診断により可視化できるのは言語化されているからです。比較先があるから。一方、プロジェクトやチームについての脆弱性、つまり、プロジェクトのアウトプットに影響する仕組みのリスクファクターは可視化できないのでしょうか。
世の中に多くのプロジェクトが並行して存在し、組織の中にも多くのプロジェクトとプロジェクトチームが存在します。
プロジェクトがトラブって炎上させるより、脆弱性を可視化して定時で上がれるプロジェクト運営をしたいはずです。
ソフトウェアの脆弱性とプロジェクトの脆弱性の違い、差分は、脆弱性診断検査対象が言語化されているかどうかです。
言語化するためにどうしたら良いか。それはプロジェクトの世界観を可視化することです。
プロジェクト計画書があるからできるのではないか。そうなんですよね。本来はプロジェクト計画書でしたいのです。計画書とずれていることが脆弱性なのですから。
でもそれが実現できないのは、計画書からチームに展開されたとき言語化されていないことについては、チーム、メンバ一人ひとりに解釈と意思決定の基準が投げられ、そのまま可視化されずに結果しか得られないというところなんですよね。
多分それは、永遠に可視化されない…。リポジトリ、コミュニケーションをAIに食べさせてAI任せにしないと情報量過多と複雑で無理ゲーな気がします。
期待されていないSEがこっそり異能を手に入れるには
ハキハキ、アカルク、セッキョクテキニ、チョウジカンロウドウモイトワズ。こんなエンジニアがマネージャ受けしている組織では、同僚とでも必要以上に関わりたいくないとか、飲み会は極力避けたいとか、人前で発言するのは恥を描くかだけで大人しくしていたいとか思っているエンジニアは過ごしづらいです。
特に飲み会なんて業務以外何者でもないですよね。でも、自腹を切れとか意味わからない。役職上の勤めらしいのでそうですかと割り切ってますけど。
異能を手に入れよう
エンジニアにとって異能とは今持っていない能力です。
エンジニアで頭の良い人を見ていると、効率的でない仕事のやり方であっても自分の仕事をいかに省力化して楽をするかを考えて行動しています。頭は良くないし、積極性もそれほどないけれど楽をしてそこそこの仕事をしたい。だから、今持っていない異なる能力を身に付けたい。
そう思うことは正しい（正誤ではなく、生き延びるためにという意味合いで）のです。エンジニアとして仕事をし続けるなら。
本能に近い動機を持つ
異能を手に入れたいと思う動機は、本能的な動機に基づいたほうがいいです。なぜなら、本能がそれを要求し続けるから。食欲、性欲、睡眠欲。あとは富と名声。こうした本能に近いところの動機の方がいいです。
「○○をマスターしたい」
「なぜ○○をマスターしたいのだ」
「マスターして会社で貢献…」
「それは本心ではないな。自分に正直になれ」
「本当に…」
「マスターして活躍して認められたい」
「認められてどうなりたい」
「…稼いで課金したい」
「そうだ、それでいい」
いいかどうかは人それぞれですが、原動力となる動機は本能に近い方がいいです。
タイプ別異能の選び方
今持っていない能力は大別すれば次の能力に分けられます。
- 基礎的スキル
- 技術的スキル
基礎的スキルは生まれ持った性格や経験で習得した性質です。技術的スキルは方法論やそれを実践に適用する技術、あとは言語やツールの利用技術です。
さて、どっちを選べばいいのか。いや、どっちかにしないといけないのかという疑問もあるけれど、まず1つやってみましょう。二兎追うものは、です。
それでどちらを選ぶのか、ということです。
技術の習得の仕方を身に付けているなら、基礎的スキルを推します。技術の習得の仕方を身に付けていないなら、技術的スキルから。それも言語やツールの方から。
どうして技術の習得の仕方を身に付けていないエンジニアは言語やツールの方からを進めるかというと、言語でコーディングすれば動くオブジェクトが手に入れられるから、です。自分のPCでリターンを得るのが一番実感が湧くでしょう。
方法論は理解したことを検証するのは手間ですし（でもやらないと身につかない）、基礎的スキルは抽象的なテーマが多いので技術習得が身についていないとどうしようもないです。焦れずに、まずは基礎固めしましょう。レベル上げは大事なのです。
なお、異能を手に入れ発揮するとエンジニアのステージが変わったり、転生したりすることがあります。
20代エンジニアに足らないものと30代エンジニアに足らないもの
もう一生分のブクマとスターをいただいたのではないかって思うくらいにエントリを読んでいただいて大変ありがたいことです。セミ・エンジニアって多いいんだなーって思いました。（ニッコリ
さて、このブログ自体はワタシ的にはいくつかの目的を持って書き続けている（一番やりたかったことは実現できた）のですが、そこそこ長く連続で書いてはポストしていると、たまーにそこそこのアクセスがあることがあるくらいで、ほんとびっくりでした。
ご存知のとおりこのブログでは、エンジニア、システム開発、チームビルディング、育成とITの中でもコードでもフレームワークでもない、プロジェクトマネジメントに偏った感じのテーマを扱っています。
はてブがそこそこついたエントリの後のエントリ以降も同じようなものをかければいいのですがセミ・エンジニアネタも通勤の途中でいくつかの出来事が繋がったから書けたのでそうしたことがないと同じようにならないでしょうし、無理に繋げても面白いかといえばそんなことにならないところに物書きの面白さがあるんですよねぇ。
多分に2700超のエントリを見返せば車輪の再発明的なテーマを捉え直して書いていることが何度もあるし、途中まで書き続けて気づいてやめたとこも何度もあります。車輪の再発明的なエントリになったとしても歳によりテーマの捉え方も変わるし、経験をへて解釈も変わるし、切り口なんて一番変わるかもしれないです。
そいううこともあって、毎日書いていると書きたいテーマが見つけられればそれでいいやって感じです。こういったことはあまり考えても仕方がないし、タイムボックスの中で書くことで瞬発力を鍛えられるというか、老化しないように維持をするための管理プロセスのようなものなので。
20代エンジニアには時間が足らない
誰かに尋ねられれば、エンジニアであればこそ、確かに20代、30代で様々な挑戦をした方が良いと答えるでしょう。まあ、今のスタンスは直接的には言わないですが、メンバに対してなら去年よりスキルでもスキルレベルでもいいから向上してね、そうしたら花丸つけるよということにしています。
まあそれは、手段はOJTでもOFFJTでもいいから勉強して実践力を身につけて、ってことになんですけどね。
そうした言い分の半分は過去の自分への自戒が含まれていますけれど。色々考えていたらエンジニアは好きに育てばから頑張れと支援すると伴走していて気づいたら1周して元に戻って、エンジニアが成長するための挑戦を周りが押し付けるものどうかと思うようになりました。
今の20代、30代のエンジニアは学ばなければならない技術が多すぎるような気がしますし、それを学ぶためには時間が足らなすぎると思うのほどの情報があるのです。そこに思い至ったとき、そうしたことが若い世代のエンジニアは効率的に失敗のない選択を志向せざるをないのではないかと思うのです。だから、
「これ覚えて役に立ちますか」
なんて聞くんですよ。若いエンジニアも必死なんです。ワタシ達の年代のように時間がない。
そんな20代のエンジニアの挑戦とは技術の広さを知り、30代以降の自分の専門を見つけるための挑戦なのではないかと思うようになりました。
もちろん、お仕事で取り扱う技術を極めるのも一つの選択ですけれど、新人SEとして配属されて6年も大規模システムの維持管理（新規開発でも再構築でもない）にいたら、そこで学ぶ技術や担当する技術領域（アプリなのかインフラなのかなど）しか知らないのですから自分の持っている特性を活かしきれるかどうかの判別ができるわけがありません。そうした環境に慣れてしまうと実は自分の性質（生まれ持った性格や経験で習得した性質）とは合っていないお仕事をしているかもしれないのに気づくことさえできないんですね。
そうした性質とお仕事の適合性について考え至る様になったのは、ある場での議論を見守っていて参加者の発言をずっと聞いていたときの最後のまとめの意見を求められたときでした。その場でお話ししたことは、
「今アサインされているお仕事がエンジニアとして貢献できているかどうかは複数の技術領域を経験しないと自己評価できないのではないか。それを組織が恣意的にアサイメントし直し時期なのではないか」
というメッセージです。
30代エンジニアには露出が足らない
30代のエンジニアは20代で経験した範囲で自分のこれからの専門性を選び進みつつ、役割としてのロールをレベル上げに挑戦する時期だと思いってます。30代は、20代で覚えた仕事の終わらせ方、技術の習得の仕方を基礎に、技術スキルを伸ばす挑戦を続けることと仕事に対する取り組みなど定性的な基礎的スキルを開発するための挑戦する時期なのです。
特に基礎的スキルは、基礎的スキルは必要とされなかったり、騒ぎを起こして管理される側から管理する側にスイッチする場面展開の年代だと思います。スイッチしつつも、技術リーダとして、専門家としてもキャッチし続けなければならないので大変ですが最後の体力がある年代もあって一番仕事ができる体力を消費する年代でもあります。
でも、その先はそうはいかないのです。
だから、この30代で40代、50代、おぼろげに60代の定年までを考えてキャリアを自分で選ぶ年代でもあるのです。
だから、30代から人の前に立って仕事をしたほうがいいのです。やりきれば失敗ではありません。やりきれれば。それが難しいから人は躊躇するのですけれど。ただ、そこを乗り越えないと後の40代、50代の選択肢がガクッと減ってしまうのです。
人前に出るということは組織の看板を背負う（エンジニアは専門家なので新人からそうなのですけれど）ので自分の広告をしているとも見ることができます。そうした組織の外へいかに露出するかをこの30代で考え、対外的にプレゼンスを持てる活動したほうが良いです。
50代エンジニアになると睡眠する体力が足らないです。はい。
成功しているチームを分析すると金の卵もチームも失う
すっかりアジャイルもvsウォーターフォールから組織論に遷移しているので成熟度が上がってきたなとか、バズワードから実践に裾野が広がってきた感がありますね。
まあ、別にウォーターフォールは必ずしも失敗するシステム開発手法というわけでもなくて、プロジェクトに適したシステム開発手法を選び（ここ大事）、制約事項や前提条件を実現できるツールとテクニックを選定して、あとはチームのマインドセットをいかに維持するかチームの運営をすればいいのです。
すればね。
間違っていけないのは、プロジェクトの目的を達成するために適した手法や手段を選んでいるのか、というところです。そんなの単なる道具なのでチームが選択すれば良いです。
マネージャ、成功しているチームを見つける
どこの組織でも1つくらいは上手にチームを運営して、立てたプロジェクトの計画を無理、無駄なく遂行しているチームはあるものです（そう信じたい）。10人いたら1人か2人くらいは、そういう人がいるでしょうし（いて欲しい）。
システム開発もお仕事なので大変なのですが、大変なのと大変にさせられるのとは違います。大変なのだとしても、計画を立て、実績から見通しをつけ、先行きが想定できるようなプロジェクトの推進が出来ていれば頑張れます。
外野からあれこれ言われて大変にさせられるのは、自分の仕事じゃないのです。予めわかっている面倒ごと、組織の中のプロセスレビューや工程管理、コスト管理などのプロジェクトレビューは、そのプロジェクトが始まる前から認識しているので織りこめますが、それはあくまでもプロジェクトチームの対外的な外の話です。チームの中に介入されるのであれば話は違います。
得てして、成功しているチームは自分が関与していない上司に限って上に自慢をするのです。
PMO、成功しているチームを分析する
経営者まで自慢が届くと、経営者はそのチームが上手に出来ているなら組織の中に同じやり方を広めよう、と思いついたように指示します。
そりゃそうです。経営者の仕事は儲けるための仕事をするのですから。
そうするとPMOとか品質管理の部門や担当が出てきて成功しているチームにあれこれと聞き取りを始めます。
ただ、どうしてそれでそのチームが上手に運営出来ているのか理解できません。なぜなら、PMOや品質管理の部門は、そのチームのやり方とは違う（従来の）組織の価値観で行動を決定しているからです。
PMOや品質管理の部門は、理解できないので自分たちのメジャー（価値判断）を成功しているチームがなぜ上手に運営しているかを調べようとします。従来のプロセス、従来の価値観にそった情報提供を求めます。それは上手に運営しているチームには必要のないことです。
成功していたチーム、消滅する
上手に運営していたチームは本来やりたいプロジェクトの進捗を遮られ、よくわからない会議に呼ばれたり、何に使うかわからない資料を作成に時間を取られるようになります。
そのうち、嫌気のさしたメンバが1人抜け、2人抜けするようになります。そして…。
しなければならなかったのは、従来の価値観に基づく分析ではありません。成功しているチームが行動する際に何を行動の基準としていたかを知り、それに基づいた組織のプロセス設計をし直すことが一つ。
もう1つは、成功していたチームをマスターとして次のチームを育てることです。
新人SEが同じ場所で常駐を続けると蝉になる
4月入社の新人システムエンジニアも、春のうちに配属になったり、夏のこの時期から現場に配属になったりと、組織の教育制度によりバラバラでその辺りは新人SEをどこまで教育できるかという組織の体力や現場のリソース不足が如実に現れますね。それよりこうして配属時期を思うと、入社してすぐにSEとして認められるなんてある意味すごい業界なような気がしますね…。
新卒の学生が企業を選択するのも、企業が新卒を採用するのもどちらも博打な訳ですが言い方を変えればエンゲージメントなのですよね。合うのか合わないのかはそれぞれの体質みたいなものですから。
新人SE、常駐先に配属になる
ワタシもそうでしたが、新人教育というなのちょっとした教育期間後に、速攻で現場に常駐に出されるケースが多いです。現場の規模が大きければ大きいほど、顧客とSIerの双方の依存関係は深いですからワークロードの道幅も広く、業務も顧客よりエンジニアの方が詳しいことが多いです。
こうした先に常駐となると何が起きるかというと、出て来れない。もう、ずっと常駐先にいることになります。組織の仲間も多いですし、擬似的に自分の会社で働いているような気がしてくることもあるので居心地が良いことも多いです。
新人SE、業務に深く潜る
業務知識がある程度必要な業種だと、それを覚えることも必要ですが、役割が縦割りになってサイロ化するんですよね。機能的組織構造を取るので結果的にそうなるだけですけど。
一方、技術は次世代システム再構築とかアプリ化対応などのイベント的なプロジェクトにアサインされなければずっと維持管理ですから目新しいものがないわけです。
ずっと。
もう、1年なんてあっという間です。気づいたら6年くらいやっている。もうね、アブラゼミの幼虫です。ずっと同じ場所に潜っている。業務もその顧客の業務は詳しくなっているし、開発プロセスもその顧客のやり方に染まってしまっている。
というか、その顧客、そのプロジェクトのお作法で育っているので他を知らないのです。さらに技術は維持管理であれば更新がない、と。
常駐SE、外に出される
顧客と企業の関係よろしくずっと居続けられるかもしれませんし、次期システムを他社に取られてしまったら順次撤退ですからどこかで外に出されるかもしれません。
両社の関係よろしければ、自分から希望しなければずっと深く潜ったままかもしれません。それはそれで幸せなのかもしれませんが、6年もずっとやってきて会社の都合で外に出されたとき、新人SEとして配属されたエンジニアはどうなってしまうでしょうか。
常駐SE、外界の技術に置いてけぼりで7日で尽きる
アブラゼミが１週間で死んでしまうのは都市伝説らしいです（wikipedia）が、エンジニアは適応力がないとマジで技術力的に死んでしまいます。
なぜなら、ずっと常駐先で維持管理をしていて同じ技術、古くなったバージョンでしか仕事をしていなかったからです。
現実にはこんなことはないのでしょうけれど（適応力があるので）、学卒だったとしたら、6年経っていると28歳くらい。
それまで、常駐先で好奇心を持って自己研鑽していたり、自己研鑽していたことを使っていたような常駐エンジニアであれば、それこそ適応力でなんとかなりそうですけれど。
でも、積極的に、自主的に、技術を学ぶ人は少ないです。もちろん、大学まで行っているので勉強の仕方は知っているし、優秀なのでしょうけれど、日々続けられているかどうかは別な話です。
さて、あなたはエンジニアだと思っているかもしれませんが実はセミなのかもしれませんよ。
顧客に見せるパワーポイントでこれはやるなよなー
エンジニアがパワーポイントで資料を作る場面ってどんなのがあるだろうなんてどうでもいいことを思ったのは、パワポでの資料作りがワタシと比較して「こりゃひどい」と思ったことがなんどもあるので。
何も高度なことをしてね、ということじゃなくて、
このくらいは作りながらやっておこうよ＝見やすい品質を確保しようよ
と思うから。
フォントとフォントサイズを合わせる
これはやるなよなーの例。
- 同じ箇条書きなのにフォントが揃っていない
- フォントサイズが揃っていない
他にも色々あるけれど、これ割と多いですし、直すのもお手軽でいい感じになるので。
フォントやフォントサイズが揃っていない人はこんな直し方をしています。
文字に対してフォントやフォントサイズを設定しているんです。これではバラバラになってしまいます。
テキストではなく、テキストボックス（□がある枠）をつまんで枠でフォントやフォントサイズを指定します。
個人的には、箇条書きは資料を介して会話をする際に、何番目か指し辛いので項番で振る方が良いと思います。
まあ、スタイル使え、ってことです。
開始位置を揃える
前の例でもう一つこのくらいやっておいてよと思うのが、テキストボックスや図形の表示位置を揃えることです。
これも最初に配置するときに合わせていれば揃え直す必要がない作業です。下の図では、「引用 PMBOK5th」のテキストボックスがずれています。
普段であれば、わざわざ引用をテキストボックスを分けて書きませんが、テキストごとにテキストボックスを作って書く人が割といます。全部同じテキストボックスで書いた方が楽チンなんですよ。
見た目より内容だけど
些細なことで見た目が綺麗よりは資料の内容の方が大事です。でも、資料の用途によっては、シンメトリーであったり、揃っている方がより良い印象を与えます。
顧客で資料を読む高齢者の方が普段から気にかけていることが多いので、客受けするためにはちょっとしたことを資料を作るときから意識して織り込んでおくといいですよ。
